Proxmox host memory: what Windows guests really cost

Verified 2026-10-292 min read

Measured host memory on a 31.2GB Proxmox box running two Windows 11 VMs, why the numbers are larger than the guest allocation, and how to plan headroom.

Tested onPro (26H2) / LTSC 2024 · Build 26300.9457 / 26100.1742 · x64

Build: 26300.9457 / 26100.1742
Edition: Pro (26H2) / LTSC 2024
Architecture: x64
Support: E2 lab observation
Evidence: E2Reproduced in the lab, measured in a passthrough VM
Verified: 2026-10-29
Page type: Method

The short answer

Guest RAM is not host RAM. A “32GB host” running two 8GB Windows VMs does not have 16GB free.

In this site’s lab — Proxmox VE 9.2.2, 16 cores, 31.2GB RAM, two Windows 11 VMs at 8GB each — the host reported roughly:

Metric	Observed
Used	~24GB
Available	~6.7GB
Swap used	~4.7GB

That is the real number to plan with. Two 8GB guests consumed 16GB of guest allocation and about 24GB of host memory.

Where the extra memory goes

Consumer	Why
Guest working set	Windows uses what it is given; 8GB guest often holds 6–7GB
QEMU/KVM overhead	each VM process, device models, OVMF, vTPM
ZFS ARC	the filesystem cache will take a large share if left unbounded
Host services	PVE daemons, container(s), monitoring
Swap	the safety valve that tells you the host is over-committed

ZFS ARC is the one people forget. On a ZFS root, ARC grows to fill RAM by default; it is cache, so it shrinks under pressure — but it also means the “free” figure is misleading and swap can be used at times you did not expect.

Measure it properly

On the PVE host:

free -h
zfs_arc_summary 2>/dev/null | head -20   # or: cat /proc/spl/kstat/zfs/arcstats | head
qm list                                   # VM inventory
qm config 361 | grep -E 'memory|balloon|cores'

Then per-VM, from inside the guest:

Get-CimInstance Win32_OperatingSystem |
  Select-Object @{n='TotalGB';e={[math]::Round($_.TotalVisibleMemorySize/1MB,1)}},
                @{n='FreeGB';e={[math]::Round($_.FreePhysicalMemory/1MB,1)}}
Get-Counter '\Memory\Available MBytes' -MaxSamples 3

If the host swap is being used while guests report plenty of free memory, the host is over-committed — not the guests.

Planning headroom

A rule that survives contact with reality:

reserve 2–4GB for the host (PVE + ZFS ARC floor + monitoring);
allocate guest RAM × 1.2 as the real cost (overhead + working set drift);
leave 10–15% unused;
never plan to the last gigabyte.

For a 32GB host: 32 − 3 = 29GB usable, so two 8GB guests plus one 8GB guest is already at the edge, and a third Windows VM means freeing memory first — exactly the conclusion in this lab’s record.

Tuning that helps (and does not)

Change	Effect
Bound ZFS ARC (`zfs_arc_max`)	frees RAM predictably; slightly less cache
Set `balloon` on guests	host can reclaim under pressure; guest may slow
Reduce guest RAM to 6GB	works for light workloads, not for Windows Update + browser
Disable memory compression in guest	frees nothing useful, usually hurts
Add a second host	the only real fix once you are at the limit

What this observation does and does not prove

Proves: on this host, with these guests, two 8GB Windows VMs cost ~24GB of host memory and pushed the host into swap.
Does not prove: that every 32GB host behaves this way — ZFS settings, guest workloads and PVE version all change the number.

Re-measure your own host; the method above is the point.

Lab boundary

E2 (M-V): host figures come from the lab record for this two-VM configuration. Guest-side counters were not sampled simultaneously for this page, so only the host observations are quoted as measured.