Recently I had to prepare a business case on virtualization for a client and, while collecting data and writing the document, I realized that one of the key point those pushing for VMware often use is actually not suitable for production environments servers. I’m talking here about memory overcommitment which VMware has been using intensively to promote their virtualization solution. Memory overcommitment basically consists of assigning an amount of memory to several VM’s while the total amount of allocated memory is greater than what is physically available on the host system.

This is technically possible because in most case VM’s are not using the total allocated memory, thus allowing for more VM’s on a single host. However, if you are thinking of implementing High Availability and have the ability to “live migrate” VM, memory overcommitment does not make sense.  If you overcommit memory on hosts and a member of a cluster has a major problem, you won’t have enough resources available for you failed VM’s to be loaded. This alone makes memory overcommitment irrelevant for a production environment.

VMware also state the following in their Performance Tuning Best Practice for EXS server:
Make sure the host has more physical memory than the total amount of memory that will be used by ESX plus the sum of the working set sizes that will be used by all the virtual machines running at any one time.

With this in mind and considering here that we are talking about production environment in which you will want to have High Availability capability, there is no way memory overcommitment can be used as an “advantage” of VMware. In most scenarios I’ve seen on the Internet, people compare VMware with overcommitment vs. Microsoft Hyper-V, but in a real world production environment, you cannot consider these scenarios. Of course, for a development or test environment were High Availability, failover or live migration are less critical, you could consider memory overcommitment but you would still have to keep a close eye on usage.