Eight shared storage types in Proxmox, and only two without small print

On 30 October, Lightbits announced that Proxmox has named it a Solution Provider and released a storage plugin for Proxmox VE. In the release, Tim Marx, COO of Proxmox, puts it this way: "Proxmox VE supports a wide range of storage technologies, so organizations can build their infrastructure the way it best suits them." That is true, and it is gracious. The official documentation table says the same thing with less courtesy: there are eight shared storage types and, in the snapshots column, only three arrive without a footnote. Open those footnotes and two are left.

This matters most if you are coming from VMware with an array that is paid for and written down. The question that lands on our desk is almost always the same: "will my SAN work with Proxmox?" The short answer is yes. The useful answer is that it works with a specific list of trade-offs, and that list is in no press release: it is in the table's footnotes.

The eight rows, and what each footnote hides

The storage types table in the Proxmox VE documentation marks nine rows with "yes" in the shared column. One is Proxmox Backup Server, which does not even score in the snapshots column: it says "n/a". Eight remain, and here is the reading with the footnotes already opened:

The three clean rows in the main table are CephFS, Ceph/RBD and ZFS over iSCSI. CephFS falls out on its own as soon as you look at its own entry: it does not accept disk images, and its own table adds a warning the general one does not show, "While no known bugs exist, snapshots are not yet guaranteed to be stable, as they lack sufficient testing." Two are left. And of those two, one asks for a ZFS-capable appliance and a passwordless SSH key stored in /etc/pve/priv/zfs/ so Proxmox can create the ZVOLs for you. That is not a flaw, it is the design; but it is a sentence worth reading before signing off the architecture, not after.

Footnote 2: the snapshot that stops the machine

If your shared storage is a NAS over NFS, snapshots exist but qcow2 makes them, not the storage. And the documentation is explicit about the price: "Creating and deleting internal qcow2 snapshots will block a running VM and is not an efficient operation", with an addition that is rarely quoted: "The performance is particularly bad with network storages like NFS" and, on disks of hundreds of gigabytes or terabytes, "these operations may take several minutes, or in extreme cases, even hours". If your setup is affected, the documentation recommends creating and removing snapshots with the VM shut down, expecting a long task. That same footnote leaves the other door open, and it is worth saying: volume chains also work on file-based storage. But there they are still a preview, and that is what the next section is about.

Translated into real life: the "snapshot before updating" button everyone treats as free can be a service outage on the largest machine you own, which tends to be exactly the one you can least afford to stop. This is not a complaint about NFS, which works beautifully for other things. It is that the button does not cost the same in every row of the table.

Footnote 4: the switch that only applies to tomorrow's disks

Here is the good news in Proxmox VE 9, and it is genuinely good. It is called snapshot-as-volume-chain and it is a flag on the LVM backend. With it, the snapshot is not taken by LVM (whose native snapshots, the documentation says, "interfere with all write operations within the entire volume group while the snapshot is active") but by Proxmox itself, chaining volumes: the current state keeps the snapshot's name and a new volume is started that points back at it and records only the differences. It uses qcow2 purely for chaining, not for its internal snapshots. And the relevant part: "Snapshots as volume chains provide vendor-agnostic support for snapshots on any storage system that supports block storage. This includes iSCSI and Fibre Channel-attached SANs." That is, your array.

Now the three sentences that come with it, all on the same page:

• It is still a preview. "Snapshots as volume chains are currently a technology preview in Proxmox VE," says the note. That is not decorative: on Proxmox's roadmap, taking it out of tech preview on LVM-thick, Directory, NFS and CIFS is still a listed goal, along with online removal of the top-most snapshot.
• It does not reach what you already have. "Enabling or disabling this flag only affects newly created virtual disk volumes." This is the sentence of the article. If you migrate two hundred machines onto the array and turn the flag on afterwards, those two hundred still have no chain. The order of the migration decides who gets snapshots.
• Your space accounting lies, unless the array helps. Snapshot volumes are thick LVM logical volumes, and "Each snapshot will appear to use the full volume size on the PVE side, but the actual space usage on the underlying storage will be smaller" only if the array supports thin provisioning and discard. If it does not, the apparent consumption is the real one.

The other route: someone else's code inside PVE::Storage::Custom

Back to the 30 October news, because it illustrates a route that is being used more and more: the third-party plugin. Lightbits' one connects Proxmox to its storage over NVMe/TCP, is published under Apache 2.0 on GitHub, its repository was created on 1 June 2026 and had fifteen stars the day we wrote this. Technically it promises what you want: shared volumes, snapshot and rollback on the storage itself, live migration without copying disks, and HA. The press release calls it a "native" plugin.

