>Hyper-V is a Type 1 hypervisor, not a Type 2 hypervisor_

Hyper-V comes bundled with Windows. You can enable it via the Windows Features panel, configure it using a graphical interface, and keep the same desktop. Most technicians instinctively classify it as a type 2 hypervisor, on a par with VirtualBox or VMware Workstation. This is a mistake. As soon as the box is ticked, Windows is no longer in control of your machine.

Reconfiguring hardware layers using Hyper-V

On a PC without Hyper-V, Windows communicates directly with the processor, memory and peripherals via its drivers. This is the traditional architecture, with the hardware at the bottom and the OS just above it.

When you tick the Hyper-V box and restart, this architecture switches over. Hyper-V sits between the hardware and everything else. Windows no longer communicates directly with the processor; instead, it goes through the hypervisor, just like any other virtual machine. The only difference is that it is granted special privileges to continue providing drivers and managing the child VMs. This is known as the parent partition (or root partition).

How does Windows work without Hyper-V?

Apps (Chrome, games, Office, etc.)
      │
      ▼
Windows OS  ────────  Ring 0 — direct communication with the hardware
      │
      ▼
Physical hardware  (CPU · RAM · Disk · Network)

The Windows architecture with Hyper-V enabled

Windows applications
      │
      ▼
Parent partition — Windows OS  ──  Virtual Ring 0 · drivers via VMbus
      │              ┌──────────────────────────┐
      │              │  Child VM 1  (FreeBSD)  │
      │              │  Child VM 2  (pfSense)  │
      │              └──────────────────────────┘
      │  hypercalls
      ▼
Hyper-V  ───────────────────────  Ring −1 (VMX root) — actual control
      │  VT-x / AMD-V required
      ▼
Physical hardware  (CPU · RAM · Disk · Network)

Why is Hyper-V a Type 1 hypervisor rather than a Type 2 one?

The distinction between Type 1 and Type 2 comes down to a single factor: who controls the hardware at Ring 0 or below?

Intel (VT-x) and AMD (AMD-V) processors have introduced a privilege level even lower than the standard ring 0 (ring −1 or VMX root mode). Only the hypervisor can run at this level. Guest operating systems, even Windows with its parent partition privileges, run in virtual ring 0, i.e. ring 0 emulated by the hypervisor.

Hyper-V runs in ring -1 from boot-up. VMware ESXi does too. VirtualBox and VMware Workstation do not. They rely on Windows or Linux to access the hardware, which classifies them as type 2.

The VMbus: the proprietary channel between Windows and Hyper-V

The parent partition no longer communicates directly with the physical hardware as it did before. Instead, it uses the VMbus, a proprietary Microsoft virtual bus that connects the parent partition to the child partitions and the hypervisor. In practice, when a child VM needs to access the network or a disk, it sends a request via the VMbus to the parent partition, which has the actual drivers. The parent partition responds and returns the data.

It is this mechanism that explains why Hyper-V does not need its own drivers for each piece of hardware. It delegates this task to Windows (the parent partition), which is familiar with the hardware. It is a hybrid architecture, but actual control of the hardware remains with the hypervisor.

Is Hyper-V being enabled without your knowledge in Windows 11?

Many users find that Hyper-V is running on their machine without them ever having enabled it manually. VBS (Virtualisation-Based Security) and Credential Guard, two security features enabled by default on Windows 11 Pro and Enterprise editions, rely on Hyper-V to isolate critical memory areas.

If you have VBS enabled, Hyper-V runs in ring −1 on your machine even if you don’t create any VMs. Windows is already a parent partition. This is also why VirtualBox and VMware Workstation suffer from performance issues or refuse to start certain VMs on these configurations. They cannot access ring 0 as Hyper-V has already taken it.

To check whether Hyper-V is running on your machine, open a Command Prompt as an administrator and type.

systeminfo | findstr /i "hyper-v"

If the message ‘Hyper-V requirements: a hypervisor has been detected’ appears, Hyper-V is already running on your system.

A comparison with ESXi, Proxmox and KVM

VMware ESXi is installed on a bare-metal server with no pre-existing operating system. Its management interface can be accessed via a web browser from another computer. It is a pure Type 1 hypervisor. There is no host operating system; the hypervisor is the only software layer between the hardware and the VMs.

Proxmox VE is based on Linux (Debian) and KVM. KVM is a Linux kernel module that transforms Linux into a Type 1 hypervisor, also utilising VT-x/AMD-V extensions. Proxmox is therefore also a Type 1 hypervisor, with Linux as the management partition, just as Windows is with Hyper-V.

Hyper-V shares with Proxmox/KVM this hybrid architecture, in which the management OS runs in a privileged partition rather than being absent. The difference between Hyper-V and ESXi is not a difference in type, but a difference in management architecture.

When should you use Hyper-V rather than an alternative?

Hyper-V is the right choice for Windows-centric environments (Windows Server, corporate workstations with Active Directory, hybrid deployments with Azure). Native integration means there is no need to install a dedicated OS, and the host Windows partition serves directly as the management interface.

If you want to use virtualisation on a personal PC running Windows 11 without affecting VBS or VirtualBox compatibility, you can still disable Hyper-V (and VBS) using the built-in Windows features. However, disabling VBS also removes Credential Guard’s memory protections, which is a trade-off to consider depending on how the machine is used.

For multi-OS virtualisation, open-source solutions, or virtualisation on Linux hardware, Proxmox or KVM offer greater flexibility. ESXi remains the standard for VMware data centres.