Virtualization Host Capacity Calculator

Limiter {{ resultsReady ? computation.values.artifacts.limiter : '—' }} Runway {{ resultsReady ? formatSigned(computation.values.analysis.runway_vm, 'VM') : '—' }} Posture {{ resultsReady ? computation.values.artifacts.risk_band : '—' }}

Workload preset:

Presets update the visible VM shape, overcommit, utilization, and scheduling fields.

Hosts in cluster:

Whole hosts from 1 to 512.

hosts

Failure tolerance:

Use 0 for no failure reserve, 1 for N+1, or 2 for N+2.

N+hosts

Maintenance reserve:

Failure plus maintenance reserves must leave at least one active host.

hosts

Physical cores per host:

Use homogeneous host cores for this planning run.

cores

Host CPU reserve:

Must stay below physical cores per host.

cores/host

Memory per host:

Use installed GiB for homogeneous hosts.

GiB

Host memory reserve:

Must stay below memory per host.

GiB/host

Average VM vCPU:

Model outsized guests separately in Advanced.

vCPU

Average VM memory:

The per-VM overhead below is added before memory density is calculated.

GiB

Per-VM memory overhead:

Use 0 only when overhead is already included in average VM memory.

GiB/VM

Current VM fleet:

Use 0 when sizing a new cluster.

VMs

Projected VM target:

The host search is bounded at 512 total hosts.

VMs

CPU overcommit:

Validate CPU ready and co-stop telemetry before increasing this ratio.

vCPU:pCPU

Memory overcommit:

Keep conservative for pinned, database, boot-storm, or swap-sensitive workloads.

CPU utilization cap: {{ formatNumber(cpu_target_utilization_pct, 0) }}%

From 40% to 95%.

Memory utilization cap: {{ formatNumber(memory_target_utilization_pct, 0) }}%

From 40% to 95%.

Scheduler and NUMA penalty: {{ formatNumber(scheduler_penalty_pct, 0) }}%

Use higher values for mixed or fragmented clusters.

Ballooning safety buffer: {{ formatNumber(ballooning_buffer_pct, 0) }}%

Use 0 only when the risk is already excluded from the memory policy.

Growth reserve: {{ formatNumber(growth_reserve_pct, 0) }}%

Final procurement and organic-growth headroom.

Largest VM vCPU:

The neutral default is 0; enter a positive shape only when placement must be modeled.

vCPU

Largest VM memory:

The neutral default is 0 GiB.

GiB

Largest VM cohort:

The neutral default is 0; both shape fields must be positive when the cohort is enabled.

VMs

NUMA nodes per host:

Used only when the largest-VM cohort is enabled.

nodes

Failure envelope depth:

Changes ledger coverage only, not the selected N+ policy result.

Display precision:

Changes presentation rounding only.

{{ row.label }}{{ row.display }}

Policy calculation:

The lower CPU or memory VM count is reduced once by the selected growth reserve.

safe VMs = floor(min(CPU VM limit, memory VM limit) × (1 − growth reserve))

{{ row.label }} {{ row.value }} {{ row.note }}

The chart renderer is unavailable. The same host rows remain available through the chart CSV and failure envelope.

Failed hosts	Active hosts	CPU limit	Memory limit	Safe ceiling	Runway	Limiter	Copy
{{ formatNumber(row.failed_hosts, 0) }}	{{ formatNumber(row.active_hosts, 0) }}	{{ formatNumber(row.cpu_vm_limit, 0) }} VMs	{{ formatNumber(row.memory_vm_limit, 0) }} VMs	{{ formatNumber(row.safe_vm_ceiling, 0) }} VMs	{{ formatSigned(row.runway_vm, 'VM') }}	{{ row.limiter }}

A cluster that looks roomy during normal operation can become crowded as soon as a host fails or another host is drained for maintenance. Capacity planning therefore starts with the hosts that must remain available under the chosen failure policy, not the total number installed.

CPU and memory also behave differently. Virtual CPUs can be overcommitted when workloads do not peak together, while memory overcommit can expose guests to reclaim or swapping when demand rises. The smaller of the two resource limits controls ordinary VM density. Growth headroom is then removed so the calculated ceiling is not also the operating target.

Failure tolerance: The number of failed hosts the remaining cluster must absorb, such as one host for N+1.
Maintenance reserve: Hosts deliberately held outside VM capacity for patching, evacuation, firmware work, or other planned outages.
Overcommit: The planned amount of guest CPU or memory assigned for each unit left on the active hosts.
Placement: Whether each large guest can fit on one surviving host, and preferably within one non-uniform memory access (NUMA) node.

Average density cannot prove that every VM can be placed. A cluster may have enough aggregate CPU and memory while an unusually large database VM fits nowhere after failover. Storage capacity, network throughput, licensing, affinity rules, hardware differences, and platform limits can impose further constraints that are outside a CPU-and-memory estimate.

A useful capacity plan combines measured workload demand with an explicit recovery policy. Preset ratios can start a discussion, but production decisions should be checked against scheduler data, CPU ready or co-stop time, memory pressure, boot storms, and a real evacuation test.

How to Use This Tool:

Model one homogeneous host pool at a time and use the policy that must still work during the intended maintenance or failure event.

