Why does hypervisor remain enabled even when Hyper-V is disabled in Windows Features?

A customer found that even though they set the hypervisorlaunchtype to off in the boot configuration, and they unchecked Hyper-V in the Turn Windows features on or off dialog, they found that hypervisor was still enabled. As a result, Oracle VM VirtualBox Manager refuses to create a 64-bit guest.

Someone from the kernel team explained that the hypervisor might still be enabled in the UEFI, so that's one thing to check.

Another thing that will force the hypervisor on is Virtualization-Based Security, which goes by the acronym VBS. This is confusing because to most people VBS stands for VBScript.

Comments (11)
  1. IanBoyd says:

    It seems then that setting `hypervisorlaunchtype` to **off** is only a suggestion; and that a service can still launch the hypervisor.

    In this context, is *hypervisor* can be thought of a kind of service available to the OS itself? If you specify launch type off, will Hyper-V service later simply turn it in; making the hypervisor a sort of delayed-start feature?

    Or is it the case that Hyper-V service not function when `hypervisorluanchtype` was set to off at boot time?

    Or, if hypervisor and Hyper-V are two terms for the same thing – if one is running it means the other is running – can the hypervisor be disabled if the Hyper-V service startup is set to disabled?

    Is there a Channel 9 video that documents what hypervisor *is*, how it relates to Hyper-V, UEFI, and the hardware features?

    1. JAS says:

      The only time Channel 9 does anything deep anymore is when it plays upcoming features from whatever the latest C# version. The other videos are just super duper and vapid. Suspiciously plain on purpose like Corn Flakes.

    2. JDG says:

      Hyper-V is a fundamentally different way of running the OS. It cannot be turned on or off at runtime. Windows without Hyper-V runs directly, and its drivers have unfettered access to the hardware. If Hyper-V is enabled, though, then there *is* no host OS at all. Your main Windows instance is actually itself also a virtualized container. Windows does not have a Hyper-V Service, it has a Hyper-V *Management* Service. You are free to stop or disable this service, but doing so will have no effect on running VMs. It simply disables the conventional means of managing the VMs. When Hyper-V is turned on, the “real” host “OS” is Hyper-V itself, and *all* it does is host VMs. If something in your Windows boot config indicates that Hyper-V is required, then Windows isn’t actually the first thing to boot on system startup. Hyper-V initializes first, sets up a container for your main Windows instance, and then boots up Windows in that VM. It is in this way that Hyper-V (and similar systems such as VMWare eSXI) differ fundamentally from products like VirtualBox, VMWare Workstation and Virtual PC: the VMs are not just processes in a host OS, they are sitting alongside the primary OS, which is no longer a host per se, and which does not have any direct insight or control into the other VMs, except that granted to it by the hypervisor.

      As for terminology, a hypervisor is anything that manages the hosting and execution of virtual machines. VirtualBox is a hypervisor, and so is Hyper-V. They are fundamentally different technologies but both meet the definition of hypervisor.

  2. poizan42 says:

    In recent Windows Insider Previews will Windows Defender actually enable Hyper-V. The new Windows Hypervisor Platform API should fix the issues with virtualization being unable to other software such as VirtualBox – see also this discussion: https://github.com/Microsoft/WSL/issues/2850

  3. Antonio Rodríguez says:

    The problem here is not why a core OS component is enabled. IMHO, TRWTF is that a common piece of software from a major vendor requires a core OS component to be turned off in order to work correctly. 32-bit virtual machines are fine for testing and reproducing scenarios in user support; but that company is in the high-end enterprise server market, where 64-bit OSes are a must…

    Yes, I know VirtualBox maybe implements, as a virtual machine host, its own hypervisor which may clash with Hyper-V. But at least they should try to make it work with Hyper-V, even if it meant a “partial emulation” method with reduced performance, like the one used by early versions of VMWare (which ran user mode directly on the processor, but ran privileged mode inside an x86 emulator).

    1. poizan42 says:

      There have up until now been no way of “working with Hyper-V”. It’s all or nothing, once hyper-v is enabled virtualization becomes completely unavailable to all other applications.

      This is being fixed now with Windows Hypervisor Platform API: https://docs.microsoft.com/en-us/virtualization/api/hypervisor-platform/hypervisor-platform, but it’s still going to take some time before the major virtualization software supports it.

      1. John Elliott says:

        How very VCPI.

  4. cheong00 says:

    I’ll add that Edge’s “Windows Defender Application Guard” also uses hypervisor, so there’s one more thing to check.

    Not sure when it’ll go live though, and seems there’s neither follow-up post to address unanswered enquiries on that post, and no related news either.

  5. xp.client says:

    Also gets enabled when Docker for Windows is installed.

    1. Yukkuri says:

      Holy crap Xpclient is back

      1. Tanveer Badar says:

        I didn’t notice that when I read it on 30th.

Comments are closed.

Skip to main content