Choosing a Proxmox VE Storage Backend: LVM-thin vs ZFS vs Ceph RBD

If you're setting up a Proxmox VE cluster, one of the first real engineering decisions is where VM disks actually live. The three backends most people weigh are local LVM-thin, ZFS on Linux, and Ceph RBD. The useful takeaway: there is no universally "best" option — the right choice depends on whether you need live migration and snapshots across nodes, how much RAM and network bandwidth you have, and how much operational complexity your team can absorb. All three are fully supported in Proxmox VE 8.x and can coexist in the same cluster, so you can also mix them per workload.

The decision and its constraints

Start by answering four questions:

• Do you need live migration and shared snapshots? If VMs must move between nodes without downtime, local-only storage (LVM-thin, directory storage) is out unless you replicate.
• What is your I/O profile? Latency-sensitive databases want local NVMe; bulk VDI or backup targets tolerate network latency.
• What hardware do you have? ZFS wants RAM; Ceph wants at least three nodes and fast networking.
• Who operates it? Ceph is a distributed system with its own failure modes. A two-person team running Ceph for ten VMs is usually over-engineering.

Comparing the three supported options

Trade-offs in practice

LVM-thin is the default local storage for a reason: it's simple, fast, and thin-provisioned. Its weakness is that everything is node-local — no cross-node snapshots, no live migration without copying the disk. Scaling means manually extending volume groups. For a single node or a small cluster where VMs stay put, it's hard to beat.

ZFS gives you integrated snapshots, compression, and checksummed self-healing on local disks, plus easy replication to another node with zfs send. The cost is RAM: the ARC (ZFS's read cache) performs best with roughly 1 GB of RAM per TB of storage, and performance degrades noticeably if the working set can't be cached. Pool design matters — a pool built from the wrong vdev layout is painful to fix later.

Ceph RBD is the only option here that gives you genuinely shared, fault-tolerant, horizontally scalable block storage with native live migration. The price is latency from network overhead and real operational weight: you need at least three monitor nodes for quorum, enough OSDs (the per-disk storage daemons) for performance, and a 10 GbE or faster network to keep VM boot and migration latency acceptable.

Concrete validation: ZFS backend

As an example of validating a choice before committing workloads, here's the ZFS path. Run these on the Proxmox node as root.

Create a mirrored pool from two spare disks (replace sdb/sdc with your devices — this destroys their contents):

zpool create tank mirror /dev/sdb /dev/sdc

Then add it in the Proxmox GUI under Datacenter → Storage → Add → ZFS, selecting pool tank. Create a test VM with its disk on that storage, take a snapshot from the GUI, and verify it exists at the ZFS level:

zfs list -t snapshot

You should see a snapshot entry under the VM's dataset. Inside the guest, run fio against the virtual disk to confirm performance matches your expectations before migrating real workloads. Two cautions: watch ARC memory usage (arc_summary or cat /proc/spl/kstat/zfs/arcstats) and, if RAM is tight, cap ARC via /etc/modprobe.d/zfs.conf (e.g., options zfs zfs_arc_max=4294967296 for 4 GB) followed by a reboot or module reload.

Limitations and mixing backends

Mixing storage types in one cluster is supported and often sensible — databases on local ZFS/NVMe, bulk VMs on Ceph — but it complicates backups. Make sure your backup setup (for example, Proxmox Backup Server) handles each backend's snapshot mechanism correctly, and test restores per storage type, not just backups. Also note that ZFS's RAM guidance and Ceph's network requirements are rules of thumb; validate against your own hardware and workload before production use.