Choose a Workload preset, then enter Hosts in cluster, Failure tolerance, and Maintenance reserve. The two reserves must leave at least one active host.
Enter installed cores and memory, their host reserves, and a representative ordinary VM shape. Include Per-VM memory overhead unless it is already part of the average guest memory.
Set CPU and memory overcommit, utilization caps, scheduler penalty, ballooning buffer, and growth reserve from observed behavior. Open Advanced to model a large-VM cohort and NUMA placement when averages would hide it.
Compare Safe VM ceiling with the current and projected fleet, then inspect Failure envelope. A negative runway, a placement warning, or a projected shortfall needs resolution before the plan is used.

Interpreting Results:

Safe VM ceiling is the lower CPU-or-memory limit after the growth reserve. It is a policy estimate, not a guarantee that every workload will meet its service target.
Runway compares that ceiling with the current fleet. Projected gap makes the same comparison with the planned fleet; a value below zero is a shortage.
Limiter names CPU or memory as the first aggregate constraint. It does not rule out storage, network, licensing, or placement constraints.
Placement status takes priority over a favorable average density when a declared large guest cannot fit on one surviving host or one NUMA node.
Risk band summarizes the calculator's own planning penalties. It is not a vendor certification or a measured reliability score.

Technical Details:

Host capacity is calculated after failed and maintenance-reserved hosts are removed. Both CPU and memory pools are discounted for the selected policy, converted to whole-VM limits, and compared. Only then is growth headroom removed.

Formula Core:

The equations below show the ordinary-VM path. Each floor operation discards a partial VM because capacity is reported as a whole-guest count.

\begin{array}{lcl} H_{a} & = & H - F - M \\ C_{cpu} & = & H_{a} \times (p_{h} - p_{r}) \times O \times U_{c} \times S \\ C_{mem} & = & H_{a} \times (r_{h} - r_{r}) \times Q \times U_{m} \times S \times (1 - B) \\ N_{hard} & = & \min (⌊ \frac{C_{cpu}}{p_{v}} ⌋, ⌊ \frac{C_{mem}}{r_{v} + r_{o}} ⌋) \\ N_{safe} & = & ⌊ N_{hard} \times (1 - G) ⌋ \end{array}

Virtualization capacity formula symbols
Symbol	Meaning	Unit or form
H, F, M	Total hosts, failed hosts, and maintenance-reserved hosts	hosts
p_h, p_r, p_v	Physical cores per host, reserved cores per host, and vCPU per ordinary VM	cores or vCPU
r_h, r_r, r_v, r_o	Host memory, host reserve, guest memory, and per-VM overhead	GiB
O, Q	CPU and memory overcommit ratios	ratio
U_c, U_m	CPU and memory utilization caps entered as fractions	0 to 1
S, B, G	One minus scheduler penalty, ballooning buffer, and growth reserve	fraction

Rule Core:

Large-VM placement is evaluated after the same failure policy. Per-host CPU and memory budgets are divided by the number of active hosts. A large guest must fit within one host; fitting within one NUMA node is reported separately. The declared cohort consumes whole host-local slots before remaining capacity is filled with ordinary VMs.

The planning score adds the penalties below and caps the total at 100. Boundaries belong to the higher band at 25, 50, and 75.

Virtualization capacity planning risk rules
Condition	Points
Failure tolerance is 0 hosts	12
CPU overcommit is greater than 6, or greater than 4.5 through 6	20 or 10
Memory overcommit is greater than 1.35, or greater than 1.15 through 1.35	18 or 8
CPU utilization cap is greater than 85%	10
Memory utilization cap is greater than 85%	10
Scheduler and NUMA penalty is greater than 10%	8
Growth reserve is less than 10%	12
Current fleet exceeds the safe ceiling, or nonnegative runway is less than 10% of that ceiling	30 or 12

Scores below 25 are Conservative; 25 through 49 are Balanced; 50 through 74 are Aggressive; and 75 or more are Stressed. A current shortage or placement failure outranks that band in the recommendation. The minimum-host search tests whole host counts through 512 and reports the first count whose safe ceiling meets the fleet target.

Full precision is retained for policy pools and density. Whole-VM limits and the final safe ceiling are floored at their stated stages. Display precision changes presentation only.

Accuracy Notes:

This is a deterministic planning model built from the entered assumptions. Presets and risk points are calculator-specific planning rules, not universal limits published by a hypervisor vendor.

Use separate runs for heterogeneous hosts, pinned guests, dedicated-device VMs, or workload groups with materially different demand.
Replace assigned-size averages with measured working-set and contention data when possible.
Confirm storage, network, licensing, affinity, NUMA, and vendor scale limits independently before procurement or evacuation.

Worked Examples:

Ten-host N+1 cluster with maintenance reserve

Ten 32-core, 512 GiB hosts with one failed host and one maintenance host leave eight active hosts. Using the General Server policy, the CPU pool supports 342 ordinary VMs and memory supports 403. CPU therefore limits the hard ceiling to 342; a 15% growth reserve floors the safe ceiling to 290. Against 180 current VMs and a target of 220, the result shows 110 VMs of current runway and 70 above the projected target.

References:

Insufficient configured resources for the desired vSphere HA failover level, Broadcom.
Hyper-V maximum scale limits in Windows Server, Microsoft Learn, October 17, 2025.
How to add a host to OpenNebula, Simplified Guide.
How to remove a host from OpenNebula, Simplified Guide.