Proxmox VM Live Migration Without Shared Storage: When It Really Works and Where the Limits Are

Shared storage has been the standard promise for clean Proxmox live migration for years: Ceph, NFS, iSCSI or GlusterFS underneath every node, and a VM switches hosts in seconds without the backend missing a beat. In practice, though, this is far from universal in SMB clusters. Two- or three-node environments with local ZFS pools on fast NVMe drives are still very common — often because Ceph would be oversized for the workload, or because a dedicated SAN’s latency adds no real value for the applications involved.

The question we get regularly: can a Proxmox VM be live-migrated without shared storage? The short answer is yes. The longer answer comes with conditions, limits and decision criteria — which is what this article is about.

Proxmox Live Migration Without Shared Storage: What Proxmox Actually Does

If you start a migration between two nodes where the target storage ID is not shared, Proxmox detects this automatically. Instead of transferring only RAM state, it initiates a parallel storage migration: QEMU attaches a new backing device on the target node and mirrors the disk blocks live. Internally this is the same drive-mirror mechanic used by local qm move-disk — just stretched across two nodes.

The command feels familiar at first:

qm migrate 101 pve-node02 --online --with-local-disks

The crucial piece is the --with-local-disks flag. Without it, Proxmox refuses the migration because the disk is not on a jointly accessible storage. With it, the VM migration and disk replication start simultaneously: RAM pages travel via classic pre-copy, disk blocks travel via mirror. Both processes run in parallel until the short switchover at the end.

What docs tend to gloss over: the process has three phases, not two. Phase one is the actual disk copy, phase two is the RAM transfer, phase three is the switchover. The larger the disk, the longer phase one — and the higher the risk that enough has changed on both disk and RAM during that time to make the final delta take longer than you would like.

When Live Migration Without Shared Storage Actually Works

From our projects a few clear patterns emerge for when the procedure runs cleanly:

• Small to mid-size VMs with disks up to around 500 GB and single-digit GB of RAM move in very manageable timeframes.
• Low to moderate write load during the migration window. An ERP database under full load is the hardest case; a terminal server at lunch is the easiest.
• Fast node-to-node link, ideally dedicated 10 GbE for migration and replication. 1 GbE works technically but easily pushes migration time of larger disks past 30 minutes.
• Same storage backend on source and target. ZFS to ZFS is the default. LVM-thin to ZFS also works, but takes longer because no blocksize alignment is possible.

Things get problematic once very large VM disks are involved — 2 TB and up — combined with heavy I/O. Not because Proxmox cannot technically do it, but because the mirror phase runs so long that the delta never really converges. In those cases the switchover pause lengthens noticeably, or the migration outright fails.

ZFS Replication as Accelerator: The Trick to Know

This is the lever that turns a slow migration into a relaxed one. When both nodes use ZFS as local storage, Proxmox can set up asynchronous replication between the pools — via the “Replication” GUI tab or on the CLI with pvesr. Replication runs in the background at configurable intervals, say every 15 minutes, and only transfers the ZFS snapshot deltas to the target node.

The result: when you later start a live migration, Proxmox does not have to copy the full disk — only the blocks that have changed since the last replication snapshot. Instead of several hundred gigabytes, maybe a few gigabytes move, and the migration takes two to three minutes instead of 30.

This combination — ZFS replication plus live migration — is in our view the most sensible path for two- and three-node clusters without a SAN. More on this in the article on Proxmox replication between two sites, which covers the mechanics and setup in detail.

What to Consider About Replication

Replication is not a backup. It transfers whatever is in the snapshot, including accidentally deleted files or a corrupted database. For data protection, the Proxmox Backup Server remains the right choice — replication runs alongside, not instead. Replication also writes snapshots regularly on both sides, which weighs on pool space and ARC. For heavily write-intensive VMs on a tight pool, that needs to be calculated realistically before rollout.

Network Requirements in Practice

A dedicated migration network pays off twice with local storage: it cleanly separates mirror traffic from VM production traffic, and it prevents a migration from tanking throughput for other services. 10 GbE on dedicated NICs with its own VLAN is our project standard; 25 GbE and 100 GbE come into play for larger clusters. What to avoid: running migration over the normal 1 GbE management network, because the mirror phase then becomes a patience test depending on disk size.

Migration bandwidth can be capped in the Datacenter under “Options -> Migration Settings” or in /etc/pve/datacenter.cfg if you want to throttle traffic to protect production. A sample value of 500 MB/s on a 10 GbE link is a good starting point in a live environment. For more background on cluster network design, see the article on Proxmox cluster network design.

