These past few days, we've seen some back and forth postings taking place on various corporate blogs around the topics of virtualization ROI and a unique feature found in VMware ESX Server called memory overcommitment.

VMware's Eric Horschman posted an interesting blog post on VMware's Virtual Reality Blog site answering remarks made by many in the industry that VMware's solution is overpriced. Many have said that with companies giving away platforms built on top of Xen, and Microsoft planning on charging $28 for their yet to be released Hyper-V hypervisor, it seems as though VMware's price tag could be a little steep and might have to come down to a price that is more "reasonable".

Horschman countered the 'high pricing' claim saying "Virtualization customers should focus on cost per VM more than upfront license costs when choosing a hypervisor. VMware Infrastructure's exclusive ability to overcommit memory gives it an advantage in cost per VM the others can't match." And he adds, "Our rivals are simply trying to compensate for limitations in their products with realistic pricing."

To back his claims up, Horschman lays out an elaborate presentation and example of how to calculate this cost per VM, and attempts to show readers how a free hypervisor ends up costing more money per VM than that of the more expensive ESX Server product because of the memory overcommitment feature currently exclusive to VMware.

Roger Klorese, Senior Director on the Product Marketing team for Citrix XenServer, answers Horschman's post with a blog posting of his own. As a side note, in addition to now working at Citrix on the XenServer product, Klorese was, in another life, an early member of the VMware family and so he draws on some of his past experience with the ESX Server product.

"The test he uses to support the claim is very impressive - if what you want to do is to power on virtual machines. If you're going to look at their screensavers all day while you do your work with a pencil and paper and abacus, power-on statistics are meaningful. And the moment you power on is the time you get the most out of page-sharing: nearly all pages are either operating system and services code pages (which are identical from guest to guest in many cases) or all-zero (which are all initially mapped to the same physical page)."

He continues, "What do you think happens when those pages start to un-share, as people start doing real work? How big do you need to expand those balloons, and how much do you have to starve those guests, to keep your 5:1 memory allocation? And if you can't balloon 5:1, how much do you further degrade it when you start using the hypervisor swap file?"

Simon Crosby, CTO of the Virtualization and Management Division at Citrix Systems, writes on his blog: "The bottom line: VMware's 'ROI analysis' offers neither an ROI comparison nor any analysis. But it does offer valuable insight into the mindset of a company that will fight tooth and nail to maintain VI3 sales at the expense of a properly thought through solution that meets end user requirements. The very fact that the VMware EULA still forbids Citrix or Microsoft or anyone in the Xen community from publishing performance comparisons against ESX is further testimony to VMware's deepest fear, that customers will become smarter about their choices, and begin to really question ROI."

Citrix wasn't alone in answering Horschman's blog post. Microsoft blogger James O'Neill didn't agree with the numbers either. On his blog, he wrote, "They were able to start 40 instances of Windows XP to achieve the 40 VMs, with 512MB of memory on a machine with only 4GB of RAM - a 5 times over commitment ratio. Of course they didn't actually run anything in them, because if you and I fired up Outlook, and IE (with our own mail boxes and choice of pages) you open word and I open PowerPoint very few memory pages will be sharable (I've got 47 pages open in IE right now, and it's using over 300MB of RAM, almost all for data). That means a lot of paging will have to happen in the virtualization stack. Brace yourself for really poor performance."

Where to begin? All of these blogs are starting to get wonderful responses. And the battle over memory overcommitment and product pricing continues.

What's interesting to note is that it sounds like Citrix may already have the memory overcommitment capability in the Xen product. But they haven't gone further down that road because of performance issues. Microsoft is also supposedly planning on adding this very feature into the next version of Hyper-V according to a recent interview done with Bob Muglia.

All of this discussion around memory ballooning, paging and memory overcommitment made me remember something I heard in a break-out session back at VMworld 2006. The memory overcommitment feature was described to me as an automobile airbag. It's one of those features you are glad to have in case of an emergency, but you certainly don't use it on an everyday basis.

From the responses that many of these blog postings are receiving, it sounds like a mix bag review of the feature. Some say it works great for them in their environment - and they do get a bump in consolidation densities. Others are saying that it drags down performance of their virtual machines. Again, sounds like a case by case issue. And the battle... er, discussion, rages on.

Posted by David Marshall on March 20, 2008 08:29 AM