Failure on running linux containers on windows 10 (beta 31) #267
Comments
Ncage1974
changed the title
|
ping @simonferquel |
|
Same issue for me. I'm trying to run Docker in a Windows 10 VM in Parallels Desktop Pro. |
|
@Ncage1974 @tverboon we can't really support running Windows 10 in a VM and then run Docker for Windows on top as this requires nested virtualisation. Getting nested virtualisation right is very hard and we can't control nor check how you configured the VM nor what else is running on the physical host. Therefore I'm closing this issue. Having said that, we do use nested virt on top of ESXi for some of our testing, but also see intermittent failures due to it, which is another reason we can't support this. |
|
@rneugeba Thank you for clarifying and I understand that's not worth the effort if it's impossible to get it totally right in all situations and environments. That said, maybe you should consider removing or changing this blogpost: https://blog.docker.com/2016/04/containers-and-vms-together/ And I guess it could be more clear in: https://docs.docker.com/docker-for-windows/#what-to-know-before-you-install This information was making me hopeful and I bought the Pro license from Parallels to have virtualization enabled through nested virtualization. |
|
cc @londoncalling it might be worth adding a callout to that "what to know before you install" docs section that nested virtualization scenarios may work, but come with no guarantees. |
|
@tverboon thanks for the suggestion of improving the docs. As for the blog post it describes a different scenario.It uses a hypervisor to run different OSes which then then run native docker engines. In Docker for Windows you can run either Linux containers (which run in a Linux VM) or Hyper-V windows container (which also run in a VM), ie you need to be able to run a hypervisor on top of a hypervisor and this scenario is requires something called nested virtualisation. You seem to be running a Mac. If you want to work with Linux containers, Docker for Mac is a better approach. If you want to work with Windows containers on the Mac, then, for now i would suggest to install Windows 2016 Server and use the native Windows Container feature there. Unlike Hyper-V containers, the native Windows containers on Windows Server do not require nested virtualisation. See https://msdn.microsoft.com/en-us/virtualization/windowscontainers/about/index?f=255&MSPPError=-2147217396 for an explanation of the different container types on Windows. |
|
@rneugeba I see, thanks. It is our build server that we need to run on Windows, because code coverage with OpenCover doesn't work with .Net Core on the Mac and now we have a Docker build task. Maybe I could connect to the Docker Host running on the Mac and perform the docker build en docker push(?), but I guess I will configure a Mac mini and boot Windows native with Bootcamp. |
|
@friism , docs updated per PR 780 on docker.github.io. |
|
I have the same issue while not running inside a VM. My ID is: EF5B5C5D-8BE2-400B-B341-39C486F7F6C0/2016-12-06_19-28-48 |
|
Same for me.
|
|
@rneugeba Not sure if something has changed with Docker regarding this. But I am now running Parallels on my Late 2015 iMac instead of late 2009. The big difference of course is that my late 2015 iMac has the required hypervisor Intel goodies Intel VT-x feature set that includes Extended Page Tables (EPT) And docker is running on virtualized Windows in Parallels. Great! |
|
It is unfortunate that this issue is closed. I have a very specific reason to use Docker under Parallels with windows on my Mac.. I'm supporting others that "do windows", so for me, it's a process development and validation need. Parallels Pro purportedly support this, so not sure why it's failing. I've spent 2 last two days on and off updating, validating and basically doing everything I can think of to make this work, but it won't cooperate. |
|
@kutenai can you create and run a normal Linux Hyper-V VM inside your Windows parallels VM on your Mac? |
|
I've never tried. I'll have to google how to do that, but I'll give it a shot. |
|
Yes, I am able to boot a Hyper-V with an iso image, and it appears to be working as expected. |
|
@kutenai Which Mac are you running on? Could you run this command in Terminal and see if it returns 1: On my Late 2009 iMac it didn't work with Parallels 11 or Parallels 12 Pro, my Late 2015 iMac with Parallels 11 is working. I figured the big difference is the Intel processor. |
|
Tom,
Yes, it returns 1.
I am on an 2010 MacPro with dual quad-core Xeons. These are Westemere
processors and they do support the intel hardware virtualization, Virt-X
or whatever it's called.
… Tom Verboon ***@***.***>
January 25, 2017 at 11:53 PM
@kutenai <https://github.com/kutenai> Which Mac are you running on?
Could you run this command in Terminal and see if it returns 1:
|sysctl kern.hv_support|
On my Late 2009 iMac it didn't work with Parallels 11 or Parallels 12
Pro, my Late 2015 iMac with Parallels 11 is working. I figured the big
difference is the Intel processor.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#267 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABK4OQdaq24cMlLDG0Z8mkZ3VEZk7Ugiks5rWEMGgaJpZM4LAOK3>.
--
Sent from Postbox
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
|
|
Strange thing is that I don't have the Pro edition of Parallels 11. According to Parallels, it should not work. I bought 12 Pro for the old iMac, hoping it would work, but it didn't. I'm running Windows 10 Pro on Parallels 11 on MacOS Sierra. What is your exact configuration? |
|
I don't know how much detail you want, but here's a start.
Hardware: Mac Pro 2010, 8-core - dual 2.4Ghz Xeon CPU's. 32GB of Ram.
Core Operating System: latest version of OSX Sierra.
Parallels: Parallels Desktop 12 for Mac Pro Edition
Windows VM: Windows 10 Pro, 64bit, with all of the latest patches and
updates that the update utility reports.
Docker: Docker for Windows version 1.13. I've tried the release version
and the beta version, with the same results for both.
I was able to create a Hyper-V with Ubuntu 16 on the Windows VM, so at
least that works. I've tried a few settings on the windows VM as well,
and on the Parallels config, but nothing that looks relevant helps so far.
I uploaded a diagnostic, if this helps:
A diagnostic was uploaded with id:
1F7254AA-D866-4A06-976C-16D3EE5819FD/2017-01-26_12-51-32
… Tom Verboon ***@***.***>
January 26, 2017 at 12:41 PM
Strange thing is that I don't have the Pro edition of Parallels 11.
According to Parallels, it should not work. I bought 12 Pro for the
old iMac, hoping it would work, but it didn't. I'm running Windows 10
Pro on Parallels 11 on MacOS Sierra.
What is your exact configuration?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#267 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABK4OS95Urczm9dEmKKD3LHzCglpZ0eVks5rWPbygaJpZM4LAOK3>.
--
Sent from Postbox
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
|
|
Well we have the same setup for the most part. The most obvious differences are the underlying hardware and Parallels Desktop version. You could try to run a backup of your VM image on parallels desktop 11: http://www.parallels.com/directdownload/pd11/ Other than that I am out of ideas, because it's either something in Docker or Parallels or both. |
|
Docker for Windows should be able to run inside Windows 10 VM running on top of Parallels and or VMware on a Mac provided it the VM is properly configured, and even then it is possible that sometimes issues occur due to the way Parallels and VMware virtualise the Hardware. FWIW, I run Docker for Windows in a Windows VM on VMware Fusion on my Mac and we use Windows VMs on ESXi for testings. And in these environments we do see intermittent failures which are clearly attributable to the fact that we are using nested virtualisation. For these reasons we can't really support this configuration and it's really YMMV. It works for some and it doesn't work for others. As a general rule, though:
Typical failures we see with nested virtualisation:
CPU utilisation is also very likely to be higher... |
|
I have verified all of the items you mention above. I have 8GB and 4 CPU's assigned to the VM, and then 2 CPU's with 2GB assigned to Docker. I have nested virt. enabled, windows is up-to-date, etc.. I also have Westmere processors.. But, as you said, YMMV. I think my next step is to install a fresh copy of Windows 10.. since the one I'm using has a lot of cruft. Windows always did have a tendency to get crufty rather fast.. one of the (many) reasons to prefer OSX. Thanks for all of the advice and help. I can't thank you all enough, I very much appreciate your time in offering advice and support. |
|
@londoncalling yeah, that would be useful. Then I can just link to it if similar issues arise. |
|
@rneugeba cool, I will do it! |
|
Some more info in my testing. I have a similar setup and same error... Windows 10 Enterprise running on Parallels for Mac 12 Pro. macOS 12 on latest MacBook Pro 13". I can start Hyper-V and create a Linux VM fine and run it fine. The Moby VM, when the Docker agent starts it, uses 20-25% CPU and I never see it boot in the VM Console, Hyper-V just says "Connecting". Docker for Mac used to work, many months ago. This also had the same result on my older 2012 MacBook Pro. I wonder if this isn't a Docker thing specifically, but something with the Moby Alpine Kernel. Docker errors out because it can't connect to the VM, but the VM never boots. Hyper-V can't even get a Console connection to it. When trying to boot the latest Alpine Linux, it won't boot in this setup either unless I choose the Xen version of the iso, as documented by many here as an ongoing issue with Hyper-V https://bugs.alpinelinux.org/issues/1021 If I take the docker-provided mobylinux.iso and create a new VM with the exact settings (gen 2, disable secure boot, 2gb of ram, no dynamic ram) it exhibits the exact same issue, it starts to boot, never boots, and sits at 20% CPU. Any chance they are related? Any way to determine if the mobylinux.iso is same Kernel/Driver setup as one of the stock provided by Alpine Downloads? |
|
@BretFisher the MobyLinux VM is configured to not use the console, but the serial console, which the Docker for Windows application is monitoring (and the output should be in the logs). So you won't see anything in the Hyper-V manager console. You also can't just boot the ISO because the Linux inside is configured to contact some services on the host during boot. So, if the app is not running the services are not there and therefore the Linux VM boot does not complete. the mobylinux.iso does not use the same kernel as alpine linux. we use a recent 4.9.x kernel. I keep a patched kernel at https://github.com/rneugeba/linux-stable |
|
I'm working with VMware Workstation here, and I'm facing the same situation:
My Windows 10x64 VM is properly configured for virtualization, according to this Microsoft Wiki article:I'm working as a consultant, servicing different enterprises, each with their particular software setup. For professional use it's inevitable to utilize virtual machines to have a clean and safe development environment for each project/customer. Is this a matter of joining heads with VMware to get this problem solved? Or this is issue pertinent to Docker for Windows alone? |
|
@SetTrend I don't see how your issue is related to this GH Issue. You likely have a problem with Hyper-V running properly on your Windows 10 Pro machine. You should verify you can boot a working OS in Hyper-V before you start troubleshooting Docker. |
|
@BretFisher, why in detail do you feel that my Hyper-V installation isn't running properly when I'm reporting a Docker for Windows issue here? As you can see from the following animation, Hyper-V is running flawlessly from within my VMware virtual machine:
|
|
@SetTrend we had a lot of issues with nested virt. Our CI used to run very carefully configured and provisioned Windows VMs in order to test Docker for Windows. We had a lot of transient failures related to nested virt. Some of them are related to the fact that sometimes the Linux VM is stalled because of other activity on the physical host over which we have no control. We also have no visibility on how your windows VM is configured etc. Basically this means we can't really support this type of configuration. If it works, great...but if it fails we can't really diagnose it properly. Incidentally the error your are seeing may be related to #1995. We have a timeout to check if the VM is up and the error may happen if the timeout is exceeded (which happens often in nested virt scenarios). You could try the latest edge release where we have changed the timeout handling a little and it may help... |
|
Thank you for your reply.
That's in fact the basic nature of virtualization. Hypervisors define reality for the guest OS. There is no such thing like a punch-through up the hierarchy of hypervisors 'til you reach the real hardware. For example, if a hypervisor decides that time elapses in double time in the guest, then, for the guest, time elapses in double time - without it knowing or recognizing. Put in other words: A VM's reality is defined by the hypervisor. Any information you don't get from the hypervisor just isn't available. There is no fourth dimension or a fifth wall - not for any virtualized operating system. Einstein described it very well in his theory of relativity. If the hypervisor pauses a VM - time stands still in the VM. There is no reason for the VM to doubt that a time lapse didn't truely happen.
Given my above reasoning, that strategy seems inappropriate for checking whether a VM is up and running. Probably the time base you compare to should be taken from an alternative, VM robust source (e.g. (guest) OS ticks). So I propose you think of a new, safe alternative to check whether a VM is up and running. May I ask: How mission critical is this check anyway? Would you want to implement an expert option, a Boolean, in Docker for Windows settings, allowing the user to disable/bypass this check? |
|
hello |
|
+1 |
|
Same here. I am able to run Linux VMs in HyperV in the Cloud (e.g. nested virtualization), but when it comes to running Docker for Windows, it fails on MobyLinux checks. It's very opaque, and difficult to troubleshoot. Again, Windows users are second class citizens. |
|
@gillesdouaire I don't think you're being fair here. Nested virtualization is hard, and this issue is common on macOS as well. Some setups work, some don't. There are no favorites, just hard problems that everyone involved would love to fix if they had unlimited time and budget. What I can say works for me in December 2018 with 18.09 release using nested virtualization:
What does NOT work for me using nested virtualization:
|
|
@ DfW contributors/maintainers: Why don't you use WSL for Docker for Windows in favour of the proprietary MobyLinuxVM? The WSL Linux VMs run flawlessly, even in nested virtual environments. |
|
@BretFisher What I am saying is the issue is not with the nested virtualization alone. The issue is also with Docker interacting with the nested virtualization, and Docker team simply refuses to acknowledge that. Some people report timeouts during the MobyLinux VM setup in the nested virtualization context, so why not make that timeout adjustable? The Linuxkit yaml file used to build MobyLinux ISO refers to docker images that are set as private. What isn't that open to help people adjust the kernel version, etc? While Docker may still decide to refuse to officially support it, they could at least make it easier for their customer base to explore and solve it. Who knows, someone out there may finally find a more robust setup... That's why I am not happy with Docker on that topic. |
|
I created a suggestion at UserVoice to the WSL team: |
|
Sorry, but WSL is not a VM. WSL and the LinuxKit VM for Docker are not similar technologies. WSL does limited system call translations from Linux binaries to the Windows Kernel. It isn’t a complete replacement for the Linux Kernel and not recommend uses outside its scope: https://docs.microsoft.com/en-us/windows/wsl/faq#can-i-run-all-linux-apps-in-wsl |
|
Yes, you're absolutely right. But ...
Currently, from my point of view, there is no real reason for utilizing WSL. The benefits compared to installing a Linux VM reach zero. It's plain easier and more versatile to simply install/clone a Linux VM and enable file sharing. So WSL lacks a reason for existing. Joining DfW and WSL would support both projects: WSL would receive a bold reason for existing, and DfW would finally run Linux containers without flaw. And both would take a great leap towards integrating the Windows OS a bit more into current web development. My 2 cents. I might be wrong, though. |
|
Chipping in my two cents to agree that WSL would be a nice move - the first upgrade would be able to specify cross platform compatible pathing for volume mounting which is weird on windows at the moment ( |
|
Closed issues are locked after 30 days of inactivity. If you have found a problem that seems similar to this, please open a new issue. Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. |
I was eagerly awaiting Beta 31 because it fixed the following issue
#54
Unfortunately its more of the same. When i open up hyper-v i can see 'MobyLinuxVM' is constantly hogging about 25% of the CPU and restarting and doing it again and again until docker fails. The error message this time though is different:
Docker hv-sock proxy (vsudd) is not reachable
at Docker.Backend.ContainerEngine.Linux.ConnectToVsud(TaskCompletionSource`1 vmId)
at Docker.Backend.ContainerEngine.Linux.DoStart(Settings settings)
at Docker.Backend.ContainerEngine.Linux.Start(Settings settings)
at Docker.Core.Pipe.NamedPipeServer.<>c__DisplayClass8_0.b__0(Object[] parameters)
at Docker.Core.Pipe.NamedPipeServer.RunAction(String action, Object[] parameters)
I'm running docker inside VMware workstation 12.5.2 on top of windows 10 professional with virtualization enabled in the bios of the VM.
Please note that i was about to use the workaround in the previously listed issue to get things working.
Here is the log:
The text was updated successfully, but these errors were encountered: