Most virtualisation hosts are bought wrong in one of two directions: over-specified on cores you'll never licence, or under-specified on memory and RAM-bound within a year. This is the build framework our engineers use when we configure a vSphere (or vSAN) host for UK customers — the order to make the decisions, and where the money actually matters.
Start with the consolidation ratio, not the spec sheet
A virtualisation host is sized backwards from the VMs it will run. Count the production vCPUs and committed RAM you need to host, apply a realistic consolidation ratio (4:1 to 6:1 vCPU:pCPU for general server workloads, closer to 2:1 for busy databases), and add N+1 headroom so a host can fail without tipping the cluster over its limits.
The most common mistake is sizing each host to run comfortably at 90% — then losing all headroom the moment one node goes down for patching. Size the cluster so any single host can be evacuated and the rest absorb its load under ~80% utilisation.
Cores: fewer, faster, and licence-aware
Since Broadcom moved VMware to per-core subscription (16-core minimum per CPU), core count is a direct, recurring cost — not a one-off. That flips the old "buy the most cores" instinct. For most consolidation workloads a pair of mid-bin CPUs (32-48 cores total) with a strong per-core clock beats a pair of 64-core parts you pay to licence and rarely saturate.
Check the per-core licensing of what runs inside the VMs too — SQL Server and Windows Server Datacenter are also core-based. A NUMA-aware, slightly-higher-clock CPU often lowers total licence spend across the whole stack.
Memory is where hosts actually run out
RAM, not CPU, is the usual ceiling on a virtualisation host. Size committed VM memory, add ~20-25% for the hypervisor, vSAN (if used) and overhead, then populate DIMMs to keep every memory channel balanced — an unbalanced config silently throttles bandwidth on both Intel Xeon 6 and AMD EPYC.
DDR5 RDIMM at the platform's rated speed, all channels populated at 1 DIMM-per-channel where budget allows, is the sweet spot. Going to 2 DIMMs-per-channel for capacity drops the clocked speed on most platforms — fine for capacity hosts, a tax on latency-sensitive ones.
Storage: vSAN-ready or external array
Two paths. Local/HCI: an all-NVMe vSAN ESA configuration on a certified ReadyNode hardware list — simplest to scale, no SAN. External: boot plus minimal local NVMe, with capacity on a shared array over 25/100GbE. The choice usually comes down to cluster size, existing SAN investment and the team's operational comfort.
Whichever you pick, never boot the hypervisor off the data tier — use a mirrored boot device (Dell BOSS-N1 or M.2 RAID-1) so a boot-drive failure doesn't take the host down and rebuilds stay trivial.
- •All-NVMe vSAN ESA → certified ReadyNode, 25GbE+ for vSAN traffic
- •External array → dual-port HBA/NIC, redundant fabric, boot on BOSS/M.2
- •Always: a mirrored boot device, separate from data
- •Match cache/endurance to the write profile (mixed-use for general virtualisation)
Networking and resilience
A modern host wants redundant NICs sized to role: 2× 25GbE is the current mainstream for combined VM + vMotion + management, with vSAN or storage traffic on its own 25/100GbE pair. OCP 3.0 mezzanine NICs keep PCIe slots free for future GPUs or HBAs and are hot-serviceable on most platforms.
Dual power supplies on separate feeds, redundant fans, and out-of-band management (iDRAC / iLO) licensed for remote console are non-negotiable on anything running production VMs.
Putting it together
When you've made those calls, the model choice is usually a 1U or 2U dual-socket box from Dell PowerEdge, HPE ProLiant or Lenovo ThinkSystem — and our server configurator lets you build the exact spec and request a quote. For the generic, workload-agnostic version of this method, read how to spec a server in 2026, and Dell vs HPE vs Lenovo for the platform call.