I work with a Managed Service provider and we sell virtual servers as a service to our customer installed base. All resources are sold incrementally for CPU and MEM. We do not currently have options for selling priorities via the use of shares or greater reservations per VM. We built our cluster with oversubscribing resources in mind and thus we created reservations per VM of only 50% of actually provisioned resources. We are finding that the actual VM useage rates are much less than 50% but our reservations have now exceeded our adminision control limits limiting our DRS and upgrade process for evacuating a Host by moving all VMs to other Host in a cluster. We have to remove the reservation to complete Vmotion and Host evacuation drills, even with allow admission control to be exceeded.
My question is within an environment in which all guest are to be treated as equals regarding the ability to access CPU and Memory resources does it even make sense to create reservations per VM? With these circumstances are reservations still a way to provide gaurenteed resources to VMs and maybe we should look to reduce the res to 25%??
Of course reservations are still a way (the way, actually) to guarantee minimum settings. But you have discovered something in managing your environment that I see broadly across large numbers of our customers: no one uses the amount of CPU they think they do.
CPU reservation settings are not very common. Reservations are very important if you want to protect a one or more VMs from the demands of a large group. But, as you have discovered, setting reservations for all is protecting them all the same. Protecting everything the same is not really protection. I recommend that you do away with the CPU reservations except for a few important VMs.
Memory is a little different. Guest OSes will expand to use all of the memory you provide them, which is unlike CPU and can be wasteful. We recommend setting memory reservations for VMs to match the amount of memory you know the guest will use: the OS (100-300 MB), the applications (20-150 MB), and critical cache/heap. This guarantees that the balloon driver does not encroach into critical memory and that these pages will never be swapped out by ESX. But you can safely size the memory of the VMs far beyond this reservation.
More information on my blog and on Twitter: