I posted this a while back to osnews.com, but I thought it might be useful for those who want to understand the different types of virtualization software.
So to start, let’s layout the three common methods to building a virtual machine monitor in use today and their commonly acknowledged strengths and weaknesses (and yes I am dropping the Type 1 vs. Type 2 designators because I don’t think they help properly illustrate the discussion):
The first is kernel based VMM. This model uses a kernel mode driver or extension to provide the VM environment within a host OS wherein the host is responsible for memory management (natively or via extension), virtual machine scheduling via its own scheduler and interrupt handling. In this model the host OS itself becomes the VMM. This is the VMWare Server, VMWare Workstation, Microsoft VPC, Virtual Server and KVM model. The downside to this model is it depends on the general purpose OS’s notion of memory management, processor scheduling and interrupt handling which is not necessarily optimal for VM resource management.
The second option is a monolithic virtual machine monitor (or fat-hypervisor), such as VMWare ESX. The advantage to this scenario is that the VMM, and its driver model, is specifically engineered to handle memory allocation and processor scheduling, interrupt handling and resource management in a Virtual Machine centric fashion. The primary negative of this model is that there is the overhead of what amounts to a complete secondary driver set in the VMM, adding complexity to the VMM codebase and creating yet another driver model that 3rd parties and OEMs must support.
The third option, employed by Xen and Microsoft’s hypervisor’s, is a thin-layer VMM that only provides basic VM instantiation, tear-down, memory management, processor scheduling and interrupt handling (and redirection) for Virtual Machines. Everything else, including hardware device access, is implemented via the root (parent, dom 0) VM’s OS driver model. The advantage to this model versus the monolithic VMM is that in theory, no proprietary virtualization specific driver model exists. The downside to this model is that the VMM is dependent on the root VM’s driver implementation, which might not be optimal or may require modification of the root OS’s kernel and driver model to perform well.
We will continue to see all three models for the foreseeable future. All three models have their weaknesses and strengths. While architecture fundamentals are important, what ultimately matters is the implementation. Architecture only matters in so much that it facilitates a good implementation.