The use case is mainly interoperability with VirtualBox; they can still keep thier own disk/vm formats, guest tools, etc. and use HyperV as the 'virtualization engine'. Users that have workflows that call out to VirtualBox can continue to work; a lot of vm image tools (vagrant, packer) continue to work, etc.
But yes, of course you can also change your tools to use HyperV directly.
"Having to use HyperV" is not actually anything nefarious as the other comment seems to imply. You can't have two type 1 hypervisors running cooperatively on the bare metal and you cant implement your type 2 hypervisor hooks if you have a type 1 hypervisor running. So if you have enabled HyperV directly or indirectly by using WSL2 or installing any of the container runtime platforms (Docker Desktop et al) that use it, then you have to use HyperV as your hypervisor.
Note this is different than nested virtualization (ESXi on HyperV, etc.) which is supported but a completely different beast.
For the same reason you cannot run Xen and KVM VM's simultaneously on Linux (excepting nested virtualization).
> "Having to use HyperV" is not actually anything nefarious as the other comment seems to imply. You can't have two type 1 hypervisors running cooperatively on the bare metal and you cant implement your type 2 hypervisor hooks if you have a type 1 hypervisor running.
The nefarious part is that Windows enables Hyper-V even if you don't actually use Hyper-V VMs and never will. KVM doesn't take exclusive control of VMX until you _actually_ run a KVM VM.
By the way, the distinction between type 1 / 2 is purely academic at this point: there is no definition where KVM is a type 1 hypervisor and VirtualBox isn't, as they are _literally_ the same conceptually-wise: both are a kernel module that implements a VMX manager/root. Same on Windows. The only remaining type 2 hypervisor these days is kqemu which can still work in binary translation mode (and therefore can work even without access to VMX).
> The nefarious part is that Windows enables Hyper-V even if you don't actually use Hyper-V VMs and never will.
It does not actually enable it by default but there are many settings or apps that can cause it to become enabled. Virtualization-based-security, WSL, container tools, etc. Providing a hypervisor and related functionality is part of what a modern OS kernel should do! It's not nefarious!
But yes, of course you can also change your tools to use HyperV directly.
"Having to use HyperV" is not actually anything nefarious as the other comment seems to imply. You can't have two type 1 hypervisors running cooperatively on the bare metal and you cant implement your type 2 hypervisor hooks if you have a type 1 hypervisor running. So if you have enabled HyperV directly or indirectly by using WSL2 or installing any of the container runtime platforms (Docker Desktop et al) that use it, then you have to use HyperV as your hypervisor.
Note this is different than nested virtualization (ESXi on HyperV, etc.) which is supported but a completely different beast.
For the same reason you cannot run Xen and KVM VM's simultaneously on Linux (excepting nested virtualization).