VM Density & Host Sizing

Enter your real virtual machines, row by row. The calculator returns the hosts, their shape, the failover capacity N+1 or N+2 actually requires, and what high availability needs from the network and storage.

Add your virtual machines row by row — real configurations, not averages. The calculator sums them, applies your consolidation ratio and headroom, respects the per-host core and memory ceilings, and sizes the failover capacity high availability actually needs.

What it works out

Consolidation is arithmetic, and the interesting part is which constraint binds first. A database estate reaches the memory ceiling with cores to spare; a compute estate fills its cores with memory half empty. The tool names which, because that is what tells you what to change.

  • Total vCPU, memory and storage across every configuration
  • Physical cores after the overcommit ratio, memory at 1:1
  • Hosts required by CPU and by memory separately, and which binds
  • Per-host shape, spread evenly rather than filled to the brim
  • Failover capacity for N+1 or N+2, and what share of the cluster it costs

Why memory has no overcommit setting

CPU overcommit degrades under load. Memory overcommit takes an environment down: ballooning and swapping fail non-linearly and the damage lands on whichever machine is busiest. Memory is sized 1:1 here and the option to do otherwise is not offered.

What high availability actually requires

A spare host is not high availability. It needs storage every host can reach, a migration network fast enough that evacuation stays practical, heartbeat traffic on its own path, and no single switch or power feed in the way. All four are returned when HA is selected.

How virtualisation host sizing actually works

Consolidation is a CPU decision and a memory rule

Virtual machines share physical cores well. A vCPU is a scheduling entity, and most workloads spend most of their time idle, so two or three vCPU per physical core is routine for application estates and comfortable for VDI. Databases and latency-sensitive systems are the exception, and 1:1 is the honest setting for them.

Memory does not work that way, and the difference is not a matter of degree. A vCPU waiting for a core is slow; a virtual machine that cannot get the memory it was promised is a machine the hypervisor starts taking pages from, and the failure mode is an outage rather than a slowdown. This calculator has no memory overcommit setting, and that is deliberate.

  • 1:1 — no consolidation. Databases, real-time systems, anything with a latency SLA
  • 1:2 — the common setting for mixed application estates
  • 1:3 — VDI and bursty workloads, where most desktops are idle most of the time

Two ceilings, and only one of them binds

A host has a maximum core count and a maximum memory capacity, and an environment runs into one of them before the other. A database estate reaches the memory ceiling with cores to spare — those hosts are bought for RAM. A compute estate does the opposite and fills its cores while memory sits half empty.

Knowing which one binds tells you what to do about it. Memory-bound means a larger memory ceiling per host cuts the host count directly. CPU-bound means either bigger processors or, if the workloads genuinely tolerate it, a higher overcommit ratio. Sizing that reports only a host count hides the lever.

High availability is failover capacity, not a spare box

N+1 does not mean buying one more server and leaving it switched off. It means the cluster is sized so that when any one host fails, the survivors have the capacity to take everything it was running — the load spreads across fewer machines, and those machines must have been specified for that moment rather than for a normal Tuesday.

The useful consequence is that HA gets proportionally cheaper as the cluster grows. Protecting a three-host cluster costs a third of it. Protecting a twenty-host cluster costs five percent, for the same protection. A small cluster that needs HA is often better served by making the hosts smaller and buying more of them.

The requirement people discover last

High availability needs storage every host can reach. A virtual machine cannot restart on a surviving host if its disk only exists on the one that failed — so HA implies a SAN, an iSCSI or NFS array, or a hyper-converged layer spread across the hosts. That decision shapes the network, the budget and the failure behaviour of the whole cluster, and it is routinely left until after the servers are chosen.

The network matters as much. Live migration moves a host's worth of memory across the wire, which on a shared gigabit link takes long enough that people stop evacuating hosts before maintenance — quietly removing the thing HA was bought for. Heartbeat traffic needs its own path, because a burst of backup traffic that delays a heartbeat looks exactly like a dead host, and the cluster will fence a machine that was working perfectly.

Common questions

How many VMs can one server host?
It is decided by resources rather than a VM count. Sum the vCPU, memory and storage your machines actually need, divide CPU by your overcommit ratio, leave headroom, and see how that fits inside a host's core and memory ceilings. Fifty small VMs and five large ones can need the same host.
What CPU overcommit ratio is safe?
1:1 for databases and latency-sensitive systems, 1:2 for general application estates, up to 1:3 for VDI and bursty workloads. The ratio is a statement about how much of the time your workloads are actually running, so it is a property of the estate rather than a setting to copy.
Can I overcommit memory in a virtualised cluster?
You can, and it is the most common cause of a virtualisation outage. Ballooning and swapping degrade non-linearly, and when a host runs short the effect lands on whichever machine is busiest. Size memory at 1:1. This calculator does not offer the option.
How do I size a cluster for N+1 high availability?
Size the hosts so that the cluster minus one still carries the entire load within its headroom, then add that one host. The per-host specification comes from the failure case, not the normal case. N+2 follows the same rule with two, which also covers a failure during maintenance on another host.
Does high availability need shared storage?
Yes, in some form. A VM restarts on another host only if that host can reach its disk, so HA implies a shared array or a hyper-converged storage layer across the cluster. It is the dependency that decides the network design and it should be settled before the servers are chosen.
Which hypervisor should I use?
Proxmox VE and XCP-ng are open source with optional support subscriptions, so there is no per-socket or per-core licence in the build cost — which changes the economics of a cluster considerably. Hyper-V, VMware and Nutanix are licensed per host or per core. The technical fit matters, but so does the fact that licensing can exceed the hardware over a cluster's life.