Live migration on Proxmox VE
(the vMotion equivalent)

vMotion vs qm migrate

In the PVE panel: VM → Migrate → “Online”. From the CLI:

qm migrate <vmid> <target> --online

--online is ignored if the VM is stopped. The default vmid range in man qm is 100–999999999. This is not a product named “vMotion” — it is QEMU/KVM live migration that vSphere wraps in another brand.

The GUI shows a memory-iteration bar: QEMU copies dirty pages until the delta fits the switchover window. The more the guest writes, the longer the “last” iteration takes. That is why the migration network and the --bwlimit cap are part of the design, not CLI decoration. A guest with a huge database cache on local ZFS without shared storage will walk for minutes — that is not a fault, it is a volume copy.

Shared storage and local disks

The pvesm guide: on shared storage (NFS, RBD, iSCSI) nodes see the same image, so live migration is fast — no disk copy. On local ZFS/LVM-thin you enable --with-local-disks (live storage migration). --targetstorage maps source to target; 1 maps each storage to itself.

--force allows migrating a VM that uses local devices (passthrough, for example). Root only. Without it the task fails on a local device.

Network, encryption, limits

• --migration_network — CIDR used for migration.
• --migration_type — traffic uses an SSH tunnel (encrypted) by default. On a fully private network you can disable that for performance.
• --bwlimit — KiB/s cap; default from datacenter or storage.
• --with-conntrack-state — whether to migrate conntrack entries (default 0).

Keep the migration network off Corosync and off Ceph. Saturating the cluster link with live migration is a classic way to lose quorum during a “harmless” vMotion.

CPU type and compatibility

Live migration needs the target to run the same vCPU model. Type host pins physical CPU flags — between Intel/AMD generations the migration fails. A safer common denominator: x86-64-v2 / x86-64-v3 or an explicit QEMU model. Details: Choosing a CPU type in Proxmox.

Containers, HA and the load balancer

A running LXC cannot live-migrate — PVE does a restart migration. Cluster HA is a different mechanism: after fencing the guest starts on another node (needs quorum and a reachable disk). The PVE 9.2 Dynamic Load Balancer itself issues live migrations to even out CPU/RAM — honouring affinity. That is the DRS equivalent, not vMotion in isolation.

The Storage vMotion equivalent is --with-local-disks / changing --targetstorage while the VM is up. Changing a portgroup in flight is a bridge/VLAN edit — not always without a short link blip; we do not promise “zero” where QEMU must re-plug the NIC.

What breaks live migration

• PCI/USB passthrough and local devices without --force (root only) — the job dies on a local device.
• CPU type host across Intel/AMD generations — the target cannot execute the same flags.
• LXC: no live migrate; PVE migrates with a restart. That is not container vMotion.
• Shared storage + a common CPU baseline (x86-64-v2 / x86-64-v3) + a dedicated migration CIDR — that is the path we design as default.

The PVE 9.2 Dynamic Load Balancer itself starts live migration while honouring affinity — that is the DRS analogue, not a separate product. HA is still a different mechanism (restart after fencing). Quorum: cluster and quorum.

Datacenter: network and migration type

qm man: --migration_type defaults to an SSH tunnel (encrypted). On a fully private network you can switch it for throughput — that is a risk decision, not “always turn it off”. --bwlimit in KiB/s takes the default from the datacenter or storage. --with-conntrack-state defaults to 0. --targetstorage 1 maps each storage onto itself.

Offline, HA and design order

Offline migration (VM powered off) copies the disk with no memory iterations — a plain volume transfer. --online is then ignored (man qm). HA is still a different mechanism: after fencing the guest starts on another node if quorum holds and the disk is visible there. Live migration does not replace HA, and HA does not replace live migration.

Design order is fixed: a common CPU baseline and a dedicated migration CIDR first, then shared storage or a conscious copy of local disks, and only then the Dynamic Load Balancer. Affinity and HA maintenance mode live in other articles — we do not mix them with the vMotion bar in the GUI.