Downtime Expectation: Honest, Not Polished

Zero downtime is not realistic with this variant. In practice we see switchover pauses that range from a few seconds up to just under a minute, depending on VM and load. For most applications this is uncritical — RDP sessions reconnect, SMB shares usually survive short pauses without data loss, web apps and databases respond with a brief delay.

What does not work: real-time workloads like VoIP gateways, phone systems or process control technology without buffers. For those, either shared storage with clean sub-second live migration is the better choice, or an application-level cluster that abstracts migration away entirely.

Realistic Expectations in Three Scenarios

Scenario	Disk	Network	ZFS Replication	Realistic Pause
Terminal server 200 GB	Local ZFS	Dedicated 10 GbE	Active, 15-min interval	A few seconds
File server 1 TB	Local ZFS	Dedicated 10 GbE	Active, hourly	10 to 30 seconds
ERP DB 2 TB, high load	Local LVM-thin	1 GbE	None	30 seconds or migration fails

The numbers are experience values, not benchmarks. Every environment brings its own variables, and for production migrations we always test the exact path once beforehand with an uncritical VM.

Limits You Should Know About

Live migration without shared storage is not a cure-all. Three points where the procedure hits its limits:

Thin provisioning and overprovisioning. If the target pool is tight and the VM disk is thin-provisioned, a live migration can fail mid-way because actual space usage is higher than expected. Verify beforehand with zfs list and qm list --full to see real usage.

Snapshots during migration. Snapshots created during an active migration lead to inconsistent state and are rightly blocked by Proxmox. Pause scheduled snapshots during that window — a point easily overlooked when combined with PBS use.

Hardware features in passthrough mode. PCIe passthrough, SR-IOV, vGPU or dedicated USB devices simply do not survive a live migration. A VM like that has to be gracefully shut down before moving to another node.

Decision Framework: When Shared Storage Is Still the Better Path

There is a clear point at which a SAN or hyperconverged solution like Ceph or iSCSI on TrueNAS really pays off. Roughly: clusters of four or more nodes, workloads over 10 TB of net VM data, strict downtime requirements below five seconds — or when replication puts too much pressure on the ARC. In those environments we often build hybrid solutions for customers: TrueNAS Enterprise with NVMe-TCP or iSCSI as central block storage, Proxmox on top as hypervisor. The article on the Proxmox TrueNAS plugin with NVMe-TCP covers the interplay in detail, and on the hardware side our TrueNAS configurator helps with sizing.

For everything else — the classic two- and three-node SMB setups — the combination of local ZFS pools and asynchronous replication has been proven for years and is more than sufficient in most environments. Which variant fits best is best clarified with a short inventory review — something we handle as part of our virtualization services or via TrueNAS support when the storage side matters.

FAQ

Do I need an enterprise repository for live migration without shared storage, or is the community variant enough?

The functionality is included in every Proxmox VE installation regardless of the repository. For production environments we recommend the enterprise repository because of more stable updates and vendor support — the migration itself works identically in both cases.

Can I migrate between nodes with different storage backends, say LVM-thin to ZFS?

Yes, Proxmox translates blocks automatically during mirroring. It is slower than ZFS-to-ZFS migration because no blocksize alignment is possible and ZFS re-compresses the incoming data. Fine for one-time consolidations; for regular migrations we would recommend a unified backend.

What happens if a migration breaks mid-way?

Proxmox keeps the source VM active until switchover succeeds. If migration aborts beforehand — due to network issues or a full target pool — the VM continues running undisturbed on the source node, and the partial disk pieces on the target are automatically cleaned up. Rollback risk is low in practice.

Does this work with Windows VMs too?

Yes, the procedure is OS-agnostic. Windows VMs with VirtIO drivers migrate just as cleanly as Linux guests. For older Windows versions without VirtIO, it is worth updating drivers beforehand — the switchover pause is then noticeably shorter because network reconnects are faster.

Should I pause Proxmox Backup Server during migration?

Scheduled backups and snapshots during an active migration occasionally conflict. For larger migrations we pause backup jobs for the affected VM in the PBS job or via the protection flag, and re-enable them after the move. For small VMs with migration times of a few minutes it is usually not needed.

What happens to the migration if the VM has a running snapshot?

Snapshots from the Proxmox snapshot menu move along if the target storage supports them — ZFS to ZFS or qcow2 to qcow2. Between incompatible backends (ZFS to LVM-thin without a qcow2 interlayer) the snapshot has to be deleted first, otherwise Proxmox refuses the migration with a corresponding error message.