Moving to Proxmox and reusing your SAN: the snapshot is what does not travel

In almost every VMware exit project that reaches us there is one budget line nobody argues about: the array stays. It is paid for, it has three years of support left and it works. It is the cheapest decision in the whole plan. It is also the one that decides whether, six months from now, somebody on your team will be able to take a snapshot before applying a patch.

This is not a hidden surprise or a bug. It is written, in plain English, in the first line of the section that deals with exactly this in the Proxmox documentation: "We generally recommend Ceph for shared storage. However, there may be scenarios where you want to use storage provided by a pre-existing NAS/SAN for shared storage in your cluster."

The vendor opens the chapter about your array by recommending something else, and then proceeds to explain how to do it with yours anyway. The rest of the chapter reads differently after that sentence.

Where the snapshot used to live, and where it lives now

In vSphere, the snapshot is a hypervisor feature. Bar the known exceptions — physical-mode RDMs, disks marked independent, multi-writer, passthrough devices — you press the button and it works, whether the datastore sits on a high-end array, on one from eight years ago, or on NFS. The capability travels with the hypervisor, not with the hardware underneath. That uniformity is so convenient that it has stopped being perceived as an architectural decision and has become an expectation: of course I can take a snapshot.

Proxmox splits that work differently, and says so bluntly on the same page: "The storage plugins interact on a higher level with Proxmox VE (for example: create & delete disk images, take snapshot, …) and handle the low-level implementation for the individual storage types." The snapshot is not the hypervisor's call: it is the storage plugin's. And on block storage, "functionality like snapshots are provided by the storage layer itself".

With local ZFS, with Ceph RBD or with local LVM-thin this causes no trouble: all three layers underneath know how to take snapshots. The problem shows up in the specific case you are planning, which is the usual one: one big LUN from your array, over Fibre Channel or iSCSI, shared across every node. There Proxmox uses LVM thick to carve up space on the LUN, and the documentation states the drawback in one line: "Snapshots are not possible by default…"

That sentence is the whole article. The rest is what to do about it.

The seven options, quoted verbatim

The documentation heads the list with a date — "As of Proxmox VE 9.2 (May 2026), there are at least the following options" — and that at least is honest: the list does not claim to be exhaustive. These are the seven, with the advantages and drawbacks as the vendor publishes them:

1. Your array vendor's own plugin. "Your storage vendor may provide a custom Proxmox VE storage plugin. Such plugins could potentially provide snapshot capability." Two conditionals in seventeen words: may provide and could potentially. This is the first question to put to your storage vendor, in writing, before signing anything in the virtualization project.
2. One big LUN with LVM-thick, default configuration. Advantage: "Low maintenance burden, as new guest disks can be created on the Proxmox VE side." Drawback: "Snapshots are not possible by default…" This is where everyone ends up by inertia, because it is the one that works first time.
3. The same LUN with "Allow Snapshots as Volume-Chain" enabled. This is the one that fixes the previous option, and it comes with a label: "'Snapshots as Volume-Chain' was introduced as a technology preview in Proxmox VE 9.0 and can be enabled on thick-provisioned LVM storages." We come back to it in the next section, because it deserves one of its own.
4. Network filesystems: NFS or SMB/CIFS. Here you do get snapshots, with qcow2, internal ones by default. And there is a drawback that changes the whole design for a lot of people: "Snapshots of containers are not possible (as containers cannot use qcow2)." If your plan involved moving workloads to LXC containers, that line is yours.
5. One LUN per guest disk. The documentation itself marks it "(not recommended!)", exclamation mark included. The advantage is real — "Snapshots often possible on the SAN side" — and so is the price: "High maintenance burden, as you have to manually create one LUN on the SAN side per guest disk." With thirty machines and two disks each, that is sixty hand-created LUNs, and one more request to the array every time somebody asks for another disk.
6. ZFS over iSCSI. "Requires a storage box with ZFS and SSH support and supported iSCSI management tooling." Three requirements a classic vendor array does not meet, and a ZFS-based one does. Which is to say: this is not an option for the array you already own, it is an option for the one you would buy.
7. Setting up a clustered filesystem by hand. Technically possible; Proxmox is Debian and the docs explain how. And then they write the sentence that ends the conversation with management: "Not a supported setup", reinforced further down with "Please note that unsupported file systems are out of scope of the technical enterprise support." Translated: on the day of the incident, you are on your own.

And one line that is not an option but tags along with all of them: "When using iSCSI/FC/SAS, there are often multiple redundant connections to the SAN. In this case, multipath should be configured as well." The multipath that came built in as standard in vSphere is here a task with a name, and one that starts with your array vendor's documentation.

"Technology preview" is a contract word, not a manual word

