You just installed Proxmox VE on a fresh 2 TB drive and everything looks fine, until you try to upload a couple of Windows ISOs and store a few backups. Suddenly the web UI is complaining that local is almost full, even though the drive itself has barely been touched. Run df -h and the picture gets clearer: your root filesystem is sitting at around 94 GB used out of roughly 96 GB total, while a separate pool called local-lvm is parked on well over a terabyte you can't actually use for ISOs, templates, or backup archives.
That's not a bug, and it's not something you did wrong during setup. It's just how the Proxmox VE installer splits a disk by default, and it trips up a lot of people coming from a regular Linux install where the whole drive is just... the drive.
The fix doesn't require touching your Proxmox installation itself. You can remove or shrink that local-lvm pool from the command line and hand the freed space to root, without reinstalling anything or losing your existing configuration. This guide walks through exactly how, along with the one thing you absolutely need to check first so you don't wipe out a VM disk you were still using.
What You Will Learn
- Why Proxmox VE splits a fresh disk into a small root volume and a much bigger local-lvm pool
- How to check what's actually stored on local-lvm before you touch anything
- How to safely remove the local-lvm thin pool, or shrink it instead of deleting it outright
- How to grow the root logical volume and its filesystem into the space you just freed
- How to update Proxmox VE's storage list so it stops looking for a pool that no longer exists
- What to do if you still want some LVM-thin storage around, just a smaller slice of it
What Is This Feature?
When Proxmox VE installs itself onto a disk using the default ZFS-free, LVM option, it creates a volume group named pve and splits it into three logical volumes: swap, root, and data. A volume group, if you haven't run into LVM before, is just a pool of raw disk space that gets carved into logical volumes on demand, a bit like a virtual disk that you can resize later without repartitioning the physical drive.
root holds your actual Proxmox VE operating system, plus the local storage that Proxmox uses for ISO images, container templates, and backup files by default. data is the one labeled local-lvm in the web interface, and it's built as an LVM-thin pool, meaning it doesn't reserve space up front. It just hands out storage to VM disks as they actually write data, which is efficient for running VMs but useless for storing an ISO file.
Here's the part that surprises people: no matter how big your disk is, the installer caps root at 96 GB by default once your disk is larger than 48 GB. Everything else, minus a small reserved buffer, goes straight into the local-lvm thin pool. Install on a 4 TB drive and root still gets roughly 96 GB. The other 3.9-ish TB sits in local-lvm, ready for VM disks, and completely inaccessible to ISOs or backup files stored on local.
Why Would You Use It?
This matters most if your Proxmox box isn't primarily running big VMs with large virtual disks. Plenty of homelab setups lean heavily on LXC containers with modest storage needs, or run one or two VMs off a separate NVMe drive entirely, leaving the boot disk mostly there to hold the OS, a stash of ISOs, and nightly backup archives. In that situation, a 96 GB root partition fills up fast, while hundreds of gigabytes sit idle in a thin pool nothing is using.
It also comes up a lot after the fact, once someone realizes their backup retention policy needs more headroom than local has, or they want to keep a bigger library of ISOs on hand without constantly deleting old ones. Rather than adding a second disk just to store files, reclaiming the local-lvm space you're not using solves the same problem for free.
One case where you should not do this: if you're actually running VMs whose disks live on local-lvm and you plan to keep doing that, you don't want to remove the pool at all. This guide is specifically for people who've decided they don't need a large thin-provisioned pool on this particular disk.
Prerequisites
- Root or SSH access to your Proxmox VE host's shell, and basic comfort typing commands (each one here gets explained)
- A Proxmox VE 8.x or 9.x installation using the default LVM/LVM-thin layout, not ZFS or a hardware RAID controller with its own partitioning
- A backup or migration plan for any VM disk currently stored on local-lvm that you want to keep
- About 20 to 30 minutes, most of which is just waiting for
lvremoveandresize2fsto finish
If you installed with ZFS as the root filesystem instead of the default LVM option, this guide doesn't apply to you. ZFS pools grow and shrink differently, and there's no local-lvm thin pool involved in that setup at all.
Step-by-Step Tutorial
Step 1: Check what's actually stored on local-lvm
Before deleting anything, find out whether any VM or container disks currently live on that storage. Run this from the Proxmox shell:
pvesm list local-lvmThis lists every volume Proxmox knows about on that storage, along with which VM ID owns it. An empty result means nothing is stored there and you're safe to proceed straight to Step 3. If you see entries like vm-101-disk-0, that VM has a real disk sitting on local-lvm, and you'll want to deal with it before removing the pool.
Step 2: Move or back up anything you need to keep
If Step 1 showed disks you still need, you have two options. If you have other storage available (a second disk, a NAS over NFS, whatever else is configured), move the disk there from the VM's Hardware tab in the GUI, using Disk Action → Move Storage. From the command line, the equivalent is:
qm move_disk 101 scsi0 localThat moves disk scsi0 belonging to VM 101 onto the local directory storage (or swap in whatever target storage you actually have room on). If you don't have anywhere else to put it, back the VM up instead with Datacenter → Backup, or from the shell:
vzdump 101 --storage local --mode snapshotEither way, don't skip this step. Removing the thin pool in Step 5 deletes every disk stored on it permanently, and there's no undo once it's gone.
Step 3: Confirm your volume group and logical volume names
Almost every Proxmox VE install uses pve as the volume group name and data as the thin pool, but it's worth confirming rather than assuming, especially if this box was set up by someone else or renamed at some point:
vgs
lvs -avgs shows your volume group (almost certainly pve) and how much free space it currently has. lvs -a lists every logical volume inside it, including root, swap, and data, along with the thin pool's current usage under the Data% column. If your volume group is named something other than pve, substitute that name in every command below.
Step 4: Remove local-lvm from Proxmox VE's storage configuration
Before touching LVM itself, tell Proxmox to stop treating local-lvm as a valid storage target. In the web UI, go to Datacenter → Storage, select local-lvm, and click Remove. This only edits the storage list in /etc/pve/storage.cfg — it doesn't touch the underlying logical volume yet, so there's nothing risky about this step on its own.
Doing this first matters because if you delete the thin pool before removing it from the storage list, the GUI keeps showing a broken local-lvm entry with errors every time it tries to query a pool that no longer exists.
Step 5: Remove the local-lvm thin pool
With Step 4 done and Step 1 confirming nothing important is left on it, delete the pool:
lvremove /dev/pve/dataLVM will ask you to confirm, since this is destructive. Type y and it removes the thin pool along with anything still stored inside it. This step is close to instant, since it's just freeing metadata rather than zeroing out gigabytes of data.
Step 6: Grow the root logical volume and its filesystem
The space local-lvm was using is now unallocated free space in the pve volume group, not automatically added to root. Extend root into all of it, and resize the filesystem in the same step, with:
lvresize --resizefs --size +100%FREE /dev/pve/rootThe --resizefs flag is what saves you a second manual step here. Without it, you'd need to grow the logical volume and then separately run resize2fs (for ext4) or xfs_growfs (for XFS) to make the filesystem actually use the new space. With --resizefs, lvresize handles both in one command, and it works fine while the root filesystem is mounted and Proxmox VE is running normally.
If you'd rather leave some free space in the volume group instead of using every last byte, swap +100%FREE for a fixed amount, like +300G.
Step 7: Verify the new size
Confirm the change actually applied:
df -h /
lvs -adf -h / should now show your root filesystem at close to the full disk size, minus swap and the small reserved buffer LVM keeps aside. lvs -a should show root as the only remaining logical volume besides swap, with no data entry left.
Step 8 (optional): Recreate a smaller local-lvm pool
If you later decide you do want some thin-provisioned VM storage back, but a much smaller slice than the default, you can recreate the pool at whatever size you choose, as long as you leave that much space unused when you resize root in Step 6. Creating a new thin pool afterward looks like this, sized here at 200 GB as an example:
lvcreate -L 200G -T pve/dataThen add it back as a storage target under Datacenter → Storage → Add → LVM-Thin, pointing it at the data volume you just created.
Commands Explained
| Command | What it does |
|---|---|
pvesm list local-lvm | Lists every volume Proxmox has stored on a given storage target, including which VM owns each one. |
qm move_disk | Moves a VM's virtual disk from one storage location to another, optionally converting its format in the process. |
vgs | Shows summary information for each LVM volume group, including total and free space. |
lvs -a | Lists every logical volume inside your volume groups, including thin pools and their current usage percentage. |
lvremove | Permanently deletes a logical volume and everything stored inside it. Cannot be undone. |
lvresize --resizefs | Grows (or shrinks) a logical volume and resizes its filesystem to match, in a single command. |
lvcreate -T | Creates a new LVM-thin pool of a specified size inside an existing volume group. |
Common Errors
- "Can't remove open logical volume" when running
lvremove— something is still using the pool, usually a running VM whose disk you missed in Step 1. Shut the VM down or double-checkpvesm list local-lvmcame back empty. - "Insufficient free extents" from
lvresize— you're asking for more space than the volume group actually has free. Runvgsagain to confirm how much is really available before retrying. - storage 'local-lvm' does not exist in a backup job's task log — you removed the pool but forgot Step 4, and a backup job or VM config still references local-lvm as a target. Check Datacenter → Backup and any VM's disk configuration for leftover references.
- root filesystem size unchanged after lvresize — you ran
lvresizewithout--resizefs, which grows the logical volume but leaves the filesystem at its old size. Runresize2fs /dev/pve/root(ext4) orxfs_growfs /(XFS) manually to finish the job.
Troubleshooting
If lvremove refuses to run because the pool is "open," the most common cause is a VM or container that's still running with a disk on local-lvm, even one you thought you'd already moved. Run lvs -a again and look for any vm-XXX-disk-Y entries still listed under the pool before trying again.
If you extended root but df -h / still shows the old size, the filesystem resize didn't happen, usually because --resizefs was left off or the resize command targeted the wrong device path. Double check with lsblk that /dev/pve/root is genuinely the device mounted at /, then run the filesystem-specific resize command by hand.
If the Proxmox web UI still shows a red, broken local-lvm entry after you've deleted the underlying volume, that almost always means Step 4 got skipped. Go back to Datacenter → Storage and remove the stale entry; nothing about the LVM layer needs to change again at that point.
Best Practices
- Always run
pvesm list local-lvmbefore deleting anything. It takes ten seconds and it's the difference between a clean resize and an accidental data loss incident. - Decide your storage layout before you have dozens of VMs to migrate. Reclaiming local-lvm space is far easier on a fresh install than on a host that's been running in production for a year.
- If you're not fully sure you'll never want VM-thin storage on this disk again, shrink the pool with Step 8's approach rather than removing it entirely — you can always grow it back later.
- Leave a bit of headroom in the volume group rather than using literally every byte with
+100%FREE. A completely full root filesystem behaves badly during updates and log rotation. - If you're planning to add a dedicated disk for VM storage anyway, it usually makes more sense to keep the boot disk lean and put local-lvm (or ZFS) on that separate drive instead of fighting over space on one disk.
Frequently Asked Questions
Will this delete my Proxmox VE installation or configuration?
No. You're only touching the data logical volume and the local-lvm storage entry. Your Proxmox VE system, its configuration in /etc/pve, and anything already on root or local are untouched.
Can I shrink local-lvm instead of removing it completely?
Not directly with a simple resize command — LVM-thin pools don't support in-place shrinking the way regular logical volumes do. The practical approach is to remove the pool entirely and recreate it afterward at your preferred, smaller size, which is what Step 8 covers.
Does this work the same way on Proxmox VE 8 and 9?
Yes. The default LVM partitioning layout and the lvremove / lvresize commands here haven't changed between the two versions.
What if I installed with ZFS instead of LVM?
This guide doesn't apply. ZFS installs don't create a local-lvm thin pool at all — you'd be looking at zfs list and adjusting dataset quotas or reservations instead, which is a different process entirely.
Is it safe to run lvresize while Proxmox VE is live and VMs are running?
Growing root with lvresize --resizefs is safe to run online, since you're only extending root, not the pool other VMs might depend on. Just make sure you've already handled anything living on local-lvm before you get to the lvremove step, since that part is destructive regardless of timing.
How much space should I actually leave for local-lvm if I recreate it?
That depends entirely on how many VMs you plan to run and how big their disks are, but for a homelab running a handful of lightweight VMs, 100 to 300 GB is usually plenty. You can always grow the pool later with lvresize the same way you'd grow any other logical volume, as long as the volume group still has free space to give it.
Conclusion
A 96 GB cap on root probably made sense as a conservative default years ago, but on modern multi-terabyte drives it leaves most homelab and small-business installs with a storage layout that doesn't match how they actually use the box. Once you know it's just LVM under the hood, fixing it is a five-minute job: check what's on local-lvm, move or back up anything real, remove the pool, and grow root into the space.
From here, your local storage has room to actually hold the ISOs, templates, and backup history you meant to keep on it in the first place, and if you ever do need thin-provisioned VM storage again, nothing stops you from carving a slice back out later.