OpenShift Virtualization cluster sizing

Walk through raw capacity, overcommit, node selection and HA to arrive at a defensible node count — the same six-step process as the vendor guide, worked live against your workload.

1

Determine raw capacity

List every VM t-shirt size in the target workload. Memory overhead per VM is computed automatically using the documented formula.

VM size vCPU Memory (GiB) Graphics devices Count Total vCPU Overhead / VM Total memory (GiB)
Total VMs0
Total raw vCPU0
Total raw memory0 GiB
Memory overhead0 GiB
Avg VM size—
2

Factor in overcommitment

Overcommit ratios are a business risk decision. Use real utilization data when available — otherwise choose a ratio matching your workload's burstiness.

Physical CPU required0 cores
Physical memory required0 GiB
Post-overcommit avg VM—
Target CPU:memory ratio—
3

Identify node size

Compare candidate server configurations. Effective cores account for SMT/hyperthreading; overhead accounts for kube-reserved resources plus the fixed OpenShift Virtualization footprint (2 cores / 360 MiB per node).

Server label Cores Threads Memory (GiB) Eff. cores Overhead (C/GiB) Workload capacity CPU:mem ratio Max VMs/node Node count Pick

Workload node count is the minimum servers of this size needed to place every VM (CPU- or memory-bound, whichever is tighter). Pick the row that best balances failure-domain size against node count — this selection feeds steps 4–7.

4

Adjust for cluster architecture

Control plane topology and infrastructure workloads (ingress, registry, monitoring, storage agents) consume capacity too.

Infra CPU per node—
Infra memory per node—
Headroom after infra—
5

Adjust for high availability

Choose how many simultaneous node failures the cluster must tolerate. Utilization cap = (n − k) / n; extra nodes are added until normal operating utilization sits at or below that cap.

Cluster size Cluster CPU Cluster memory Workload CPU util. Workload mem. util. Utilization cap (n−k)/n Fits?
6

Storage, network & special resources

Outside the scope of the CPU/memory calculation above — don't let these get lost. Check each before finalizing a bill of materials.

  • CPU, memory, network and disk overhead for Kubernetes-native storage (ODF, Portworx, etc.), sized separately from VM workload.
  • Network throughput for SDN, live migration, storage traffic and application traffic.
  • GPUs, SR-IOV devices, dedicated CPUs, NUMA alignment for any VMs that need them.
  • Regulatory or self-imposed scheduling constraints — anti-affinity, taints/tolerations — that reduce effective cluster utilization.
  • Outlier VMs drastically larger than the workload average, which may struggle to schedule even with free aggregate capacity.
  • Disaster recovery: secondary cluster capacity, replication bandwidth, RTO/RPO, and cross-cluster live migration if used.
✓

Final result

Summary of the sizing exercise, ready to drop into a proposal.