VM consolidation & overcommit calculator
How many hosts does your VM fleet need? Sized from vCPU overcommit and RAM, the two constraints that actually decide it, with N+1/N+2 failover included and a comparison across overcommit ratios, so you can see exactly what a denser ratio buys you and what it risks.
Cluster size
Same fleet at other overcommit ratios
| Ratio | Hosts (incl. failover) | VMs / host | Suits |
|---|
How it's calculated
Hosts needed is the worse of two constraints. CPU: ceil(total vCPUs / (cores × ratio × (1 − reserve))). VCPUs are time-shared, so overcommit is normal and healthy; the right ratio depends entirely on how busy the vCPUs actually are. RAM: ceil(total RAM / (host RAM × (1 − reserve))). Memory is not time-shared, and this model deliberately refuses to overcommit it: ballooning and swapping are failure modes, not capacity plans. In most real fleets RAM is the binding constraint long before CPU, which the result above will happily demonstrate.
The failover option reserves N+1 or N+2 hosts' worth of capacity so the cluster survives a host failure or a maintenance window at full load. The same logic as VMware HA admission control or Proxmox HA groups. Without it, losing one host means memory pressure everywhere at 3 a.m.
On ratios: 1:1 is for latency-critical or licensing-bound workloads (databases, RT systems), 3–5:1 fits mixed server fleets with typical 10–30% average CPU busy, and 6:1+ is defensible only for dev/test or VDI with proven low usage. Counting physical cores rather than SMT threads is intentional: hyperthreads add roughly 20–30% throughput, not 100%, so treating them as cores silently doubles your real ratio. If CPU ready time (or steal) climbs above a few percent, your ratio is too optimistic. Measure, then densify.