When you install Proxmox or add a disk, you have to tell it how to store virtual machines. The three local options you’ll meet are LVM, LVM-Thin, and ZFS, and the choice affects whether you can take snapshots, how efficiently you use disk space, and how much RAM the system eats. Pick wrong and you find out later, usually when you try to snapshot a VM and the option isn’t there.
This breaks down what each one is, how they differ on thin provisioning and snapshots, why ZFS wants so much memory, and which to choose for common setups. None of them is “best” outright — they trade simplicity, features, and safety against each other.
The three options at a glance
Before the details, here’s the shape of the decision:
LVM vs LVM-Thin vs ZFS in Proxmox
| LVM (thick) | Classic volume manager. Allocates full disk size up front. No snapshots in Proxmox. Low overhead. |
|---|---|
| LVM-Thin | LVM with thin provisioning. Allocates space as written. Supports snapshots. Low overhead. |
| ZFS | Filesystem + volume manager + software RAID. Thin by default, snapshots, checksums, compression. Hungry for RAM. |
| Thin provisioning | LVM: no. LVM-Thin: yes. ZFS: yes. |
| Snapshots | LVM: no. LVM-Thin: yes. ZFS: yes. |
| Software RAID | LVM: no (needs mdadm/hardware). LVM-Thin: no. ZFS: yes, built in. |
| Data checksumming | LVM: no. LVM-Thin: no. ZFS: yes. |
| RAM appetite | LVM/LVM-Thin: minimal. ZFS: high (ARC cache). |
LVM: simple and predictable, but no snapshots
LVM (Logical Volume Manager) is the traditional Linux way to carve disks into flexible volumes. In Proxmox, a thick LVM storage gives each VM a logical volume of a fixed size, allocated in full the moment you create the disk. Ask for a 100 GB disk and 100 GB is reserved immediately, whether the VM writes to it or not.
That predictability is the upside. There’s almost no overhead, performance is consistent, and there’s no caching layer to tune. The catch is the one that matters most for day-to-day work: thick LVM in Proxmox does not support snapshots. You can’t grab a point-in-time copy before a risky update, which is something you’ll want constantly.
LVM-Thin: thin provisioning plus snapshots
LVM-Thin is LVM with a thin pool. Instead of reserving a VM’s full disk size up front, it allocates blocks only as the guest actually writes them. Create a 100 GB disk on a VM that only uses 12 GB, and just 12 GB is consumed on the pool. This is thin provisioning, and it lets you over-commit storage — define more virtual disk than you physically have, on the bet that not every VM fills up at once.
Crucially, LVM-Thin also supports snapshots. You can snapshot a VM before an upgrade, test the change, and roll back if it breaks. That alone makes it the better default over thick LVM for local disks.
The default Proxmox installer on ext4 actually sets up an LVM-Thin pool called local-lvm for you, so many people are using it without realizing.
There’s a related failure people hit when the install disk fills up. If you ever see the local-lvm pool reported as full, that’s the thin pool exhausting its real space, and it’s worth understanding before it happens in production.
ZFS: the feature-rich, RAM-hungry option
ZFS is a different animal. It’s a filesystem, a volume manager, and a software RAID system rolled together, and it brings features the LVM options don’t have:
- Built-in software RAID — mirrors (RAID1), RAID10, and RAIDZ (parity, like RAID5/6) with no hardware RAID card.
- Snapshots and clones — instant, cheap, copy-on-write snapshots.
- Checksumming — every block is checksummed, so ZFS detects silent data corruption (bit rot) and, with redundancy, repairs it automatically.
- Compression — transparent compression (lz4) that often saves space and can even improve throughput.
- Thin provisioning — on by default.
That’s a strong list, and it’s why ZFS is popular for hosts that need data integrity and redundancy. But it comes with a real cost in memory.
The ARC: why ZFS wants your RAM
ZFS uses free RAM as a read cache called the ARC (Adaptive Replacement Cache). The more memory it has, the more it caches, and the faster reads get. The rough sizing guideline is about 1 GB of RAM per terabyte of pool, on top of whatever your VMs need — and more is better for performance.
On a server with plenty of RAM that’s fine. On an 8 GB box, a large ZFS pool and a couple of VMs will fight over memory, and your VMs lose. You can cap the ARC to stop it eating everything:
# limit ZFS ARC to 4 GB (value is in bytes)
options zfs zfs_arc_max=4294967296After editing, update the initramfs and reboot for it to take effect:
update-initramfs -u
rebootSingle-disk ZFS detects corruption but can’t fix it
You can run ZFS on one disk and still get snapshots, compression, and corruption detection via checksums. What you don’t get is repair — fixing bit rot needs a second copy of the data, which means a mirror or RAIDZ. So single-disk ZFS tells you when something’s wrong but can’t heal it. For real data safety, ZFS wants two or more disks.
How to choose
Match the storage to your hardware and what you actually need.
Pick based on your setup
- One disk, want simplicity and snapshots: LVM-Thin (the installer's default)
- One disk, want checksums/compression and have spare RAM: single-disk ZFS
- Two or more disks, want software RAID + snapshots + integrity: ZFS (mirror or RAIDZ)
- Hardware RAID card already handling redundancy: LVM-Thin on top of it
- Tight on RAM (8 GB or less): avoid large ZFS pools, prefer LVM-Thin
- Need maximum, predictable performance on a single modest SSD: LVM-Thin
A few plain recommendations:
- For most single-disk installs, LVM-Thin is the sensible default. It’s what the installer gives you on ext4, it does thin provisioning and snapshots, and it stays out of your RAM.
- Choose ZFS when you have two or more disks and want redundancy plus data-integrity checking, and you can feed it the memory. Pair it with enterprise SSDs (or HDDs) rather than cheap consumer drives.
- Thick LVM is rarely the best choice today. Its lack of snapshots outweighs its simplicity for most people. Reach for it only when you specifically don’t want any thin-provisioning or caching behavior.
Bottom line
LVM-Thin and ZFS both give you the snapshots you’ll want; plain thick LVM doesn’t. The split between them is about hardware and goals: LVM-Thin for a light, fast, single-disk setup, and ZFS for multi-disk redundancy and data integrity when you can spare the RAM and use decent drives.
The storage choice happens during setup, so it’s worth reading the bare-metal install guide where this decision comes up, and if you’re still comparing platforms, the Proxmox VE vs VMware ESXi guide covers the broader picture. For more, browse the Proxmox guides.
