VM Consolidation Ratio & Host Sizing Calculator

How to measure VM density or size a VM cluster

1. Choose Measure or Size capacity: Measure divides running VMs and allocated vCPU by active hosts and physical cores; Size capacity opens the planning model.
2. Enter the quick inputs: for sizing, supply installed hosts, VM count, and average allocated vCPU and RAM. Open advanced groups only when needed.
3. Use measured demand: enter average active CPU and a peak multiplier, or enable workload classes to model different peak behavior.
4. Set topology and policy: separate sockets, physical cores, SMT contribution, overhead, growth, HA, RAM, and optional storage assumptions.
5. Read the lowest limit: the allocation, demand, RAM, or storage limit that is reached first determines capacity; compare N+1/N+2 and sensitivity results before deciding.

Formula and assumptions

GiB versus GB: this page uses binary GiB (1 GiB = 1,073,741,824 bytes) and TiB (1 TiB = 1,024 GiB). Decimal storage labels from vendors may use GB/TB, so convert them before entry. Ratios are starting assumptions, not universal safe limits.

Worked example: eight-host N+1 cluster

Assume 8 hosts, N+1 reserve, 2 sockets × 16 physical cores, 512 GiB RAM with 24 GiB reserved, 30% SMT sibling efficiency, 10% host CPU overhead, a 70% CPU ceiling, 5:1 allocated vCPU:pCore guardrail, 80% RAM ceiling, and 1.1:1 vRAM commitment. The average VM has 2 vCPU, 8 GiB RAM, 20% average active CPU, and a 1.75× peak multiplier. Current demand is 220 VMs with 20% annual growth over 12 months and a 10% buffer.

1. Active hosts after reserve: 8 − 1 = 7.
2. Physical and effective cores: 2 × 16 = 32 physical cores per host; 32 × [1 + (2 − 1) × 0.30] = 41.6 effective cores per host.
3. Supported allocated vCPU: 7 × 32 × 5 = 1,120 vCPU, so the allocation guardrail is floor(1,120 / 2) = 560 VMs.
4. Peak CPU demand: each VM needs 2 × 0.20 × 1.75 = 0.7 core equivalent. Cluster peak capacity is 7 × 41.6 × 0.90 × 0.70 = 183.456 core equivalents, so demand supports floor(183.456 / 0.7) = 262 VMs.
5. Usable RAM: 7 × (512 − 24) × 0.80 = 2,732.8 GiB. Supported vRAM is 2,732.8 × 1.1 = 3,006.08 GiB, so RAM supports floor(3,006.08 / 8) = 375 VMs.
6. Final density: the lower limit wins: min(560, 262, 375) = 262 VMs, or 262 / 7 = 37.4 VMs per active host.
7. Growth and buffer: 220 × 1.20 = 264 projected VMs; 264 × 1.10 = 290.4 buffered VMs.
8. Required hosts: demand needs ceil(290.4 × 0.7 / 26.208) = 8 active hosts, so N+1 requires 8 + 1 = 9 hosts.

Interpretation: allocated vCPU and RAM both appear sufficient, but measured peak CPU demand is tighter. Capacity from another resource cannot compensate for CPU scheduling demand, so the 262-VM demand limit determines the result.

Scenario interpretation

Methodology and sources

The calculator separates allocated vCPU from performance demand. It independently calculates the allocation guardrail, peak-demand CPU capacity, committed-RAM capacity, and optional storage capacity, then uses the smallest. Mixed workloads are converted to count-weighted average allocation and demand so their entered class proportions are preserved in the capacity estimate.

The presets are transparent starting scenarios only: conservative uses 3:1 allocation, 60% peak CPU, 75% RAM, 1:1 vRAM, and 15% overhead; balanced uses 5:1, 70%, 80%, 1.1:1, and 10%; dense uses 8:1, 75%, 85%, 1.2:1, and 8%. None is a vendor recommendation. Replace them with telemetry covering representative peaks, maintenance, and failure conditions.

