How to Add a New Disk as LVM-Thin Storage in Proxmox VE (Step-by-Step Guide)

Introduction

You just added a second drive to your Proxmox box. Maybe it's a spare SSD you had lying around, or a fresh NVMe stick you bought specifically to stop cramming everything onto the boot disk. Now you're staring at Datacenter → Storage → Add and looking at a dropdown with Directory, ZFS, LVM, LVM-Thin, and a handful of others, and none of them explain themselves.

LVM-Thin is usually the right answer if that new disk is a single drive, you don't need ZFS-style checksumming or multi-disk redundancy, and you want thin provisioning — meaning your virtual disks only use the space they actually need, not the space you allocated to them. It's also what Proxmox uses by default for the local-lvm storage on a standard install, so you're not exactly picking an obscure option.

This guide walks through turning a blank second disk into working LVM-Thin storage, both from the GUI and from the command line, plus the errors that trip people up the first time they do this.

What You Will Learn

• What LVM-Thin actually is and how it's different from plain LVM, ZFS, and directory storage
• How to create a thin pool on a new disk using the Proxmox web interface
• How to do the same thing entirely from the shell with pvcreate, vgcreate, and lvcreate
• How to register that pool as usable storage so it shows up when you create a VM or container
• The errors you'll hit if the disk already has data on it, and how to clear them safely

What Is This Feature?

LVM stands for Logical Volume Manager. It's a layer that sits between your raw disk and your filesystem, letting you carve one or more physical disks into flexible logical volumes instead of fixed partitions. You can resize those volumes later, which is the whole point — a rigid partition table can't do that nearly as gracefully.

LVM-Thin adds thin provisioning on top of regular LVM. With regular ("thick") LVM, if you create a 50 GB volume, Proxmox reserves 50 GB immediately, whether the VM inside is using 2 GB or 49 GB. With a thin pool, that same 50 GB volume only consumes space on disk as data is actually written to it. Create ten VMs each with a 50 GB disk on a 500 GB thin pool, and as long as none of them are anywhere near full, you're fine — the pool only fills up as real data lands on it.

That's also the pool's biggest trap. It's entirely possible to allocate more virtual disk space than the pool physically has, a state called overcommitment. Proxmox will warn you, but it won't stop you, and a thin pool that actually fills up stops accepting writes for every VM on it at once. Keep an eye on real usage, not just what you've allocated.

One more thing worth knowing up front: LVM-Thin pools are local to the node they're created on. There's no built-in way to share one across a cluster the way you can with NFS or Ceph. If you need shared storage for live migration without downtime, LVM-Thin isn't that tool — it's built for fast, simple, single-node storage.

LVM-Thin vs. the alternatives

Storage Type	Thin Provisioning	Snapshots	Shared Across Nodes	Best For
Directory	Depends on filesystem	No (qcow2 only)	Only over NFS/CIFS	Simplicity, ISO/backup storage
LVM (thick)	No	Limited	Only with shared block storage	Predictable, fixed allocation
LVM-Thin	Yes	Yes, fast	No — single node only	Single local disk, VM/LXC storage
ZFS	Yes	Yes, extensive	Only with replication, not true sharing	Redundancy, checksumming, multi-disk pools

Why Would You Use It?

Most homelabs and small setups don't need ZFS's checksumming and multi-disk redundancy on every single drive. If your second disk is a single SSD and you're not mirroring it, ZFS on a lone disk gives you snapshots and checksums but no actual redundancy — it can't rebuild from a bad block, it can only tell you one happened. LVM-Thin skips that overhead and gets you snapshotting and thin provisioning with less RAM usage and a simpler mental model.

It's also noticeably lighter on memory. ZFS wants RAM for its ARC cache — commonly cited guidance is around 1 GB of RAM per TB of storage as a rough starting point, more if you lean on deduplication. On a small NUC or an older server with 16 GB of RAM, that's not nothing. LVM-Thin doesn't have that appetite.

I'd reach for LVM-Thin any time I've got one extra disk and want it usable in five minutes without thinking too hard about pool topology. I'd reach for ZFS instead the moment I have two or more disks I want mirrored, or I care about bit-rot detection on data I can't easily replace.

Prerequisites

• A Proxmox VE host, 8.x or 9.x — the steps below are the same on both
• A second physical disk (or an unused partition) that isn't already storing data you need — this process wipes anything on it
• Root access, either through the web GUI or an SSH session
• Roughly five minutes for the GUI method, or ten if you're doing it by hand on the command line

Before anything else, confirm you've identified the right disk. Running the wrong command against your boot drive is the single most common way people wreck a working Proxmox install while following a storage guide. Check twice.

Step-by-Step Tutorial

Step 1: Identify your new disk

Open a shell on the Proxmox host (via the web console or SSH) and run:

lsblk

You'll get a list of every block device on the system. Look for the disk that matches the size of the drive you just installed and isn't already mounted anywhere — no partitions listed under it, or partitions with no mount point. On a typical setup your boot disk shows up as sda and the new drive as sdb, but that's not guaranteed, especially with NVMe drives, which usually show up as nvme0n1, nvme1n1, and so on. Match by size, not by assumption.

Step 2: Create the thin pool from the GUI

This is the easiest path and the one I'd recommend for a first attempt.

• In the left-hand tree, click your node (not Datacenter — this is a per-node, per-disk operation).
• Go to Disks → LVM-Thin.
• Click Create: Thinpool.
• In the dialog, pick your new disk from the Disk dropdown.
• Give it a Name — something like data works fine, it's just an internal label.
• Leave Add Storage checked. This tells Proxmox to automatically register the pool as usable storage right after creating it, so you don't need a second step.
• Click Create.

Proxmox partitions the disk, creates the volume group and thin pool, and adds the storage entry, usually in under a minute for an SSD. Once it finishes, you'll see the new storage listed under Datacenter → Storage, ready to hold VM disks and container root filesystems.

If you'd rather name the storage entry something more descriptive than the pool name, or you unchecked Add Storage, skip ahead to Step 4.

Step 3: Create the thin pool from the command line

If you'd rather see exactly what's happening — or the GUI wizard is throwing an error you want to work around — here's the manual version. This example assumes the new disk is /dev/sdb with nothing useful on it.

pvcreate /dev/sdb
vgcreate data-vg /dev/sdb
lvcreate -l 100%FREE -n data -T data-vg

pvcreate marks the disk as an LVM physical volume. vgcreate groups it into a volume group named data-vg — pick any name that makes sense to you, it doesn't need to match anything else. lvcreate -T creates a thin pool logical volume inside that group, using all available space with -l 100%FREE.

If you'd rather size the pool manually instead of using all the free space (leaving room to expand later, for example), swap that flag for something like -L 400G.

Step 4: Register the pool as Proxmox storage

If you used the GUI wizard with Add Storage checked, this step is already done — skip it. If you created the pool by hand, or unchecked that box, add it manually:

• Go to Datacenter → Storage → Add → LVM-Thin.
• ID: a name for this storage entry, e.g. local-lvm-2.
• Volume group: select data-vg (or whatever you named it).
• Thin Pool: select data.
• Content: check Disk image and Container — LVM-Thin can't store ISOs, templates, or backup files, only VM disks and LXC root filesystems.
• Click Add.

Or from the CLI, the equivalent single command is:

pvesm add lvmthin local-lvm-2 --vgname data-vg --thinpool data --content images,rootdir

Step 5: Confirm it works

Create a test VM (or resize an existing one) and point its disk at the new storage. In the VM's hardware settings, its disk should now list your new storage ID as the target. Delete the test VM once you've confirmed it, and you're done.

You can also check pool usage at any time from the node's Disks → LVM-Thin tab, which shows how much of the pool is actually written to versus how much is allocated to VMs — the number that matters is the "Usage" figure, not the sum of your VMs' disk sizes.

Commands Explained

A quick reference for what ran above, since it's worth knowing what each piece actually does before you run it again on a production box.

• pvcreate /dev/sdb — initializes a disk (or partition) as an LVM physical volume. This is the first layer; nothing else works until this exists.
• vgcreate data-vg /dev/sdb — groups one or more physical volumes into a named volume group, the container that logical volumes live inside.
• lvcreate -l 100%FREE -n data -T data-vg — creates a thin pool logical volume named data inside the volume group, using all remaining free space. The -T flag is what makes it a thin pool instead of a normal volume.
• pvesm add lvmthin <id> --vgname <vg> --thinpool <pool> --content images,rootdir — registers an existing thin pool with Proxmox's storage layer so it shows up as a selectable target in the GUI.
• lsblk — lists block devices and their partitions, mount points, and sizes. The fastest way to sanity-check which device is which before you touch anything.
• pvs, vgs, lvs — list physical volumes, volume groups, and logical volumes respectively. Useful for confirming a step actually worked.

