VMware HA Capacity Calculator

Check vSphere HA admission control: how much capacity a percentage or N+1 slot policy reserves and whether restarts actually fit.

About VMware HA Capacity Calculator

Admission control reserves capacity in one of two shapes: a flat percentage of cluster CPU and memory, or slots sized so that losing N hosts still leaves room. Both reduce to the same test — cluster capacity minus current demand must exceed the demand of the VMs that were running on the hosts you are prepared to lose, checked separately for CPU and for memory. HA that cannot restart a host's worth of VMs is a false sense of safety, and the failure is silent until the day a host dies; equally, an over-generous reserve blocks legitimate power-on operations with an insufficient-resources error.

Formula

VMware HA Capacity

reserve = failover hosts ÷ total hosts; restart demand = ceil(VMs ÷ hosts) × failover hosts × average VM demand, which must fit in cluster capacity minus current demand.

failover hosts: Hosts whose workload must be absorbed by the survivors
reserve: Fraction of the cluster admission control holds back
restart demand: CPU and memory needed to power the failed host's VMs back on

Worked example

With the default values below, VMware HA Capacity Calculator returns Spare Cluster Capacity of 50.1%. Change any input above and every figure here is recalculated in your browser.

Inputs used

Hosts in clusteraccepts 2–96 hosts: 8 hosts
CPU capacity per hostaccepts 1–2,000 GHz: 83.2 GHz
Memory per hostaccepts 8–24,576 GiB: 512 GiB
ESXi host memory overheadaccepts 0–20 %: 6 %
Powered-on VMsaccepts 1–20,000 VMs: 160 VMs
Average CPU demand per VMaccepts 50–64,000 MHz: 900 MHz
Average memory per VMaccepts 0.25–6,144 GiB: 12 GiB
Admission control policyone of Slot policy — tolerate 1 host failure (N+1), Slot policy — tolerate 2 host failures (N+2), Percentage of cluster resources reserved: Slot policy — tolerate 1 host failure (N+1)
Percentage reserved (percentage policy)accepts 0–60 %: 25 %

Results

Spare Cluster Capacity: 50.1%
Reserve Demanded by Policy: 12.5%
VMs to Restart After Failure: 20 VMs
CPU Headroom After Reserve: 438.4 GHz
Memory Headroom After Reserve: 1,449.0 GiB
Admission Control Verdict: Failover capacity is sufficient with room to power on more VMs

Step by step

1Values used
2VMware HA Capacity
3Spare Cluster Capacity= 50.1
4Reserve Demanded by Policy= 12.5
5VMs to Restart After Failure= 20 VMs
6CPU Headroom After Reserve= 438.4 GHz
7Memory Headroom After Reserve= 1,449.0 GiB
8Admission Control Verdict= Failover capacity is sufficient with room to power on more VMs

Assumptions and limits

The result is derived only from the 9 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is VMware HA Capacity calculated?

reserve = failover hosts ÷ total hosts; restart demand = ceil(VMs ÷ hosts) × failover hosts × average VM demand, which must fit in cluster capacity minus current demand. Admission control reserves capacity in one of two shapes: a flat percentage of cluster CPU and memory, or slots sized so that losing N hosts still leaves room. Both reduce to the same test — cluster capacity minus current demand must exceed the demand of the VMs that were running on the hosts you are prepared to lose, checked separately for CPU and for memory.

Why does VMware HA Capacity matter?

HA that cannot restart a host's worth of VMs is a false sense of safety, and the failure is silent until the day a host dies; equally, an over-generous reserve blocks legitimate power-on operations with an insufficient-resources error.

What values do I need to enter?

This calculator takes 9 inputs: Hosts in cluster, CPU capacity per host, Memory per host, ESXi host memory overhead, Powered-on VMs, Average CPU demand per VM, Average memory per VM, Admission control policy, Percentage reserved (percentage policy). The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why should the reserve be sized against the largest host?

With mixed hardware, a percentage reserve calculated from the cluster average is too small when the biggest host fails. Size the reserve so the single largest host's workload fits, then convert that back into a percentage.