The real value of ESX Server memory overcommit capability

The virtualization phenomenon changed (and it’s still changing) a lot of things in the IT world. Some of them, anyway, have nothing to do with technology.

One is the new level of competition that the vendors can reach when pitching their products, probably the highest ever seen in the computer industry.
Such fierce conflict is made of claims and refusals and accusations going back and forth from one corporate blog to another.
Who benefits the most from this modern media fight is the end-user which has a surprisingly efficient tool to spot some obscure statements in this or that vendor’s offering.

This long and unusal premise was needed to introduce a concrete example.

Recently VMware opened a new corporate blog to debate on those press articles or competitors statements which are not considered fair enough.

The last post published on this blog, Virtual Reality, covers the frequent complains about the VMware Infrastructure price (complains that actually exist since much before Microsoft announced the price for its upcoming Hyper-V).
To justify the cost difference between its hypervisor and the competing ones, VMware focus on the so called cost per virtual machine and invokes the memory overcommit feature, something that nor Citrix XenServer neither Microsoft Hyper-V can offer today.

The achievements described in that post (a 4GB RAM physical server runs up to 40 concurrent VMs busy with light activity or up to 14 VMs busy with heavy activity) instantly provoked reaction from Microsoft and from Citrix.

The three positions are all interesting and worthwhile of a full analysis but readers should be aware that metrics can be manipulated without limits to support one position or another.

The value of ESX Server memory overcommit exist. Despite that, the scenario described by VMware seems far away from many real-world deployments.

VMware used the identical OS image for all the virtual machine instances but it’s highly unlikely that a virtual infrastructures can host tens of virtual machines with the same identical Windows edition, service pack, patch level and running applications. Thus the chances to have many memory pages to share are probably lower than the ones available in the tested environment.

Surely there are batteries of identical virtual machines (at least at the OS level) deployed out there, for example for web server farms or VDI farms, but to match a realistic average scenario VMware should use a mixed environment made of Windows 2000, 2003 and 2008 VMs, with different SP and patch levels, and with different installed applications.

In such environment the memory overcommit ratio would assume a more concrete value and a cost per VM calculation would be more precise.

Update: VMware posted a new scenario to validate its memory overcommit technology in the real-world.
It’s the case of a VDI farm with 178 virtual machines (512 MB virtual RAM each) which consumes less than 20GB physical RAM instead of 89GB.

Definitively an interesting environment but, as noted in the original post above, we’d like to see the memory overcommit ratio achieved where you cannot have a farm of identical guest OSes with identical applications.