This week’s XenClient announcements out of Synergy 2010 have got me rethinking some earlier opinions on hypervisors and their approach towards drivers. My new thinking leans towards the recognition that Hyper-V’s and XenServer’s “Type 1 Hybrid” hypervisor architecture is in fact a brilliant long-term play as virtualization begins moving towards client devices.
Allow me to explain.
We all know that one of the primary jobs of the hypervisor is in abstracting physical resources to create a virtual environment. From a high level perspective, this is done by “converting” or “translating” (not exactly correct terms, but you get my point) the physical drivers needed by a host system into the virtual drivers used by its virtual machines.
Obviously, in order to accomplish this job, those drivers need to reside somewhere. In and amongst our three major hypervisors today (ESX, Hyper-V, XenServer), two different approaches have been used. The first approach, used by ESX, stores those drivers within the hypervisor itself. This approach is good for server virtualization, because today’s servers have a relatively small (in comparison) set of needed drivers. The problem is that actually inserting any new drivers in the hypervisor means that VMware must insert them itself, which requires substantial testing and validation. It also means that the code in ESX’s hypervisor can tend to change more often as drivers are routinely added and removed over time.
Contrast this to the approach used by Hyper-V and XenServer. In both of these hypervisors, drivers are actually stored in the parent partition. This parent partition is what I like to call “the OS that used to be the only OS before you installed Hyper-V or XenServer”. Driver calls to Hyper-V’s and XenServer’s hypervisor are “passed through” (again, bad terminology, but I’m purposely using easy-to-understand terms here) to the parent partition where the actual drivers are stored.
This effectively means that any driver which is supported by the parent partition is automatically supported by its hypervisor.
Click here to read Part 2 of my thinking…