Hyper-V Program Manager
Today I would like to try and clear up some confusion that seems to be out there at the moment. People have been throwing around the terms 'VMM' and 'hypervisor' recently - and it is fairly apparent that the vast majority of the general populace does not know clearly what these terms mean, and specifically what the key differences are between the two.
So let us start with the first one - 'VMM'.
This term suffers from the problem that there are actually two meanings for 'VMM'. The first is 'virtual memory manager' - this is part of the Windows operating system and has nothing to do with computer virtualization - and everything to do with operating system memory management. This is not what I am discussing today :-)
The second meaning is 'Virtual Machine Monitor'. There are a number of different programs and implementations that use the moniker 'Virtual Machine Monitor'. In the simplest terms - the VMM is the piece of software responsible for monitoring and enforcing policy on the virtual machines for which it is responsible. This means that the VMM keeps track of everything happening inside of a virtual machine, and when necessary provides resources, redirects the virtual machine to resources, or denies access to resources (different implementations of VMMs provide or redirect resources to varying levels - but that is a topic of discussion for another day).
Classically there are two types of VMM.
A type II VMM is one that runs on top of a hosting operating system and then spawns higher level virtual machines. Examples of type II VMMs include the JavaVM and .Net environment. These VMMs monitor their virtual machines and redirect requests for resource to appropriate APIs in the hosting environment (with some level of processing in between).
A type I VMM is one that runs directly on the hardware without the need of a hosting operating system. Type I VMMs are also known as 'hypervisors' - so the only true difference between a VMM and a hypervisor is where it runs. The functionality provided by both is equitable. Examples of type I VMMs include the mainframe virtualization solutions offered by companies such as Amdahl and IBM, and on modern computers by solutions like VMware ESX, Xen and Windows virtualization.
This raises two interesting questions:
The answer the first question is quite tricky. Virtual PC / Virtual Server are hosted solutions (they run on top of Windows). However - the Virtual PC / Virtual Server VMM runs in ring 0 'beside' the Windows kernel. When we are executing a virtual machine we back the Windows OS state off of the CPU and run the virtual machine state. However - any access to hardware resources is routed through the Windows OS.
We have always referred to this as a 'hybrid VMM' model. It is not clearly type I - as we rely on a hosting operating system for much of our functionality, however it is not clearly type II as we run our virtual machines directly on the hardware whenever possible.
The answer to the second question is also quite interesting. There are many reasons for this decision (some of which I am not at liberty to discuss publicly) but I think that they would best be summed up by the statement 'flexibility'. The reality is that many of the solutions that we deliver in the first release of Windows Server Virtualization could have easily been done on a hybrid VMM model. However - as we look down the road to our 2nd, 3rd, etc... releases of Windows virtualization there are a number of areas we are interested in which will require hypervisor technology. While I admit that this sounds incredibly cheesy; I believe that we are heading in the right direction (from a technological point of view) to be able to deliver on many interesting scenarios.
HyperVisor type1 (VMM 1, hardware hyperVisor) they get installed on bare metal (host without OS) and then they allow installation of VMs on top of it. ex Citrix Xen, VMware ESXi
HyperVisor type 2 (VMM 2, software hyperVisor) they require host OS, they get installed on top of host OS and then allow multiple VMs to run on top. eg Microosft virtual PC, VMware vSphere, VMware server