Why Is Your Proxmox VE Storage Full? How to Check Disk Usage and Free Up Space

You install Proxmox VE, spin up a handful of VMs, and everything's fine for a few weeks. Then one day a backup job fails, or a VM refuses to boot, and the error buried in the task log says something like no space left on device. You check your disk and think: that's impossible, I've got a 2 TB drive and maybe six VMs on it.

Here's the thing — you're probably not wrong about the physical disk. What's actually full is a much smaller, more specific pool of space inside it, and Proxmox's default storage setup doesn't make that obvious unless you know where to look. This trips up almost everyone the first time it happens, homelab users especially, because the numbers you see in the web UI don't always mean what you'd assume.

This guide walks through exactly how storage usage works in Proxmox VE, how to check what's actually consuming space, and how to free it up safely without deleting something you needed.

What You Will Learn

• Why Proxmox VE storage can report "full" even when your physical disk has room
• What thin provisioning actually means, and why it makes the numbers confusing
• How to check real usage from both the web UI and the command line
• The most common things silently eating space: old backups, orphaned disks, and snapshots
• How to safely reclaim space on local-lvm, directory storage, and ZFS
• What to do when a thin pool is genuinely full and VMs won't start

What Is This Feature?

When you install Proxmox VE with the default options, the installer usually splits your disk into two storage locations: local, a plain directory used for ISOs, backups, and container templates, and local-lvm, an LVM-thin pool used for your VMs' actual virtual disks.

The word to pay attention to there is thin. A thin pool doesn't reserve real disk space upfront when you create a VM. If you create a VM with a 100 GB disk, Proxmox doesn't carve out 100 GB immediately — it just promises that space is available if the VM ever needs it. The VM only consumes real blocks on disk as it actually writes data. This is called thin provisioning, and it's why you can technically create five VMs with 200 GB disks each on a 500 GB drive without anything breaking, as long as none of them fill up for real.

ZFS storage works on a similar principle by default — volumes don't reserve their full size unless you explicitly tell ZFS to (with a reservation), so the same "allocated vs. actually used" gap shows up there too.

This is convenient right up until it isn't. Because the pool doesn't know in advance how full it'll get, it's entirely possible for your VMs' combined real usage to catch up to and exceed the pool's actual physical size, even though each individual VM still reports having free space inside its own disk. When that happens, the thin pool itself runs out of room, and every VM using it can start throwing I/O errors at the same time — regardless of how much free space df shows inside any one of those VMs.

There's a second, unrelated way you run low on space: the plain local directory storage filling up with routine files — old backup archives (.vma.zst files from vzdump), ISO images you forgot to delete, and container template downloads. That one is much simpler — it's a regular filesystem, and "full" there means exactly what you'd expect.

Why Would You Use It?

Understanding this matters because the failure mode is nasty if you don't catch it early. A thin pool that hits 100% doesn't just refuse new writes gracefully — running VMs can crash mid-write, filesystems inside guests can go read-only, and in the worst case a VM's disk image can end up corrupted if it was in the middle of writing when space ran out.

Checking usage regularly, and understanding the difference between "allocated" and "actually used," lets you catch a slow creep toward full well before it becomes an outage. It also saves you from a very common false alarm: seeing local-lvm reported at 95% allocated and panicking, when the pool itself might only be 40% actually full.

You'll want to work through this guide if:

• Proxmox's dashboard or a backup job is warning you about low space
• A VM failed to start with a disk-related error
• You just want to understand what the storage percentages in the GUI actually mean before you hit a problem

Prerequisites

• A working Proxmox VE 8.x or 9.x installation with root or SSH access to the host shell
• At least one VM or container already created, so there's something to look at
• Roughly 15 minutes — checking usage is quick, but freeing space safely takes a bit more care

You don't need any prior LVM or ZFS knowledge. This guide explains each command as it comes up.

Step-by-Step Tutorial

Step 1: Check overall storage status from the GUI

Log into the web interface, click your node's name in the left-hand tree, then click Disks. This shows every physical disk Proxmox sees, which is useful for confirming the raw hardware isn't actually failing or misdetected.

For the storage pools themselves, click Datacenter, then Storage. Each row shows a Usage bar with a percentage. This is the number that confuses people — for local-lvm, this percentage often reflects how much space has been allocated to VM disks, not how much is physically used on the underlying pool. A 90% bar here can mean your VMs are close to using up their assigned disk space, or it can mean very little real data has actually been written yet.

Step 2: Get the real numbers with pvesm status

SSH into the node (or use the Shell button in the web UI) and run:

pvesm status

This lists every configured storage with its type, total size, used space, and available space, all in real terms — no ambiguity about thin provisioning here. A typical fresh install looks like this:

Name             Type     Status           Total            Used       Available   %
local             dir     active       98497780        12483216        80981564  12.68%
local-lvm     lvmthin     active      380507136       142384128       238123008  37.42%

If local-lvm shows something alarming here, like 95% or higher, that's a real problem worth acting on immediately, unlike the allocation percentage in the GUI.

Step 3: Check the LVM thin pool directly

For a closer look specifically at the LVM layer, two commands give you different angles on the same pool:

vgs

This shows the volume group — the big pool your thin storage lives inside — along with how much of it is free at the LVM level.

lvs -a

This lists every logical volume, including the thin pool itself (usually named data) and each VM's individual disk (named something like vm-101-disk-0). Look at the Data% column on the thin pool's row — that's the actual percentage of physical space used inside the pool, which is the number that matters most.

Step 4: Check ZFS pools, if you're using ZFS storage

If your storage is ZFS-backed instead of LVM-thin, use these instead:

zpool list

Shows each pool's total capacity, allocated space, free space, and a fragmentation percentage. The CAP column is your real usage percentage.

zfs list -o space

Breaks usage down per dataset, including how much space is tied up specifically in snapshots (the USEDSNAP column) versus live data — this is often where "missing" space actually went.

Step 5: Find what's actually consuming space on directory storage

For the plain local directory storage, standard Linux disk tools work fine since it's just a filesystem:

df -h /var/lib/vz

To see what's actually taking up room inside it, broken down by folder:

du -h --max-depth=2 /var/lib/vz | sort -rh | head -20

This almost always points straight at /var/lib/vz/dump (backup archives) or /var/lib/vz/template/iso (ISO files you downloaded once and forgot about).

Step 6: Clean up old backups

Backups are the single most common cause of a slowly filling local storage. Rather than deleting files by hand, use Proxmox's built-in retention system. Go to Datacenter → Backup, edit the relevant job, and set a Keep policy — for example, keep the last 3 daily backups and the last 4 weekly ones. Proxmox prunes older backups automatically on the next run once this is set.

To prune existing backups immediately from the command line instead of waiting for the next scheduled job:

vzdump 101 --prune-backups keep-last=3

This keeps only the 3 most recent backups for VM 101 on whatever storage that job targets, deleting the rest.

Step 7: Remove or consolidate old snapshots

Snapshots are the sneaky one — a forgotten snapshot from six months ago keeps every block that's changed since then pinned in place, even if you never look at it again. Check a VM's Snapshots tab in the GUI, or list them from the shell:

qm listsnapshot 101

Delete ones you no longer need with:

qm delsnapshot 101 before-upgrade

Give it time — removing a snapshot means merging its changes back into the base disk, and that can take several minutes on a large disk. Don't interrupt it partway through.

Step 8: Enable discard so deleted data actually frees space

Here's a gotcha that catches a lot of people: deleting a file inside a VM doesn't automatically tell the underlying thin pool that space is free again, unless the VM's virtual disk has discard (the virtual equivalent of TRIM) enabled. Without it, a thin-provisioned disk can only ever grow, never shrink, no matter how much you clean up inside the guest.

To turn it on for an existing VM, go to Hardware, edit the disk, and tick Discard. Then, inside the guest OS, either enable periodic TRIM (most modern Linux distros run a weekly fstrim timer already) or run it manually once to reclaim existing dead space:

fstrim -av

Run that inside the guest, not on the Proxmox host — it needs to run wherever the filesystem that owns the deleted files actually lives.

Step 9: Grow the thin pool if you've added a new disk

If you've physically added a new disk or freed up an unused partition and want to expand an existing thin pool rather than free space within it, this extends the volume group and the pool onto the new device:

vgextend pve /dev/sdb1
lvextend --resizefs -l +100%FREE /dev/pve/data

Replace /dev/sdb1 with your actual new partition, and confirm pve matches your volume group's real name from the vgs output first — this isn't something to guess at.

Commands Explained

Command	What it does
pvesm status	Shows real used/available space for every storage Proxmox knows about, bypassing the thin-provisioning allocation percentage shown in the GUI.
vgs / lvs -a	LVM commands showing the volume group's free space and each logical volume's actual data usage, including the thin pool itself.
zpool list / zfs list -o space	ZFS equivalents — pool-level capacity and per-dataset space, including how much is locked up in snapshots.
du -h --max-depth=2	Breaks down disk usage by folder on regular filesystems, useful for finding what's actually large inside directory storage.
vzdump --prune-backups	Deletes old backup archives for a VM according to a keep-count you specify, without touching the most recent ones.
qm delsnapshot	Removes a VM snapshot and merges its changes back into the base disk, freeing the space the snapshot was holding.
fstrim -av	Tells the filesystem to notify the underlying thin-provisioned storage which blocks are actually free, run inside the guest OS.
lvextend --resizefs -l +100%FREE	Grows a logical volume (and its filesystem) to use all remaining free space in its volume group.