Option 3 is the good one on paper, and it works: Proxmox described it fairly precisely when it landed in 9.0. "A new property on thick-provisioned LVM storages enables support for snapshots as volume chains. With this setting, taking a VM snapshot persists the current virtual disk state under the snapshot's name and starts a new volume based on the snapshot. This enables VM snapshots on shared thick-provisioned LVM storages, as they are often used on LUNs provided by a storage box via iSCSI/Fibre Channel." It is written with exactly your case in mind.

What matters here is not the technical part, which is solid, but the label. Proxmox marked it technology preview in 9.0 (August 2025) and it is still marked the same way in the 9.2 documentation. That is not us reading between the lines: it is on the product's public roadmap, in the "Storage & Snapshots" section, as a future goal: "Bring 'snapshots as volume chains' (tech preview since Proxmox VE 9.0) out of tech preview on LVM-thick, Directory, NFS, and CIFS storages, including support for online removal of the top-most snapshot."

Two releases later — 9.1 and 9.2 — removing that label is still a plan. And the page itself warns at the top, in so many words, how it should be read: "The items below describe development directions and priorities. Not all are planned for immediate delivery." Further down the same list there is another one worth reading if your array is fibre-attached: "Improve multipath integration and setup experience for Fibre Channel and iSCSI deployments."

What follows is our opinion, not the documentation's. "Technology preview" is not a verdict on whether the code works — it does, and 9.1 ships a batch of specific fixes that confirm people are running it in production. It is a sentence you have to be able to say out loud in a meeting: the feature our change procedure rests on is in preview. If that sentence can be said without anybody's face changing, go ahead. If it cannot, the problem is not technical and no amount of lab testing will fix it.

The detail that lands squarely on the oldest VMs

Among the 9.1 fixes there is one that looks minor until you think about who it lands on: "As 'snapshot as volume chains' requires machine version 10 or higher, fail early when attempting to start a VM with a lower machine version."

The QEMU machine version is not the Proxmox version: it is a per-VM property, and Proxmox pins it deliberately so as not to change the virtual hardware under a guest that is already installed. For Windows it does so explicitly, and wrote it down when introducing machine version 9.2+pve1 — a note from the Proxmox VE 8.4 release, not from the 9 series: "New Windows VMs are pinned to that machine version. Existing Windows VMs are already pinned to an earlier machine version…" Which means the machines that have been running for years keep the version they were born with. Which are precisely the ones you least want to touch.

We are not saying your VMs will be below 10 — that depends on when and with which Proxmox version they were created, and we cannot know that from here. We are saying it is an inventory check, not an assumption, and a cheap one: it comes out of a qm config per machine or one API query, and it is done before deciding anything. If the answer is that twenty inherited VMs sit below the line, it is not that option 3 fails to cover them: the 9.1 note says "fail early when attempting to start a VM with a lower machine version". They will not start on that storage until their machine version is raised — which is a virtual hardware change and gets planned like one.

It is the same pattern we already hit with drivers: the migration copies the disk whole without losing a byte, and then Windows will not boot because the controller it expects is not there. What never travels is not the data; it is the assumption the guest made on the day it was installed.

The way out the vendor itself proposes (and why it is not the same thing)

The documentation has a section headed "Alternatives to Snapshots", and it does not propose another kind of snapshot. It proposes changing strategy: "If an existing iSCSI/FC/SAS storage needs to be repurposed for a Proxmox VE cluster and using a network share like NFS/CIFS is not an option, it may be possible to rethink the overall strategy; if you plan to use a Proxmox Backup Server, then you could use backups and live restore of VMs instead of snapshots."

And the proposal has technical substance; it is not a consolation prize: "Backups of running VMs will be quick thanks to dirty bitmap (aka changed block tracking) and the downtime of a VM on restore can also be minimized if the live-restore option is used, where the VM is powered on while the backup is restored." Genuine incremental backup, and the VM boots while the restore runs. It works.

Here is our objection, flagged as opinion. A snapshot and a restore address the same fear but they are not the same control. A snapshot is a safety net put up and taken down by the same person applying the change, within the same window, and rolling back is a thirty-second decision that needs nobody's permission. A restore has a different RTO, often a different owner and almost always a different conversation. The moment undoing a change stops being free for the person making it, fewer changes get undone: people limp along with a half-broken system a while longer, "to see if it settles". That does not appear on any feature matrix, and in our experience it is the real effect.

So yes to Proxmox Backup Server — we deploy it on every cluster, snapshots or no snapshots — but not as a silent substitute for the snapshot. If you are going to operate that way, let it be a decision said out loud with the change procedure rewritten, not a discovery on the first patch Tuesday.

The decision tree we are willing to sign

Four branches, in order. This is not a list of best practices: it is the order in which we ask when we walk into one of these projects.