Common Errors

"Device /dev/sdb excluded by a filter" when running pvcreate — the disk already has a filesystem signature, an old partition table, or leftover RAID metadata on it from a previous life. Wipe it first with wipefs -a /dev/sdb, then double-check with lsblk -f that it's really blank before retrying.

"Insufficient free extents" during lvcreate — you're asking for more space than the volume group actually has, usually because a chunk of the disk is already allocated to something else. Run vgs to see actual free space in the group and size your request below that.

Thinpool creation fails in the GUI with "disk already in use" — the same root cause as the filter error above. The wizard refuses to touch a disk it thinks holds real data, which is a good instinct, but it means you'll need to clear it manually first.

VM disk creation fails with "not enough space" even though the pool looks empty — this happens when the pool's metadata volume, not the data volume, has filled up. Thin pools keep a small separate area for metadata, and a huge number of tiny snapshots can exhaust it faster than the data itself. Check with lvs -a and look at the Meta% column.

Troubleshooting

If a VM freezes or goes read-only and the pool usage in the GUI is sitting near 100%, that's thin pool exhaustion, not a VM-level bug. Every write to every guest on that pool stalls once it's full — this is the downside of overcommitting space that thin provisioning makes easy to do by accident.

The fix in the moment is to free space fast: delete an old snapshot, remove an unused VM disk, or extend the underlying volume group if there's a spare disk you can add. Longer term, keep the pool's actual usage below 80% or so and set a reminder to check it rather than relying on Proxmox to warn you in time.

If a newly created thin pool doesn't show up as a storage option when creating a VM, double-check the Content field on the storage entry under Datacenter → Storage — it's easy to add the pool without ticking Disk image, and Proxmox will simply hide it from the VM disk dropdown until that's fixed.

If you're not sure whether a disk is really unused before wiping it, run lsblk -f and look at the FSTYPE column. An empty FSTYPE next to a device with no children means it's genuinely blank. Anything else — ext4, ntfs, LVM2_member, zfs_member — means there's real data or metadata on it, and you should stop and confirm before going further.

Best Practices

Leave a bit of headroom in the volume group instead of allocating 100% of it to the thin pool immediately. A few GB of unallocated space gives you room to extend the pool's metadata volume later without a disruptive rebuild.

Name storage IDs after what they are, not where they happen to be today — ssd-fast ages better than node1-storage2 if you ever move disks around.

Don't put backup files or ISO images on LVM-Thin storage — it physically can't hold them, since it only supports disk images and container filesystems as content types. Keep a directory or NFS storage around for that.

Monitor real usage, not allocated usage. A pool showing 300% allocated across your VMs is completely normal with thin provisioning; a pool showing 90% actually used is the number that should get your attention.

If you're not confident about disk overcommitment, size your VM disks closer to what they'll realistically use rather than defaulting to round numbers like 100 GB out of habit.

Frequently Asked Questions

Can I add more disks to an existing thin pool later?

Yes, if they're in the same volume group. Extend the volume group with vgextend, then grow the thin pool with lvextend. The GUI doesn't currently expose this directly, so it's a CLI job.

What happens if the pool fills up completely?

Every VM writing to that pool will stall or throw I/O errors until space is freed. It doesn't corrupt existing data, but it's not graceful either — treat it as an outage, not a warning.

Is LVM-Thin as safe as ZFS?

Not in the same way. ZFS checksums every block and can detect silent corruption; LVM-Thin doesn't. On a single disk with no redundancy, neither one protects you from that disk failing — only backups do that.

Can I resize a VM's disk on LVM-Thin storage?

Yes, and it's one of the format's strengths. Resize from the VM's Hardware tab or with qm resize <vmid> <disk> +10G, then grow the filesystem inside the guest.

Do I need to partition the disk myself before pvcreate?

No. You can run pvcreate against the raw device (like /dev/sdb) directly. Partitioning it first is optional and mostly a matter of preference.

Conclusion

LVM-Thin isn't glamorous, but it's the storage type doing quiet work behind most default Proxmox installs, and now you know how to point it at a disk of your own choosing instead of only the one it came with. Start with the GUI wizard — it handles the fiddly parts for you — and keep the CLI steps in your back pocket for the day the wizard won't cooperate.

The one habit worth building now: check pool usage occasionally instead of assuming thin provisioning will sort itself out. It won't, and a full pool takes down every VM on it at the same time, which is a bad way to find out you should have been watching that number.