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

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.