Enable setting the dockerd exec-opt isolation=process on Windows 10 client version 1607 or greater

[ngbrown]

Now that Windows 10 Anniversary Edition has been released, Windows 10 client (such as Pro or Enterprise) can support docker run --isolation=process ...

In Windows 10, with the containers feature and Hyper-V feature configured to run, I got things setup and I could run in both hyperv and process isolation modes.

I regularly need to use VMware Workstation and cannot have Hyper-V turned on at the same time. Turning Hyper-V on or off requires rebooting. Very much not in the ethos of "quick".

I rebooted into Hyper-V off mode (through a bcdedit option) and can now run both VMware Workstation and docker run command, but I have to specify the isolation mode every time:

> docker run --isolation=process -it microsoft/nanoserver cmd

Setting the default options for dockerd are blocked from being changed to that default:

> dockerd.exe --exec-opt isolation=process
Error starting daemon: error setting default isolation mode: Windows client operating systems only support Hyper-V containers

Another good reason is that running Docker in process mode is quicker than running it an Hyper-V container mode. Even the second and subsequent times.

Proposal is that these lines in deamon_windows.go be modified to check for a minimum Windows client version, rather than blanket denying it:

        if containertypes.Isolation(val).IsProcess() {
            if system.IsWindowsClient() {
                return fmt.Errorf("Windows client operating systems only support Hyper-V containers")
            }
            daemon.defaultIsolation = containertypes.Isolation("process")
        }

@jhowardmsft, @mebersol, and @taylorb-microsoft were on merge #22774 that put this restriction into place.

[lowenna]

That was deliberate. Only Hyper-V containers are supported on client. Windows server containers only work in a supported way on Windows server, as the name suggests.

[ngbrown]

Sure, in May that made sense, when using --isolation=process caused an error. It doesn't cause an error now and it works better than using Hyper-V. Like I mentioned above, not everyone can use Hyper-V. Using process mode with shared kernels is the way that Docker was intended to be used in the first place.

Please reconsider the closure of this.

[lowenna]

Unfortunately it's not a technical debate - this is licensing and policy.

[ngbrown]

Ok. Thanks for being clear about that.

[seanturner83]

Unfortunately I think it is a technical debate. One of the benefits to developing applications that run in containers is that the developer environment behaves like production as much as possible. This violates this principle.

[thaJeztah]

@seanturner83 while I understand that having your dev environment match your production environment as close as possible is desirable, this is not a change we can make.

While we cannot prevent individual people from building their own binaries from source and enabling this feature, the binaries/packages that are shipped cannot have this feature enabled because the Microsoft license does not allow it.

If you feel strongly about this, please contact Microsoft and ask them to consider changing the license/policy, but unfortunately there's nothing that can be done here.

I'm locking this issue because discussing here won't resolve the issue, but happy to make the proposed change in the event the Microsoft license/policy changes in future

[thaJeztah]

This has been addressed on master through #38000