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.
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.
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.
Heh, it's funny that I'm actually a hypervisor developer and I don't use that terminology. The whole team doesn't. I actually had to look up "type 1" and "type 2" to remind myself which was which. Those are terribly non-descriptive. Our terminology is "bare metal" or "OS" or "boot loader", and "VMX driver". Anyway...
Our hypervisor is far more demanding than ESXi, KVM, and Hyper-V. It needs to interact with low-level Intel processor details in a way that is not supported by any other hypervisor. It won't run correctly if nested inside any other hypervisor. If we supported running under another hypervisor, we would lose important functionality.
If it becomes impossible or impractical to disable Hyper-V, we'll need to do something strange and annoying. Perhaps we could load the driver very early in boot, before Hyper-V loads. Booting as an OS ("type 1", ugh) is an option too, but maintaining that and using it is a real pain. Probably we'd drop Windows host support before we did that.
