Source

I am sitting in the VMworld session “TA3880 – Head-To-Head Comparison: VMware vSphere and ESX vs. Hyper-V and XenServer”.  It is interesting to listen to VMware’s perspective on this.

One point that they have raised – which I have heard before – is that VMware ESX has better scalability than Hyper-V because they run their drivers in the hypervisor, while we run our drivers in the parent partition.  VMware usually then continues to say that they tried this approach (drivers in the parent partition, or the “service console” to use VMware nomenclature) with older versions of ESX and it caused scalability issues that were resolved by moving the drivers and emulated devices into the hypervisor.

Now, I remember when VMware announced that they were moving all of their drivers and emulated devices into the hypervisor.  At this time they were proudly talking about how they were doing this and how it helped so much with scalability, and I was thinking “that’s insane – why would they do that! I would never put code that complicated into the hypervisor”.  So I decided to do some research; and I found the simple answer for this:

The ESX service console (in what they now call “ESX classic”) is a uniprocessor partition.

Compared to this the Hyper-V parent partition has access to all processors in the physical computer, and runs an operating system with great scalability (Windows Server).

So yes, a running your drivers and emulated devices in a uniprocessor partition would be a scalability bottleneck.  But running your drivers and emulated devices in a multi-processor, highly scalable parent partition does not cause a single bit of scalability issues.

Cheers,
Ben