I've heard WSL2 is different and better than WSL1. However, you say WSL2 is backed by Hyper-V. Which leads me to a very important question: does enabling WSL2 (which now supposedly uses Hyper-V) have the same problem that previously enabling Hyper-V had; namely that all other virtualisation software is incompatible?
At my day job, my company hasn't yet released the version of Windows that provides WSL2 (IIRC Microsoft released that in June, and my company takes ~12 months to validate and push out new versions of Windows). Many developers have tried to get away with using Docker for Desktop on Windows, which requires the direct use of Hyper-V unless your version of Windows supports WSL2, in which case Docker for Desktop will use that instead of Hyper-V.
Our problem is we have some legacy non-Dockerized apps that require the use of vagrant and VirtualBox (we've failed trying to use vagrant and Hyper-V due to lack of boxes), and VirtualBox is 100% incompatible with Hyper-V. VirtualBox has long "supposedly" been able to function alongside/with Hyper-V, but we have not had a single employee encounter success, out of at least a dozen who have tried. To the point where just disabling Hyper-V from Windows' Optional Features isn't enough to get VirtualBox to work again; it took some searching to discover that you additionally have to prevent the virtualisation stack from even being loaded at boot by running "bcdedit /set hypervisorlaunchtype off" as Administrator.
All we want is Docker to run natively on desktop; and yet, we also need to run VirtualBox VM's side-by-side. Because of work-from-home, some employees are "getting away" with running work-related stacks on their personal macOS or Linux machines, which of course have no such limitations. You can run Docker for Desktop and VirtualBox side-by-side on macOS with zero compatibility problems (and you can use NFS for mounts too instead of the buggy and slow-ass vboxfs or cifs/samba). Proving that Windows is, once again, the outsider and shit operating system that can't even do virtualisation properly (seriously, the "exclusive use of virtualisation" that Hyper-V requires is a fucking joke). We have to run vagrant on each developer's machine for the sole purpose of running a Docker daemon within it, or use shared hosting for a hundred developers on a single VM with only a dozen CPU cores, backed by slow network storage instead of SSDs, because that's what a company with multi-million dollar revenues, and thousands of employees, is willing to provide.
End of rant. I did have a question initially, which is this: does installing and using WSL2 break other virtualisation layers (VirtualBox and friends) in the same way that enabling Hyper-V to use Docker for Desktop broke such software prior to WSL2 support?
Yes WSL2 uses Hyper-V so you'll have the same problems. Hyper-V is a type-1 hypervisor, meaning it runs at the hardware level with exclusive access to the CPU virtualization extensions. When enabled it runs Windows itself as a VM which is why it requires a reboot to disable.
VirtualBox is a type-2 hypervisor running on the guest/Windows OS but can't access the CPU extensions since Hyper-V has already acquired them. Running Linux containers on Windows (using Docker or otherwise) always involved Hyper-V, just with different hosts from LinuxKit to WSL2. Docker on Mac OS uses hyperkit which seems to also be a type-2 hypervisor which doesn't conflict with VirtualBox (and in fact the docs state that Docker on MacOS uses VirtualBox drivers to create VMs).
VirtualBox 6.0 is supposed to detect and use the Hyper-V API as well as support nested virtualization but its still experimental. Also I believe you can run 32-bit VirtualBox while Hyper-V is enabled, have you tried that?
I think you're in a tough position and the best solution is probably to make the business case in either upgrading away from Vagrant/VB to Docker or getting some proper standalone Vagrant servers to develop with.
Thank you so much for the reply; it at least helps me understand why things are the way they are. VirtualBox's own docs have said since some 5.x version that it's compatible alongside Hyper-V. However, we've had developers on the latest 5.x as well as 6.x of VirtualBox, and the bugs that appear are out-of-this-world impossible to debug. Basically, running VirtualBox with Hyper-V enabled on a Windows host will appear to work at first, but you'll very quickly run into some random weird bug (often related to networking) that cannot even be Googled because it's a unique one-time error that seems to occur purely because of which cpu instruction was being executed during a particular nanosecond.
So even WSL2 will not help us, unless we can migrate all VirtualBox boxes to Docker or native Hyper-V. Sigh. Fuck companies who produce software purely for Linux servers, who force their developers to work on Windows machines because of ActiveDirectory, and their relationship with kissing Dell's ass for hardware I could piece together from a garbage dump.
I can't speak for VirtualBox but I can confirm that VMware Player/Workstation do support Hyper-V now and are compatible with having WSL 2 installed simultaneously.
This information probably doesn't help you much if you're tied to VirtualBox though.
At my day job, my company hasn't yet released the version of Windows that provides WSL2 (IIRC Microsoft released that in June, and my company takes ~12 months to validate and push out new versions of Windows). Many developers have tried to get away with using Docker for Desktop on Windows, which requires the direct use of Hyper-V unless your version of Windows supports WSL2, in which case Docker for Desktop will use that instead of Hyper-V.
Our problem is we have some legacy non-Dockerized apps that require the use of vagrant and VirtualBox (we've failed trying to use vagrant and Hyper-V due to lack of boxes), and VirtualBox is 100% incompatible with Hyper-V. VirtualBox has long "supposedly" been able to function alongside/with Hyper-V, but we have not had a single employee encounter success, out of at least a dozen who have tried. To the point where just disabling Hyper-V from Windows' Optional Features isn't enough to get VirtualBox to work again; it took some searching to discover that you additionally have to prevent the virtualisation stack from even being loaded at boot by running "bcdedit /set hypervisorlaunchtype off" as Administrator.
All we want is Docker to run natively on desktop; and yet, we also need to run VirtualBox VM's side-by-side. Because of work-from-home, some employees are "getting away" with running work-related stacks on their personal macOS or Linux machines, which of course have no such limitations. You can run Docker for Desktop and VirtualBox side-by-side on macOS with zero compatibility problems (and you can use NFS for mounts too instead of the buggy and slow-ass vboxfs or cifs/samba). Proving that Windows is, once again, the outsider and shit operating system that can't even do virtualisation properly (seriously, the "exclusive use of virtualisation" that Hyper-V requires is a fucking joke). We have to run vagrant on each developer's machine for the sole purpose of running a Docker daemon within it, or use shared hosting for a hundred developers on a single VM with only a dozen CPU cores, backed by slow network storage instead of SSDs, because that's what a company with multi-million dollar revenues, and thousands of employees, is willing to provide.
End of rant. I did have a question initially, which is this: does installing and using WSL2 break other virtualisation layers (VirtualBox and friends) in the same way that enabling Hyper-V to use Docker for Desktop broke such software prior to WSL2 support?