Skip to content
Calcrivo

VMware VM Density Calculator

Work out how many VMs an ESXi cluster really holds once CPU overcommit, host memory overhead and per-VM VMX overhead are applied.

Inputs

hosts
cores

Doubles logical CPUs; real throughput gain is closer to 20-30%.

GiB
ratio

4:1 is the usual general-purpose ceiling; use 1:1 for latency-sensitive VMs.

%

VMkernel, drivers and agents typically consume 5-6% of host RAM.

vCPU
GiB
MiB

The monitor, vmx process and graphics buffers charged on top of configured RAM.

%

VMs per Cluster

197VMs

VMs per Host

32VMs

Ceiling from CPU

384VMs

Ceiling from Memory

197VMs

vCPU to Core Ratio Used

4.10:1

Limiting Resource

Memory bound — add RAM before adding sockets

Step by step

  1. Values used

    Hosts in cluster = 6 hosts; Physical cores per host = 32 cores; Hyper-threading enabled = Yes; Memory per host = 512 GiB; vCPU per logical CPU = 4 ratio; ESXi host memory overhead = 6 %; vCPUs per VM = 4 vCPU; Memory per VM = 16 GiB; VMX overhead per VM = 90 MiB; Page sharing and compression gain = 10 %

  2. VMware VM Density

    VMs by CPU = hosts × cores × threads × overcommit ÷ vCPU per VM; VMs by memory = hosts × RAM × (1 − host overhead) × (1 + sharing gain) ÷ (VM RAM + VMX overhead); density is the lower of the two.

  3. VMs per Cluster

    = 197 VMs

  4. VMs per Host

    = 32 VMs

  5. Ceiling from CPU

    = 384 VMs

  6. Ceiling from Memory

    = 197 VMs

  7. vCPU to Core Ratio Used

    = 4.10 :1

  8. Limiting Resource

    = Memory bound — add RAM before adding sockets

How it works

Density is a two-sided constraint: the CPU side multiplies logical cores by the overcommit ratio you are prepared to run, while the memory side starts from installed RAM, removes the VMkernel's 5-6% overhead, adds back whatever transparent page sharing and compression recover, then charges each VM its configured RAM plus VMX overhead. Whichever side runs out first is your real ceiling. Buying hosts against a CPU number when the cluster is memory bound is the most common capacity-planning mistake in vSphere — memory almost always saturates first, because CPU can be overcommitted safely and RAM cannot.

Formula

VMware VM Density

VMs by CPU = hosts × cores × threads × overcommit ÷ vCPU per VM; VMs by memory = hosts × RAM × (1 − host overhead) × (1 + sharing gain) ÷ (VM RAM + VMX overhead); density is the lower of the two.

logical CPUs
Physical cores × 2 when hyper-threading is on
overcommit
vCPUs you are willing to schedule per logical CPU
VMX overhead
Per-VM monitor and process memory charged above configured RAM

Frequently Asked Questions

How is VMware VM Density calculated?

VMs by CPU = hosts × cores × threads × overcommit ÷ vCPU per VM; VMs by memory = hosts × RAM × (1 − host overhead) × (1 + sharing gain) ÷ (VM RAM + VMX overhead); density is the lower of the two. Density is a two-sided constraint: the CPU side multiplies logical cores by the overcommit ratio you are prepared to run, while the memory side starts from installed RAM, removes the VMkernel's 5-6% overhead, adds back whatever transparent page sharing and compression recover, then charges each VM its configured RAM plus VMX overhead. Whichever side runs out first is your real ceiling.

Why does VMware VM Density matter?

Buying hosts against a CPU number when the cluster is memory bound is the most common capacity-planning mistake in vSphere — memory almost always saturates first, because CPU can be overcommitted safely and RAM cannot.

What values do I need to enter?

This calculator takes 10 inputs: Hosts in cluster, Physical cores per host, Hyper-threading enabled, Memory per host, vCPU per logical CPU, ESXi host memory overhead, vCPUs per VM, Memory per VM, VMX overhead per VM, Page sharing and compression gain. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why does hyper-threading not double density?

Logical CPUs double but throughput typically rises only 20-30%, because the two threads share one core's execution units. Treating hyper-threads as full cores is safe only when you also keep the overcommit ratio conservative.

You might also need