Fud y más Fud es lo que se ve últimamente en el mundo de la virtualización, eso está bien, cuando la gente se pone nerviosa es que la competencia está trabajando bien…
El origen del lío (el Fud origen del lío)
If you really want to focus on the disk footprint that matters, the amount of software that could be directly exposed to VM attack, the Hyper-V hypervisor and virtualization stack combined is about 20 MB, ~19.4 MB for the virtualization stack and ~600k for the hypervisor.
Comparison #1: Microsoft Hyper-V Server 2008 & VMware ESXi 3.5
Disk Footprint & Patch Count. Here's what we found:
- Microsoft Hyper-V Server 2008: 26 patches, totaling 82 MB.
- VMware ESXi 3.5: 18 patches, totaling over 3.7 GB.
Yes, I said over 3.7 GB. To put it another way,
Because VMware releases a whole new ESXi image every time they release a patch. Furthermore, because VMware releases a whole new ESXi image every time they release a patch it also means that every ESXi patch requires a reboot.
At this point, a VMware salesman, may concede the point that every ESXi server has to be rebooted for every patch, but they will then state that they have VMotion (Live Migration), so it doesn't affect their uptime.
Except when their own patches cause days of downtime and render VMotion impotent.
Reliability/Availability. With VMware ESXi 3.5 Update 2, it included a serious flaw which resulted in two days of downtime for their customers including the loss of VMotion
After VMware released Update 2, which affected both ESXi & ESX, they rushed to get a fix out the door and did so in a few days. One interesting thing I noticed was that in the span of a few days, the patch grew 17 MB.
17 MB in a few days????