Microsoft responds to VMware's ability to overcommit memory

Microsoft responds to VMware’s claims that they are a cheaper solution due to memory overcommitment.

——————————————————————————————————————-

While at VMworld, there was some interesting talk about memory overcommitment and how you can lower your TCO by using it in a production environment. I walked over to the Microsoft booth at VMworld to get a response and spoke directly with Brett Shoemaker, Product Manager at Microsoft. We had a discussion about memory overcommit, and he agreed that it is useful to use but only in a test/development environment. He did not see much use for it in a production environment, which aligns with what I said in my original post, “VMware Says Memory Overcommitment Makes Them Cheaper than Both Microsoft and Xen Server.”
He goes on to say the following:

“First, since I’m uncertain whether you are aware, Microsoft will have its own solution in the future. Given that, it probably will not be a surprise that I believe there are cases where memory over-commit is useful. For example, the ability to over-commit memory is more useful for test/dev than in production. That said, I would contend that choosing a virtualization solution today for the ability to overcommit memory would be shortsighted. Yes, you would get a small gain, but you would have to pay more for it upfront and really don’t want inflated consolidation ratios because of the negative impact it has on high availability and failover response. Doing so would ignore key areas, such as management (physical + virtual, multi-hypervisor, etc.), ease of integration, and TCO/ROI.”

Brett also addresses that it is cheaper to purchase memory than to pay for the ability to use a memory overcommit scenario due to the additional cost of ESX licenses. In addition, if you overcommit your memory, performance may take a hit if the person that is performing the memory overcommit is inexperienced in doing such a major production tweak. Basically, if you are “green,” you could get yourself in a lot of trouble.

I browsed through some of VMware’s documentation and found this bullet item where they state the following:

“Avoid high memory overcomittment. Make sure the host has more memory than the total amount of memory that will be used by ESX plus the sum of the workingset sizes that will be used by all the virtual machines.”

It seems to me that memory overcommitment isn’t as easy as it looks, but let’s be honest what is when it comes to the virtualization of software.