Shrink LVM-Thin Proxmox: Safe Methods and Dead Ends

Shrinking an LVM-thin pool on Proxmox isn’t directly possible. You can’t just lvreduce a thin pool and call it a day. Here’s the safe workaround: create a new smaller pool and move your VMs over.

Why lvreduce doesn’t work

LVM-thin pools are built on thin provisioning. The pool has a virtual size and a real data size. You can’t shrink the virtual size while data is in use. lvreduce on a thin pool will fail with an error like “thin pool data is still in use” or just refuse to run.

lvreduce -L 100G pve/data
  WARNING: Reducing active logical volume to 100.00 GiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
  Do you really want to reduce pve/data? [y/n]: y
  Size of logical volume pve/data_tdata changed from 200.00 GiB (51200 extents) to 100.00 GiB (25600 extents).
  Logical volume pve/data successfully resized.

That looks like it worked, but check the pool with lvs -a. The data LV is smaller, but the metadata LV and the thin pool itself still think they’re the old size. Your VMs will start throwing I/O errors. Don’t do this.

The safe workaround

Create a new thin pool on the same volume group, move your VMs to it, then remove the old pool. This is the only reliable way to shrink without data loss.

Step 1: Check your current setup

lvs -a
  LV              VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data            pve twi-aotz-- 200.00g             10.42  5.29
  [data_tdata]    pve Twi-ao---- 200.00g
  [data_tmeta]    pve ewi-ao----   2.00g
  root            pve -wi-ao----  50.00g
  swap            pve -wi-ao----   8.00g

You have a thin pool named “data” with 200G virtual size. You want to shrink it to 100G.

Step 2: Create a new thin pool

lvcreate -L 100G -T pve/data_small
  Logical volume "data_small" created.

This creates a thin pool with 100G virtual size. It will allocate metadata automatically.

Step 3: Move your VMs

In the Proxmox web UI, go to each VM’s Hardware tab, select the disk, and click “Move disk”. Choose the new storage “data_small” as the target. This will copy the disk image to the new pool. Do this for all VMs and containers using the old pool.

Alternatively, use the command line:

qm move-disk 100 scsi0 data_small

Replace 100 with your VM ID and scsi0 with the disk you’re moving.

Step 4: Remove the old pool

Once all VMs are moved, remove the old thin pool:

lvremove pve/data
  Do you really want to remove active logical volume pve/data? [y/n]: y
  Logical volume "data" successfully removed.

Now you have your space back. The new pool is smaller, and your VMs are safe.

What about pvmove?

pvmove moves physical extents between physical volumes. It doesn’t shrink a thin pool. It’s useful if you’re replacing a disk, but not for shrinking. Don’t waste your time.

My take

This is annoying, I know. You’d think LVM would let you shrink a thin pool since it’s thin. But the design makes it risky. The workaround is straightforward enough. Just do it during a maintenance window when you can shut down VMs or at least tolerate the copy time.

If you’re hitting this because you over-provisioned, maybe reconsider your storage layout. Check out ZFS Fast Dedup Proxmox Recommendation for a different approach.