Computer & IT
Server Consolidation Capacity Calculator
Estimate a defensible target-host count from workload CPU and RAM demand, host headroom, hypervisor overhead, and an explicit N+x reserve; then compare it with the current estate.
Peak-adjusted vCPU demand-
Usable peak cores per host-
Hosts required by CPU-
Workload RAM demand (GB)-
Usable RAM per host (GB)-
Hosts required by RAM-
Capacity hosts before failure reserve-
Target host count-
Workloads per target host-
Current hosts potentially released-
Decision view
Rack packing plan with CPU, RAM, and N+x reserve
Rack packing plan with CPU, RAM, and N+x reserveWorkloads pack into target hosts while two independent capacity rails expose the binding resource.
Exact scenario comparisonTarget peak CPU utilization (%) changes while all other entered assumptions remain constant.
| Target peak CPU utilization (%) | Peak-adjusted vCPU demand | Usable peak cores per host | Hosts required by CPU | Workload RAM demand (GB) | Usable RAM per host (GB) | Hosts required by RAM | Capacity hosts before failure reserve | Target host count | Workloads per target host | Current hosts potentially released |
|---|
How to use Server Consolidation Capacity Calculator
- Inventory workloads and their allocated vCPU/RAM.
- Use a peak factor supported by monitoring rather than an arbitrary overcommit ratio.
- Enter target headroom and N+x policy before comparing released hosts.
Calculator guide
Understanding Server Consolidation Capacity Calculator
A consolidation ratio is useful only after the target cluster survives both peak CPU demand and memory allocation. This calculator keeps those resource tests separate and adds failure reserve after the binding capacity is known.
Detailed calculation process
Detailed server-consolidation capacity calculation
The default estate consolidates 180 workloads onto 32-core, 256 GB hosts at a 70% CPU target, 20% RAM reserve, 12 GB hypervisor overhead, and N+1.
General formula: C_d=N*v*f_pC_h=c*u_cH_c=ceil(C_d/C_h)M_d=N*mM_h=M*(1-r_m)-M_oH_m=ceil(M_d/M_h)H_b=max(H_c,H_m)H_t=H_b+H_rR=N/H_t CPU demand includes the peak multiplier. RAM uses the entered allocation and reserve. The larger rounded requirement sets base hosts before failure reserve.
What each symbol means
Worked substitution with the default inputs
The default first-pass target is 23 hosts, subject to workload-level placement and non-CPU/RAM constraints.
Worked situations
Practical examples
- The default 180 workloads create 486 peak-adjusted vCPU and require 22 CPU hosts.
- The same estate needs only six hosts by RAM, so CPU controls the 23-host N+1 target.
Better inputs
Useful tips
- Separate licensing hosts from capacity hosts.
- Model NUMA, storage IOPS, and affinity after this first-pass resource test.
- Use a high-percentile observation window that includes business peaks.
Before relying on the result
Limitations and common mistakes
- No storage, network, NUMA, GPU, licensing, affinity, or maintenance-window constraint is modeled.
- Average workload allocations are not a workload-by-workload bin-packing proof.
- The released-host result assumes every current host is comparable and removable.
Reference
Key terms
- Peak factor
- Multiplier applied to average vCPU allocation for the modeled demand state.
- Binding resource
- CPU or RAM requiring the larger rounded host count.
- N+x reserve
- Whole hosts retained beyond the capacity requirement for failures or maintenance.
Important note
Validate the result with workload-level placement, failover testing, licensing rules, storage/network capacity, and vendor support before migration.
Frequently asked questions
Why not divide workloads by a target consolidation ratio?
That assumes the answer before testing CPU and RAM demand.
Does N+1 mean one spare server is always idle?
Not necessarily; it means capacity remains acceptable after one modeled host is unavailable.
Can peak CPU exceed physical cores?
Only enter a target utilization and peak factor consistent with the platform's measured contention policy.