It’s easy to provision additional VMs and increase resource commitment from your overall resource pool using the vSphere web portal. Maybe too easy. If you overstretch your resources, some features like High Availability failover may not function as planned. HA keeps your VMs from failing by pooling VMs and hosts in a cluster, relaunching failed VMs on alternate hosts.
Overcommitting resources can also lead to general performance problems, so it is in your best interest to use Admission Control to keep a close watch on overall capacity. Another reason? You might be trying to power on new VMs, only to run into errors as you exceed your Admission Control rules. Tweaking them can save you from buying additional host resources.
This post will introduce the concepts of slot sizes and configuration of Admission Control to allow more VMs to move between hosts when you have turned on High Availability in vSphere/vCenter.
To access VMware High Availability settings, right click your Cluster in the Inventory panel of the vSphere Client, and then click Edit Settings. Choose VMware HA. From here, you’ll see some configuration settings for Admission Control near the bottom of the screen. There are three types:
They are all fairly self-explanatory. Setting the first option to “1,” for example, means that the equivalent of a single host is kept as a standby resource in case of VM failure. The host, of course, depends on the underlying hardware at your cloud service provider or within your own data center facility. The host server could be a 5 Ghz CPU and 80 GB RAM, or it might be 20 Ghz CPU and 384 GB RAM.
This is essentially applying the concept of “N+1” to your virtual infrastructure. If your entire cluster of VMs dies, you have the capacity to completely failover. If your virtual data center is running across 10 hosts, then for an N+1 HA design you would enter “10.” In order to guarantee you have enough resource capacity, vSphere uses “slots.”
Each Slot is equal to the biggest VM you have reserved — so if you have three VMs that are 1 Ghz and 2 GB memory, and a couple VMs that are 4 Ghz and 8 GB memory, your Slot would be 4 Ghz / 8 GB. By default the Slot is set at 32 Mhz and 0 MB (this is only if you have no resources reserved for VMs).
Image source: VMware video on HA
You can view your Slots by clicking the Cluster Summary tab and then Advanced Runtime Info.
You’ll also see there are two settings for “Define failover capacity by static number of hosts.” The default is to cover all powered-on VMs, based on the slot size as defined above. The second is the specify a fixed slot size, which we’ll get to momentarily.
Talk to an infrastructure consultant today.
Reserving resources for your VMs guarantees that they will have a certain amount of memory or CPU power allocated to them. It also guarantees that memory will come from the physical resources — if you do not reserve your VM memory, it can instead pull from the VM swap file, which can hurt your performance.
However, if your hosts have plenty of room, which they should, this will rarely be a problem.
If you followed the logic from above, you’ll see that a failover situation can get tricky if you have used a reservation for one of your larger VMs. In this case, you might have a very performance-intensive VM that needs way more CPU and RAM juice than your other workloads. If it is reserved, then your failover host will think it can only fit a few of these VMs, when really it could failover your single large VM as well as all of your other smaller ones. This is because the Slot size is tied to your largest VM.
This is where you can manually change your Slot size in order to allow all of your machines to move to a new host in the case of failure. Under the HA settings, Choose “Define failover capacity by a static number of hosts,” enter your desired host number, and then select “Fixed slot size.” After you configure this for your desired size, you can click Calculate to see the number of VMs that will require multiple slots. However, HA will not halt the failover at the automatic slot limit any longer.
Another option is to avoid using Reservations unless necessary, in which case HA will default to the normal, tiny slot size, and your VMs should all move to the new host.
In some cases, you may need to disable Admission Control completely — as when overprovisioning VMs beyond the total resources allowed. In this case you must set a HA priority level for each VM to ensure that critical workloads are moved to new hosts first in the case of a failure.
Some additional best practices for Admission Control as recommended by VMware:
You can learn more about using vSphere HA in the VMware knowledge base.