What is the difference between HVM and PVM, why should anyone care, and how does this apply to the popular hypervisors? This is a set of questions I get asked a lot and, despite the fact that lots gets written on it, I think it is important enough, and confusing enough, to deserve some additional rumination. To start with, in order to really understand the answer to these questions it is critical to have a solid understanding of virtualization and, in particular the x86 flavor of it (going to avoid the Popek and Goldberg definition here).

To put it simply, x86 virtualization allows lots of instances of an x86 operating system share one physical server. The devil here is very much in the details, however. When you consider what a server is, it’s basically a collection of physical resources in a box. Namely compute (one of more processors), network connectivity, short term (memory) and long term storage (some sort of disk either attached locally or accessible via a network connection), And display and I/O capability (keyboard, mouse, etc) Access to all of these resources is provided to the end user courtesy of an operating system that is installed onto that hardware. In the x86 world, these days this is almost always either Linux or Windows.

So how does virtualization fit into this? In the case of virtualization, a special type of operating system called a hypervisor is installed first. The job of the hypervisor is to abstract these physical resources and time slice access to them. Basically the hypervisor says “these resources are mine, but I’ll allow them to be borrowed by a bunch of folks for a moment at a time”. The way it does this under the hood today is by utilizing some support that AMD and Intel have built into the instruction sets and BIOS code of their hardware. In the early days of virtualization, this “traffic cop” aspect of the hypervisor (known as the “virtual machine monitor”), was purely software magic sitting on top of a clueless hardware structure. In both cases once this hypervisor is installed and running, it is ready to accept “guests”. Guests are virtual machines in a literal sense. These are logical servers, that behave much like a physical one would, running as “applications” on the hypervisor operating system. Into these virtual machines, operating systems can be installed the same way they would on a physical server.

In order to instantiate a functional virtual server, a hypervisor operating system performs a certain amount of hardware emulation. How is that different then virtualization? Virtualization is sharing of resources via a partitioning of them and access to them provided by a monitor through time slicing. Emulation is the complete simulation of a hardware component in software. As an example, mobile developers often use “phone emulators” to test their code. In these cases a complete functional iPhone, for example, would be run as an application on a desktop computer. That emulated iPhone thinks its an iPhone and behaves like one. Things that get emulated under x86 virtualization are certain foundation hardware systems: the BIOS and the presentation of the shared storage, network, display and I/O subsystems.

At this point, we reach the fork in the road between hardware virtualization mode (HVM) and para virtualization mode (PVM). Under HVM, the guest operating system, installed into the virtual machine, can be clueless. It does not need to know it is running on a hypervisor (it can, but doesn’t need to). As far as it is concerned, it sees some apparently real hardware. For example, the host server running the hypervisor might be a Cisco UCS blade with a fancy VIC network interface. The guest OS, however, is shown a basic Intel 10/100/1000 Ethernet NIC by the emulation code in the hypervisor. This allows super easy installation of the guest OS using standard drivers and also very predictable guest OS behavior very important for time slicing. Similarly, for storage, the guest may see a basic SATA or SCSI adapter (generally configurable on the host) even though the actual storage on the host might be an NFS data store attached via the network interface! The display might show up as VGA, etc. This approach is how VMware ESX/ESXi and Hyper-V work (with an important caveat that we’ll discuss soon)

So if that’s HVM, what is PVM? In the Linux world, hypervisors have become native to the operating system. Xen and KVM are examples of this. Pure paravirtualization on Linux is primarily a Xen facility (KVM adopts para virtualization type capabilities in a manner similar to VMware ESX or Microsoft Hyper-V and is primarily an HVM system). Under para virtualization, the guest operating system actually is aware that it is running on a hypervisor. In the case of Linux this means modification of the actual kernel and the injection of certain drivers. This isn’t possible to the same degree under Windows (yet). The advantage of this approach is that performance can be improved and made more predictable and consistent since the guest is now a “virtualization citizen”. The disadvantage is the loss of flexibility. If an OS can’t be made aware of the hypervisor, it can’t run in pure PVM. So what is the caveat with VMware and Hyper-V?

Looking at the advantages of both HVM (flexibility) and PVM (performance) it becomes obvious that the best of both worlds would be really nice and this is exactly what VMware (as an option) and Microsoft (as a requirement) have done. Basically, in their respective HVM based virtualization e have both released PVM style functionality in the form of specific drivers built for the hypervisor environment for network, storage, I/O, display, etc. With VMware the hypervisor is “monolithic” meaning that the hypervisor OS has its drivers for the physical hardware compiled into the hypervisor itself. Hyper-V has a very slim hypervisor, but relies on a “parent partition” to host an instance of Windows which runs on the physical server and provides the hardware support for the hypervisor via drivers matched to the physical hardware. For their guests, it is possible to install special virtualization mode drivers. So rather than the guest seeing “Intel network card” or “standard SATA Interface”, it will see “Microsoft virtual network adapter” or “VMware virtual storage controller”. These para virtualized drivers perform better because they hook into the hypervisor directly rather than via the emulation layer.

Hopefully this clears up some of the confusion on this complex topic and also shed some light on the different operational modes of ESX, Hyper-V, KVM and Xen!