An Overview of the Hyper-V Architecture

This chapter of Hyper-V Essentials is intended to provide an overview of the architecture of Microsoft's Hyper-V server virtualization technology.

Hyper-V Virtualization Type

Hyper-V implements what is commonly referred to as Type 1 Hypervisor virtualization. In this scenario, a hypervisor runs directly on the hardware of the host system and is responsible for sharing the physical hardware resources with multiple virtual machines. This concept is illustrated in the following diagram:

In basic terms, the primary purpose of the hypervisor is to the manage CPU and memory allocation between the various virtual machines running on the host system.

Hardware Assisted Virtualization

Hyper-V will only run on processors which support hardware assisted virtualization. Before looking at Hyper-V in detail, it is worth providing a brief overview of this hardware assisted virtualization actually means.

The x86 family of CPUs provide a range of protection levels also known as rings in which code can execute. Ring 0 has the highest level privilege and it is in this ring that the operating system kernel normally runs. Code executing in ring 0 is said to be running in system space, kernel mode or supervisor mode. All other code, such as applications running on the operating system, operate in less privileged rings, typically ring 3.

Under Hyper-V hypervisor virtualization a program known as a hypervisor, as previously mentioned, runs directly on the hardware of the host system in ring 0. The task of this hypervisor is to handle tasks such CPU and memory resource allocation for the virtual machines in addition to providing interfaces for higher level administration and monitoring tools.

Clearly, if the hypervisor is going to occupy ring 0 of the CPU, the kernels for any guest operating systems running on the system must run in less privileged CPU rings. Unfortunately, most operating system kernels are written explicitly to run in ring 0 for the simple reason that they need to perform tasks that are only available in that ring, such as the ability to execute privileged CPU instructions and directly manipulate memory. One solution to this problem is to modify the guest operating systems replacing any privileged operations that will only run in ring 0 of the CPU with calls to the hypervisor (known as hypercalls). The hypervisor in turn performs the task on behalf of the guest system.

Another solution is to leverage the hardware assisted virtualization features of the latest generation of processors from both Intel and AMD. These technologies, known as Intel VT and AMD-V respectively, provide extensions necessary to run unmodified guest virtual machines. In very simplistic terms these new processors provide an additional privilege mode (referred to as ring -1) above ring 0 in which the hypervisor can operate, essentially leaving ring 0 available for unmodified guest operating systems.

Hyper-V Root and Child Partitions

Running on top of the hypervisor are a root partition (also known as a parent partition) and zero or more child partitions (one for each virtual machine) as illustrated below:

The root partition runs a copy of Windows Server 2008 and is responsible for providing the device drivers for the virtual machines running in the child partitions, managing the child partition lifecycles, power management and event logging. The root partition operating system also hosts the Virtualization Stack which is responsible for performing a wide range of virtualization functions (the Virtualization Stack will be covered in more detail later in this chapter).

Child partitions host the virtual machines in which the guest operating systems run. Hyper-V supports both Hyper-V Aware (also referred to as enlightened and Hyper-V Unaware) guest operating systems.

The Hyper-V Virtualization Stack

Component	Description
Virtual Machine Management Service (VMM Service)	Manages the state of virtual machines running in the child partitions (active, offline, stopped etc) and controls the tasks that can be performed on a virtual machine based on current state (such as taking snapshots). Also manages the the addition and removal of devices. When a virtual machine is started, the VMM server is also responsible for creating a corresponding Virtual Machine Worker Process.
Virtual Machine Worker Process	Virtual Machine Worker Processes are started by the VMM Service when virtual machines are started. A Virtual Machine Worker Process (named vmwp.exe) is created for each Hyper-V virtual machine and is responsible much of the management level interaction between the parent partition Windows Server 2008 system and the virtual machines in the child partitions. The duties of the Virtual Machine Worker Process include creating, configuring, running, pausing, resuming, saving, restoring and snapshotting the associated virtual machine. It also handles IRQs, memory and I/O port mapping through a Virtual Motherboard (VMB).
Virtual Devices	Virtual Devices are managed by the Virtual Motherboard (VMB). Virtual Motherboards are contained within the Virtual Machine Worker Processes, of which there is one for each virtual machine. Virtual Devices fall into two categories, Core VDevs and Plug-in VDevs. Core VDevs can either be Emulated Devices or Synthetic Devices.
Virtual Infrastructure Driver	Operates in kernel mode (i.e in the privileged CPU ring) and provides partition, memory and processor management for the virtual machines running in the child partitions. The Virtual Infrastructure Driver (Vid.sys) also provides the conduit for the components higher up the Virtualization Stack to communicate with the hypervisor.
Windows Hypervisor Interface Library	A DLL (named WinHv.sys) located in the parent partition Windows Server 2008 instance and any guest operating systems which are Hyper-V aware (in other words modified specifically to operate in a Hyper-V child partition). Allows the operating system's drivers to access the hypervisor using standard Windows API calls instead of hypercalls.
VMBus	Part of Hyper-V Integration Services, the VMBus facilitates highly optimized communication between child partitions and the parent partition.
Virtualization Service Providers	Resides in the parent partition and provides synthetic device support via the VMBus to Virtual Service Clients (VSCs) running in child partitions.
Virtualization Service Clients	Virtualization Service Clients are synthetic device instances that reside in child partitions. They communicate with the VSPs in the parent partition over the VMBus to fulfill the child partition's device access requests.