Understanding the architecture of Hyper-V’s type 1 hypervisor will help you when you are trying to understand the benefits of features such as Single-Root IO Virtualization (SR-IOV), figure out why you need updated integration components for Dynamic Memory, see the reason for Linux Integration Services to exist, and to decipher the cryptic error messages in Hyper-V Manager or in the Windows event logs. I will discuss the architecture of Hyper-V in this post.
How Hyper-V Works
Below is a high-level depiction of the architecture of Hyper-V. We can get very deep in the weeds when looking at this architecture. This would be beneficial to those who are developing for Hyper-V, but we’ll stick to the components that are relevant to IT pros.
Where Hyper-V runs is something that those who are new to Microsoft’s enterprise virtualization may find confusing, or it can be stated incorrectly. Hyper-V does not run on Windows. True, you do install Windows first and then enable Hyper-V afterwards. However, Hyper-V is slipped beneath Windows. The Windows install, now known as the management OS, runs in the root partition on top of Hyper-V. Virtual machines (guests) run in child partitions, also on top of Hyper-V.
Drivers
Only the management OS has direct connectivity with the hardware on the host. That means the drivers for the host’s hardware are installed only in the management OS, where they run in kernel mode.
Note that SR-IOV is an exception to this. Selected virtual machines use virtual functions (VFs) to bypass the management OS to connect directly to physical functions (PFs) on a physical NIC in the host.
VMWP
The Virtual Machine Worker Process (VMWP) does lots of supervision and management for virtual machines. There is one tiny VMWP.EXE process for each running in user mode in the management OS for each virtual machine (child partition) that is active on the host. The VMWP will be involved with tasks such as live migration and state transitions (start, stop, restart, and so on).
VMMS
The Virtual Machine Management Service (VMMS) is a traditional Windows service that runs in user mode in the management OS. This service supervises the state of all virtual machines and, as the name suggests, manages Hyper-V.
WMI
Windows Management Instrumentation (WMI) is the interface through which tools such as PowerShell, Hyper-V Manager, and Failover Cluster Manager interact with Hyper-V. In theory, it is possible to bypass WMI, but the correct way for developers to interact with Hyper-V is through the documented WMI interface. Bypassing WMI can cause really weird problems.
Note that Windows Server 2012 (WS2012) uses a new version of WMI (v2) and that’s why you cannot use Windows 8/WS2012 or later tools to manage older versions of Hyper-V.
Virtual Switch
This is not shown in the diagram, but any virtual switch that you create in Hyper-V will reside in user mode in the management OS.
VSPs, VMBus, and VSCs
Virtualization Service Providers (VSPs) are used by the management OS to interact with virtual machines. Each integration service that is used, such as clock synchronization or integrated shutdown, uses a VSP in kernel mode in the management OS to communicate with the virtual machines.
There is one secure channel between the management OS and each running virtual machine (child partition). This channel is known as the VMBus, and it is protected by Data Execution Prevention (DEP). DEP prevents buffer overrun attacks – a method where an attacker deliberately writes instructions incorrectly into data memory and it slips via a bug into execution memory and is run to give the attacker system access to the operating system. DEP is enforced by hardware to provide security; this is why Hyper-V requires DEP to be enabled in the host hardware before the hypervisor can be launched.
The final piece of the puzzle is the Virtualization Service Client (VSC). The VSC is an integration component or integration service that runs in kernel mode in the guest OS of the virtual machine. The VSC works in tandem with the VSP to implement the integration service.
We refer to virtual machines as enlightened if they have integration components installed. Unenlightened virtual machines are ones that do not have integration components and they cannot use the advanced features or drivers of Hyper-V. For example, the Hyper-V support forums are littered with posts where people cannot get Dynamic Memory or the synthetic (default) network adapter to work with legacy operating systems. The solution is easy: install the Hyper-V integration components (Windows) or integration services (Linux).
Note: Although recent versions of Windows include the current (at the time of that version’s release) version of the integration components, newer versions of Hyper-V and even some hotfixes can require those integration components to be upgraded to make use of new features or resolve issues.
As I said, there is much more to the architecture if you are a developer, but the above information should be enough for IT pros to make the most of Hyper-V.