Common Errors

• "TASK ERROR: unable to open file - No space left on device" during a backup — the destination storage for that backup job is out of room. Check pvesm status for that specific storage and prune old backups first.
• "Thin pool ... data is now 100.00% full" in the syslog or dmesg — the LVM thin pool itself has run out of physical space. VMs using it may already be seeing write errors. This needs immediate action, not just a cleanup at your convenience.
• VM disk shows plenty of free space inside the guest, but the VM still can't write — classic thin-pool-exhaustion symptom. The guest's filesystem thinks it has room because its virtual disk reports free space, but the pool backing that virtual disk has nothing left to actually allocate.
• "cannot create 'X': out of space" from a ZFS command — the pool is full at the ZFS level. Check zfs list -o space for snapshots holding space before assuming you need a bigger disk.

Troubleshooting

If you're in the middle of an active "pool is full" situation and VMs are already misbehaving, the fastest safe fix is almost always deleting old backup files or old snapshots — both are things you can remove without touching a running VM's live data. Do this before rebooting anything; a VM that's currently running with a full backing pool can sometimes still shut down cleanly, but a fresh boot attempt against an already-exhausted pool is more likely to fail outright.

If deleting backups and snapshots doesn't free enough space, check for orphaned disk images — leftover vm-XXX-disk-0 volumes from a VM you deleted improperly, or a failed clone that left a partial disk behind. Run lvs -a and cross-reference the VM IDs listed against what actually shows up in the Proxmox GUI; anything present in lvs but not in the VM list is safe to investigate and likely safe to remove.

If you genuinely have no space left anywhere and no snapshots or old backups to clean up, your only real options are freeing space on another disk and migrating a VM's storage there with Move Disk, or physically adding more storage. There's no command that manufactures free space out of nothing once every legitimate source of slack has been exhausted.

Best Practices

• Set a backup retention policy the day you create your first backup job, not after your storage fills up. An unbounded backup job is one of the most common causes of a surprise "full" storage.
• Enable Discard on VM disks from the start, and confirm the guest OS actually runs fstrim periodically — most modern distros do this automatically, but it's worth a quick check on older images.
• Keep an eye on pvesm status occasionally rather than only trusting the dashboard bar at a glance. The two numbers measure different things, and only one of them tells you how close you actually are to trouble.
• Don't let snapshots pile up indefinitely. They're meant to be short-lived safety nets before an upgrade or risky change, not a permanent history of your VM.
• Leave real headroom — 15 to 20 percent free on a thin pool — rather than running it right up to the edge. Thin pools that fill completely tend to fail in ways that are much messier to recover from than storage that's merely "getting full."

Frequently Asked Questions

Why does the GUI show local-lvm at 90% when pvesm status shows much less real usage?

The GUI's usage bar for thin storage often reflects allocated disk space across your VMs, not physical space actually written. pvesm status and lvs report real usage, which is the number to trust when deciding whether you're actually at risk.

Can a thin pool ever run out even if every individual VM shows free space?

Yes, and this is the exact scenario that causes the most confusion. Each VM only knows about its own virtual disk's free space; it has no visibility into whether the shared pool behind it still has room to grant more.

Is it safe to just delete old .vma.zst backup files by hand from /var/lib/vz/dump?

It works, but setting a retention policy through Datacenter → Backup is safer and repeatable — manual deletion is fine for an emergency cleanup, but you'll be back here again next month without a real policy in place.

Will resizing a VM's virtual disk smaller free up host space?

No — Proxmox VE doesn't support shrinking virtual disks from the GUI or qm resize at all, and shrinking a live filesystem safely is genuinely risky even where it's technically possible. If a disk is oversized, it's better to clone the VM's data into a new, smaller disk than to attempt an in-place shrink.

Does adding discard support retroactively reclaim already-wasted space?

Yes, once you enable it and run fstrim inside the guest, previously "invisible" deleted space gets reported back to the thin pool as free. It won't happen automatically the moment you tick the checkbox — you need that first trim to actually run.

Is ZFS or LVM-thin more likely to run into this problem?

Both can fill up the same way in principle, but ZFS makes it slightly easier to spot because snapshot usage is broken out explicitly in zfs list -o space, whereas LVM-thin snapshots don't get the same clear per-snapshot accounting by default.

Conclusion

Most "Proxmox storage full" scares come down to the same root cause: the number you're looking at describes allocated space, not the space actually written to disk, and nobody tells you that distinction exists until you hit it. Once you know to check pvesm status, lvs, or zfs list -o space instead of relying on the dashboard percentage alone, the mystery mostly disappears.

Set a backup retention policy, clean up snapshots you don't need anymore, and turn on discard so your VMs can actually give space back when they delete something. Do that once, early on, and you'll likely never see that "no space left on device" error outside of a genuine, easy-to-explain reason.