High Availability (HA) and Distributed Resource Scheduler (DRS) are the two features most vSphere admins configure once and rarely revisit — until a host fails at 2 AM and admission control quietly refuses to power on half your VMs. This is a practical rundown of how these features actually behave under pressure, and the settings that most commonly get misconfigured.
How HA Actually Decides to Restart a VM
HA works off a heartbeat mechanism between hosts and, since vSphere 6.0, a network-based secondary heartbeat through the management network and datastores. When a host stops responding, HA doesn't restart VMs immediately — it first tries to distinguish between an actual host failure and a network partition, since restarting VMs that are still running elsewhere causes a split-brain scenario.
The practical takeaway: your management network redundancy directly affects how reliably HA can tell the difference between "host is dead" and "host lost its network." A single NIC or single switch for management traffic is one of the most common causes of HA behaving unpredictably during real outages.
Admission Control Is the Setting Everyone Ignores
Admission control decides whether the cluster has enough spare capacity to guarantee VM restarts if a host fails - and it will refuse to power on new VMs if that reserved capacity is used up, even if the cluster still has physical resources free.
- Cluster resource percentage is generally the most predictable policy for mixed-workload clusters - it reserves a percentage of CPU/memory rather than reasoning about "slots," which avoids the over-conservative slot-sizing problems common in older vSphere versions.
- Host failures cluster tolerates (slot policy) can dramatically overestimate reserved capacity if even one VM in the cluster has a large reservation, since slot size is based on the largest reservation in the cluster.
- Whatever policy you choose, size it around N+1 or N+2 host failure tolerance based on your actual maintenance patterns - if you patch one host at a time, N+1 is often sufficient; if you lose hosts unpredictably in pairs (shared PDU, shared rack), plan for N+2.
DRS: Automation Level Matters More Than People Think
DRS load-balances VMs across hosts using vMotion, but the automation level you choose changes its behavior more than most of the underlying thresholds:
- Manual - DRS only suggests moves; nothing happens without an admin clicking "Apply." Rarely useful outside initial testing.
- Partially Automated - DRS places VMs automatically at power-on but won't move running VMs without approval. Useful in environments where unexpected vMotion could interfere with performance-sensitive workloads.
- Fully Automated - DRS both places and continuously balances VMs. This is the default most production clusters should run, but the migration threshold (conservative to aggressive) controls how much imbalance DRS tolerates before it acts - overly aggressive settings on clusters with bursty workloads can cause excessive vMotion churn.
VM-Host and VM-VM Affinity Rules
Affinity/anti-affinity rules are where DRS and HA intersect in ways that surprise people. An anti-affinity rule that keeps two VMs on separate hosts is a should rule by default (soft), meaning DRS will violate it under resource pressure unless you explicitly make it a must rule. During an HA failover, if your anti-affinity rules are hard constraints and there isn't enough valid host placement, HA can fail to restart a VM entirely — so hard rules should be used sparingly and only where genuinely required (e.g., separating cluster nodes of the same application).
A Quick Health-Check Checklist
- Confirm management network has at least two physically separate paths (NICs/switches).
- Re-validate admission control policy after any significant capacity change, not just at initial setup.
- Audit VM reservations - a handful of oversized reservations can silently distort slot-based admission control.
- Review DRS migration threshold against actual workload volatility, not defaults.
- Check for hard affinity/anti-affinity rules and confirm they won't block HA failover placement.
- Test HA with an actual host isolation/failure drill in a maintenance window - configuration on paper and behavior under real network partition are not always the same thing.
This is a living note - I'll expand it with real cluster telemetry examples and DRS log walkthroughs in a follow-up post.