A Prism Central admin is sizing AHV hosts for a VM cluster that must survive a host failure. What should be configured so placement decisions account for failover capacity?
Select an answer to reveal the explanation.
Short Explanation
Think of reservations like putting a deposit on CPU and memory: if you don’t reserve the room, failover can’t guarantee the seat. Shares and limits are useful, but they don’t tell you whether another host can actually absorb the workload. You plan HA by reserving what the VM needs, then checking the spare capacity.
Full Explanation
Reservations declare the CPU and memory a workload must have available, so they are the resource-management setting that supports capacity-aware placement for HA failover. When you size reservations to match guaranteed workload demand, the cluster can be evaluated as if those resources are committed; you can then ask whether the remaining hosts have enough unreserved capacity to absorb the failed host’s reserved workloads. This turns failover planning into a deterministic capacity check rather than a best-effort scheduling guess. Limits are wrong because they cap maximum consumption and protect other tenants, but they do not guarantee that a VM can be placed or restarted. Shares are wrong because they only change relative scheduling priority when resources are contended, and they provide no capacity headroom for a host failure. Anti-affinity rules are wrong because they spread VMs across hosts to reduce correlated failure, yet they do not verify that the target hosts can actually satisfy the reserved CPU and memory after failover. Exam caveat: distinguish guaranteed capacity, scheduling priority, and placement spread. Operational check: total the VM reservations for a cluster and compare that number with the available capacity of the remaining hosts after removing the largest host.