ESX vs Hyper-V Footprint War…

I attended a hypervisor compete session at VMWorld this week and saw this topic come up yet again.  Can we please put the ‘footprint war’ to rest already?

VMware's claim was that since the ESX hypervisor is smaller than Hyper-V (it’s not), that means a smaller attack surface and fewer patches which equates to more “.9999’s”.  Of course, the gentlemen presenting the session called out every single Windows/Hyper-V update that causes a server reboot and conveniently neglected to show ANY similar information for ESX.  I was glad to see another attendee bring this up at the Q&A.  The presenter answered with, “That’s good feedback”.  Sure.

Here’s more from VMware’s website:

Microsoft attempted to follow VMware’s lead to reduce the attack surface of its virtualization platform by offering Windows Server Core (a subset of Windows Server 2008) as an alternative parent partition to a full Windows Server 2008 R2 install. However, the disk footprint of Server Core in its virtualization role is still approximately 3.6 gigabytes (GB). Until Microsoft changes its virtualization architecture to remove its dependency on Windows, it will remain large and vulnerable to Windows patches, updates, and security breaches.

Alright, let’s put this thing to rest already…

First of all – there’s this great feature called ‘clustering’.  Both Hyper-V and ESX have the ability to move virtual machines to other hosts in the cluster with no downtime (ie; vMotion or Live Migration).  That means hosts can come down for routine maintenance with little or no impact to the virtual workloads.

REALITY:  Everyone has to patch.  Our friends at VMware are not the exception to this rule.  If you run VMware, you know this already.  If you don’t – check out this PAGE.

I count 8 critical update packs since July of 2009 for ESX 4.0.  


Now, I don't claim to be an ESX guru so I don’t know if the VM shutdown part is completely accurate – but it’s possible that one or more of the updates in these ‘packs’ require the VM’s to restart (perhaps upgrades to the integration components?).  If that’s the case though, that’s even worse than I originally thought.  Either way, I’m just reading what THEY say. 

Add them all up – it’s over 4GB of updates in a year.  Now, I don’t know how much of that 4GB is over writing older stuff or is adding new stuff.  Does it matter?  It’s bigger…a LOT bigger than 70MB footprint they claim…

Back to VMWorld.  At the compete session, I see this slide again.


Seriously?  How can you have 4GB of updates for ESX in a year and then say that your disk footprint is 70MB? 

Want more proof?  Here’s a picture I snapped when doing my own ESX 4.0 install.  If it’s hard to read (you can click on it to make it bigger) – here’s what it says:



Here’s a comprehensive list of Hyper-V updates – going back to R1.  (I know of one other from a few weeks ago that’s not in this list.  It was last updated in May, so there may be others)

The moral of the story is – whatever you are running - Hyper-V or ESX, you are going to have to deal with updates, service packs, patches and the like. 

Ah, but you say…VMware is moving to ESXi now – no more ESX.  So, that will significantly decrease the number of patches, right?

Doubt it.  I count 9 updates to ESXi since July 2009.  1.6GB worth to be exact – all require rebooting the host.

Now, can we move on please?

Comments (2)
  1. Ken says:

    Thanks Mohamed.  I understand WHY – but you can tell here by their messasing they lead people to believe just the opposite.  My point with this article is, everyone patches and with features live Live Migration and vMotion, patching really shouldn't be an issue.  When they focus on size and correlate that to the number of patches required – that's misleading and the evidence clearly shows that.  

    Appreciate you stopping by.

  2. Mohamed Garrana says:

    great article , why vmware has more updates is because vmware esx/esxi hypervisor has the virtual machines' drivers included in the hypervisor , so when u need an update for the drivers u update the hypervisor which requires rebooting of al the hosts as infact you remove the old hypervisor and replace it with a new one

Comments are closed.

Skip to main content