Someone might look at this sequence of actions and how Hyper-V is managed and
come to the conclusion that the Hyper-V hypervisor is running on top of Windows
Server; that is not the case at all. When the Hyper-V role is enabled on Windows
Server, changes are made to the boot configuration database to configure the
hypervisor to load first, and then the Windows Server operating systems runs on top
of that hypervisor, effectively becoming a pseudo virtual machine itself. Run the
command bcdedit /enum on a Hyper-V host, and it shows that the hypervisor launch
type is set to automatically launch.
The Windows Server operating system becomes the management partition for the
Hyper-V solution. The hypervisor itself is quite compact and needs to be as light as
possible, so it’s focused on interacting with compute and memory resources and
controlling access for virtual machines to avoid introducing latencies in performance.
The management partition works for the hypervisor, and it is tasked with various
items, such as hosting worker processes to communicate with virtual machines,
hosting drivers for storage and network adapter interactions, and more. However, all
of the virtual machines are running directly on the hypervisor and not on the host
operating system that was installed. This is best shown by looking at the Hyper-V
architecture in Figure 1.4, which clearly shows the hypervisor running in Ring –1 and
both the management partition and all the virtual machines running side by side on
the hypervisor. The management partition does have some additional privileges,
capabilities, and hardware access beyond that of a regular virtual machine, but it is
still running on the hypervisor.
Figure 1.4 Hyper-V architecture
WHAT IS A PARTITION?
In the discussion of the history of Hyper-V, I referred to a management partition.