Understanding VMBus
Before we get into virtual machine resources, this section covers the Hyper-V
architecture in more detail than the high-level overview provided in Chapter 1,
“Introduction to Virtualization and Microsoft Solutions.” It is important to understand
how the various resources for virtual machines are engineered and enabled. Figure 1.4
in Chapter 1 shows the hypervisor running directly on the hardware, with all of the
virtual machine resource access serviced through the hypervisor. If you look carefully
at the figure, I deliberately showed only the processor and memory resources being
managed by the hypervisor. Other resources must be available for a fully functioning
environment, such as storage and networking. The mechanisms to communicate with
the processor and memory in a system are quite standardized, removing the need for
many different sets of code to handle the different types of processors and memory
found in a system.
This is not the case with storage controllers and network devices. Each vendor
typically has its own specific implementation and must provide a driver to enable the
operating system to correctly communicate with the hardware. There are thousands of
these drivers for Windows, with most written by the independent hardware vendor
(IHV). All of these types of storage and networks need to be usable by Hyper-V, and
therefore the drivers need to be available. Type 1 hypervisors have two architectures:
monolithic and microkernelized, as shown in Figure 2.1.
Figure 2.1 The monolithic and microkernelized hypervisors
With a monolithic hypervisor, the drivers responsible for communication with the
hardware sit in the actual hypervisor, which is a fairly complex kernel, basically a mini
operating system. The virtual machines access the hardware via these specialized
device drivers, which results in very good performance because the virtual machines
can go directly to all hardware via these drivers in the hypervisor.
There are issues, however, with a monolithic hypervisor approach. The first is that
these shared drivers are specifically written for the hypervisor, which limits the
hardware that is supported by a monolithic hypervisor; and virtualization solutions
that use a monolithic hypervisor typically have a small hardware compatibility list.