How to Fix the Proxmox Local-LVM Full Issue

You go to start a VM or restore a backup, and Proxmox throws an error about no space left on local-lvm. The odd part is your disks don’t look that big. A handful of small VMs, nothing obviously wrong, yet the storage is full.

This catches almost everyone running a default Proxmox install at some point. local-lvm is a thin pool, and thin pools fill in ways that aren’t obvious from the VM list. The disk you created at 32 GB might be eating 60 GB of pool space because of snapshots and blocks that were written but never reclaimed.

This guide walks through why the pool fills, how to read the real usage with lvs and df, and how to get space back safely — deleting unused disks and snapshots, moving disks to other storage, and growing the pool when there’s room. The steps target Proxmox VE 8.x, but the LVM commands are the same on 7.x.

First, confirm what’s actually full#

“local-lvm full” and “the root disk is full” are two different problems with the same symptom, and fixing the wrong one wastes an afternoon. On a standard install, your single disk is split into two storages:

Check both before you touch anything. Start with the plain filesystem view:

df -h

Look at the line for /. If that’s at 100%, your problem is the root filesystem — usually ISOs or backups dumped into local, or logs and old kernels. If / has room but Proxmox still complains about local-lvm, the thin pool is the culprit. Now look at LVM directly:

lvs -a

You want the row for the pool itself, named data in volume group pve. The Data% column is the number that matters — it’s how full the thin pool’s data space is. Anything in the 90s means you’re close to writes failing.

  LV              VG  Attr       LSize   Pool Data%  Meta%
  data            pve twi-aotz-- 800.00g       96.21 12.40
  vm-101-disk-0   pve Vwi-aotz--  32.00g data  100.00
  vm-102-disk-0   pve Vwi-aotz-- 100.00g data   58.30
  snap_vm-101...  pve Vri---tz-k  32.00g data

Why a thin pool fills when the disks look small#

Thin provisioning is the whole point of local-lvm: a disk only consumes pool space for blocks that have actually been written. That lets you create a 100 GB disk on a 50 GB pool because the guest rarely uses all of it at once. The trade-off is that the math stops being obvious. A few things quietly eat space.

Snapshots are the usual offender. Every snapshot keeps the old version of any block that changes after you take it. A snapshot you took “just in case” before an upgrade, then forgot about, grows every single day as the VM writes data. Leave a few of those around and they can dwarf the live disks.

Deleted files inside the guest don’t shrink the pool. When you delete a 20 GB file inside a Linux or Windows VM, the guest marks that space free, but the underlying thin volume still holds those blocks unless TRIM/discard tells LVM to release them. Without discard enabled, a disk only ever grows.

Overcommitment catches up with you. Three VMs with 100 GB disks each on a 200 GB pool work fine until they collectively write more than 200 GB. The pool was never big enough; it just hadn’t been asked for the space yet.

Wrong content in the wrong place. Uploading ISOs or dumping backups never touches local-lvm — those go to local — but people sometimes create oversized disks or extra disks they forget about. An orphaned vm-999-disk-0 from a deleted VM that didn’t clean up is real space gone.

Step 1: Find and delete unused disks#

Sometimes the fastest win is a disk that belongs to nothing. When you remove a VM, its disks usually go too, but a failed deletion or a manual lvcreate can leave orphans. List every volume and cross-check the VMIDs against what’s actually in your VM list:

# every logical volume in the pve group
lvs

# the configs that should own them
ls /etc/pve/qemu-server/   # VMs
ls /etc/pve/lxc/           # containers

If you find a vm-150-disk-0 but there’s no 150.conf and no VM 150 in the GUI, that disk is orphaned. Confirm it’s truly unused, then remove it:

# double-check nothing references it first
lvremove /dev/pve/vm-150-disk-0

For disks that do belong to a VM you no longer need, delete the whole VM from the GUI (right-click → Remove, with “Purge from job configurations” ticked). That removes the config and its disks together, which is cleaner than picking off volumes by hand.

Step 2: Clear out old snapshots#

Snapshots are where most of the space usually hides. List them per VM and delete the ones you don’t need:

# list snapshots for VM 101
qm listsnapshot 101

# for a container
pct listsnapshot 201

Delete a snapshot you no longer need by name:

# remove a VM snapshot
qm delsnapshot 101 preupgrade

# remove a container snapshot
pct delsnapshot 201 beforechange

In the GUI it’s the same job: select the VM, open the Snapshots tab, and remove the stale entries. After deleting, run lvs -a again and watch the pool’s Data% drop.

Step 3: Reclaim space deleted inside guests#

If your disks have grown because of files written and later deleted inside the VMs, you can give that space back to the pool — but only if discard is enabled.

First, make sure the VM’s disk has Discard turned on. In the GUI, open the VM → Hardware → the disk → Edit, and tick Discard. The disk should also use a controller that supports it (VirtIO SCSI is the typical choice). Then, inside the guest, issue a TRIM:

# inside a Linux guest
sudo fstrim -av

On Windows guests, the OS issues TRIM automatically when discard is enabled on the disk and the storage reports it, so usually no manual step is needed. After a TRIM, the freed blocks return to the thin pool and lvs shows lower usage on that volume.

Step 4: Move a disk to other storage#

If cleanup isn’t enough, take pressure off local-lvm by moving a VM’s disk somewhere else — another local pool, a ZFS dataset, or an NFS share. This works while the VM is running.

In the GUI: select the VM → Hardware → click the disk → Disk Action → Move Storage, pick the target, and optionally tick “Delete source” so the old copy is removed once the move finishes.

From the CLI:

# move VM 102's disk to a storage named 'nas-vmdata', deleting the source after
qm move-disk 102 scsi0 nas-vmdata --delete 1

# the container equivalent
pct move-volume 202 rootfs nas-vmdata --delete 1

This is also the clean way to rebalance once you realize one host’s local-lvm is doing more than its share. If you don’t have anywhere to move disks to yet, adding NFS storage to Proxmox or another pool gives you the room.

Step 5: Grow the thin pool (when the VG has space)#

If the cleanup options are exhausted and you genuinely need more capacity, you can extend the thin pool — provided the volume group has free extents. Check first:

# free space in the volume group?
vgs pve

Look at the VFree column. If there’s free space there, extend the data pool into it:

# grow the data pool by 100G
lvextend -L +100G /dev/pve/data

# or fill all remaining free space in the VG
lvextend -l +100%FREE /dev/pve/data

Proxmox keeps the pool’s metadata sized automatically in most cases, but if you’re extending a lot, you can grow metadata too with lvextend --poolmetadatasize. After extending, lvs -a shows the larger data LSize and a lower Data%.

If VFree is zero, the VG itself is full and you can’t extend until you add a physical disk: pvcreate the new disk, vgextend pve /dev/sdX to add it to the group, then run the lvextend above. That’s a hardware change, so plan a maintenance window.

Stop it from filling again#

Getting space back is half the job. The other half is making sure you’re not back here next month.

The deeper fix for some setups is rethinking the storage layout entirely. Thin LVM is great for overcommitting and snapshots, but if your usage is predictable and you’d rather have simple capacity math, a thick layout or ZFS changes the trade-offs. Proxmox LVM vs LVM-Thin vs ZFS lays out where each one fits, and if you’re rebuilding a host from scratch, the storage choice happens during the bare-metal install.

A full local-lvm is rarely a sign that something broke — it’s the thin pool doing exactly what it was designed to do, just without anyone watching the gauge. Free the space, enable discard, prune your snapshots, and put a monitor on the Data% so the next warning arrives long before writes start failing. For more walkthroughs, browse the Proxmox guides.