Live Migration of VMs in Proxmox VE Between Cluster Nodes

Live Migration lets you move a running VM from one Proxmox node to another without downtime. The virtual machine keeps running with minimal interruption (usually a few milliseconds).

Migration Types

Requirements for Live Migration

• Both nodes are in the same Proxmox cluster
• Identical (or compatible) CPU types
• Shared storage (Ceph, NFS, iSCSI) or local storage with the --online flag
• A gigabit network between nodes (dedicated is recommended)

Live Migration via CLI

# Migrate VM 100 from the current node to node2
qm migrate 100 node2 --online

# Migrate with local storage (live disk copy)
qm migrate 100 node2 --online --with-local-disks

# Migrate specifying the target storage
qm migrate 100 node2 --online --targetstorage local-lvm

# Offline migration
qm migrate 100 node2

Migrating LXC Containers

# Live migration of a container
pct migrate 200 node2 --online

# Offline migration with local volume copying
pct migrate 200 node2 --targetstorage local-lvm

Configuring the Migration Network

# /etc/pve/datacenter.cfg
migration: type=secure,network=10.0.1.0/24

# Or via the web interface
# Datacenter → Options → Migration Settings

Troubleshooting Migration Errors

# Error: CPU types incompatible
# Solution: use a compatible CPU type
qm set 100 --cpu x86-64-v2-AES

# Error: missing storage on target
# Solution: check storage availability on the target node
pvesm status

# Error: VM has local resources (USB passthrough, etc.)
# Solution: disable USB passthrough before migration
qm set 100 --delete usb0

Migration errors unrelated to CPU or storage

Besides CPU incompatibility and missing storage, network- and system-level errors also show up — they are less obvious because the error text points to a symptom (a dropped connection, a timeout) rather than the root cause in the network or cluster certificate configuration.

ERROR: migration aborted (duration 00:00:03): Failed to sync data - copy failed: unexpected end of file
kvm: -incoming tcp:0:60000: Failed to bind socket: Address already in use
ERROR: online migrate failure - client_migrate_wait: got timeout waiting for reply

• unexpected end of file: the connection between nodes dropped mid-transfer — check network stability and MTU; with jumbo frames, make sure the MTU matches on both nodes and the switch.
• Address already in use: the incoming migration port is held by a previous unfinished attempt. Wait for the stuck task to finish in the task list, or restart pvedaemon on the target node.
• got timeout waiting for reply: the target node is not responding over the migration's SSH tunnel — check that port 22 and the cluster certificates between the nodes are in order (pvecm updatecerts).

Check the logs on the target node first for all three errors, not the source: they show whether memory transfer even started, and at what percentage it broke off.

When live migration is not the right fit

The technology has clear boundaries — outside them, migration is either impossible or does not deliver the guarantees you expect, and working around the limitation usually costs more than an offline move.

• A VM with a passed-through PCI/GPU device or statically allocated hugepages can only be moved offline.
• Moving between different Proxmox clusters: the standard qm migrate command only works within a single cluster; for cross-cluster moves, use VM export/import or replication via Proxmox Backup Server.
• A narrow link between nodes with a large amount of RAM: migration may fail to sync "dirty" memory pages faster than the VM changes them, and get stuck in a re-sync loop.

Verifying the migration result

After the move, confirm that the VM is really running on the new node and has not lost its state.

# Which node the VM is currently on
pvesh get /cluster/resources --type vm | grep -A2 '"vmid": 100'

# VM status and uptime after the move
qm status 100 --verbose

# Check the log of the latest migration task
pvesh get /nodes/node2/tasks --typefilter qmigrate --limit 1

If the VM's uptime was not reset and the agent reports the current IP address, the migration completed without losing state. General principles for building fault-tolerant infrastructure are covered in setting up a Proxmox VE cluster.

Frequently asked questions

Can a VM with GPU passthrough or another PCI device be live-migrated?

No, live migration of such VMs isn't supported: the device is physically tied to a specific node, and the hypervisor can't transfer its state to another server without stopping it. The only option for a VM with PCI passthrough is offline migration — fully stopping the machine, moving the configuration, and reattaching the device on the target node.

What's the difference between migrating with shared storage and migrating with local disks?

With shared storage (Ceph, NFS, iSCSI), only memory and CPU state move across, while the disks physically stay in place and simply become visible to the new node. With local storage, the VM's disks get copied to the target node during the migration itself using the --with-local-disks flag, which takes noticeably longer and puts more load on the network.

Can a VM be moved from one Proxmox cluster to another?

The standard migration command only works within a single cluster and cannot move a VM between separate Proxmox clusters. Moving between independent clusters requires exporting and then importing the VM configuration, or replicating it through Proxmox Backup Server — both approaches take extra steps compared with the ordinary migration command.

Does the VM stop even for a moment during live migration?

Technically yes, but the pause is so short — typically a few milliseconds — that applications and users barely notice it. At that moment the hypervisor switches CPU execution from the source node to the target one only after most of the memory has already been synchronized, so network connections inside the VM generally stay intact.