Memory overcommit, the basics.

In short: When you assign more RAM to your VMs than available in your host.

Good memory overcommit: When you assign more RAM to your VMs than available in your host BUT never cross the line where the amount of RAM that is USED by your VMs is more than available in your host.

Bad memory overcommit: When you assign more RAM to your VMs than available in your host AND cross the line where the amount of RAM that is USED by your VMs is more than available in your host.

A simple example:
Host has 48GB of RAM and just for the sake of argument we’ll pretend the hypervisor doesn’t use any RAM and we don’t have memory overhead per VM. I now start loading it with VMs that have 4GB RAM assigned. Without any memory overcommit I can load this host with 12 VMs of each 4GB.

Now let’s say, these VMs normally use only 2.5GB of RAM but sometimes they peak to 4GB. With memory overcommit I could now load the host with 19 VMs of 4GB RAM assigning a total of 76GB RAM and demanding 19 x 2.5GB = 47.5GB of physical memory. Even to me this is a bit on the edge, so I’d reserve some RAM for spikes and would go back to 17 VMs, which would leave me with 17 x 2.5GB = 42.5GB of actively used physical RAM, 17 x 4GB = 68GB of RAM assigned and therefore 68GB-48GB = 20GB of overcommitted RAM. So, 20GB of RAM I didn’t have to pay for. This is a good use of memory overcommit.

Bad use of memory overcommit is when in the previous example I would place more VMs on this host, to the point where the use of physical RAM is higher than the amount of physical RAM present in the host. ESX will start some memory optimization and reclaim techniques, but in the end it will swap host memory to disk, which is bad. It is essential to carefully monitor your hosts to see if you’re moving from good memory overcommit to bad memory overcommit.