Proxmox VE Storage Types Explained: Directory vs LVM vs ZFS vs Ceph (Which Should You Use?)

Somewhere around the third or fourth time you click Add Storage in the Proxmox VE web interface, you hit a dropdown with names like Directory, LVM-Thin, ZFS, NFS, CIFS, iSCSI, and Ceph (RBD) — and not one word of explanation about what any of them actually do. Most people either pick whatever the installer defaulted to, or copy a command from a forum post without knowing what it changes.

That gap matters more than it looks like at first. The storage type you pick decides whether snapshots work, whether you can live-migrate a VM to another node, and whether a full disk actually eats a full disk's worth of space. Picking wrong doesn't break anything immediately — it just quietly limits what you can do six months from now, right when you need that feature.

What You Will Learn

This isn't a single how-to. It's the explainer that should come before you touch any of the individual storage guides. By the end, you'll know:

• What Proxmox VE actually means by "storage," and how /etc/pve/storage.cfg ties it together
• The real difference between file-level and block-level storage
• Which storage types support snapshots, thin provisioning, and cluster-wide sharing — and which don't
• How to check what storage you already have configured, using both the GUI and the command line
• How to add a second storage type yourself, as a hands-on example
• The errors people run into most often, and what causes them

What Is This Feature?

In Proxmox VE, "storage" isn't just a disk. It's a defined location — local or remote — where the hypervisor is allowed to keep specific kinds of data. Every storage entry lives in one config file, /etc/pve/storage.cfg, and because that file sits inside /etc/pve/, it gets synced automatically to every node in a cluster. Add a storage on one node, and every other node sees it immediately.

Proxmox groups what a storage is allowed to hold into a handful of content types:

• images — virtual disks for QEMU/KVM virtual machines
• rootdir — the root filesystem for LXC containers
• vztmpl — LXC container templates you download from the built-in template list
• iso — ISO installer images you upload or download
• backup — vzdump backup archives
• snippets — small helper files like cloud-init snippets or hook scripts

Not every storage type supports every content type. A ZFS pool, for example, is happy to hold VM disks and container root filesystems, but it won't hold an ISO file directly — you'd point ISOs at a directory storage instead. That's why most Proxmox hosts end up with two or three storage entries rather than one: one fast block storage for disks, one plain directory for ISOs and backups.

The other split worth understanding is file-level versus block-level storage. File-level storage (Directory, NFS, CIFS, CephFS) stores VM disks as regular files, usually in qcow2 or raw format, sitting on top of a normal filesystem. Block-level storage (LVM, LVM-Thin, ZFS, Ceph/RBD, iSCSI) hands the VM a raw block device directly, without a filesystem layer in between. Block-level tends to be faster and supports better snapshot behavior; file-level is simpler to inspect, back up, and move around by hand.

Why Would You Use It?

You don't get to skip this decision — Proxmox VE won't run without at least one storage location for VM disks. But picking deliberately, instead of accepting the installer default, buys you a few things:

Snapshots. If you want to roll back a VM to how it looked five minutes ago, you need a storage type that actually supports snapshots. Plain directory storage only supports them if the disk is in qcow2 format; ZFS, LVM-Thin, and Ceph support them natively and more efficiently.

Thin provisioning. This just means the storage only writes the blocks a VM actually uses, instead of reserving the full disk size up front. Create a 100 GB virtual disk on thin storage and it might only use 4 GB on the real disk until the guest OS fills it up. ZFS, LVM-Thin, and Ceph all do this. Plain LVM does not — it reserves the full size immediately, which is one of the more common "why is my disk full already" surprises for people coming from LVM.

Live migration. Moving a running VM between cluster nodes without downtime needs storage that both nodes can see at the same time — shared storage like NFS, Ceph, or iSCSI. Local ZFS or local LVM-Thin can still migrate a VM, but Proxmox has to copy the entire disk over the network first, which is slower and briefly interrupts the guest.

Here's how the common options stack up against each other:

If you're running a single box in a homelab, that "Shared" column mostly doesn't matter to you yet. If you're building a cluster, it's close to the whole decision.

Prerequisites

Before working through the examples below, you'll want:

• A working Proxmox VE install (this article applies to 8.x and 9.x — the storage subsystem hasn't changed in any way that affects these steps)
• Root access to the web interface, or SSH access to the host as root
• At least one spare disk or free partition if you want to follow the hands-on example with a real second storage — you can also just read along using your existing storage
• Basic comfort typing a command into a terminal — nothing here is advanced shell work

Step-by-Step Tutorial

Rather than repeat the setup steps for eight different storage types — each already has its own dedicated guide — this walks through how to see what you're currently running, and how to add a second storage type so you can compare behavior directly.

1. Check what storage you already have

In the web interface, click Datacenter in the left tree, then Storage. You'll see every configured storage, its type, and which content types it's allowed to hold. On a fresh install this is usually local (a directory storage for ISOs and backups) and either local-lvm or local-zfs for VM disks, depending on which filesystem you picked during install.

From the shell, the same information is one command:

pvesm status

This lists every storage, its type, total size, used space, and whether Proxmox considers it currently active. It's the fastest way to sanity-check storage from a script or over SSH without opening the GUI.

2. Look at the config file directly

cat /etc/pve/storage.cfg

You'll see a block per storage, something like:

dir: local
        path /var/lib/vz
        content iso,vztmpl,backup

zfspool: local-zfs
        pool rpool/data
        content images,rootdir
        sparse 1

This file is the actual source of truth — the GUI is just a friendlier way of editing it. You generally shouldn't hand-edit it while Proxmox is running, since pvesm and the GUI both validate what they write; but reading it is a good way to understand exactly what's configured.

3. Add a second storage as a comparison

If you have a spare disk or an empty directory to test with, add a plain directory storage so you can see how it behaves differently from your default:

pvesm add dir extra-storage --path /mnt/extra --content images,iso,backup

Here, extra-storage is a name you're choosing (it can be anything, no spaces), --path points at an existing directory, and --content lists which content types this storage will accept. Run pvesm status again and you'll see it show up immediately.

If you'd rather test with network storage, adding an NFS share looks like this:

pvesm add nfs my-nfs --server 192.168.1.50 --export /export/proxmox --content images,backup

Swap in your actual NFS server address and export path. Proxmox will mount it automatically under /mnt/pve/my-nfs.

4. Try a snapshot on each and compare

Create a small test VM, then try taking a snapshot with its disk on your ZFS or LVM-Thin storage, and again with the disk on your new directory storage (as a raw-format disk). On the block storage, the snapshot completes almost instantly. On directory storage with a raw disk, you'll get an error along the lines of "can't snapshot volume of type raw" — you'd need to recreate the disk in qcow2 format for that to work. This is the fastest way to actually feel the difference the docs describe.

Commands Explained

Common Errors

A few errors show up over and over once people start mixing storage types:

"unable to activate storage 'x' - directory is expected to be a mount point." This happens when a directory storage is marked as requiring a mount point (the is_mountpoint option), but nothing is actually mounted there — often after a reboot where an fstab entry failed silently. Check mount to confirm the device is really mounted before Proxmox tries to use it.

"no such logical volume." Usually means an LVM or LVM-Thin storage is pointing at a volume group that no longer exists — common after replacing a disk without updating storage.cfg to match the new volume group name.

Disk shows up in storage.cfg but not as an option when creating a VM. Nine times out of ten this is a content-type mismatch — the storage doesn't have images in its allowed content list. Edit the storage in Datacenter → Storage and add it.

"storage ID 'x' already defined." You tried to add a storage name that's already in use. Names have to be unique across the whole cluster, not just the current node.

Troubleshooting

If a storage shows as inactive in pvesm status, start with the basics: is the disk actually present (lsblk), is the network share reachable (ping the NFS/CIFS server), and does the mount actually exist (mount | grep pve)? For ZFS pools specifically, zpool status will tell you immediately if a pool is degraded, faulted, or simply not imported.

For LVM and LVM-Thin, vgs and lvs show you the volume groups and logical volumes Proxmox is expecting to find. If a volume group is missing after a disk swap, you'll need to either recreate it with the same name or update storage.cfg to point at the new one.

System logs are also worth checking directly — journalctl -b filtered for the storage name will usually show the exact activation error, which is more detailed than what the GUI surfaces.

Best Practices

Keep ISOs, templates, and backups on a plain directory or NFS storage, separate from your VM disks. It keeps your fast block storage free of clutter and makes backups easier to reason about.

For a single-node homelab box, ZFS is usually the right default if you have more than one disk — you get snapshots, checksumming, and thin provisioning without any extra setup beyond picking it during install. I wouldn't reach for Ceph unless you actually have three or more nodes; it's genuinely great, but it's overkill (and a real resource cost) on anything smaller.

Avoid plain LVM unless you specifically need it for iSCSI-backed shared storage. It reserves full disk size on creation and doesn't support the same snapshot flexibility as LVM-Thin, so most people are better served picking LVM-Thin instead.

If you're clustering, decide on shared storage (NFS, Ceph, or iSCSI) before you start moving VMs around. Migrating from local-only storage to shared storage later means manually copying every disk — better to plan for it up front.

Frequently Asked Questions

Can I change a VM's storage type after creating it?

Yes. Use the "Move disk" option on the VM's Hardware tab to move a virtual disk to a different storage, including a different type. The VM does need to be stopped for some combinations, though live disk moves work for most common cases.

Do I need a Ceph or Proxmox subscription to use these storage types?

No. Every storage type covered here, including Ceph, is available in the free, no-subscription version of Proxmox VE. The subscription only affects access to the Enterprise package repository and official support.

Which storage type is fastest?

For a single node with local NVMe disks, plain LVM or LVM-Thin usually edges out ZFS on raw throughput, since ZFS trades some performance for its checksumming and copy-on-write features. In practice, that difference rarely matters outside of benchmarks.

Can I use more than one storage type at the same time?

Yes, and most setups do — it's normal to have local-zfs for VM disks and a separate directory or NFS storage for ISOs and backups on the very same host.

What happens if I delete a storage entry from Proxmox?

Removing a storage with pvesm remove only deletes the configuration entry — the actual disks, files, or ZFS pool are untouched. You can always re-add it later pointing at the same location.

Conclusion

None of these storage types is objectively "best" — they're built for different jobs. Directory and NFS are simple and easy to inspect by hand. ZFS gives a single homelab box snapshots and data integrity checking it wouldn't otherwise have. LVM-Thin is a solid, lightweight local option when ZFS's memory appetite is more than you want to give up. Ceph earns its complexity only once you actually have a cluster to spread it across.

The real trap isn't picking the "wrong" one — it's not knowing the tradeoff you made until a snapshot fails or a migration takes far longer than expected. Now that you know what each option actually promises, the dropdown in Datacenter → Storage should make a lot more sense the next time you're staring at it.