Use this estimate to explain a VM allocation budget, then validate it against workload measurements and platform admission control. The calculator assumes equal-sized VMs on one host. It does not benchmark CPU demand or calculate a complete cluster design.
1. Define the host and VM allocation
Our example host has 32 physical CPU cores and 128 GiB RAM. Reserve 8 GiB for the host and supporting services. Each VM receives 4 vCPUs and 8 GiB RAM. The chosen CPU allocation ratio is 2:1. These are illustrative inputs, not recommended defaults for your workload.
2. Calculate CPU and RAM limits separately
Scroll the table sideways if any columns are hidden.
| Limit | Calculation | Whole VMs |
|---|---|---|
| CPU allocation | floor(32 × 2 ÷ 4) | 16 |
| RAM allocation | floor((128 − 8) ÷ 8) | 15 |
| Combined ceiling | smaller of 16 and 15 | 15 |
Open the VM Capacity worked examples, load “RAM limits a 32-core host”, then choose Calculate. The result is 15 VMs, limited by RAM. The floor operation rounds each resource limit down because a fraction of a VM does not satisfy the allocation.
3. Test a different CPU allocation policy
Load the second example to change the CPU ratio to 1:1. CPU now permits floor(32 × 1 ÷ 4) = 8 VMs, while RAM still permits 15. The combined answer is eight. The host has not become slower; you have changed the allocation policy.
Use the CPU Overcommit Calculator to inspect a vCPU-to-core ratio. An overcommit ratio permits more allocated vCPUs; it does not add physical processing capacity. The RAM Overcommit Calculator describes allocation too, not proof that every VM can use its full allocation simultaneously. This single-host model does not add a RAM overcommit factor.
4. Check failover as a separate constraint
For an illustrative cluster of three identical hosts with this same 15-VM allocation ceiling, losing one host leaves two hosts and an aggregate ceiling of 30 such VMs. A cluster containing 36 VMs would need 18 on each survivor in an even distribution, exceeding the illustrated RAM budget. Even 30 is only an arithmetic ceiling: placement restrictions, reserved failover capacity, restart overhead and uneven workload demand can require a lower limit.
The calculator does not perform this cluster calculation automatically. Check actual high-availability admission rules, NUMA placement, CPU contention, storage latency, network capacity, licensing and per-VM overhead. Measure ordinary and peak demand; avoid treating low average CPU utilisation as proof that bursty workloads can safely share a host.
5. Record evidence before a change
Keep the input units, reservation policy, workload measurements and one-host-failure scenario with the capacity review. Re-run the arithmetic when VM sizes or host resources change. A successful calculator result does not establish application performance, service availability or a recovery-time objective.