VMware vSphere experts know that the ESX architecture has a critical advantage over other hypervisors like Xen, KVM, and Hyper-V. Instead of relying on general-purpose third-party device drivers, VMware ESX comes with hardened, stress-tested drivers — ready for your toughest enterprise workloads.
Windows deserves applause for reliability improvements in recent years. Unfortunately, the most reliable Windows design will never be able to counteract the damage that can be inflicted by a misbehaving device driver. In fact, take a look at this slide from a Mark Russinovich TechEd session where he makes the point that the majority of Windows blue screens (BSODs) are caused by third-party drivers:
Experts agree — Windows reliability is a function of driver reliability.
What about those drivers included with Windows?
You might be under the impression that these third-party drivers are for off-brand NICs purchased from the clearance bin at Fry’s. That’s not exactly the case — plenty of drivers are included right on the Windows DVD.
Consider this recent situation detailed by Mark Wilson. He set up a Hyper-V test machine with some Intel PRO/100 NIC cards and when he plugged in an Ethernet cable — instant BSOD!
It’s good to know that Hyper-V was not at fault here: sure, it shows that a rogue device driver can bring down a Windows system but that’s hardly breaking news…
Meanwhile, back at the datacenter
Microsoft Hyper-V poster child Crutchfield recently found that the Broadcom NICs embedded in every one of their Dell servers were randomly losing virtual switch bindings after upgrading to Hyper-V R2. Hello downtime!
The administrator left us with the following thoughts:
Currently, Microsoft doesn’t have a work around for this issue and nor is there an ETA for resolution. After all, it may not be Microsoft, but could very well be Broadcom.
So, what do we do? Well, in my configurations I can’t afford these little gotchas and I will be working only with my trusted Intel NIC’s for my virtual networks.
Uh, you might want to check with Mark Wilson first about Intel drivers and Hyper-V.
The chain breaks when the weakest link fails
Notice the consistent theme in these two scenarios? The administrators are not blaming Hyper-V, instead focusing on the third-party hardware and drivers. Folks, it just does not matter — a hypervisor failure is incredibly disruptive.
When selecting the foundation for your private cloud, will you choose a hypervisor based on a general-purpose OS that aims to support hundreds of hardware variations from across the spectrum? Or will you build on a rock-sold, purpose-built platform that is specifically designed to aggregate and pool resources in your datacenter?