Calculate how many physical servers can be consolidated into virtual machines or containers.
Server consolidation (physical-to-virtual, or virtual-to-larger-virtual) sums the resource demand of every workload being combined, applies a safety margin to account for peak/bursty load and N+1 failover headroom (since workloads rarely all peak simultaneously but occasionally several will), and divides by each target server's usable capacity, rounding up since a fraction of a server isn't a deployable unit. Skipping the safety factor and sizing to exactly average demand risks resource contention the moment several consolidated workloads spike concurrently.
Servers needed
new_servers = ceil( sum(workload_resources) × safety_factor / target_server_capacity )
Average demand assumes perfectly smooth, non-overlapping load, but real workloads have correlated peaks (e.g. multiple batch jobs scheduled at similar times, traffic spikes hitting several services together) — a safety factor (commonly 1.2-1.5x) reserves headroom so simultaneous peaks don't cause resource contention, throttling, or OOM conditions across the consolidated host.
Hypervisors can overcommit vCPU (scheduling more virtual cores than physical cores exist, since not every VM uses its allocation simultaneously) at ratios commonly cited around 2:1 to 4:1 for general workloads, but memory overcommit is riskier and workload-dependent — this calculator's safety factor should be tuned down if the target platform's overcommit already accounts for some of that peak-smoothing.
No — a high consolidation ratio (many workloads per server) reduces hardware and licensing costs but increases the blast radius of a single host failure and can create noisy-neighbor performance issues; consolidation decisions should weigh the ratio against availability requirements and isolation needs, not optimize for ratio alone.