vSphere High Availability can restart virtual machines after an ESXi host failure only if the surviving cluster has enough usable capacity. Admission control exists to protect that capacity before the failure occurs. It can block new power-ons or other operations when accepting them would reduce the cluster below the configured failover target.<\/p>\n
For 2V0-17-25<\/a> candidates and operators alike, the key idea is that HA detection and HA recovery are separate problems. Heartbeats may detect a failed host correctly, yet recovery can still fail if CPU or memory reservations leave no place to restart workloads. Admission control is the policy layer that prevents normal growth from consuming the capacity reserved for failure.<\/p>\n Current Broadcom guidance covers policies such as cluster resource percentage, dedicated failover hosts, and slot-based calculations. The right choice depends on how homogeneous the cluster is and how precisely the organization wants to express failover capacity.<\/p>\n Do not start by selecting a percentage in the vSphere Client. Start with the availability requirement: how many hosts can fail simultaneously while the business still expects all protected workloads to restart? That number should reflect maintenance overlap, hardware failure probability, and the consequence of partial service loss.<\/p>\n The design discipline in business impact analysis<\/a> matters here because reserving failover capacity has an opportunity cost. More reserved capacity means less capacity available for steady-state consolidation.<\/p>\n Translate the business requirement into cluster capacity with headroom for workload peaks, not average utilization.<\/p>\n Maintenance windows create a common hidden scenario: one host is intentionally unavailable when another host fails unexpectedly. If the business expects full service during rolling maintenance, the failover target should consider that overlap. Otherwise the cluster may meet its formal N-1 design only when every host is healthy before the incident.<\/p>\n HA admission control considers resource requirements rather than just the number of VMs. Large explicit CPU or memory reservations can make the cluster appear much more constrained than headline capacity suggests. One VM with an unusually large reservation can dominate slot-based calculations or reduce available failover percentage.<\/p>\n Review reservations before blaming HA for blocking a power-on. Confirm whether the reservation is required for performance or application support. Removing a reservation solely to make the warning disappear may trade an obvious capacity signal for a subtler performance problem.<\/p>\n Capacity planning should treat reservations as real commitments.<\/p>\n Percentage-based admission control reserves a share of aggregate CPU and memory for failover. It can be easier to reason about in clusters with varied VM sizes because it does not depend on one slot size representing every workload.<\/p>\n Set percentages according to the failure target and host distribution. In a homogeneous four-host cluster, losing one host suggests a different reserve than in a heterogeneous cluster where the largest host carries much more capacity than the others.<\/p>\n Review the percentage after hardware refreshes. Adding one very large host changes the cluster’s failure mathematics even if the host count barely changes.<\/p>\n Percentage values should be reviewed with the largest-host failure in mind. Reserving 25 percent in a four-host cluster can be misleading if one host contributes far more than a quarter of usable memory or CPU. The policy should reflect the actual capacity distribution and, where supported, the intended number of host failures rather than a convenient round number.<\/p>\n Slot-based admission control calculates a logical CPU and memory slot size from powered-on VM requirements and then determines how many slots hosts can provide. The current failover capacity is compared with the configured number of host failures to tolerate.<\/p>\n Slots can be intuitive in regular environments, but unusual reservations can inflate the slot size and make the cluster look under-provisioned. Administrators should inspect which workload is driving the calculation before changing the policy.<\/p>\n The broader VMware HA architecture<\/a> provides context for why this conservative behavior exists: the cluster is protecting the ability to restart workloads, not maximizing consolidation at all costs.<\/p>\n Review the slot calculation after adding a VM with an unusually large reservation. The apparent failover capacity can change sharply even though host hardware is unchanged. This is a useful signal that the workload’s guaranteed resource claim has altered the cluster’s ability to absorb failure.<\/p>\n A dedicated failover host policy sets aside one or more hosts primarily for HA recovery. This makes the reserved resource visible, which some organizations prefer for operational clarity. The trade-off is utilization: capacity may remain idle during normal operation.<\/p>\n Use dedicated hosts when the simplicity or compliance benefit justifies the cost. Ensure host hardware, networking, storage, licenses, and CPU compatibility allow the protected VMs to run there.<\/p>\n An idle host that cannot access a required datastore or network is not real failover capacity.<\/p>\n Dedicated failover hosts still need lifecycle maintenance. Patch them, test their storage and network access, and confirm firmware and CPU compatibility. Capacity that is reserved but operationally stale is worse than visible utilization because it creates confidence the cluster has not actually earned.<\/p>\n Passing admission control does not guarantee good performance after failover. A cluster may have enough reserved resources to power on every VM yet run them with severe contention. Recovery objectives should define not only whether workloads restart but also what degraded performance is acceptable.<\/p>\n Model N-1 or N-2 operations with real demand data. Include backup windows, patching, storage latency, and network bandwidth. If the degraded cluster is already saturated before a failure, the policy target is too optimistic.<\/p>\n Advanced cluster planning such as VCAP-DCV operational design<\/a> treats recovery capacity as a performance problem as well as an availability checkbox.<\/p>\n Use demand history from the busiest business periods. HA events do not wait for a quiet window, and a cluster that can survive a host failure only at average load has a fragile recovery design. Include memory overhead, reservations, and workload growth forecasts when deciding whether new VMs can be admitted.<\/p>\n Broadcom documents ‘Insufficient HA failover resources’ alerts when the configured failover target cannot be met. Disabling admission control removes the block, but it also removes the guarantee. The preferred response is to determine whether capacity, reservations, host count, or policy settings are mismatched.<\/p>\n Check for hosts in maintenance mode, disconnected hosts, large VM reservations, recent hardware changes, and workloads whose requirements increased. Confirm that all hosts intended for failover can access required networks and datastores.<\/p>\n Treat the warning as a planning signal before using the disable option as a troubleshooting shortcut.<\/p>\n If a warning follows a host replacement, compare the new host’s CPU generation, memory, networking, storage access, and compatibility with the other members. A nominally more powerful host can still reduce effective failover options if certain VMs cannot run there. Admission control exposes the capacity symptom, while compatibility analysis explains the root cause.<\/p>\n Many labs test HA by failing a host after temporarily disabling controls to make the demonstration easier. That proves less than a production test should. Test with the real admission policy, current reservations, and realistic load so the cluster demonstrates the recovery behavior it is supposed to deliver.<\/p>\n Observe which VMs restart, restart order, time to service, post-failover resource pressure, and rule interactions. If hard DRS rules or hardware requirements restrict placement, include them in the scenario.<\/p>\nBegin with the number of failures the service must tolerate<\/h3>\n
Understand what CPU and memory reservations do to the calculation<\/h3>\n
Cluster resource percentage fits mixed workloads well<\/h3>\n
Slot policy can be simple but sensitive to outliers<\/h3>\n
Dedicated failover hosts create clarity and stranded capacity<\/h3>\n
Admission control is not a substitute for capacity management<\/h3>\n
Resolve insufficient failover warnings by finding the cause<\/h3>\n
Test HA with admission control enabled<\/h3>\n