// Technical guide // Storage Updated:

Choosing storage on Proxmox VE:
ZFS, LVM, NFS and Ceph

Proxmox does not force a single datastore forever. The pvesm guide splits plugins into file and block and states it plainly: shared storage lets you live-migrate without copying the disk. Below — which plugin has snapshots, which is shared, and what that means in a VMware move.

// Table of Contents
  1. Two classes: file vs block
  2. Type table (pvesm)
  3. Local ZFS and LVM-thin
  4. NFS, iSCSI and Ceph
  5. Snapshots as volume chains (PVE 9)
  6. How we choose in a design
  7. Multipath, overprovision, PBS
  8. Live migration vs storage type
  9. Content types in pvesm
// 01 · Model

Two classes: file vs block

File-level (POSIX) storage holds any content: images, ISOs, templates, backups, snippets. ZFS is the most advanced here — snapshots and clones. Block storage holds large raw images; ISOs and backups usually do not live there. Ceph RADOS is distributed block, presented as RBD.

Configuration sits in /etc/pve/storage.cfg and is shared across cluster nodes. Shared storage is physically reachable from every node; local is configured everywhere, but the content differs per host.

// 02 · Table

Type table (pvesm)

DescriptionPluginSharedSnapshots
ZFS (local)zfspoolnoyes
Directorydirnoyes (qcow2 / chain)
NFSnfsyesyes (qcow2 / chain)
CIFScifsyesyes (qcow2 / chain)
Proxmox Backuppbsyesn/a
CephFScephfsyesyes
LVMlvmno (yes on iSCSI/FC)yes (chain since PVE 9)
LVM-thinlvmthinnoyes
iSCSI / FCiscsi / nativeyesyes (chain)
Ceph/RBDrbdyesyes

Footnotes from the guide: qcow2 snapshots on NFS can stall a running VM and on large disks take minutes or hours. Types with snapshots also support thin provisioning. If storage fills up, guests get IO errors — watch over-provisioning. Shared in the table means nodes physically see the same image; local is in storage.cfg everywhere, but the content is per host. That distinction decides whether live migration copies memory or the whole volume.

// 03 · Local

Local ZFS and LVM-thin

ZFS (zfspool): VM images as zvols (block). Native snapshots and clones. Not shared — live-migrating the disk needs --with-local-disks (it copies the volume). Excellent on an NVMe node, on PBS and wherever you want checksums and scrub.

LVM-thin: a local thin pool, snapshots yes, shared no. The PVE installer often creates local-lvm. Thick LVM on a shared LUN (iSCSI/FC) slices the LUN into virtual disks; from PVE 9, snapshots as volume chains.

// 04 · Shared

NFS, iSCSI and Ceph

NFS: shared, flexible content. Snapshots via qcow2 or a chain — with the performance caveat. A good shelf for ISOs and templates; production VM disks only if the array and network can carry them.

iSCSI / FC: LUN + LVM, shared, multipath usually required. Snapshots from PVE 9 as a chain (technology preview in the 9 docs).

Ceph RBD: shared, snapshots, HCI or dedicated OSDs. Comparison with vSAN: vSAN vs Ceph. We leave CephFS for ISOs, backups and CTs, not as the only VM-disk datastore.

// 05 · PVE 9

Snapshots as volume chains

From Proxmox VE 9, snapshots as volume chains work on block storage that could not snapshot on its own (iSCSI, FC). Layers are separate volumes. The documentation marks this as a technology preview. Internal qcow2 snapshots still stall the VM on create and delete.

// 06 · Choice

How we choose in a design

// 07 · Operations

Multipath, overprovision, PBS

The pvesm guide on iSCSI/FC: LVM slices the LUN into virtual disks, and multipath is usually required in a cluster. Without it, path failover looks like “the disk vanished”. Thin provisioning comes with snapshot-capable types — when storage fills, guests get IO errors. We watch overprovision; we do not “leave it for later”.

The pbs plugin is shared and does not hold VM snapshots in the qcow2 sense — it is the backup target. A directory on the same ZFS as VM disks is not 3-2-1. Btrfs in the pvesm table is a technology preview (best-effort) — we do not put production on it. ZFS over iSCSI is in the table as shared with snapshots; that is a separate backend, not ordinary zfspool.

// 08 · Migration

Live migration vs storage type

Shared (NFS, RBD, iSCSI/FC) — live migration copies memory, not the disk. Local ZFS/LVM-thin — --with-local-disks copies the volume over the cluster network; on a large zvol that is minutes. HA after a node dies does not magically move local ZFS to a neighbour. Flag details: live migration. HCI vs vSAN: vSAN vs Ceph.

// 09 · Content

Content types in pvesm

The pvesm guide assigns each storage a content list: images (VM disks), rootdir (containers), iso, vztmpl, backup, snippets, import. Not every plugin takes every content type: LVM/RBD are mainly block images; ISOs and vzdump go on a directory, NFS or CephFS. PBS has its own plugin and is not an ISO shelf.

In a design we split: VM disks on RBD/ZFS/LVM, ISOs and templates on NFS or CephFS, backups on PBS. Mixing backups with VM disks on the same zfspool breaks 3-2-1, even when ZFS snapshots “look like a copy”.

⚠️

Note: a qcow2 snapshot on NFS can stall a running VM for minutes. We put production VM disks on NFS only when the array and network can carry them — deliberately, not “because NFS is shared”.

We’ll map storage to the cluster

ZFS, LVM-thin, NFS, iSCSI or Ceph — for live migration, snapshots and PBS, without guessing the plugin.

⚡ Free consultation → vSAN vs Ceph