Virtualisation Host Sizing: What Runs Out First

"How many virtual machines will this server run" has no general answer, and the question that does have an answer is which resource runs out first. In practice it is almost always the same one, and it is not the one people size for.

Memory is usually the constraint

Processors can be oversubscribed. Virtual machines rarely use their allocated cores continuously, so allocating more virtual cores than physical ones across the host is normal and works well — guests take turns, and the scheduler handles it.

Memory does not work that way. A virtual machine allocated memory generally holds it. There are memory-sharing and reclamation techniques, and relying on them to run more guests than the host has memory for produces exactly the performance problem you were trying to avoid.

The practical consequence: hosts run out of memory long before they run out of processor. A machine with plenty of idle cores and no free memory is the normal end state.

So size memory generously and size processors to the workload rather than the other way round.

Cores or clock speed

Virtualisation parallelises well, so more cores generally beats higher clock — more guests can run simultaneously.

The exception is where guests run single-threaded applications that are latency-sensitive. A core is a core; if the application inside the guest uses one thread, its performance depends on how fast that core is, not how many exist.

And the point that reverses the answer more often than any technical consideration: per-core licensing. Virtualisation platforms and many guest workloads are licensed by core count in the host, whether or not the workload uses them. A higher-clock, lower-core processor can be considerably cheaper overall despite costing more as hardware. Our processor guide covers the arithmetic.

Work out licence cost at each core count before choosing. It frequently exceeds the hardware difference.

Memory configuration matters as much as capacity

Getting the total right and the arrangement wrong costs performance quietly.

Populate channels evenly. Bandwidth scales with populated channels, so filling several slots on one channel while leaving others empty gives you the capacity at a fraction of the bandwidth.

Watch the speed reduction. Server platforms commonly reduce memory speed as slots fill and as ranks per channel increase. A fully populated host may run slower than the modules are rated for.

Check register type and rank limits. RDIMM and LRDIMM are not interchangeable, and LRDIMM is what reaches the highest capacities. Our memory types guide covers this.

On a dual-socket board, remember that half the memory slots belong to the second processor. A single-processor configuration cannot use them regardless of what you fit.

Storage: shared or local

This decides the cluster design rather than just the storage.

Shared block storage is what lets a virtual machine move between hosts or restart elsewhere when a host fails. That requires a SAN or equivalent — block-level, not file-level. Our storage architecture guide covers the distinction.

Local storage is cheaper and lower-latency but ties guests to one host. A host failure means those guests are down until it is recovered.

Whichever you choose, virtualisation produces heavily random I/O — many guests issuing independent requests simultaneously. That is the classic case for flash, and it is the tier most organisations move first. Our SSD versus HDD guide covers why, and the endurance guide covers picking the class.

On mechanical storage, RAID 10 usually beats parity here — better random write performance and far better rebuild behaviour under load.

Consolidation ratio and headroom

The number people want is guests per host, and the honest answer is that it depends entirely on guest size and activity. Ten large database guests and a hundred small application guests are both plausible on similar hardware.

What matters more is headroom, and there are two kinds.

Growth headroom. Guest counts grow. A host at capacity on day one is a problem within a year.

Failure headroom. This is the one that gets missed. In a cluster, when one host fails its guests restart on the others. If every host runs near capacity, there is nowhere for them to go and the failure cascades.

A cluster designed to survive one host failure must be able to run its whole workload with one host absent. That is the same principle as redundant power circuits, where each path must carry the full load alone.

Fewer large hosts or more small ones

A real trade-off with no universal answer.

Fewer large hosts consolidate better, use less rack space and power, and mean fewer things to manage. But each failure affects more guests, and failure headroom is expensive — in a two-host cluster, surviving one failure means each host runs at half capacity.

More small hosts spread risk, and failure headroom is cheaper proportionally. But there is more hardware, more power draw, more rack space and more to manage.

Licensing frequently decides it, since per-core or per-host licensing changes the economics in ways that have nothing to do with the hardware.

Practical checks

Before specifying: measure current guest memory allocation and actual usage, since the gap is often large. Check per-core utilisation on existing hosts to see whether cores or clock matter. Confirm your licensing model and cost at each core count. Decide shared or local storage, since that determines whether clustering is possible. And size for the workload with one host absent, not with all hosts present.

Then check the physical constraints: chassis TDP limits, memory slot count relative to processor count, and drive bay count for the storage tier. Our form factors guide covers what each chassis height allows.

Common questions

Tell us your guest count, memory allocation and licensing model and we will help specify a host that fits.