• Broadcom: Understanding CPU Ready values defines CPU Ready as runnable time waiting for a physical CPU and Co-Stop as time a multi-vCPU VM cannot obtain enough threads together.
• Broadcom: Troubleshooting ESXi VM performance recommends checking CPU Ready/Co-Stop and memory ballooning or swapping when investigating contention.
• Microsoft: Hyper-V scheduler types explains that SMT threads share core resources and that throughput improvement is workload-dependent rather than a doubling of core capacity.
• AWS Compute Optimizer rightsizing methodology documents percentile-based utilization analysis and explicit CPU/memory headroom, supporting the use of measured peaks and buffers instead of allocation alone.
• Red Hat: Optimizing virtual-machine performance provides KVM guidance on right-sizing CPU and memory and cautions against production overcommit without workload evidence.

Authored and technically reviewed by the Starlight Robotics infrastructure editorial team. Reviewed 15 July 2026. Calculations are deterministic arithmetic and run locally in your browser.

FAQs

What is VM consolidation ratio?

VM consolidation ratio is the number of running VMs divided by the number of active physical hosts. For example, 180 running VMs on six active hosts is 30 VMs per host.

How do I calculate VMs per host?

Divide the number of running VMs by the number of active physical hosts carrying them. Exclude a powered-off or deliberately reserved host from the denominator; include it when it returns to the active pool.

Is VM consolidation ratio the same as vCPU:pCPU ratio?

No. VM consolidation ratio is running VMs divided by active hosts. Allocated vCPU:pCore is total allocated vCPU divided by physical CPU cores. A cluster can have the same VM density with very different vCPU allocation and real CPU demand.

Do logical processors count as physical cores?

No. A logical processor created by SMT or Hyper-Threading shares execution resources with its sibling thread. This calculator keeps physical cores separate and lets you assign only an estimated incremental SMT efficiency; validate that factor on your hardware and workload.

What is the difference between N+1 and N+2?

N+1 retains enough capacity after one host is unavailable; N+2 retains enough after two. N+2 costs more capacity but covers a second failure or overlapping maintenance. Admission-control details differ by platform.

How should I size bursty workloads?

Use a representative peak percentile from a period that includes business peaks, multiply average active CPU only when that multiplier is evidence-based, and retain headroom. Model bursty or latency-sensitive classes separately and check scheduler wait, application latency, and memory pressure after deployment.

Does this work for ESXi, Proxmox, Hyper-V, and KVM?

Yes, the arithmetic is platform-neutral. The safe assumptions are not: schedulers, SMT topology, dynamic memory or ballooning, admission control, NUMA placement, storage resilience, and reported counters differ, so validate the result with the chosen platform's telemetry and guidance.

What is a reasonable vCPU oversubscription ratio?

There is no universal value. Low-latency and busy production workloads often need conservative allocation, while measured idle or development workloads may tolerate more. Use observed peak demand, CPU Ready or equivalent scheduler-wait metrics, Co-Stop for wide VMs, and application latency.

Does this include storage or network bottlenecks?

Storage capacity is optional in sizing mode and can cap the result. The calculator does not model IOPS, latency, throughput, replication rebuild time, network capacity, backup windows, GPUs, affinity rules, or NUMA placement; check those separately.

Should RAM be oversubscribed?

Only when the platform and measured workload behavior support it. Ballooning can reclaim idle guest memory, but compression, host swapping, and guest paging under pressure can hurt latency. Monitor active or working-set memory and reclamation counters rather than relying only on allocated memory.

Why subtract reserved hosts?

Reserved hosts represent capacity unavailable to normal placement because of maintenance drain or failover policy. Subtracting them before calculating density tests whether the remaining hosts can carry the workload.

Are results private?

Yes. Inputs and calculations stay in your browser; sharing creates a URL containing the entered assumptions, so review it before sending.

Disclaimer

This is an infrastructure planning aid, not a performance guarantee, procurement approval, or vendor support statement. Validate consolidation targets with production telemetry, hypervisor guidance, application owners, load testing, failure drills, and change-management requirements before relying on them.