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.
Sitemap
Comments
Alessandro - I think you've found a topic to be discussed and presented at the Congress in October.
By
Patrick, at Friday, March 14, 2008 8:55:00 PM
Eric has posted a followup: http://blogs.vmware.com/virtualreality/2008/03/more-on-vmware.html
By
John Troyer, at Saturday, March 15, 2008 3:59:00 AM
I agree that a mixed environment should be required, but do not discount that mixed environment all being built from standardized images/templates. Also, it should not be a given that various patch levels/service packs are being run. It is true that you may be running different patch/service packs between OS families, but in todays standardized datacenters your patch levels should not fluctuate drastcially within the same OS. Standards should be the norm and the non-standard should be the exception.
By
Anon, at Saturday, March 15, 2008 7:58:00 PM
VMware has just posted a detailed description of memory overcommit being used in a VDI environment with a real customer. Go here for the details: http://blogs.vmware.com/virtualreality/2008/03/memory-overcomm.html.
By
Mike DiPetrillo, at Wednesday, March 19, 2008 1:25:00 AM
Alessandro , that's the nearest thing un-biased that I've seen on this subject, and the most intelligent. Where I sympathize with VMware is to create something test which is reproducible it's difficult to make it real world. The objection on my part was the implication that 2:1 over commit could be used for all workloads, when obviously that's not practical - and VMware docs say so. Mike's description shows a customer who wouldn't be supported (http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_config_max.pdf) but who could enough over-commit on enough VMs to make the numbers work for them. It can be done, but the circumstances need to be a bit special.
By
James O'Neill, at Thursday, March 20, 2008 8:23:00 PM
The reason that the VDI workload was chosen was more to show the Citrix/XenSource people that you can have real people doing real work and still do overcommit. Overcommit is especially powerful in a VDI environment because nearly everything is identical. We're all issued standard laptops or desktops these days with the same collection of corporate approved apps. With that said, this doesn't only work for identical stuff. We're doing a comparison on a page by page memory basis so in one VM you may have a Windows app that writes out 0-0-0-0-1-1-0-0 to memory and in another VM you have a Linux drive that writes 0-0-0-0-1-1-0-0 to memory. On a page comparison basis these are identical. Remember, you can only have so many combinations of 0's and 1's in a page. To say that everything must be identical just shows a complete lack of knowledge of basic computer operations.
Many customers push the bounds of what's supported. That leads vendors to develop new tools and products and broaden the support options. For example, it wasn't until our customers started to host XP desktops for overseas workers 4 years ago that we really thought heavily about VDI. It wasn't until our customers wanted more and more memory in a VM until we tested it and put it in the interface. Microsoft has seen this same thing as well as any other ISV or OSV out there. As VMware's customers continue to push the limits VMware will continue to certify the solutions and support them just as VMware is doing with this customer and many others.
By
Mike DiPetrillo, at Saturday, March 22, 2008 6:03:00 AM
Post a new comment