The conference VMworld is just one week away and this year VMware’s competitors seem to have additional reasons to start a controversy and disturb the event.
The topic of the day is the size of the hypervisor footprint, which equals to a certain attack surface and has a relevance when you try to estimate the overall security level of a platform.
This is an area where VMware always claimed a neat superiority over Microsoft because the primary version of Hyper-V comes with a full copy of Windows Server 2008 as its parent partition.
VMware believes this is a major selling point at the point that it is highlighted on the corporate website.
Microsoft never addressed the critique before a couple of weeks ago, when it published an interesting analysis (part 1, part 2 and part 3) of what happens to the hypervisors footprint after a round of patches.
On its website, VMware compares its lightweight ESXi, the hypervisor version without the Console Operating System (COS), against the full version of Hyper-V. For Microsoft a more fair comparison should be between ESXi and its lightweight Hyper-V Server.
Nonetheless the company prepared three different analysis (only including critical and security patches):
- Hyper-V Server 2008 vs ESXi 3.5 | June 2008 – June 2009
Hyper-V: 82MB footprint increase with 26 patches
ESXi: 2.7GB footprint increases with 13 patches - Windows Server 2008 Hyper-V vs ESX 3.5 | January 2008 – June 2009
Hyper-V: 408MB footprint increase with 32 patches
ESX: 3GB footprint increases with 85 patches - Windows Server 2008 Hyper-V vs ESXi 3.5 | January 2008 – June 2009
Hyper-V: 408MB footprint increase with 32 patches
ESX: 2.7GB footprint increases with 13 patches
Without patches, Microsoft highlights that the only part of the two platforms that can be really attacked (the hypervisor plus the virtualization stack) is 32MB in ESX and 20MB in Hyper-V.
At the end of the last week VMware officially answered.
First on the hypervisors footprint without patches:
…
We don’t know how many lines of code are in a Hyper-V system, so we use the installed disk footprint– the size of the installed files needed to support virtual machines — as a reasonable proxy for lines of code.
…
A df -h command will then show you that the total size of those compressed ESXi boot images in the directory corresponding to /bootbank is 59.3MB — somewhat less than the 70MB figure we’ve publicly stated.
…
For comparison, here’s a look at the disk footprint of ESX 4.0 “Classic”, which measures about 1.7GB. Most of the additional footprint is due to the Linux-based service console.
The disk footprints we measured for Hyper-V R2 RTM are far larger. Windows 2008 R2 Server Core with the Hyper-V role enabled, was 3.6GB. For those Hyper-V users that want to preserve the “Windows they know,” a full Windows Server 2008 R2 installation is pushing 10GB.
Yes, ESX “Classic” does use a Linux-based service console and therefore has a larger disk footprint, but VMware has publicly stated that the OS-free ESXi architecture is our future direction and ESXi has all the capabilities of ESX “Classic”. Microsoft has made no such commitments to eliminate Hyper-V’s dependency on Windows…
And then on the footprint with patches:
…
Because ESXi is installed and patched like an appliance — the entire image is replaced as a whole — our patches are naturally the size of the full ESXi installer package. Our customers prefer that appliance approach because it ensures consistency in the their installations and avoids “patch drift” away from a validated configuration. With the Windows Update-based patching used for Hyper-V, patches can be smaller, but customers can skip or miss patches, resulting in insecure, partially patched configurations.
…
With both ESX and ESXi, a host reboot following patching has always been non-issue because VMotion and Maintenance Mode make it trivial to shift VMs to alternate hosts during the reboots. Microsoft’s customers must certainly be looking forward to using those same features in the long-awaited release of Hyper-V R2
…
We’ve kept track of the “Patch Tuesday” patches required on a Server Core Hyper-V system since Hyper-V first shipped in June 2008 and there have been multiple “Important” or “Critical” patches to apply almost every month. Most of those patches don’t apply to Hyper-V, but users must still install them and then reboot their hosts. And, as users are painfully aware, Hyper-V R1’s missing live migration support has meant downtime for their VMs with each reboot. The downtime may lessen with Hyper-V R2, but the patches won’t…
Both positions are extremely long and articulated. The excerpts above can’t really give the readers a full summary of every detail that both companies covered in their analysis.
A complete reading of all articles is recommended to evaluate who’s right.
Anyway it’s worth to remind everybody that security of the hypervisor impacts the security of the virtual infrastructure just partially.
The attacks can come from everywhere: the virtualization.info security columnist, Claudio Criscione, is covering this very topic on his first series: Real-World Security in a Virtual Infrastructure (Part 1, Part 2 and Part 3. Wait for Part 4 in the coming days).