Proxmox PulseProxmox VE 9.2: Live Migrate VMs with Zero Downtime
You can move a running virtual machine between Proxmox VE 9.2 nodes with live migration, but the move only behaves like zero downtime when the VM's
On this page
You can move a running virtual machine between Proxmox VE 9.2 nodes with live migration, but the move only behaves like zero downtime when the VM's storage, network, and CPU requirements line up on both sides. This checklist walks through the pre-flight checks, the migration commands, and the storage and network traps that turn a quick move into a failed task or a long storage copy.
Key Takeaways
- Shared storage: Live migration needs storage visible to both nodes, or you accept a full disk copy.
- Compatible CPU: Use a common CPU model if nodes differ, especially across Intel and AMD generations.
- Stable network: The target node must have the same bridge, VLAN, or SDN zone active before the VM arrives.
- Backup first: Take a recent backup before moving anything that matters, especially on non-shared storage.
- Short pause: Expect a pause measured in milliseconds to a few seconds, not a full reboot.
What to Check Before You Start
Start with cluster health. A missing quorum or a node that is not online will stop the migration before it begins.
pvecm status
Then confirm the target node can see the storage and has enough free memory. Run the storage check on the target node, then check memory there as well.
pvesh get /nodes/node02/storage --output-format json
free -h
Before starting, make sure these items are true:
- The cluster is quorate and both source and target nodes are online.
- The VM's disks are on shared storage, or you are prepared for a full storage copy.
- The target node has enough free memory for the guest's configured maximum.
- The target node has the same bridge, VLAN, or SDN zone as the source node.
- No passed-through GPU or USB device is attached to the guest.
- A recent backup exists.
Run the guest status and configuration checks on the source node before you start.
qm status 101
qm config 101
If the configuration shows a PCI device, a GPU, or a USB device attached directly to the guest, assume live migration is not available unless you have a very specific passthrough setup. A powered-off move is the safer path.
How to Run the Migration Safely
Live migration works by copying memory pages while the guest runs, then syncing dirty pages, then pausing the guest for a short time. The pause is the only visible downtime, and it is usually very short.
Run this command when the VM's disks are already on shared storage:
qm migrate 101 node02 --online
If the disks are not shared, tell Proxmox where to put them. This performs a full disk copy while the guest keeps running, so plan for I/O load and time.
qm migrate 101 node02 --online --storage local-zfs --full
If you have a dedicated migration network, point the task at it so the copy does not compete with normal guest traffic.
qm migrate 101 node02 --online --migration-network 10.0.0.0/24
Watch the task in the web UI. The progress bar moves in phases: memory copy, then a short pause, then completion. Do not cancel the task during the pause.
What to Watch During the Move
Run this command after the task finishes:
qm status 101
The VM should be running on the target node, and the disk should now be owned by the target node's storage path. If the VM is running but the network is wrong, the task may have completed while the guest lost connectivity.
If the migration fails while the VM is still running, the guest should remain on the source node. Do not restart it immediately. Read the task log, then verify the storage and network on both nodes.
If the task failed during storage copy, the disk may be partially copied on the target. Clean up that copy before retrying. If the task failed during the pause, the VM may have moved but the network on the target may be wrong.
What Makes Live Migration Stop Working
CPU compatibility is the most common hidden blocker. If both nodes use the same CPU family and model, host passthrough is fine. If they differ, use a common CPU model before the move, then reboot the guest during a planned window.
qm set 101 --cpu qemu64
Memory allocation matters too. If the target node cannot allocate the guest's configured memory, the migration will fail. Check available memory on the target before starting.
free -h
Ballooning can make a VM look smaller than it is. If the guest has ballooned down, the migration may still need full memory on the target. Make sure the target has enough free RAM for the configured maximum, not just the current ballooned value.
Guest operating systems usually behave well, but drivers and CPU features matter. Linux guests with virtio drivers are common and usually behave well. Windows guests generally migrate well too, but you should still test the exact VM profile you plan to move.
Storage Caveats That Turn Live Migration Into a Long Copy
Live migration is fastest when the storage is already shared. If storage is local to one node, the migration must copy the whole disk image to the target. That is still a live move, but it is not a cheap one.
| Storage setup | Live migration behavior | Practical check |
|---|---|---|
| Ceph RBD | Works well when the cluster is healthy. | Confirm the pool is online and the placement group is not backfilling. |
| NFS | Works, but latency can slow the memory and disk sync. | Confirm the mount is active and healthy on both nodes. |
| ZFS over iSCSI | Works when both nodes see the same iSCSI target. | Confirm the initiator sessions and multipath state before the move. |
| Local LVM-thin | Not shared, so the move becomes a full storage copy. | Expect a longer task and more I/O pressure on both nodes. |
If you are choosing between ZFS vs Ceph on Proxmox, remember that live migration only cares whether both nodes can reach the same storage path right now.
A shared storage entry should look something like this before you try the move:
[nfs01]
path /mnt/pve/nfs01
content images,rootdir
server 10.0.0.20
export /tank/proxmox
shared 1
A local storage entry looks different and should not be used for live migration unless you are prepared for a full copy:
[local-lvm]
vgname pve
content images,rootdir
shared 0
Network Caveats That Break Guest Connectivity
The guest network must exist on the target node in the same form it has on the source node. A bridge on one node is not automatically present on another.
Run this command on both nodes and compare the output:
cat /etc/network/interfaces
Do this on both nodes. If the VM uses a VLAN-aware bridge, the VLAN must be configured on both nodes. If it uses an SDN zone, that zone must be active on the target before the migration starts. If your network design is split between VLAN and VXLAN, see VLAN vs VXLAN in Proxmox VE.
For migration traffic, a dedicated network is worth it. Use a second bridge or a separate VLAN with enough bandwidth and a low-latency path. If you set a migration network in the datacenter options, the migration task will use it.
Guest connectivity will drop briefly during the pause. If your application uses long-lived TCP connections, expect a brief timeout or reconnection. That is normal.
A Gotcha I Hit
I once migrated a VM that looked fine on the source node and failed on the target because the target did not have the same bridge. The task failed with a network configuration error, and the VM stayed running on the source.
Run this command on the target node:
pvesh get /nodes/node02/network --output-format json
The fix was simple: create the missing bridge on the target node, then retry the migration. The lesson is to compare the network configuration on both nodes before you start, not after the task fails.
Honest Tradeoff
Non-shared storage live migration is convenient, but it trades time and I/O for the ability to keep the guest running. On a 200 GB VM with 8 GB RAM over 10 GbE, I have seen the full copy take about four minutes and the final pause run just over one second. On slower storage or a busy cluster, that pause can grow, and the risk of a failed task is higher.
If you can take a short outage, backup and restore is often the safer option. If you cannot, live migration is the right tool, but only after the storage and network checks pass. Take a backup first. If your backup window is tight, PBS 4.2 parallel sync jobs can make that step less painful.
Conclusion
Live migration in Proxmox VE 9.2 works well when the storage is shared, the network is identical on both nodes, and the CPU model is compatible. Run the pre-flight checks, use the simple migration command for shared storage, and reserve full storage moves for cases where you accept the extra time and I/O. Your next step is to pick a low-risk VM, verify the storage and network on both nodes, and perform a test migration during a quiet window.