1. Does your array speak NFS, and do you have the network for it? Then the answer is usually NFS, not a LUN. Snapshots with qcow2, a well-trodden path, and a configuration that does not start life with a preview label. The toll is written down and has to be accepted with open eyes: no container snapshots, and the performance of a network filesystem, which is not that of a fibre-attached LUN. If your heavy workloads are databases, measure it rather than argue about it.
2. Does your array vendor ship a Proxmox plugin? Ask in writing and ask for two specific things: whether the plugin implements snapshots, and which Proxmox versions it is supported on. That answer changes the whole project and costs nothing to obtain. If it takes three weeks to arrive, or arrives in the conditional tense, that is information too.
3. If you stay on LUN + LVM-thick with volume-chain, treat it as what it is labelled. That means four concrete things, not a statement of intent: an inventory of QEMU machine versions before switching it on; the feature tested on a test cluster with the same array model, not on a local disk; a "while this remains in preview we do X" clause written into the change procedure; and Proxmox Backup Server live, with a real restore timed on a stopwatch rather than a planned one. And mind the small print it already carries today: with TPM state, "the top-most snapshot cannot be removed while the VM is running".
4. And if, once you do these sums, the array stops paying for itself, say so. There is a point at which reusing the hardware costs more in hours, in risk and in operational tolls than it saves on the invoice, and that point arrives sooner than people expect. That is where the documentation's first sentence starts to make sense, the "we generally recommend Ceph" one: distributed storage on the nodes themselves, with native snapshots and no array in the middle. It is more change and more up-front investment, and it is not always the answer — we have advised against it on small clusters — but it stops you dragging a 2019 decision through another five years. And it brings small print of its own, which we have also written about: rotating a Ceph key is not finished by rebooting the VM.

Whichever branch you take, the decision is made before the first machine moves, because it is the only one in the whole project that is expensive to change afterwards: moving thirty VMs from a LUN with LVM-thick to NFS is not ticking a different box, it is redoing the entire migration. It is the same reason we insist on writing the rollback plan before starting rather than when you need it.

When keeping the array is, without argument, the right call

None of the above is an argument for throwing away an array that works. There are two situations the decision tree does not cover that tip the balance towards keeping it. One: most of your VMs are the kind that never get hot-patched anyway, because they have their own window and their own backup — there, the snapshot you lose was not being used. Two: the cluster is small and there is neither the budget nor enough nodes to do distributed storage properly, which is more common than it sounds.

What is not defensible is not having looked. And if, on looking, the answer is that today is not the day to migrate, that is a valid answer too: we already wrote about when NOT to migrate from VMware to Proxmox, and shared storage is one of the reasons that shows up there by name.

The array was never discussed, because it was already paid for. The snapshot will get discussed six months later, on a Tuesday afternoon, halfway through a patch. And by then it will not be free.

What we are not claiming

We are not saying Proxmox is worse than VMware at shared storage, or the reverse: we are saying they divide the work differently and that this has concrete operational consequences. We have no comparative performance figures between NFS and a LUN on the same array, so we give none; measuring it on your own hardware is part of the job. We have not tested every array vendor's plugin and cannot say which ones implement snapshots. "Technology preview" is Proxmox's own label, not our judgement on the stability of the code, and the roadmap itself warns that its items carry no committed date — so we are not claiming when it will leave preview either. We do not know what QEMU machine version your VMs are on; that is why we frame it as a check and not a diagnosis. And we are not an interested party: we resell neither Proxmox nor VMware licences, nor anybody's arrays.

Note on sources

All consulted on 18 September 2026, downloading the original text of the pages rather than second-hand coverage. One: the "Migrate to Proxmox VE" article on the official wiki, sections Storage, Storage boxes (SAN/NAS), Alternatives to Snapshots and Unsupported File Systems: source of the Ceph recommendation, the heading "As of Proxmox VE 9.2 (May 2026), there are at least the following options", the seven options with their verbatim advantages and drawbacks, the description of what storage plugins do, the multipath note, the sentence about enterprise support and unsupported filesystems, and the paragraph on backups with dirty bitmap and live-restore. Two: the Proxmox VE Roadmap page, source of the warning on how to read it ("Not all are planned for immediate delivery"), the goal of bringing snapshots as volume chains out of tech preview, the item on improving multipath for FC/iSCSI deployments, and — from the release history on the same page — the Proxmox VE 9.0 entry introducing snapshots as volume chains, the 9.1 batch of fixes including the machine-version-10-or-higher line, and — from the Proxmox VE 8.4 entry, not the 9 series — the note on machine version pinning for Windows guests. What is our opinion, flagged as such in the body: that the array is the cheapest decision and the one that most changes day-to-day operations; the reading of "technology preview" as a sentence you have to be able to say in a meeting; the difference in real-world effect between a snapshot and a restore; the four-branch decision tree; and the list of cases where keeping the array is the right call.

Cover image: photograph of a rack-mounted disk array, from Wikimedia Commons (CC BY-SA), cropped by us. The text and branding are ours, added on top.