Whether you land on Proxmox, Nutanix, Azure Local or XCP-ng, the first number that decides your project cost is the host count. Get it wrong and you either overspend on idle steel or under-provision and lose resilience. This page explains, in plain terms, how a replacement cluster is sized from a VMware estate — and the calculator below turns that method into an exact figure for your VMs.
| VMs | Hosts | VMware VCF / yr | Proxmox VE / yr | 3-yr saving |
|---|---|---|---|---|
| 50 | 3× | £50,304 | £2,820 | £142,452 |
| 100 | 4× | £67,072 | £3,760 | £189,936 |
| 250 | 8× | £134,144 | £7,520 | £379,872 |
| 500 | 15× | £251,520 | £14,100 | £712,260 |
All figures are indicative estimates for planning only and subject to change; licence prices vary by reseller and deal size, and any monthly finance figure is subject to credit approval — not a quotation.
Start with the resource your estate really consumes
A host count is never a guess — it is derived from what your VMs actually demand. Total vCPU across the estate, divided by a realistic consolidation ratio, gives the physical cores you must land on the floor. Total RAM and total provisioned storage are summed the same way. Because vCPU-to-core overcommit hides real pressure, this step is where most in-house estimates drift: an aggressive ratio understates cores, while ignoring memory or capacity understates the other two dimensions entirely.
Take the greater of CPU-, RAM- and storage-bound counts
The heart of the method is that a cluster is sized three ways at once. Divide required cores by usable cores per host and you get a CPU-bound count; do the same for memory and for capacity and you get RAM-bound and storage-bound counts. The cluster must satisfy whichever is largest — the binding constraint. Many VMware estates turn out RAM-bound or, on hyperconverged targets where replication multiplies raw capacity, storage-bound, which quietly pushes the node count above the CPU maths alone.
Add N+1, then choose a per-host spec
Sizing to the workload is not enough: lose a node during patching or a failure and the survivors must absorb its VMs without tipping into contention. That is why N+1 (or N+2 for larger estates) is added on top of the workload hosts, and why a target utilisation ceiling leaves headroom rather than running flat out. Only then do you fix the per-host recipe — cores, memory and NVMe per node. Denser hosts cut the count but concentrate risk; the calculator lets you trade the two live.
FAQs
How is the number of hosts to replace VMware actually calculated?
Total vCPU divided by your consolidation ratio gives required physical cores; total RAM and total storage are summed the same way. Each is divided by the usable capacity of one host to give a CPU-, RAM- and storage-bound count. You take the greatest of the three, then add N+1 for resilience. The calculator does this instantly for your estate.
Why might I need more hosts than a simple vCPU calculation suggests?
Because CPU is often not the binding constraint. Memory-heavy estates go RAM-bound, and hyperconverged platforms replicate data, so raw storage can exceed usable and make the cluster storage-bound. The method sizes all three dimensions and picks the largest, so the real host count can sit well above what a core-only sum implies.
What consolidation ratio should I use for the sizing?
Use the ratio your workloads genuinely sustain, not a vendor headline. Mixed general-purpose estates often run comfortably, but latency-sensitive or CPU-heavy VMs need a conservative figure. A too-aggressive ratio understates cores and produces an undersized, contention-prone cluster. Validate against real CPU-ready and contention data before committing, then confirm with a Servnet scoping call.