Cluster resource percentage, slot policy and dedicated failover hosts compared, with what each reserves.
From Ultra Transcenders 2V0-16.25 by Tony Rough (coming October 2026)
Restarting VMs only works if spare capacity exists when a host fails. Admission control reserves that capacity by refusing operations that would eat into it: powering on a VM, migrating a VM into the cluster or raising a VM’s CPU or memory reservation.
The administrator sets Host failures cluster tolerates and then picks how failover capacity is defined.
| Policy | How capacity is reserved | Points to remember |
|---|---|---|
| Cluster resource percentage | A percentage of total cluster CPU and memory is held back | Uses VM reservations; a VM with none counts as 32 MHz CPU (das.vmcpuminmhz) and 0 MB memory plus overhead; also requires at least two HA-enabled hosts |
| Slot policy (powered-on VMs) | Hosts are divided into slots sized for the largest CPU and memory reservations; capacity is how many hosts can fail and still leave enough slots | One large reservation inflates the slot size; cap it with das.slotcpuinmhz or das.slotmeminmb, or set a fixed slot size |
| Dedicated failover hosts | Named hosts are kept empty for failover | VMs cannot be powered on or migrated to them, DRS does not balance onto them, and restarts fall back to other hosts if they are unavailable |
| Disabled | No capacity reserved | Allows power-ons that break availability constraints; do not leave it permanently disabled |
Calculations use each host’s root resource pool, not its raw physical capacity, and count only hosts that are connected, not in maintenance mode and free of HA errors.
A worked percentage example from the documentation: three hosts provide 24 GHz and 21 GB to VMs; five powered-on VMs reserve 7 GHz and 6 GB. Current failover capacity is (24 - 7) / 24 = 70% for CPU and (21 - 6) / 21 = 71% for memory, so with 25% configured, 45% of CPU and 46% of memory remain for new power-ons.
“Performance degradation VMs tolerate” warns when a failover would leave VMs with less than their current usage. It is only available with DRS enabled. The default of 100% produces no warnings; 0% warns as soon as usage exceeds what would be available after a failure.
Common trap: Assuming VMs without reservations consume nothing in the percentage calculation - each powered-on VM is counted at its reservation or the 32 MHz CPU default plus memory overhead, so a cluster full of unreserved VMs can still look almost empty to admission control while actually being heavily used.
This note is one section of Ultra Transcenders 2V0-16.25: VMware vSphere Foundation 9.0 Administrator, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Broadcom TechDocs.
Due on Amazon in October 2026, in Kindle and paperback editions.
About the book · 2V0-16.25 terms in the glossary · All 2V0-16.25 study notes
What VVF 9.0 includes, what only VCF 9.0 adds, and where the two share a code base.
Storage pools or disk groups: the hardware, memory and network each vSAN architecture needs, and how failures differ.
The rules in a vSAN storage policy, their defaults, and how mirroring compares with erasure coding.
Per-host or vCenter-managed networking, and the features only a distributed switch brings.
How each library type gets and shares its content, and when subscribers download items.
The two vSAN encryption services, the threat each addresses and which one needs a key provider.
Node layouts, failure protection and latency limits for each VCF Operations cluster model, and how a VVF platform reaches them.