If you’ve ever stared at your Proxmox summary and wondered why it claims your VM is eating 98% of its RAM while your internal dashboard says it’s only at 40%, you aren’t alone. It’s a classic Linux “RAM hoarding” quirk that makes your hypervisor look like it’s choking when it’s actually just breathing through a straw.
The Ghost in the Machine
The discrepancy comes down to how Linux manages memory. In the FOSS world, “free” RAM is wasted RAM. The kernel (likely Debian if you’re sensible) grabs every spare megabyte for disk caching and buffers to keep I/O snappy. Proxmox, looking from the outside, sees this allocated cache as “used” because the guest hasn’t technically released it back to the host.
Without the qemu-guest-agent installed, Proxmox is essentially blind. It treats your VM like a black box that has swallowed its entire allocation. This doesn’t just mess up your graphs; it ruins your node summary, making it look like you have zero headroom for new containers when you actually have gigabytes of “ghost” usage.
Turning the Lights On
Installing the guest agent is the “pro” move that joins the virtualisation dots. On a Debian-based VM, it’s a simple one-liner:
sudo apt update && sudo apt install qemu-guest-agent -y
Once you enable the agent in the Proxmox GUI (Options tab) and perform a full stop/start of the VM, the magic happens. Proxmox can finally “see” inside the guest, distinguish between actual application usage and disposable cache, and report the “true” numbers. Your node summary will suddenly “clear” loads of RAM, giving you the green light to spin up that next self-hosted project.
The Reboot Trap: Why Your Agent is Still “Red”
Here is what most people miss: simply running reboot inside your VM won’t cut it. Proxmox needs to “pass through” the new hardware flag for the agent to initialize the virtual serial port. You must perform a cold boot—fully Stop the VM from the Proxmox GUI and then Start it again. If you don’t, that red dot in your summary will stay red, and your backups won’t be application-consistent.
ZFS: The Greedy Gold Standard
If you’re running ZFS (and you should be, for that sweet bit-rot protection), there’s another RAM hog to watch: the ARC (Adaptive Replacement Cache). By default, ZFS can grab up to 50% of your system RAM. On a 32GB node, that’s 16GB gone before you’ve even started your Docker VM.
Setting a sensible limit—like 4GB—is a must for home lab stability. You can apply this immediately and make it persistent. Note that ZFS expects this value in bytes (4×10243=4294967296).
The Verdict
By combining the guest agent with a “leash” on your ZFS ARC, you move from a system that’s constantly hitting I/O stalls to a professional-grade, stable environment. You get accurate dashboards, graceful shutdowns (no more corrupted Vaultwarden databases!), and faster incremental backups via Proxmox Backup Server.
Stop guessing why your graphs don’t match. Install the agent, cap the ARC, and let your hardware actually do the work it was meant for.
Quick Command Reference
To apply a 4GB ARC limit immediately without a reboot:echo 4294967296 > /sys/module/zfs/parameters/zfs_arc_max
To make it persistent across reboots:echo "options zfs zfs_arc_max=4294967296" > /etc/modprobe.d/zfs.confupdate-initramfs -u -k all
Verify your current ARC stats:arc_summary or arcstat