Starlight Tools
Average VMs hide extremes
Averages are useful for quick planning, but large database, VDI, and latency-sensitive VMs should be modeled separately.
Segmentation
VM Consolidation Ratio Calculator
Estimate how many virtual machines a host cluster can carry from CPU cores, RAM, vCPU oversubscription, memory commitment, target utilization, HA reserve, and growth. Use it to compare density limits before buying hosts or changing virtualization ratios.
Inputs
Workload profile
Oversubscription and utilization
Workload presets
Planning posture presets
Results
Capacity status--
Supported VMs--
Consolidation ratio--
Required hosts--
Cluster capacity
Active hosts after reserve:-
Total physical cores:-
Usable CPU core capacity:-
Supported vCPU capacity:-
Usable physical RAM:-
Supported vRAM capacity:-
Workload fit
CPU-limited VM count:-
RAM-limited VM count:-
Bottleneck:-
Projected VM demand:-
Projected demand with buffer:-
VM headroom after buffer:-
At buffered demand
Actual vCPU:pCore ratio:-
Actual vRAM:usable RAM ratio:-
Estimated CPU utilization:-
Estimated RAM utilization:-
Socket count now / required:-
Advertisement
How to use this VM consolidation calculator
- Start with physical capacity: enter the host count, cores, RAM, sockets, and reserved hosts for N+1, maintenance, or zone loss planning.
- Describe the average VM: use a representative average vCPU and vRAM profile, or run separate scenarios for small, medium, and large VM classes.
- Set oversubscription policy: choose vCPU:pCore and vRAM:pRAM ratios that match measured CPU ready time, memory pressure, workload burstiness, and service risk.
- Include growth: enter the current or target VM count, annual growth, horizon, and planning buffer to see whether the cluster still fits.
- Check the bottleneck: the lower CPU-limited or RAM-limited VM count determines the practical consolidation limit.
Formula and assumptions
Active hosts: physical hosts - reserved hosts
Usable CPU cores: active hosts x cores per host x target CPU utilization
Supported vCPU: usable CPU cores x vCPU:pCore oversubscription ratio
CPU-limited VMs: floor(supported vCPU / average vCPU per VM)
Usable RAM: active hosts x (RAM per host - hypervisor reserve) x target RAM utilization
Supported vRAM: usable RAM x vRAM:usable-RAM commitment ratio
RAM-limited VMs: floor(supported vRAM / average vRAM per VM)
Required hosts: the larger of CPU-host and RAM-host requirements, plus reserved hosts.
Ratios are planning assumptions, not universal safe limits. CPU overcommit should be validated with CPU ready time, steal time, run queue, application latency, and peak-hour data. RAM overcommit depends on ballooning, compression, swapping, NUMA locality, transparent page sharing policy, and guest memory behavior.
Scenario interpretation
| Signal | What it means | Typical follow-up |
|---|---|---|
| CPU bottleneck | vCPU demand reaches the selected core ratio or CPU target before memory does. | Lower vCPU allocation, add cores, reduce oversubscription, or split noisy workloads. |
| RAM bottleneck | Committed vRAM reaches the selected usable memory target before CPU does. | Add RAM, reclaim oversized VMs, reduce memory commitment, or separate memory-heavy workloads. |
| Host reserve pressure | Normal operation fits, but N+1 or maintenance reserve makes the active pool too small. | Add hosts or reduce the number of simultaneous host-loss scenarios being modeled. |
| Socket growth | Required hosts may change licensing, support, or virtualization platform entitlements. | Review socket, core, and per-VM licensing rules before purchasing or migrating. |
Methodology
The calculator treats CPU and RAM as separate constraints, applies the selected target utilization to the physical active pool, then applies oversubscription or commitment ratios to estimate virtual capacity. It uses the smaller CPU-limited or RAM-limited VM count as the supported VM limit because a cluster cannot use excess CPU capacity to satisfy missing memory, or excess memory to satisfy CPU scheduling pressure.
Growth is compounded over the selected horizon, then the planning buffer is applied to the projected demand. Required hosts are calculated from that buffered VM count and the same utilization and oversubscription assumptions. This makes the output useful for quick what-if planning, but it does not model per-host NUMA placement, datastore latency, network limits, backup windows, GPU devices, or per-VM affinity rules.
Last reviewed: June 2026. Calculations are deterministic arithmetic and run locally in your browser.
FAQs
What is a reasonable vCPU oversubscription ratio?
There is no universal value. Low-latency and busy production workloads often need conservative ratios, while dev/test or mostly idle workloads may tolerate higher ratios. Use observed utilization and CPU ready metrics.
Does this include storage or network bottlenecks?
No. It models CPU and RAM density only. Check datastore capacity, IOPS, replication, backup windows, east-west traffic, and uplink capacity separately.
Should RAM be oversubscribed?
Only when the platform and workload behavior support it. Memory pressure can create severe performance issues if ballooning, compression, or swapping occurs during peak demand.
Why subtract reserved hosts?
Reserved hosts model capacity held back for host failure, maintenance, or cluster evacuation. A cluster that fits only when every host is active may not meet availability goals.
Are results private?
Yes. Inputs are processed in the browser and are not sent to a server.
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.
Practical planning notes
CPU ready matters
High vCPU density can look fine on aggregate CPU charts while guests wait to be scheduled.
Scheduler health
Memory pressure is costly
Swapping and compression can turn a small memory shortage into a broad latency incident.
RAM guardrail
Reserve capacity is real capacity
N+1 and maintenance targets should be subtracted before calculating VM density, not added afterward.
Availability