A brief architecture overview of VMware ESX Server, Xen and Microsoft Windows Server Virtualization

Massimo Re Ferrè, IT Architect at IBM, just published on his personal blog a very interesting article providing an architectural overview of most popular hypervisors on the market: VMware ESX Server 3.0, Xen 3.0 and upcoming Microsoft Windows Server Virtualization (codename Viridian):

As you could see from these pictures VMware ESX implements what it is referred to as the “VMKernel” which is a bundle of hypervisor code along with the device driver modules used to support a given set of hardware. The size of the VMkernel is known to be in the range of some 200.000 lines of code or a few MBytes. On top of that there are a so called VMware Console OS that is in fact a sort of system virtual machine that is used to accomplish most administrative tasks such as providing a shell to access the VMkernel, the http and VirtualCenter services to administer the box. The Console OS is not typically used to support virtual machines workloads as everything is handled by the VMkernel.

On the other hand Viridian and Xen implement a different philosophy where the so called “Parent Partition” and “Dom0” play a different role than the Console OS. The hypervisor implementation in Viridian and Xen is much smaller than that in the ESX implementation and in fact it is in the range of some few thousands lines of code (vs the 200.000 of the VMKernel) or some KBytes (vs the MBytes of the VMKernel). However the Viridian/Xen implementation pretty heavily involves the usage of the Parent Partition / Dom0 as far as device drivers are concerned. In fact they are using these two entities to “proxy” I/O calls from the virtual machines to the physical world. On top of this proxy function of course the Parent Partition and Dom0 also provide higher level management functions similarly to the VMware Console OS. So in my opinion claiming that the Viridian / Xen hypervisor is “thinner” than the VMKernel is partially true since VMware decided (for their own convenience) to put stuff into the VMKernel that on the other solutions did not just evaporated… they are merely called differently and are included in different “locations”…

Read the whole article at source.