vSphere active vs consumed vs granted memory: why the percentage lies

The “Memory Usage” percentage on a vSphere host summary is one of the most misread signals in infrastructure monitoring. An 85% number that pages you at 3 a.m. may represent a healthy host with no reclamation at all. The same number on a different host may mean VMs are being actively swapped to disk. The percentage alone tells you nothing useful about either state.

The host summary percentage is computed from consumed memory divided by physical RAM. Operators interpret this as demand, but consumed is not demand. It is a high water mark that includes idle pages. To reason about memory pressure you must read consumed alongside active, granted, and the reclamation signals (balloon, compression, swap). This article explains what each metric actually measures, why consumed greater than active is normal and expected, and how to tell a healthy 85% from a crisis 85%.

What it is and why it matters

vSphere exposes three memory metrics that look similar but answer three different questions:

• Granted - how much guest physical memory the VMkernel has mapped to machine (host physical) memory. Counted at the guest physical level. Includes transparent page sharing (TPS) shared pages.
• Consumed - how much machine memory is actually backing the VM, after TPS savings, including VMkernel overhead for that VM.
• Active - a sampled estimate of how much memory the VM has touched (read or written) within the last sampling window.

The host summary “Memory Usage” percentage is computed from consumed memory divided by physical RAM, not from active memory. That is the first lie. A host can report 85% memory usage while the active memory across all VMs is 25% of physical RAM, with zero balloon, zero compression, and zero swap. That host is healthy. The same 85% with balloon inflating, compression rate climbing, and swap-in rate non-zero is an emergency.

ESXi deliberately overcommits memory and reclaims it through a four-tier cascade. The percentage hides which tier you are in. Reading the reclamation signals independently is the only way to know which side of the cliff you are on.

How it works

Three metrics, three different measurement mechanisms.

Granted is a mapping counter. When the guest touches a guest physical page for the first time, the VMkernel allocates a machine page and maps it. Granted counts those mappings. It does not decrement when the guest frees memory internally, because the hypervisor cannot see the guest free list. Granted also does not subtract TPS savings, so when inter-VM page sharing is active granted can overstate real machine memory use.

Consumed is granted minus TPS, plus overhead. Consumed is the machine memory actually backing the VM. It subtracts pages deduplicated by TPS and adds the VMkernel overhead (vmmemctl control structures, monitor tracks, and so on). Because the hypervisor cannot see guest frees, consumed does not drop when an application inside the VM frees memory. A VM that allocated 16 GB and then freed 12 GB back to its own page cache will still report roughly 16 GB consumed indefinitely.

Active is a sampled estimate, not a measurement. The VMkernel does not track per-page access bits exactly (that would be far too expensive). Instead it periodically invalidates a subset of page table entries and counts how many get re-faulted within the sampling window. The estimate can under-report workloads that touch a lot of memory but only a little per sampling period. Active is fit for DRS placement decisions, not for precise capacity accounting.

flowchart TD
  G[Granted
guest physical mapped to machine
includes TPS shared pages]
  C[Consumed
granted - TPS + VMkernel overhead
does not see guest frees]
  A[Active
sampled estimate of pages touched]
  G --> C
  C --> A
  A -.->|active close to consumed| DANGER[red flag:
demand near allocation]
  A -.->|active far below consumed| OK[expected:
idle pages held mapped]

Where it shows up in production

The “consumed much greater than active is normal” trap is the single most common misreading. Operators see a 16 GB VM reporting 16 GB consumed and 1.5 GB active, assume 14.5 GB is wasted, and either migrate VMs unnecessarily or chase a memory leak that does not exist. Both reactions are wrong. ESXi holds freed guest pages mapped because unmapping on every guest free would be far more expensive than reclaiming later through ballooning when actually needed. Consumed is a high water mark, not current demand.

The “active equals granted” danger signal is the opposite trap and the more serious one. When a VM’s active memory is at or near its granted memory, the VM is touching essentially every page it has been allocated. That means demand exceeds comfortable allocation, and any further pressure will push the host straight into reclamation against that VM. If you see active close to granted on multiple VMs simultaneously while host consumed is high, the cluster is out of headroom.

The “inter-VM TPS no longer helps” change blinds teams who learned vSphere on 5.x. Before vSphere 6.0, rising TPS was an indirect indicator of memory pressure because the host deduplicated identical pages across VMs when memory got tight. Since vSphere 6.0, inter-VM TPS is disabled by default for security reasons (TPS salting, Mem.ShareForceSalting=2). Only intra-VM TPS remains, and intra-VM TPS is not a contention signal. Teams that still key alarms off TPS savings are watching a dead channel.

