RAM or Cores: Sizing a Virtualization Host

Ask a hypervisor host what it is short of and the answer is nearly always memory. CPU on a general-purpose virtualization host idles at 15–30% for most of its life; RAM sits allocated around the clock. Understanding why leads to better-shaped servers — and to the pleasant realization that the fix is the cheapest part on the refurbished price list.

CPU overcommits gracefully; memory does not

Twenty VMs with four vCPUs each on a 28-core host is a 2.8:1 overcommit — and usually fine, because VMs rarely want their CPU at the same moment. Scheduling smooths the peaks. Memory has no equivalent: a VM's allocated RAM is held whether the guest is busy or bored. Ballooning and swap exist as emergency valves, and the moment they engage, every guest on the host feels it. So capacity planning is asymmetric by nature: CPU by ratio, memory by sum.

Honest numbers to plan with

For mixed general workloads, 3:1 to 4:1 vCPU:pCore is comfortable; latency-sensitive guests (databases, VDI, call systems) deserve closer to 1.5:1. For memory, sum the allocations, add the hypervisor's own overhead (a few GB plus per-VM slivers), and keep 15–20% headroom for failover and growth. A host whose RAM is 90% committed on day one is a host you will be upgrading during an outage.

NUMA: the quiet sizing rule

Dual-socket hosts split memory between sockets. A guest that fits inside one node — both its vCPUs and its RAM — runs measurably faster than one that straddles. Practical consequence: prefer more medium VMs to one giant VM, and when a giant is unavoidable, size it to a node boundary. On a 2×16-core host with 384GB, that boundary is 16 cores / 192GB.

What this means for refurbished builds

Used DDR4 RDIMMs are abundant and cheap, which inverts the usual economics: fill the memory channels first, buy capacity generously, and choose CPUs one or two bins down from the flagship. A 1U workhorse like the DL360 Gen10 or R640 with 2×16-core mid-bin CPUs and 384GB serves a small company's entire VM estate; the same chassis with flagship CPUs and 128GB serves half of it, less smoothly, for more money.

Upgrade order when a host feels slow

First check ballooning/swap — if present, add RAM and stop. Then check CPU ready/steal time — if guests wait for scheduling, rebalance vCPU counts before adding silicon; oversized VMs (eight vCPUs doing two cores of work) cause ready time all by themselves. Storage latency masquerading as slowness is the third suspect. Actual raw CPU exhaustion is the rarest finding, which is exactly why second CPUs and faster SKUs should sit last on the shopping list — pleasant news, since on these platforms the second socket is always there waiting.