Virtualizing critical apps – Reserve memory when there is no RAM overcommitment?

I get this question a lot, should I have memory reservation for critical apps even if I am plentiful on RAM and there is no over commitment?

VMware’s best practice for virtualizing critical applications is to reserve the VM’s memory to prevent a situation of memory being balloned or swapped out, this is detailed in many guides for different applications best practices, see here: https://www.vmware.com/business-critical-apps/ .

The question I am being asked a lot is “If I have plenty of RAM should I set memory reservations as well?” the short answer is yes

But, there is no technical reason to do that though, if you have enough RAM ESXi will not balloon or swap your memory out, this is done only when ESXi reaches the em.MinFreePct  “Soft” threshold of the memory sliding scale function, (see this article for more information on the sliding scale function http://blogs.vmware.com/vsphere/2012/05/memminfreepct-sliding-scale-function.html) (update July 2015 – the memory states in vSphere 6 changed a bit, read about it in this excellent post by Duncan Epping http://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/)

So why set RAM reservation in that case? The answer is future proof it (or idiot proof it if you’d like). If in any case in the future ESXi reaches the “Soft” threshold,  memory reservation will protect your application performance. what can cause this situation on a well designed system with no overcommitment?:

1. Human error – someone who dont follow the operational methodology for critical apps and overload the server.

2. Multi server HA event – there could be a situation that there are multi servers failing in a number that is over your HA admission control policy, in this case vSphere will try and bring the VMs up on a best effort potentially affecting your resource policies.

So why not set reservations for the CPU then? VMware’s recommendation for CPU is to make sure there is no overcommitmant by not allocating more vCPU then physical cores on the server but not to set reservations, unlike RAM CPU is not a pool of resource but a queue that service one thread at a time, if CPU access is being taken from your VM because of the reasons listed above and you change the shares of your VM to allow more access to your critical VM the result is immediate whereas on memory it will take time to get memory taken out back. Setting reservations on CPU will limit the ESXi scheduler from doing its job in the most efficient way in regular times.

To conclude this, setting reservations will make sure your critical VMs are protected from memory being taken from them and it needs to be set even if you have plenty of memory to go around.   Niran