Memory overcommitment on VMware ESXi 5.0

Solution 1:

More (moar) RAM is always better, if the path to obtaining it is clear. In most VMWare deployments, you'll run out of RAM far sooner than your CPU resources.

I'd suggest providing the lowest reasonable amount of RAM for each specific VM, making sure the VMWare tools are installed and running within each VM. This controls the balloon driver.

One way of approaching a RAM-constrained environment is to set basic resource allocation (share) rules. These only come into play when contention occurs. In the graphic below, I've lowered the "Shares" priority for several VMs and increased it for others. This allows you to control which VMs take precedence when the RAM is tight.

If you use this approach, you'll have to make decisions about the relative importance of the VMs. An application server may take precedence over a DHCP server... or an idle Windows XP instance.

Solution 2:

(everything ewwhite said) plus:

Memory overcommit will probably not help you at all, as you're going to run a mix of different sets of data in RAM (different operating systems). It only helps when you have lots and lots of nearly identical stuff in data (like a big VDI server where everyone has the exact same master image).