Tag Archives: docker

Can You Run Oracle’s VirtualBox on a Windows System with Microsoft’s Hyper-V enabled?

Every year or two I try running VirtualBox on a system with Hyper-V enabled and it goes poorly. Recently there was some hope that VB would run alongside Hyper-V…and I actually had this working for a split second. But when I updated to the latest Windows build it broke again.

Figured I’d share what I’ve learned here. Right now the information seems to be scattered around the web and it can take a while to follow the threads and figure out what the current status really is.

If you aren’t familiar with why VirtualBox (and other hypervisors) can’t run on a system with Hyper-V enabled check out this SuperUser Q&A.

The confusion is largely driven by VirtualBox’s own documentation which states: “Oracle VM VirtualBox can be used on a Windows host where Hyper-V is running.”

This did work on Windows 10 1809 but then was broken by Windows 10 1903 (the next release). For more details see this post over on the VirtualBox forums.

Currently there are only two ways to run VB and Hyper-V on the same machine – and they aren’t running simultaneously. One is to add/remove Hyper-V every time one wants to use VirtualBox and the other is to edit one’s boot records using BCDEdit, which requires a restart every time you make the switch. There is a free utility available that automates this process, but it still involves a reboot (I haven’t tried the utility yet).

If you are wondering why one would even want to run the two simultaneously there are at least two good reasons I know of: (1) WSL 2 requires Hyper-V and (2) Docker’s future on Windows involves utilizing WSL 2 and thus Hyper-V.

Note: I personally don’t use VMWare these days (have in the past) so this article focuses on VirtualBox and Hyper-V’s interactions but the problem holds true for VMWare as well.

If anyone hears of any new developments regarding this topic, I’d love to hear about them!

A Few Hints For Getting Portainer Running on Windows

Portainer is a GUI mean to make managing Docker easier. By default Docker is managed using mainly CLI tools and while this is all grand it can be a bit much for those who just need quick access for simple purposes.

I recently attempted to setup Portainer on my local Windows 10 Enterprise Edition PC using the basic installation instructions. I opened up PowerShell and ran:

docker volume create portainer_data
docker run -d -p 8000:8000 -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

And of course that didn’t work. Instead I was shown this error message:

C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: pull access denied to portainer/portainer, repository does not exist or may required 'docker login': denied: requested access to the resource is denied. See 'C:\Program Files\Docker\Docker\Resources\bin\docker.exe run --help'.

I tried authenticating without issue to Docker using docker login as recommended in above error. I reran the initial command again but received the same error. I decided to try pulling down the portainer image to my local machine without any attempt to run it:

docker pull portainer/portainer

Shouldn’t work right? It did! Now I rerun the initial command but Docker is still telling me it is “Unable to find image ‘portainer/portainer:latest’ locally”. It is at this point that I notice the Note in the installation documentation:

Note: the -v /var/run/docker.sock:/var/run/docker.sock option can be used in Linux environments only.

Oops. Okay, so how do I get Portainer running on Windows? Unfortunately the next instructions are for setting up Portainer on a Windows Docker Host running Windows Containers – but I’m trying to run Linux Containers on a Windows Docker Container. Still, I get a hint:

$ docker volume create portainer_data 
$ docker run -d -p 8000:8000 -p 9000:9000 --name portainer --restart always -v \\.\pipe\docker_engine:\\.\pipe\docker_engine -v portainer_data:C:\data portainer/portainer 

Note in the above the highlighted portion. Here we see that portainer_data has been specified using a Windows rather than *nix path as in our original command. So I swap this Windows path into my original command (forgetting, btw, to change out the -v /var/run/docker.sock…):

docker run -d -p 8000:8000 -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v C:\ProgramData\Portainer:/data portainer/portainer

Now I’m getting another error…

C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: Mount denied: The source path "C:/ProgramData/Portainer" doesn't exist and is not known to Docker..."

Some Googling done I stumble upon Issue #2575 on GitHub for the portainer repository. And then Manuel Patrone’s question on the Docker Forums. Based on this my understanding is that the issue is two fold:

  1. When we use a *nix path when setting up the data location for Portainer it becomes a local path within the Docker VM on Windows (but theoretically fixed this by changing the path to a Windows path above)
  2. For some reason Docker/Portainer attempt to save the Docker image to C:\ProgramData\Portainer where no such folder exists and Windows isn’t too happy to create one.

So I make one last change to my command:

docker run -d -p 9000:9000 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v C:\Portainer:/data portainer/portainer

And it works beautifully. I’m able to launch Portainer, setup my admin password, and begin navigating around the UI. You’ll note in the above that I set the path as C:\Portainer instead of inside C:\ProgramData. This path could be anywhere, but I figured setting it outside of ProgramData might save me some pain in the future (or not).

You may also note that my command is still technically incorrect. According to the Portainer documentation I should have replaced /var/run/docker.sock:/var/run/docker.sock with \\.\pipe\docker_engine:\\.\pipe\docker_engine – since the former only runs on Linux according to the Portainer documentation.

Why is this working? I don’t know. Maybe I’ll go back and rerun it later using the correct path, but it is worth noting that the pipe path used is only available in 1803+ versions of Windows, so if you have something before that you’ll need to (1) upgrade (I would), (2) use the Linux command as I did above, or (3) find some other command that works pre-1803.

I hope this rambling journey helps others who may find themselves running into the same issue.