Feature Request: Swapable Virtualization backends

[raesene]

Expected behavior

Able to change the virtualization back end used by Docker for Windows to accomodate scenarios where the user already has a virtualization product installed.

Actual behavior

Docker for Windows requires Hyper-V which doesn't co-exist with other virtualization platforms for windows (e.g. Virtualbox, VMWare Workstation)

Information

It would be really nice if it was possible to swap out what virtualization backend is used by Docker for windows. There are likely a large number of potential users who already have a virtualization platform installed, and so can't install this, as in general virtualization platforms don't co-exist well on a given OS install.

Cute Animal Picture

[vlascik]

+1, this decision was just bad, forcing all docker users to convert all their VMs from vmware/vbox/android emulators/etc to hyper-v, because hyper-v disables other vm solutions...I mean, really?
You should make mobylinux.iso bootable in vmware&co. or provide a separate version that is bootable again, 1.11 worked great.

[friism]

Thanks for the feedback. We know that this is a serious limitation and we're thinking about how to improve.

The problem is that Docker for Mac and Windows are a lot more than scripts that setup Linux with Docker in a Hyper-V VM. They also:

• Manage networking to ensure that Docker works with VPN and proxies
• Ensure that host volume mounting into containers works reliably
• Manage seamless updates as new Docker versions are released

(We know there's still progress to be made on these things). To make most of these happen, we have to integrate tightly with a particular hypervisor and run additional services on the host.

If you're content with Toolbox and boot2docker and don't need improvements we're trying to introduce with Docker for Mac and Windows, we're still releasing those as new versions of Docker show up.

[vlascik]

Thanks, it's good to know Docker Toolbox will still be updated, I checked it earlier today and it was still on 1.11, I assumed it's dead, but it's on 1.12 now. Maybe it would be a good idea to mention somewhere on your site what docker's plans for the future of toolbox vs. docker for win/mac are, to avoid the confusion?
I suspect you won't support two similar solutions forever, but please have a plan B without the need for Hyper-V afterwards.

[rn]

I have to second @friism comments and add that integrating a different hyper-visor is likely an effort of one or two man years of engineering followed by the complexity of maintaining several versions. Furthermore, native Windows container in Windows 10 Pro (coming with RS1) also require Hyper-V so won't co-exist with other virtualisation solutions.

[k-dahl]

@rneugeba I wouldn't think they'd want to tightly couple native container functionality on Windows to the overall solution for managing docker on Windows anyways.

It wouldn't be as much of an issue if Hyper-V played nice with other VM solutions, but it doesn't - so anyone with an existing VM solution installed that is not Hyper-V simply can't use Docker for Windows.

Having used Hyper-V for Linux VMs on Windows, and being frustrated by the complete lack of support from MS, I'm thinking that this is going to end up being a big issue. I expect that most people would end up using VirtualBox or VMWare for Linux development on Windows, and are likely in the same boat.

[cweagans]

The problem is that Docker for Mac and Windows are a lot more than scripts that setup Linux with Docker in a Hyper-V VM. They also:

• Manage networking to ensure that Docker works with VPN and proxies
• Ensure that host volume mounting into containers works reliably
• Manage seamless updates as new Docker versions are released

It's almost like that problem has been solved already, specifically: networking, volume mounting, and updates. :)

In all seriousness, though, what about a degraded functionality mode that can be run when HyperV is not available - eg on Windows 10 Home.

[davidmyersdev]

native Windows container in Windows 10 Pro (coming with RS1) also require Hyper-V

@rneugeba I don't think this is the case. There is a clear distinction between Hyper-V containers and Native Windows Containers. Is Docker for Windows using Hyper-V containers (which are essentially just VMs still), or is it actually using Native Containers?

[rn]

@Drm2 I'm fairly certain that Windows 10 AE only supports Hyper-V containers. Native Windows Containers are a feature of Windows Server 2016

[davidmyersdev]

@rneugeba I apologize. You are correct, at the moment, but I believe the plan is to get native container support on Windows 10 eventually (hopefully sooner rather than later). I'm not saying another hypervisor software should be implemented (that would be no different than Docker Toolbox). I'm just saying that when native container support is available in Windows 10, it will be nice to not need Hyper-V enabled, and I hope that is part of the plan.

[cweagans]

@Drm2 That's not accurate. Native containers use the Windows kernel, which might be useful to some people, but the vast majority of people want to use the linux-based containers from hub.docker.com. Two separate things.

[friism]

@cweagans container images work the same way whether they're for Linux or Windows. Also note that Windows Server Containers (shared kernel) and Windows Hyper-V containers (lightweight Hyper-V VM per container) images are interchangeable, i.e. the same Windows Container image can be run in either mode.

Docker Hub can store, and already has, both Linux and Windows container images.

[cweagans]

@friism I understand. I'm pointing out that Docker for Windows is designed to run Linux images. AFAIK, Docker for Windows is just starting up a Linux VM using HyperV, running the Docker daemon in that VM, and handling any of the hoops you'd normally have to jump through in order to connect your local Docker client to that daemon and not one VM per container.

Where did you see that Windows Server Containers and HyperV containers are interchangeable? That sounds wrong, to be frank. If you're running a Linux container in HyperV, you can't just pick that container up and run it with the shared kernel functionality on Windows Server. It's not the same kernel.

[rn]

@cweagans maybe to clarify, there are Linux and Windows container images on the hub (as well as ARM images, etc). Linux containers can be run on Linux Container engine, which, with Docker for Windows are run inside a Linux VM on top of Hyper-V.

Windows container images can be run on two different types of Container engines, either as native Windows Server containers (where they run on the same kernel as the host, shared kernel) or as Windows Hyper-V containers, which utilises a lightweight windows VM on top of Hyper-V to execute the container. Note, the latter VM is a different VM to the Linux VM, Docker for Windows uses to run Linux container.

Admittedly, the terminology is a bit confusing...and the latest Docker for Windows Beta now also allows you to choose between running Linux containers and Windows containers.

[rn]

I'm closing this issue. While we understand the background for the request, qe currently have no concrete plans to offer other virtualization backends for Docker for Windows for the reasons outlined above. We continue having Toolbox and docker-machine updates for non-Hyper-V users.

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

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.
/lifecycle locked