Virtualization products can use several different architectures to share a computer’s hardware resources among VMs. The earlier type of virtualization products, including Microsoft Windows Virtual PC and Microsoft Virtual Server, requires a standard OS installed on a computer. This becomes the “host” OS. Then you install the virtualization product, which adds the hypervisor component. The hypervisor essentially runs alongside the host OS, as shown in Figure 3-1, and enables you to create as many VMs as the computer has hardware to support.
FIGURE 3-1 A hybrid VMM sharing hardware access with a host operating system
This arrangement, in which the hypervisor runs on top of a host OS, is called Type II virtualization. By using the Type II hypervisor, you create a virtual hardware environment for each VM. You can specify how much memory to allocate to each VM, create virtual disk drives by using space on the computer’s physical drives, and provide access to peripheral devices. You then install a “guest” OS on each VM, just as if you were deploying a new computer. The host OS then shares access to the computer’s processor with the hypervisor, with each taking the clock cycles it needs and passing control of the processor back to the other.
Type II virtualization can provide adequate VM performance, particularly in classroom and laboratory environments, but it does not provide performance equivalent to separate physical computers. Therefore, it is not generally recommended for high-traffic servers in production environments.
The virtualization capability built into Windows Server 2012 R2, called Hyper-V, uses a different type of architecture. Hyper-V uses Type I virtualization, in which the hypervisor is an abstraction layer that interacts directly with the computer’s physical hardware—that is, without an intervening host OS. The term hypervisor is intended to represent the level beyond the term supervisor, in regard to the responsibility for allocating a computer’s processor clock cycles.
The hypervisor creates individual environments called partitions, each of which has its own OS installed and accesses the computer’s hardware via the hypervisor. Unlike Type II virtualization, no host OS shares processor time with the hypervisor. Instead, the hypervisor designates the first partition it creates as the parent partition and all subsequent partitions as child partitions, as shown in Figure 3-2.
FIGURE 3-2 A Type I VMM, with the hypervisor running directly on the hardware
The parent partition accesses the system hardware through the hypervisor, just as the child partitions do. The only difference is that the parent runs the virtualization stack, which creates and manages the child partitions. The parent partition is also responsible for the subsystems that directly affect the performance of the computer’s physical hardware, such as Plug and Play, power management, and error handling. These subsystems also run in the OSs on the child partitions, but they address only virtual hardware, whereas the parent, or root, partition handles the actual hardware.
It might not seem like the Hyper-V role in Windows Server 2012 R2 provides Type I virtualization,
because it requires the Windows Server OS to be installed and running. However, adding the Hyper-V role actually converts the installed instance of Windows Server 2012 R2 into the parent partition and causes the system to load the hypervisor before the OS.