If you’re planning a move from VMware to Proxmox, you’ve probably already read plenty about the hypervisor side. Storage is where the surprises tend to show up, because the datastores you know from VMware map onto several different Proxmox options, and the one you pick decides how snapshots, high availability, and recovery behave afterward. The good news is that Proxmox’s migration guide documents the options in detail, and this post pulls out the parts that matter most for storage.
What should I do about storage when migrating from VMware to Proxmox?
Match each workload to a Proxmox storage type that gives it the shared access, snapshots, and high availability it needs, plan the copy window, and test on a pilot cluster before you move production. Proxmox’s own migration guide generally recommends Ceph for shared storage, and it also lists several ways to reuse an existing SAN or NAS.
Can I keep using my existing storage?
In most cases, your existing hardware can serve as the storage for your Proxmox environment – but some manner of migration at the software level is required. Proxmox’s storage documentation says VM images can live on local storage or on shared storage such as NFS or iSCSI. What changes is how each type handles snapshots and sharing, so it helps to start from what you run today. Here’s how common VMware setups map across, based on Proxmox’s documentation and its migration guide as of Proxmox VE 9.2.
| What you run on VMware today | Proxmox option | Snapshots | Catch |
|---|---|---|---|
| A SAN with a storage vendor that provides a Proxmox plugin | The vendor’s storage plugin | The plugin may provide them | Plugins are third-party, so check which Proxmox versions are supported |
| Datastores on an iSCSI or Fibre Channel SAN | One large LUN with shared LVM | Not by default | Snapshots need an opt-in setting that Proxmox labels a technology preview |
| A DIY storage array that runs ZFS | ZFS over iSCSI | Yes | Needs root SSH access to your ZFS array, and supports a limited set of iSCSI targets |
| NFS datastores | NFS (or CIFS) storage | Yes, with qcow2 | VM snapshots only, since containers can’t use qcow2, and long-running snapshot tasks can block running VMs |
| vSAN or other hyperconverged storage | Ceph | Yes | There’s no direct import method from vSAN – VMs with disks on vSAN must have their disks moved to intermediary storage |
| Local disks | Local ZFS, LVM-thin, or directory storage | Yes | Not shared, so true high availability isn’t possible |
Proxmox’s guide also names two choices to steer clear of. Giving each guest disk its own iSCSI or FC LUN is not recommended because of the maintenance burden, and a manually built shared-disk clustered file system is not a supported setup.
Because Proxmox is capable of connecting over the same protocols that VMware can, you don’t need to redesign the fabric of your SAN, so your IP schema or FC zoning can remain in place. If your SAN has several redundant connections, Proxmox can leverage multipath for enhanced speed and redundancy, as shown in the multipath guide.
What changes compared with VMware?
If you’re comparing Proxmox vs VMware on storage, here’s what’s different, starting with the one VMware admins tend to notice first.
Proxmox doesn’t use VMFS. While it’s possible to import machines from a VMFS datastore, it’s not possible to point your Proxmox cluster at a VMFS datastore and simply “reboot” a machine into Proxmox, with the changes being committed back. For iSCSI or Fibre Channel SANs, you can achieve a similar VMFS-style storage configuration by using a shared LVM filesystem on a large LUN.
Snapshots on a SAN are opt-in. On shared LVM, snapshots aren’t possible by default. Proxmox VE 9 added snapshots on thick-provisioned LVM shared storage, implemented as volume chains, as announced in its 9.0 release. This setting is a technology preview that you turn on with a storage setting. The LVM documentation says the setting only affects newly created virtual disk volumes, so enable it before you import your VMs.
Shared LVM is thick-provisioned. Proxmox’s storage table shows LVM-thin as not shared, so shared LVM is the thick variety. Snapshot volumes on shared LVM are also thick-provisioned, although the underlying block storage may provide thin provisioning. If you relied on thin disks to save space in VMFS, plan for thin provisioning at the SAN instead.
NFS snapshots can be slow on large disks. Proxmox’s storage documentation says internal qcow2 snapshots block a running VM and are particularly slow on network storage like NFS, and on disks of several hundred GiB or TiB they can take several minutes or even hours. Snapshots as volume chains are an optional alternative, but they’re also considered a “technology preview.”
Backups can stand in for snapshots. If a SAN can’t snapshot, consider implementing a Proxmox Backup Server, which allows for backup and live restore of VMs instead of snapshots. Proxmox Backup Server deduplicates data and sends only changes after the first backup.
High availability requires shared storage. While Proxmox supports replication between local storage across nodes in a cluster, it’s an asynchronous replication. If a node fails, disk images must be available on shared storage to facilitate HA recovery. Shared storage or a Ceph cluster is required in order to have an equivalent to VMware HA. The HA manager documentation explains how recovery works.
There’s no equivalent to VMware Fault Tolerance mode. Unlike VMware, two Proxmox nodes cannot run a VM in lock-step. Plan for application-level fault tolerance wherever possible.
Cluster and network requirements. Unlike VMware vSphere which works off an “elected master”, Proxmox works off a “majority vote” and must have at least (N/2)+1 votes online to avoid split-brain. A minimum of three votes are needed for a stable cluster, but a two-node cluster can use a dedicated quorum device (QDevice) for the third, running on a low-power node or as a containerized application. Proxmox also recommends a dedicated network for cluster communication, since anything related to storage or backup has a good chance of saturating a network link, causing the critical “heartbeat” traffic to be delayed and potentially resulting in false-positive cluster events.
How do I move the data?
Proxmox’s guide describes automatic and manual methods and recommends that you test the migration with one or more test VMs before moving production. All of the methods listed below require a short period of downtime on the VM workload, as there is no way to live-migrate a running workload from VMware to Proxmox.
| Method | How it works | What to know |
|---|---|---|
| Import wizard | Add the ESXi host as a storage entry, pick a VM, choose the target storage for each disk, and import | The source VM is powered down first and remains powered down until the import completes. Proxmox’s guide says it was tested from ESXi 6.5 to 8.0 as of November 2024 |
| Live import | The VM starts on Proxmox while data copies in the background | The ESXi VM must remain powered off while the Proxmox VM is booted. If an import fails, data written since it started is lost |
| Restore from backup | Perform a backup of the VM from VMware and restore it to Proxmox | Check the integration and compatibility options with your backup software first |
| OVF export and import | Export from VMware, then import with qm importovf |
Windows guests need IDE or SATA at first boot |
| Disk import | Import the VMDK files with qm disk import, which converts them on the fly |
Proxmox needs access to the VMDK files, often through a network share |
A few limits are worth knowing before you start.
- vSAN. Importing a VM with disks backed by vSAN does not work, so a temporary “pivot” storage will be required that can hold the largest VM.
- vCenter. Importing through vCenter dramatically reduces performance, so connect directly to the ESXi host instead.
- Snapshots. Importing a VM can be significantly slower if the VM has snapshots.
- Encryption. Disks encrypted through a VMware storage policy cannot be imported until the encryption is removed.
- Parallel imports. Proxmox recommends no more than four VM disks imported at the same time, because of the ESXi API’s connection limit and memory use on the Proxmox host.
What do I need to prepare on each VM?
Preparation is mostly housekeeping. Remove guest tools specific to the old hypervisor, note down the network configuration, and power down the source VM. Virtual TPM state can’t be moved, so if a guest uses full-disk encryption with keys in a vTPM, keep the recovery keys handy. It also helps to install VirtIO drivers in the guest before you move it, since Windows needs extra steps to boot from VirtIO SCSI, and Proxmox’s VirtIO driver page has the downloads.
Afterward, the guide recommends SCSI with the VirtIO SCSI single controller, discard enabled (useful when storage is thin-provisioned), and an IO thread for disks, along with the QEMU guest agent.
How long will the copy take?
A quick estimate early on saves surprises later.
Hours = data size in TB ÷ (link speed in Gbps × 0.45 × efficiency)
A 1 Gbps link moves about 0.45 TB an hour at full speed, and efficiency is the share of that you actually achieve. With round numbers, 50 TB over a 10 Gbps link at 50% efficiency takes about 22 hours. Measure your real rate on a representative VM before you plan a cutover.
A test plan for your pilot cluster
Build a small Proxmox cluster on the storage design you’re considering, then break it on purpose. Write down your recovery time and recovery point targets first, since every pass mark below is measured against them.
| Drill | What it checks | Pass looks like |
|---|---|---|
| Import a large, busy VM with the method you plan to use | Copy window and cutover plan | The import fits your window, and the VM boots with the right network and disk drivers |
| Import a VM that has snapshots | Import speed | You know how much slower it is and have a plan for the worst case |
| Snapshot a running VM under load, then delete the snapshot | Snapshot behavior on this storage | The VM stays responsive and the task finishes in a time you can accept |
| Live-migrate a VM between nodes | Shared access | The VM moves without an outage and its disks stay reachable from both nodes |
| Stop a node that is running an HA VM without migrating it first | High availability | The VM restarts on another node within your recovery time target, allowing for the wait of about two minutes that Proxmox’s guide describes before recovery starts |
| Pull one storage path (in multipath designs) | Path failure | I/O continues on the remaining path |
| Run heavy storage and backup traffic while watching cluster health | Network design | Cluster communication stays stable under load, and no false-positive alerts are logged |
| Restore a VM from backup onto the new storage | Recovery | The restore fits your recovery time target, and the VM boots cleanly |
Questions worth asking any storage vendor
- Is there a supported Proxmox integration or plugin, and which Proxmox VE versions does it cover?
- Which transports does it support, such as iSCSI, NVMe over TCP, or NFS?
- How do snapshots work on this storage, and how long do they take on a large, busy disk?
- How is the storage shared across cluster nodes, and how does multipathing work?
- What does support cover when something breaks between the hypervisor and the storage?
Where TrueNAS fits with Proxmox
If your storage is already on TrueNAS, or you’re choosing a shared storage platform for the new cluster, TrueNAS has a native Proxmox VE storage plugin, which is the first option Proxmox’s own guide lists for SAN and NAS reuse. It lets Proxmox create, snapshot, resize, migrate, and delete VM disks on TrueNAS directly. Each disk becomes a zvol published over iSCSI or NVMe/TCP, so there’s no manual LUN mapping, and snapshots run natively on OpenZFS. Because the plugin handles the volume creation and LUN mapping, there’s no need for manual provisioning or risks of human errors.
The plugin needs TrueNAS 25.10 or later and works with Proxmox VE 8.x or later, with NVMe/TCP requiring Proxmox VE 9.x. It’s an early-adopter release, available first to Community Edition users, with TrueNAS Enterprise support in validation. It handles block storage for VM disks and containers, with a separate NFS or SMB share from the same TrueNAS installation offering file-backed storage for ISOs and backups.
You can read more on the TrueNAS Proxmox storage page and in the plugin announcement.
FAQ
- How can I migrate a workload from VMware to Proxmox?
- Proxmox offers an import wizard that imports VMs straight from an ESXi host, plus manual methods such as OVF import and disk import for cases where the wizard doesn’t fit. Whichever you use, Proxmox’s guide recommends testing the VMware to Proxmox migration on a few VMs before you move production.
- Can I reuse my existing SAN or NAS with Proxmox?
- Your storage hardware can typically be reused, but check compatibility with your vendor. Proxmox supports shared storage over a variety of protocols, and its migration guide lists options for an existing SAN or NAS, including a vendor plugin, shared LVM on a large LUN, network file systems, and ZFS over iSCSI. The trade-offs are mostly around snapshots and thin provisioning.
- What shared storage does Proxmox support?
- Proxmox can use shared storage over NFS, CIFS, iSCSI or Fibre Channel with LVM, NVMe/TCP, ZFS over iSCSI, and Ceph, with some storage vendors providing their own plugins for ease of management. Each option handles snapshots differently, so check the table earlier in this post.
- Does Proxmox use VMFS?
- Only as a read-only migration source. Proxmox’s list of storage types has no VMFS support for live virtual machines. For shared iSCSI, Fibre Channel, or SAS block storage, it uses LVM to split the LUN into virtual disks.
- Can Proxmox take snapshots on iSCSI or Fibre Channel storage?
- Not by default on shared LVM. Proxmox VE 9 added snapshots as volume chains on thick-provisioned LVM as a technology preview, and you enable it with a storage setting that only affects newly created disks.
- What happens to my vSAN datastore?
- Proxmox’s alternative for hyperconverged vSAN storage is Ceph. Additionally, the import wizard can’t import VMs whose disks are on vSAN, so re-using your vSAN disks for Ceph will require you to move the VMs to a separate “pivot” storage area temporarily in order to reformat the vSAN nodes.
- Can I migrate without downtime?
- As of this writing, there’s no support for a true live-migration option without a brief VM downtime. The Proxmox “Live Import” option allows you to power the VM back up on Proxmox, while streaming the VM disk reads in the background, to minimize this downtime period, but it still requires the initial power cycle.
- How do I back up VMs after the move?
- Proxmox provides its own Proxmox Backup Server as a validated first-party option, and its guide notes that other third-party backup software may integrate as well. Rebuild and test your backups against the new storage before you rely on it.