More on VMware Memory Overcommit, for Those Who Don't Trust the Numbers
James O’Neill of Microsoft had a pretty sharp reaction to my last post. He accused me of cooking the numbers to exaggerate the cost saving benefits of VMware’s memory overcommit feature. To help James understand just how memory overcommit works, I’ve taken the numbers out of the argument and have used simple algebra to compare the TCO per VM for a host with either VI3 or Microsoft hypervisors. Let’s do the math…
Variables
| CH | Cost of server hardware |
| CM | Cost of memory per GB |
| CVMW | Cost of VMware virtualization software |
| CMS | Cost of Microsoft virtualization software |
| COS | Cost of operating system software |
| MH | Physical server memory, GB |
| MV | Memory per VM, GB |
| r | Memory overcommit ratio |
VMware |
Microsoft |
Total system cost |
Total system cost |
|
|
Number of VMs with overcommit |
Number of VMs without overcommit |
|
|
VMware Cost per VM |
Microsoft Cost per VM |
| |
Let’s simplify a little… | |
|
|
Now let’s make the assumption that the Microsoft virtualization software is free (CMS=0), and let’s go to extremes and tilt the numbers in Microsoft’s favor by assuming that the hardware and memory is also free (CH=0, CM=0). | |
|
|
Now let’s plug in some real numbers for a 2-socket server. We’ll use a conservative VMware memory overcommit ratio of 2, the list price of VMware Infrastructure Enterprise ($5750) and the list price for Windows Server Data Center Edition ($5998). | |
|
|
Finally, we get total cost per VM for both products | |
$5,874 |
$5,998 |
So, you can see in this extreme case where hardware is free, the VMware Infrastructure system still beats Microsoft Hyper-V, or any other hypervisor, in total cost per VM in a Windows environment. Plugging in any realistic costs for hardware and memory just tilts the balance further in VMware’s favor. I’m also using our most feature-rich VI3 Enterprise product in the example – had I used one of our products like ESX Server 3i or VI3 Foundation that is a little closer to the barebones capabilities of Hyper-V, the numbers would look even worse for Microsoft.
James also criticized my failure to include software support costs in my example. First, this analysis considers up front acquisition costs and not factors like support, maintenance and depreciation, which are spread over the lifetime of the products. Second, I also excluded Microsoft’s Windows Server support costs, which are comparable to those of VI3.
James also seems to think our customers aren’t using memory overcommit in the real world. The fact is most VI3 users are running with some level of overcommit and a few have kindly posted responses to that effect to my previous post. James may also want to have a chat with his VP at Microsoft. Here’s what Bob Muglia had to say about shared memory in a recent interview:
[Bink] We talked about Vmware ESX and its features like shared memory between VMs, [Muglia] "we definitely need to put that in our product"
James may not be a believer in the savings from memory overcommitment made possible by VMware’s exclusive memory sharing technologies, but apparently others at Microsoft are.
Posted by Eric Horschman on March 13, 2008 | Permalink |
If I am reading you're post correctly -- and I'm completely willing to say that I haven't -- you're saying that in the above example you have an over-commit ration of 2? Does that mean that if I have a 32 GB of RAM in a ESX host, I'm running 64 GB RAM of VM's? If that is the case I would argue that those numbers may be slightly unrealistic.
I know that my ESX servers have overcommitted their memory to their VM's, but only just. For example, if I have a 32 GB of RAM for my host, I may have spun up 40 GB of VM's -- naturally taking advantages of all of VI3's features like resource pools, DRS, HA, etc, etc. Would that mean that "r" would be 1.25?
I have never thought of to try selling VI3 on the overcommitt "advantage"; I've found that selling the existing ROI on physical memory equal virtual memory, and the fact that VI3 is a rock- solid hypervisor with an extremely rich feature set is more than enough to get approval.
I suspect that it isn't merely cost that will usher Hyper-V (and others) to be embraced by the industry; the other hypervisors require a proven track record of dependability.
And specifically in Microsoft's case, they need to prove that this isn't a "one-point-uh-oh" release. :-P
Posted by: Scott | March 13, 2008 at 04:31 PM
What about the management cost, high availability, cost of storage that supports VMotion on ESX ?
The list goes on....
Posted by: Ap | March 14, 2008 at 06:02 PM
@Ap
You ask "What about the management cost?" What management costs? Are you referrining to the costs of doing business? The costs of running a Datacenter? These are costs that will exist irregardles of what virtualization platform is chosen. I believe VMware virtualization has proven the ability to reduce these costs as much as possible in the flexibility of their hypervisor and management software. California's Pacific Gas and Electric Company (PG&E) understands the value of reducing Datacenter cost and engergy consumption and in 2006 they announced a rebate program worth up to $1 million per company for their virtualization efforts.
You ask "What about high availability?" I do not understand what you're questioning. I believe HA is important to every business small, medium, and large. I know that VMware offers multiple high availability tools such as VMware HA, VMware VMotion, VMware DRS, and VMware Storage VMotion. I understand Microsoft removed their hot migration tool from Windows 2008 HyperV in order to meet shipping deadlines for Windows Server 2008. This underlines the fact that Microsoft understands high availability and hot migration is important to the customer, but alas, it won't be available in 2008 for Microsoft customers.
You ask "What about cost of storage that supports VMotion on ESX?" VMware ESX Server is an enterprise solution. If a company needs a SAN to support their enterprise, it's up to them to weigh the cost benefits. Keep in mind ESX doesn't require a full fledged $500K or $100K shared storage SAN to take advantage of VMotion. Their are much cheaper SAN solutions that exist and let's not forget VMware ESX Server can utilize cheaper iSCSI and NAS for shared storage. I've been running VMware ESX Server in my lab off rPath OpenFiler Linux iSCSI target for 2 years realizing the beneifts of DRS, HA, VMotion, etc. How much does rPath OpenFiler cost? Nothing. The hardware is an HP Proliant ML570G2 with 12 146GB SCSI disks I scavenged from the boneyard.
You say "the list goes on". Please show me the rest of your list. Perhaps I could help you with your virtualization needs.
Jas
Posted by: Jason Boche | March 15, 2008 at 10:48 AM
Hi Jason,
Could you be willing to give a pointer(s) for more information about using OpenFiler for a VMware SAN??
Thank you, Tom
Posted by: Tom | March 20, 2008 at 10:06 AM
Something else to remember with overcommit attempts, you have to be running the same thing repeatedly in order to see this work well. As was pointed out in the other article : http://blogs.vmware.com/virtualreality/2008/03/memory-overcomm.html
All the vm's were running the same thing, the only real differences were not in the code segments, but in the data segments - ie, your dll's that stay static get their code space shared among vm's, while the data segements (ie, all the variable data that does tend to be radically different from instance to instance)does not get shared.
Posted by: Phillip Lessley | May 20, 2008 at 03:35 PM