Rob Pankow 
migrate vmware to proxmox is a search that returns a great many confident answers, and remarkably few of them are about storage.
The guides are good at the parts that are visible. They walk you through building the cluster, setting up the Linux bridges, installing the VirtIO drivers in the guests, and running qm importdisk against a flat VMDK. Storage shows up early, as a prerequisite bullet that says “configure a storage backend,” and then never again.
That bullet is the whole decision. The backend you pick on day one determines whether live migration works at all, whether the snapshot workflow your team has used for a decade still exists, what happens when a node dies, and how much raw disk you are about to buy. It is also close to irreversible in practice, because changing it later means moving every byte a second time.
This post is about that decision: the paths Proxmox VE actually offers, what each one costs you, and the condition that makes each one the right answer.
The decision that gets made by accident
Two things about a hypervisor migration are worth saying plainly before any of the options make sense.
The bytes move either way. A hypervisor cutover is a data movement project wearing a compute project’s clothes. Whether you go through qm importdisk, a backup-and-restore cycle, or a live import from the old environment, every virtual disk in the estate is read from the old datastore and written somewhere new. There is no path where the data stays still. This is why the storage target has to exist, be correctly sized, and be the one you actually want before the first VM is converted. Teams that defer the decision to “after the first wave” end up either re-running the data movement or living permanently with a backend they chose under time pressure.
You are probably here to stop paying for something. The VMware® exit is usually a cost decision, and that reframes the storage choice in a specific way. If the storage path you pick consumes the saving in raw disk and host CPU, the project can land on budget and still fail its own business case. The capacity multiplier of the backend is therefore not a footnote for the storage team. It is a line in the hardware quote.
Those two facts together explain why the storage decision belongs at the front of the plan rather than in the prerequisites.
If you are still weighing the platform choice itself rather than the storage underneath it, that is a different question and it is already covered in VMware vs Proxmox. This post assumes the destination is settled.
The three native paths, and the condition that makes each one right
Proxmox VE supports a long list of storage plugins, but for a production cluster receiving a VMware estate the realistic shortlist is three. They are not variations on a theme. They fail in different places and they are correct in different situations.
ZFS on local disks
ZFS is the path of least resistance and it is genuinely capable. You get snapshots, thin clones, compression, and end-to-end checksums that catch silent corruption. For a team coming off vSphere, the snapshot semantics feel familiar immediately.
The constraint is in the first word: local. A ZFS pool belongs to one node. There is no shared pool, so there is no true live migration. Proxmox will still migrate a running VM between nodes with local ZFS, but it does so by copying the disk across the network first, which turns a seconds-long operation into one that runs for minutes or hours depending on the volume. Maintenance windows go back on the calendar.
High availability is possible through ZFS replication, which ships snapshots to a peer node on a schedule. That schedule is your recovery point. A fifteen minute replication interval means a node failure can cost you up to fifteen minutes of writes. For plenty of workloads that is perfectly acceptable, and for some it is not acceptable at all.
Choose it when the cluster is small, the node count is low, the workloads tolerate an asynchronous recovery point, and capital budget is the dominant constraint.
LVM over shared iSCSI or Fibre Channel
If you already own a SAN, this is the path that sweats it. Proxmox puts LVM on top of a shared LUN, every node sees the same volume group, and you get real shared storage: live migration in seconds, HA failover without a data copy, and no replication schedule to reason about.
The cost is specific and it surprises people. LVM on shared block storage does not give you snapshots. Thin provisioning and snapshots in the LVM world come from LVM-thin, and LVM-thin is not cluster-aware, so it is a local-only option. Put LVM over a shared LUN and the snapshot button effectively goes away at the hypervisor layer. Whatever snapshot workflow your backup tooling, your patching process, and your change windows depend on has to move down to the array, if the array can do it, and be driven by the array’s own tooling rather than by Proxmox.
Choose it when you already own capable shared storage, you are not refreshing it this cycle, and you are content to run snapshots as an array-level function rather than a hypervisor-level one.
Ceph
Ceph is the answer Proxmox itself leans toward, it is integrated into the installer and the web UI, and it solves the shared-storage problem properly: a single pool every node can see, RBD snapshots, thin provisioning, and self-healing when a disk or a node goes away. It is a good option when performance is not the main goal, and it deserves to be evaluated on its merits rather than dismissed.
Its costs are architectural rather than accidental. The default resilience model is three-way replication, so usable capacity is roughly a third of raw. There is a node-count floor: a production pool with sensible failure domains wants more hosts than most teams expect, and a three-node cluster running Ceph is a cluster with very little room to lose anything. The storage stack also runs on the same hosts as the VMs, so OSD processes consume CPU and memory that you bought to run workloads. On a node failure, the rebuild traffic competes with production I/O on the same hosts and the same network.
None of that is a defect. Replication is exactly what buys Ceph its operational simplicity and its self-healing behaviour. It is a deliberate trade, and the question is only whether it is the trade you want to make on hardware you are buying specifically because you are leaving a licence bill.
Choose it when you have the node count, you value integrated self-healing over latency, and the capacity multiplier fits the budget.
Table 1: The native Proxmox VE storage paths compared on what actually changes for a team arriving from vSphere.
| Path | What it costs you | What keeps working | Choose it when |
|---|---|---|---|
| ZFS local | No shared pool, so migration copies the disk; HA recovery point equals the replication interval | Snapshots, clones, compression, checksums | Small cluster, async RPO is acceptable, capital budget dominates |
| LVM over shared iSCSI or FC | Snapshots at the hypervisor layer, effectively entirely | Live migration in seconds, HA failover, your existing array | You own capable shared storage and can run snapshots on the array |
| Ceph | Roughly 3:1 raw capacity, a node-count floor, host CPU spent on the storage stack | Shared pool, RBD snapshots, self-healing, full HA | Node count is there and integrated resilience matters more than latency |
| Shared block over NVMe/TCP | A separate storage layer to operate rather than a built-in one | Live migration, snapshots, clones, independent scaling | You want shared storage and snapshots without the capacity multiplier |
Deciding this before the first VM is converted is worth an hour of somebody’s time. If you are sizing a Proxmox target and want the capacity and failure-domain maths checked against your actual estate rather than a reference architecture, talk it through with someone who does it regularly. Talk to a storage architect
What the resilience model does to the hardware quote
The three paths above differ on features, but the number that reaches the finance conversation is the capacity multiplier: how much raw disk you buy for each usable terabyte. It is worth looking at directly, because it is the part of the storage decision that most visibly eats the exit saving.
Take a target of 100 TB usable and hold everything else constant.
A mirrored ZFS pool writes every block twice, so 100 TB usable costs 200 TB raw, and because the pool is per-node that capacity is also stranded on the node that owns it. Ceph’s default three-way replication writes every block three times, so the same 100 TB costs 300 TB raw. Erasure coding at a single-failure tolerance changes the shape of the calculation: parity is computed across a stripe rather than copying the whole block, which lands the overhead near 1.25:1, so 100 TB usable costs roughly 125 TB raw. (Comparison based on publicly available information as of September 2026.)
The gap between 300 TB and 125 TB of NVMe is a real number on a real quote, and it arrives in the same quarter as the saving that justified the migration.
There is a second multiplier that does not appear on the disk line at all. A hyperconverged storage stack runs on the hosts, so some proportion of every host’s CPU is spent serving storage rather than running VMs. That shows up as needing more hosts, or as workloads getting less of the hosts you have. It is harder to see than the raw-capacity number and it moves the budget in the same direction. Our post on disaggregated and hyperconverged Kubernetes storage works through where that tradeoff lands.
The fourth path: shared block over NVMe/TCP
The three native options each force a trade: keep snapshots and lose the shared pool, keep the shared pool and lose snapshots, or keep both and pay the replication factor. There is a fourth shape, which is to attach shared block storage to Proxmox over a fabric and let the storage layer supply the resilience.
This is what simplyblock does on Proxmox. It presents shared block devices over NVMe/TCP, which every node in the cluster can see, so live migration stays a seconds-long metadata operation and HA failover does not wait on a data copy. Snapshots, thin clones and thin provisioning live at the storage layer rather than at the hypervisor, which keeps the workflow the vSphere team already has. Resilience comes from erasure coding rather than whole-copy replication, which is where the capacity difference above comes from. Because compute and capacity are separate, you add storage nodes when you need capacity and host nodes when you need CPU, instead of buying both every time you need one.
Two details matter specifically for a migration rather than a greenfield build.
Your existing array can become the capacity underneath it. Simplyblock’s backing devices are not restricted to local NVMe. Any whole Linux block device can join the pool, including LUNs an array already presents to the storage nodes, which is a real answer to “we are not refreshing storage this year.” Two caveats travel with that claim and should not be dropped: the non-NVMe path is newer than the NVMe one and local NVMe remains the recommendation for production performance, so treat array-backed pools as a transition or asset-sweating option rather than a design target. And simplyblock formats the devices it takes in, so this is capacity reuse, not wrapping your existing LUNs in place. The data still migrates.
The decision does not have to be made again later. The same storage layer runs under Proxmox, under bare-metal Kubernetes, and under KubeVirt or Red Hat® OpenShift® Virtualization. If Proxmox is a stop on a longer road rather than the final destination, the storage choice you make now does not have to be unmade. The sibling guide on migrating vSphere VMs to a Kubernetes-native destination covers what changes when the destination is a container platform instead.
On cost, simplyblock aligns its pricing to the way the platform underneath it is licensed, and data volume does not change the price, so growing the estate does not reprice the storage line. The capability detail sits on the Proxmox VE storage and Proxmox storage pages rather than being restated here.
The honest summary is that this is a fourth option with its own tradeoff, not a free lunch. It is a separate storage layer to deploy and operate, where Ceph and ZFS are already in the box. What you buy for that is the combination the native paths make you choose between: a shared pool, hypervisor-speed snapshots, and a capacity multiplier closer to one than to three.
Questions and Answers
Does live migration work on Proxmox VE without shared storage?
Not in the form a vSphere team means by it. Proxmox can migrate a running VM between nodes with local storage, but it copies the virtual disk across the network as part of the operation, so the migration takes as long as the data takes to move. With genuinely shared storage, whether that is Ceph, a shared LUN, or shared block over NVMe/TCP, no data moves and the migration completes in seconds. If live migration is part of your maintenance process, a shared pool is not optional.
Why can I not take snapshots when I use LVM over iSCSI?
Because the snapshot capability in LVM comes from LVM-thin, and LVM-thin is not cluster-aware, so Proxmox only supports it on local storage. Plain LVM over a shared LUN gives you the shared volume group and therefore live migration, but no hypervisor-level snapshots. Your options are to snapshot on the array instead, or to pick a backend that provides snapshots on shared storage. Storage that presents shared block over a fabric with snapshots and clones at the storage layer, which is the simplyblock model, gives you both without the compromise.
Is Ceph the right choice for a Proxmox cluster receiving a VMware estate?
It is a legitimate choice and it is a good option when performance is not the main goal. It gives you a shared pool, snapshots and self-healing, all integrated. Weigh it against three things: the three-way replication factor means you buy roughly three times your usable capacity in raw disk, a production pool needs more nodes than teams usually plan for, and the storage stack consumes host CPU that you bought for VMs. If the migration’s business case rests on the hardware saving, work the capacity multiplier before committing.
How much raw capacity do I actually need?
It depends entirely on the resilience model, and the spread is wide enough to change a purchase order. For 100 TB usable, a mirrored ZFS pool needs 200 TB raw, three-way replication needs 300 TB, and erasure coding at single-failure tolerance needs roughly 125 TB. Add the host CPU that a hyperconverged storage stack consumes, which does not show up as disk but does show up as hosts.
Can I keep the SAN I already own?
Yes, on two of the paths, and they are different in an important way. Proxmox can put LVM directly on a shared LUN, which keeps the array in charge and costs you hypervisor snapshots. Alternatively the array’s LUNs can be taken in as backing capacity underneath simplyblock, which supplies erasure coding, snapshots and NVMe/TCP presentation on top of hardware you already own. The second path formats the devices, so the data still has to be migrated, and local NVMe remains the recommendation for production performance. Both are better than writing off the array, and neither is a way to avoid moving the bytes.
Should the storage decision really come before the migration?
Yes, and it is the single most common sequencing mistake in these projects. Every virtual disk gets read and rewritten during the cutover regardless of the destination, so choosing the storage target after the first wave means either repeating that data movement or accepting a backend you picked in a hurry. Decide the backend, size it, and build it first. Then convert VMs into it once.
