I actually ditched Docker on Windows with the tight entanglement with Hyper-V. I need access to multiple VM environments and Hyper-V locks you down preventing usage of VMWare and VirtualBox. Moved to docker in Linux VM.
https://www.virtualbox.org/wiki/Changelog-6.0
https://blogs.vmware.com/workstation/2020/01/vmware-workstat...
I haven't noticed any performance issues with Hyper-V (when Hyper-V is enabled, even the Windows OS is running within Hyper-V). Does something with the Windows Hypervisor Platform that is used to support other VM hosts running on top of Hyper-V introduce some type of performance hit?
Unlike hyper-V itself, where some VM exits that return to the host are implemented (for speed reasons) in kernel drivers using undocumented APIs, the supported Windows Hypervisor Platform API is 100% userspace. (Unless this has changed since the last time i looked into this, which was admittedly a fair while back.)
That means that literally every time an instruction is run that needs custom software backing, you not only get the VM-Exit to the hypervisor and then the VM Enter back to the Host (DOM-0) kernel, but also a kernel mode to user mode transition. Then you may well need to query some things in order to know how to handle them which may incur more round trips to the windows kernel.
That all is bad enough that virtualbox wrote a kernel driver that makes undocumented calls from in kernel mode in order to handle certain operations fast enough to be tolerable when doing things like running Windows 95.
The virtualization software is limited to supporting any scenarios that Microsoft decided to support, driven mostly by the needs of the Hyper-V experience. Windows Hypervisor Platform users do not get to directly set the vm control values, so any values in them that Microsoft does not offer some API to set are limited to whatever values Microsoft chose for Hyper-V.
This can make certain things literally impossible, or require really nasty work around that have significant performance impact.
Certain simple VM exit scenarios will get handled directly by the Hypervisor without involving the host OS. If the default behavior is not good enough, there might be an option provided to handle them by re-entering the host OS, but obviously that is much slower.
> Added support for using Hyper-V as the fallback execution core on Windows host, to avoid inability to run VMs at the price of reduced performance
I'll admit to not understanding docker. Is it a VM replacement, or is it a glorified debian package?