5 ms·

VMWare [0] will also support the Hypervisor Platform Api [1] allowing it to run besides WSL2 which uses Hyper-V. VirtualBox is still struggling and runs slow i

VMWare [0] will also support the Hypervisor Platform Api [1] allowing it to run besides WSL2 which uses Hyper-V. VirtualBox is still struggling and runs slow if at all with WSL2 and Hyper-V [2] This of course has implications on how you setup Docker on a Windows machine, each way having pros and cons. [0] https://blogs.vmware.com/workstation/2020/01/vmware-workstation-tech-preview-20h1.html https://blogs.vmware.com/workstation/2020/01/vmware-workstat... [1] https://docs.microsoft.com/en-us/virtualization/api/hypervisor-platform/hypervisor-platform https://docs.microsoft.com/en-us/virtualization/api/hypervis... [2] https://forums.virtualbox.org/viewtopic.php?p=473538 https://forums.virtualbox.org/viewtopic.php?p=473538

hu3 7y ago
Thanks. This information is important to me. I abbandoned WSL2 because it couldn't work along VMWare but the tide seems to have changed.
- TheRealPomax 7y ago
  Ever since Docker became a popular tech, VMware has had little choice: I need docker for my job, so I can't use VMware. That doesn't get them the dollars they want.
  - ElCapitanMarkla 7y ago
    I’ve been in the opposite boat for a while. I need virtual box so can’t use docker on windows but it seems that has changed since February so will give that a try
souprock 7y ago
This is a worrisome development. We seem to be heading toward a future where hypervisor drivers can only be provided by Microsoft, and you're out of luck if they don't do the job. Hypervisors that need more capability are going to have to do some crazy stuff to stay compatible. One option is to save and restore the whole hypervisor state whenever it runs. Another option is to be some sort of boot loader, seizing the hypervisor capability before Windows can get to it. That'll be some tough code to debug.
- pjmlp 7y ago
  One day all OSes will be z/OS it seems, that alongside JIT/AOT runtimes, mainstream computing is finally catching up with 60's mainframes.
- saagarjha 7y ago
  Why, because of secure boot?
- zamadatix 7y ago
  Type 2 hypervisors are going to be in an interesting state. The Windows bootloader already has a flag you can easily toggle (without removing the Hyper-V role or config) but the problem is more features are starting to depend on Hyper-V being there one layer up (it's a type 1 hypervisor). I'm surprised nested virtualization can't be used for the type 2 hypervisor since Hyper-V picked this feature up a few years back and it seems like that would have solved all of the problems.
  - souprock 7y ago
    Nested virtualization only works when the outer hypervisor supports all the features that the inner hypervisor needs. If the outer hypervisor is Hyper-V, then that limits the inner hypervisor to the features that Hyper-V bothered to implement. In other words, you can't implement a hypervisor more advanced than Hyper-V. If you instead want to be on the outside, with Hyper-V on the inside, then you can't just write a driver. You have to implement a boot loader. You also have to implement nested virtualization, even if you otherwise had no need to do so.
    - zamadatix 7y ago
      Hyper-V is able to nest ESXi and KVM (and Hyper-V of course) and vice versa ESXi and KVM are able to nest Hyper-V. I'm not sure what would be limited. Yeah that's the difference between a type 1 and type 2 hypervisor. A type 1 runs on the bare metal, a type 2 runs via drivers underneath an existing OS. Since Hyper-V is a type 1 (like ESXi) you can't use a type 2 hypervisor on the root VM to escape being under Hyper-V you either have to do some sort of nesting or disable Hyper-V from loading and reboot.

hu3 7y ago

Thanks. This information is important to me. I abbandoned WSL2 because it couldn't work along VMWare but the tide seems to have changed.

TheRealPomax 7y ago
Ever since Docker became a popular tech, VMware has had little choice: I need docker for my job, so I can't use VMware. That doesn't get them the dollars they want.
- ElCapitanMarkla 7y ago
  I’ve been in the opposite boat for a while. I need virtual box so can’t use docker on windows but it seems that has changed since February so will give that a try

souprock 7y ago

This is a worrisome development. We seem to be heading toward a future where hypervisor drivers can only be provided by Microsoft, and you're out of luck if they don't do the job. Hypervisors that need more capability are going to have to do some crazy stuff to stay compatible. One option is to save and restore the whole hypervisor state whenever it runs. Another option is to be some sort of boot loader, seizing the hypervisor capability before Windows can get to it. That'll be some tough code to debug.

pjmlp 7y ago
One day all OSes will be z/OS it seems, that alongside JIT/AOT runtimes, mainstream computing is finally catching up with 60's mainframes.
saagarjha 7y ago
Why, because of secure boot?
zamadatix 7y ago
Type 2 hypervisors are going to be in an interesting state. The Windows bootloader already has a flag you can easily toggle (without removing the Hyper-V role or config) but the problem is more features are starting to depend on Hyper-V being there one layer up (it's a type 1 hypervisor). I'm surprised nested virtualization can't be used for the type 2 hypervisor since Hyper-V picked this feature up a few years back and it seems like that would have solved all of the problems.
- souprock 7y ago
  Nested virtualization only works when the outer hypervisor supports all the features that the inner hypervisor needs. If the outer hypervisor is Hyper-V, then that limits the inner hypervisor to the features that Hyper-V bothered to implement. In other words, you can't implement a hypervisor more advanced than Hyper-V. If you instead want to be on the outside, with Hyper-V on the inside, then you can't just write a driver. You have to implement a boot loader. You also have to implement nested virtualization, even if you otherwise had no need to do so.
  - zamadatix 7y ago
    Hyper-V is able to nest ESXi and KVM (and Hyper-V of course) and vice versa ESXi and KVM are able to nest Hyper-V. I'm not sure what would be limited. Yeah that's the difference between a type 1 and type 2 hypervisor. A type 1 runs on the bare metal, a type 2 runs via drivers underneath an existing OS. Since Hyper-V is a type 1 (like ESXi) you can't use a type 2 hypervisor on the root VM to escape being under Hyper-V you either have to do some sort of nesting or disable Hyper-V from loading and reboot.