Proxmox VE Storage: ZFS, LVM, Ceph, and Directory

Proxmox VE supports many storage types — from local disks to distributed cluster systems. Choosing the right storage is critical for the performance and reliability of your virtual machines.

Comparing storage types

ZFS: creating and managing a pool

ZFS is the recommended file system for Proxmox. It offers built-in snapshots, deduplication, and data integrity checks.

# Show available disks
lsblk -d -o NAME,SIZE,TYPE | grep disk

# Create a mirrored pool (RAID-1) from two disks
zpool create -f   -o ashift=12   -O compression=lz4   -O atime=off   tank mirror /dev/sdb /dev/sdc

# Create a RAID-Z pool from three disks
zpool create -f   -o ashift=12   -O compression=lz4   tank raidz /dev/sdb /dev/sdc /dev/sdd

# Pool status
zpool status tank

# Performance
zpool iostat -v tank 1

Adding ZFS storage to Proxmox

># Via CLI
pvesm add zfspool tank-storage --pool tank --sparse 1

# Or the web interface:
# Datacenter → Storage → Add → ZFS

LVM-Thin: thin provisioning

LVM-Thin lets you create disks larger than the actually available space (thin provisioning). Ideal for Dev/Test environments:

# Create a physical volume and volume group
pvcreate /dev/sdb
vgcreate data /dev/sdb

# Create a 100 GB thin pool
lvcreate -L 100G --thinpool data/vm-pool

# Add to Proxmox
pvesm add lvmthin local-thin --vgname data --thinpool vm-pool

Configuring Ceph in Proxmox

# On each Proxmox node
pveceph install --release squid

# Initialize Ceph on the first node
pveceph init --network 10.0.0.0/24

# Create MON on all nodes
pveceph createmon

# Add an OSD (disk)
pveceph createosd /dev/sdc

# Create a pool
pveceph createpool vm-pool --size 3 --min_size 2

Optimizing ZFS for SSDs

># Disable slow sync for VMs (not for production databases!)
zfs set sync=disabled tank

# Enable the ARC cache (50% of RAM is recommended)
echo "options zfs zfs_arc_max=4294967296" > /etc/modprobe.d/zfs.conf
# (4 GB = 4294967296 bytes)

# View ARC statistics
arc_summary

Storage errors and their causes

Three errors you are most likely to run into with ZFS, LVM-Thin, and Ceph.

cannot import 'tank': no such pool available
state: DEGRADED - one or more devices could not be used because the label is missing
rados_connect failed - error -13 (Permission denied)

• cannot import 'tank': the pool cache was lost after reinstalling the system or moving the disks to another server. Import the pool manually: zpool import tank, adding -f if needed.
• DEGRADED ... label is missing: one of the mirror or RAID-Z disks disconnected or failed. Identify the faulty disk with zpool status -v tank and replace it: zpool replace tank old-disk new-disk.
• rados_connect failed - Permission denied: the Ceph authentication key on the node does not match the cluster's key. Recreate the pool's keyring via pveceph createpool, or copy the current key from /etc/pve/priv/ceph.client.admin.keyring.

When these storage types are not the right fit

Every storage type has conditions under which it fails to deliver.

• ZFS on a single disk with no RAID and no ECC memory: checksums protect against on-disk corruption, but without a mirror a single disk failure still stops the VM, and without ECC, memory errors can corrupt data before it is even written to disk.
• LVM-Thin in a cluster with no shared storage: thin pools are local to the node, so live-migrating a VM whose disk sits on LVM-Thin without Ceph or NFS is impossible without the --with-local-disks flag and a pause while the disk copies.
• Ceph on a two-node cluster or a 1 Gbit/s network: Ceph needs at least three nodes for OSD quorum and high network throughput; at a smaller scale, write latency ends up higher than with local ZFS.

Verifying the result

# Pool health and read/write/checksum errors
zpool status -v tank

# The storage is attached in Proxmox and free space is visible
pvesm status

# Test write and data integrity check
dd if=/dev/urandom of=/tank/testfile bs=1M count=100
zpool scrub tank
zpool status tank

If the pool status is ONLINE, the READ/WRITE/CKSUM counters are zero, and the scrub finishes without errors, the storage is healthy. For moving data between nodes at the ZFS level, see ZFS replication in Proxmox VE.

Frequently asked questions

Can a VM disk be moved later from LVM-Thin to ZFS without recreating the virtual machine from scratch?

Yes, moving a VM disk between storage types in Proxmox works without recreating the virtual machine — through the Move Disk action in the web interface or the qm command, which copies the data to the new storage and switches the configuration to it. The VM can stay off or keep running during the copy, depending on the mode.

What happens to the data on a ZFS pool if one disk is physically pulled out of a mirror while it is running?

A ZFS mirror is built for exactly this kind of failure: the pool drops into a DEGRADED state but keeps serving data from the remaining disk without stopping any virtual machines. Once the failed disk is replaced, the new one is added to the pool with a replace command, and ZFS rebuilds redundancy by recalculating checksums from the surviving copy.

Should the ARC cache be sized manually if the server also runs other services besides Proxmox?

The share of RAM given to the ARC cache is worth revisiting when the server is shared between several roles: a fixed value sized only for Proxmox can starve other services of memory. It is safer to cap ARC with headroom left for everything else on the box, rather than leaving the default setting unadjusted for the server's real workload.

How do you decide which storage type to pick when the server has only one SSD with no way to mirror it?

With a single SSD and no way to mirror it, LVM-Thin or a plain ZFS pool without redundancy are the usual picks — both deliver high performance and thin provisioning, but neither protects against the disk itself failing. Regular external backups matter more than the choice of file system, since the single disk stays the one point of failure regardless.