Most virtualization hosts are sized by guesswork: "two CPUs, as much RAM as the budget allows, some SSDs". That usually ends with one resource exhausted while another sits idle. This guide gives a repeatable method that works for VMware ESXi, Hyper-V or Proxmox VE: measure what the virtual machines really use, add headroom and failover capacity, then translate the result into a memory layout, a RAID design and a power budget that the hardware documentation supports.
Before you start
- Collect at least two to four weeks of performance data from the current servers or VMs, including month-end or other busy periods.
- Decide whether you need high availability. A single host has no failover; a cluster needs spare capacity on the surviving hosts.
- Have the server model's installation and service manual open for memory rules, and the controller guide for RAID levels.
Step 1 — Build the workload inventory
List every VM you will run, now and in the planning period (typically three years). For each one record:
- vCPUs allocated and measured peak CPU use.
- Memory allocated and measured active memory at peak.
- Disk space used, expected growth, and peak read and write IOPS.
- Network throughput at peak, and any special devices (USB keys, GPUs, extra NICs).
Use peaks, not averages. An accounting server that is quiet all month and saturated at month-end must be sized for month-end.
Step 2 — Size memory and fit it to the DIMM rules
- Add up the memory each VM needs at peak, plus the hypervisor's own overhead. Broadcom notes that on ESXi, VM memory overhead also counts as reserved memory.
- Be careful with memory overcommitment. Broadcom defines a host as overcommitted when the combined working memory footprint of the VMs exceeds host memory, and warns that a new VM might then fail to power on. Size so that peak working memory fits in physical RAM.
- Add growth headroom, then round up to a layout the server supports.
Memory layout is where sizing meets hardware. The Dell PowerEdge R760 manual, for example, says memory is organised into eight channels per processor with two sockets per channel; supported layouts are 1, 2, 4, 6, 8, 12 or 16 DIMMs per processor; different DIMM capacities must not be mixed; and channels should be populated identically for best performance. Speed also depends on population: with 4th Gen Xeon, the manual lists 4800 MT/s at one DIMM per channel and 4400 MT/s at two.
| DIMMs | Population | Total memory | Listed speed |
|---|---|---|---|
| 16 (8 per processor) | One DIMM per channel | 512 GB | 4800 MT/s |
| 32 (16 per processor) | Two DIMMs per channel | 1 TB | 4400 MT/s |
If 512 GB is enough with headroom, the 16-DIMM layout is faster and leaves room to grow. If you will need more later, plan larger DIMMs now, because capacities cannot be mixed. Model-specific rules: PowerEdge memory rules and ProLiant memory rules.
Step 3 — Size CPU
- Sum the measured peak CPU demand of all VMs, not their allocated vCPUs.
- Add growth and headroom so the host is not running near 100% at peak.
- Check that the largest single VM's vCPU count fits comfortably within one host.
- Choose core count and clock speed together, and check how your hypervisor and guest operating system licences are counted before you pick a core count.
Step 4 — Size storage for capacity and IOPS
Capacity is the easy part: used space plus growth plus snapshots and free-space margin, then divide by the usable fraction of your RAID level (see choosing a RAID level by workload). IOPS is where designs fail, because every host write costs more than one disk write. HPE's SR controller guide lists the disk I/O for every host write:
| RAID level | Disk I/Os per host write |
|---|---|
| RAID 0 | 1 |
| RAID 1 / 10 | 2 |
| RAID 1 / 10 Triple | 3 |
| RAID 5 | 4 |
| RAID 6 | 6 |
Back-end IOPS = read IOPS + (write IOPS x the figure above). Worked example: a measured peak of 2,000 IOPS at 70% read and 30% write is 1,400 reads and 600 writes. On RAID 10 that is 1,400 + 1,200 = 2,600 back-end IOPS; on RAID 6 it is 1,400 + 3,600 = 5,000. Divide by the per-drive figure from your drive's datasheet to get the minimum drive count, then check capacity again. HPE also notes that its RAID 5 and 6 figures assume the initial parity build on the new array has completed.
Step 5 — Add failover capacity (N+1)
For a cluster, size so that the remaining hosts can run everything when one host is down. On vSphere, HA admission control reserves that capacity; Broadcom lists three ways to set it (cluster resource percentage, slot policy or dedicated failover hosts) and advises not to deactivate admission control permanently, because without it there is no assurance VMs can be restarted after a failure. For two hosts, that means each host must be able to carry the whole load alone.
Step 6 — Check power, cooling and form factor
Run the final configuration through the vendor tools: Dell's technical guides point to the Enterprise Infrastructure Planning Tool (EIPT) at dell.com/calc to calculate power consumption, and HPE's user guides point to HPE Power Advisor for electrical and heat loading. Then confirm the chassis has the bays and slots you need: see 1U vs 2U servers.
Note: after the build, validate against your sizing before moving production VMs. The virtualization go-live checks cover that stage, and Proxmox VE vs VMware vs Hyper-V covers the hypervisor choice.
Checklist
- VM inventory with measured peaks for CPU, memory, IOPS and network.
- Memory total fits peak working memory plus overhead and growth, with no reliance on overcommitment.
- DIMM count and capacity match the server's supported layouts; no mixed capacities.
- Back-end IOPS calculated with the RAID write cost; drive count covers both IOPS and capacity.
- Cluster can lose one host and still run all VMs (N+1).
- Power checked in Dell EIPT or HPE Power Advisor.
Skyline can supply, configure and maintain Dell, HPE and Huawei servers under an annual maintenance contract (AMC). Contact us.
Comments
0 total · 0 threads