The “ballooning requires VMware Tools” interaction breaks the reclamation cascade silently. If Tools is not installed, not running, or the balloon driver is disabled, the host cannot inflate vmmemctl and skips directly from TPS to compression and swap. You see swap with zero balloon and conclude the host is not actually pressured. It is pressured, more severely than the numbers suggest, because it had to skip the gentle tier.

To check Tools status from the ESXi shell:

# Find the VM ID
vim-cmd vmsvc/getallvms | grep <vm-name>

# Check Tools status (look for toolsStatus in the output)
vim-cmd vmsvc/get.summary <vmid>

The “guest swap is invisible to vCenter” gap rounds out the picture. When the balloon driver inflates, the guest OS may page to its own virtual disk to satisfy the inflation. That guest-level swap does not appear in the vCenter mem.swapped counter or in esxtop’s SWCUR column, both of which only reflect VMkernel-level swap to .vswp files. To see what ballooning is actually doing to a VM you have to look inside the guest.

Common misuses

• Thresholding on host memory percentage. A flat 80% alarm fires on healthy hosts and misses hosts in crisis. The percentage is consumed divided by total, blind to reclamation. Replace with per-signal thresholds on balloon, compression, and swap.
• Reading consumed as demand. Consumed is a high water mark, not current demand. The hypervisor cannot see guest frees. Read active for demand, consumed for allocation.
• Equating low active with waste. A database buffer cache sits mostly idle but must stay mapped for hit rate. Forcing reclamation against cached pages destroys latency. Trust active only as a placement hint, never as a free-memory signal.
• Alerting on TPS savings as contention. Inter-VM TPS is disabled by default since 6.0. Watch balloon and compression instead.
• Trusting vCenter reported 100% memory utilization. vCenter sometimes reports consumed (including idle pages) as utilization. Check the active to consumed ratio before acting.
• Reading swap with zero balloon as “not that bad.” Balloon skipped means VMware Tools is not running or the driver is disabled, and the host is in a worse state than the counters suggest.

The reclamation cascade

When host free memory drops below the high threshold (approximately 6% of physical RAM on large hosts), ESXi invokes reclamation tiers in strict order of increasing desperation:

1. TPS - deduplicate identical pages. Largely inert by default since 6.0 (intra-VM only).
2. Ballooning - the vmmemctl driver inside the guest is inflated, forcing the guest to free or page internally. Gentle in CPU cost, but if it hits a database buffer cache the latency impact is severe.
3. Compression - pages compressed in memory (default cache limited by Mem.ZipMaxPct of 10%). Avoids disk I/O but adds CPU overhead and increases access latency.
4. Host-level swap - VM memory pages written to .vswp files on the datastore. Catastrophic: orders of magnitude slower than RAM, and the swap I/O competes with VM disk I/O on the same datastore.

To see which tier the host is currently in:

# SSH to the ESXi host and run esxtop
esxtop
# Press m for memory view
# Press f to customize fields: enable ACTIVE, GRANT, CONS, MCTL, SWCUR, ZIP, UNZIP
# Look for non-zero ZIP/s or SWCUR to identify which tier the host is in

The cascade can complete in minutes during a workload spike. Memory is the one vSphere resource that degrades on a cliff edge rather than gradually. By the time the host percentage looks alarming the host may already be in the swap tier.

Signals to watch in production

The host-level headroom definition is concrete: physical RAM should sit 20-30% above total VM active memory, with N+1 host failure headroom on top. Tracking active as a fraction of physical RAM across the cluster is more useful than tracking consumed.

How Netdata helps

Netdata collects and correlates the three memory metrics alongside the reclamation signals, so the spread between active and consumed and the first non-zero balloon or swap tick are visible without flipping between vCenter views.

• Active, consumed, and granted on the same chart per VM and per host, so the active to consumed ratio is visible at a glance instead of computed by hand.
• Balloon, compression, and swap as independent alarms, not blended into a single memory percentage. The first non-zero swap-in rate can page independently of host consumed being only 70%.
• High-frequency collection catches the reclamation cascade in progress. Ballooning can begin and escalate to swap inside a five minute vCenter rollup window, and frequent polling shows the tier transitions in order.
• ML anomaly detection on active and consumed baselines per VM, so a database whose active memory creeps toward granted over weeks surfaces before it becomes a placement problem.
• VMware Tools status alongside balloon metrics, so swap with zero balloon is immediately explained (Tools is down, balloon tier was skipped).
• Correlation with datastore latency on the host’s VM datastore, since .vswp I/O competes with VM disk I/O and is often the first user-visible symptom of memory-induced swapping.

Related guides

• How vSphere actually works in production: a mental model for operators
• vSphere monitoring checklist: the signals every host, VM, and vCenter needs
• vSphere monitoring maturity model: from survival to expert
• vSphere NUMA locality low: wide VMs paying the remote-memory tax