And then there is what the project says about itself in its README, which is far more informative than the release: it is an "open-source, community-driven project" maintained "on a best-effort basis", and it puts the relationship with the commercial product in writing without hedging: "not part of the Lightbits LightOS commercial product" and "not covered by Lightbits LightOS support agreements or SLAs unless a separate written agreement explicitly states otherwise." This is not a complaint: it is vendor honesty, and we appreciate it. But it changes the question. It is no longer "does it perform?", which it probably does. It is "who fixes this at three in the morning on a Tuesday, and under what contract?".

There is a technical detail that makes it concrete, and it is in the plugin's own troubleshooting guide. Proxmox versions the interface of its storage plugins, and when an update raises that number, the third-party plugin starts emitting, on every command, the message "Plugin "PVE::Storage::Custom::LightbitsPlugin" is implementing an older storage API, an upgrade is recommended". The project declares compatibility with libpve-storage-perl up to 9.1.13 and storage API 16. Put another way: when you update Proxmox, there is one more piece in the critical path of your disks that has to keep pace with the hypervisor and that neither Proxmox nor you maintain. That does not stop us, we inventory it; what you cannot do is discover it on upgrade day.

What we build, and when we say no

We run Proxmox VE with Ceph storage in production across several data centres, and the clean row in the table matches what we see: Ceph/RBD gives you shared access, snapshots and clones with no asterisks, and takes the array out of the critical path. That is the part we sell, and it is true.

And here is the part we do not sell: Ceph is not the default answer. It asks for nodes, it asks for a dedicated network, and it asks for someone who understands it the day it goes HEALTH_WARN. We have written plainly about why a three-node Ceph doesn't heal itself, it holds on: with three nodes there is nowhere to re-place the replicas when one goes down. If your reality is three machines, a shared network and nobody on call, the honest answer is the array you already own, with the volume-chain flag turned on before you move the first disk, and a written list of what you are giving up. We decide case by case because we resell nothing: that decision is exactly the job of consulting.

This also fits what we wrote a few hours ago about which VMware exit route actually went through the VDDK: the VMware exit route almost never breaks where the forums say it does, but at one specific piece nobody looked at in time. In migrations, that piece is usually storage, and the moment it is decided is not when it fails, but when the first volume is created.

Four checks, today, on your cluster

None takes more than five minutes, and all four are answered by looking at the machine, not by reading:

# 1. ¿Qué tipos de almacenamiento tienes de verdad?
pvesm status

# 2. ¿Está la bandera de cadenas en tu storage LVM?
grep -A8 '^lvm:' /etc/pve/storage.cfg

# 3. ¿Tus discos YA creados la aprovechan? (lectura nuestra: raw = no)
qemu-img info /dev/<vg>/vm-<vmid>-disk-0

# 4. Si usas un plugin de terceros, ¿va al día?
#    (los dos números: el que exige PVE y el que declara el plugin)
perl -MPVE::Storage -e 'print PVE::Storage::APIVER(), " ",
  PVE::Storage::Custom::TuPlugin->api(), "\n"'

The third one is the one that usually hurts. If your existing volumes come back as raw and the flag is set, the switch was flipped late: the documentation says it only affects newly created volumes. Our reading, and we label it as ours, is that moving the disk to another storage and bringing it back recreates it under the current flag; test that on a lab machine before touching production, because that is where everyone is exposed. And add a fifth check that does not fit on a console line: take a snapshot of the largest VM you have, on the real storage, and time it. That number, not the table, is your maintenance window.

The Proxmox COO's sentence is true: there is plenty to choose from. What there is not is a row without a cost. Choosing shared storage is not about performance, because nearly all of them perform; it is about deciding which part of the stack you will be able to fix yourself, which part a contract will fix, and which part nobody will fix at three in the morning.

Sources. The storage types table, its footnotes 2, 3 and 4, the per-backend entries (iSCSI, CephFS, LVM, ZFS over iSCSI) and every sentence about snapshot-as-volume-chain come from the storage chapter of the official Proxmox VE documentation, consulted on 2 November 2026. The pending goals (taking volume chains out of tech preview, online removal of the top-most snapshot and improved multipath for FC and iSCSI) are on the Proxmox VE roadmap, which also dates Proxmox VE 9.2 to 21 May 2026. The Lightbits Solution Provider announcement, the Tim Marx quote and the Apache 2.0 licence come from the press release published on 30 October 2026. The sentences about the plugin's support model, the API drift message and the compatibility table (PVE 9.x, libpve-storage-perl up to 9.1.13, API 16) are from the pve-lightbits repository README; the repository creation date and star count, from GitHub's public API on 2 November 2026. Technical quotes are reproduced in their original English so they can be searched verbatim. The side-by-side reading of the general table against the per-backend entries is ours, as is the hypothesis about recreating the volume, and both are flagged as such in the text. We have no commercial relationship with Lightbits or with any storage array vendor. The social image photograph is "3PAR SAN in the server room", by Alexis Lê-Quôc, CC BY-SA 2.0, via Wikimedia Commons.