If your Proxmox NVMe is sitting at 97% VG usage — like mine was — and you have a spare SATA SSD collecting dust, this guide is exactly what you need. I’ll show you how to add LVM-thin storage in Proxmox using a second drive and then migrate your existing LXC containers to it. No reinstall. No downtime drama. Just clean, working infrastructure. 🛠️
Why Add LVM-Thin Storage in Proxmox?
When you install Proxmox VE, the installer creates a thin pool on your primary drive and allocates up to 75% of the volume group to it. That’s great until you run a few containers and VMs and suddenly you’re left with 16 GB of free space in your VG.
The cleanest fix is to add LVM-thin storage in Proxmox on a separate physical drive. Here’s why LVM-thin storage in Proxmox is the right format over a simple directory storage:
- ✅ Snapshot support for both LXC containers and VMs
- ✅ Thin provisioning — allocate 500 GB but use only what’s needed
- ✅ Same feature parity as your default
local-lvmpool - ✅ Live migration support between storage pools
If you’re just getting started with Proxmox VE, check out my guide on installing Proxmox VE 9.1 first, and don’t miss the Proxmox post-install script that handles the most annoying defaults.
Prerequisites
- A spare disk not currently used by Proxmox (in my case: Patriot P220 2TB SATA SSD on
/dev/sdc) - SSH or shell access to your Proxmox node
- A few minutes of container downtime for the migration step
⚠️ All data on the target disk will be destroyed. Double-check the device name before running any command.
Step 1 — Identify Your Disk
First, confirm which device you’re working with:
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODELIn my case the output showed:
sdc 1.9T disk Patriot P220 2048GB
└─sdc1 1.9T part ext4The disk had an old ext4 partition but nothing mounted — safe to wipe.
Also run a quick SMART check before trusting any drive with your containers. If smartmontools isn’t installed yet, grab it with apt install smartmontools -y. You can find the full attribute reference in the smartmontools documentation.
smartctl -a /dev/sdcLook for SMART overall-health self-assessment test result: PASSED and zero values on Reallocated_Sector_Ct and Current_Pending_Sector. If those are clean, you’re good to proceed.
Step 2 — Wipe the Disk
⚠️ This permanently destroys all data on
/dev/sdc. Verify the device name twice.
# Remove all existing signatures and partition tables
wipefs -a /dev/sdc
# Create a new GPT partition table with a single partition
sgdisk -N 1 /dev/sdc
# Verify the result
lsblk /dev/sdcYou should now see /dev/sdc1 with no filesystem type.
Step 3 — Create LVM Structure
This is where you add LVM-thin storage in Proxmox at the block level. If you want to dive deeper into how Proxmox handles LVM thin pools internally, the official Proxmox storage documentation covers all the details.
# Initialize the partition as an LVM physical volume
pvcreate /dev/sdc1
# Create a new volume group named ssd-data
vgcreate ssd-data /dev/sdc1
# Create a thin pool using 95% of the VG
# Leaves ~5% free for LVM metadata operations
lvcreate -l 95%VG --type thin-pool -n data ssd-dataVerify the result:
lvs -a ssd-dataYou should see the data thin pool with twi-a-tz-- attributes — that’s the correct state for an active thin pool.
Step 4 — Register the Storage in Proxmox
Now tell Proxmox about the new pool. This is the step that makes it appear in the GUI and CLI:
pvesm add lvmthin ssd-data \
--vgname ssd-data \
--thinpool data \
--content rootdir,imagesCheck that it’s active:
pvesm statusYou should now see ssd-data listed as an lvmthin storage with status active. 🎉
If you want to set it as the default storage for new containers, go to Datacenter → Storage → ssd-data and make sure it’s enabled. From this point on, any new LXC or VM you create can use the LVM-thin storage in Proxmox on the SATA SSD directly from the creation wizard. You can also raise its priority in the GUI.
Step 5 — Migrate LXC Containers
Now the fun part — actually moving your containers off the old pool. The pattern is always the same: stop → move → start. Repeat it for every container you want to migrate. I’m doing CT 100 (WireGuard) and CT 200 (OneDrive sync) as examples. If you’re running WireGuard in an LXC like me, check out this guide on self-hosting WireGuard VPN on Proxmox.
⚠️ The container must be stopped during volume migration. Plan for a short downtime window per container.
First, get the list of all your containers so you know which IDs to work with:
# List all containers with their current status
pct listThen migrate each one using this exact sequence — one container at a time:
# Replace VMID with your actual container ID (e.g. 100, 200, 300...)
pct stop VMID
pct move-volume VMID rootfs ssd-data
pct start VMIDFor example, migrating CT 100 and CT 200:
# Migrate CT 100
pct stop 100
pct move-volume 100 rootfs ssd-data
pct start 100
# Migrate CT 200
pct stop 200
pct move-volume 200 rootfs ssd-data
pct start 200
# Have CT 300? Same thing:
# pct stop 300
# pct move-volume 300 rootfs ssd-data
# pct start 300After each container starts back up, verify the migration worked before moving on to the next one. This is important — confirming each step lets you catch problems early rather than discovering all containers failed to start after a bulk operation. The whole point of using LVM-thin storage in Proxmox is reliability, so treat the verification step seriously:
# Check that rootfs now points to ssd-data
pct df VMIDThe rootfs line should now reference ssd-data:vm-XXX-disk-0 instead of local-lvm:vm-XXX-disk-0. ✅ Only then move on to the next container.
You can also do this via the GUI: CT → Resources → rootfs → Move Volume — same result, just more clicks. The GUI approach migrates one volume at a time as well, so the same stop/start logic applies.
What Happens to the Old local-lvm Pool?
After migration, the local-lvm thin pool on your NVMe is nearly empty but still physically occupies ~348 GB of VG space. You have two options:
- Leave it for VM disks or future use — it costs nothing operationally
- Reduce it to reclaim free PE in the VG — more complex, covered in a separate post
For now, just having containers off the stressed NVMe VG is already a win. The VG usage on the NVMe will drop significantly once the rootfs volumes are moved.
Final Thoughts
Adding LVM-thin storage in Proxmox to a second drive is one of the cleanest ways to expand your homelab without rebuilding anything. The whole process takes under 10 minutes and gives you a fully-featured storage pool with snapshots, thin provisioning, and live migration support.
Now that I’ve added LVM-thin storage in Proxmox on the Patriot SSD, both containers run on a dedicated 2TB pool with plenty of room to grow — while the NVMe is back to breathing comfortably. 🧘
If you’re managing your Proxmox setup and want to add more services, check out the WireGuard VPN guide — it’s a great first LXC to run on your new storage.