Proxmox VE / Advanced: coordination and recovery evidence / Lesson 14

Migration compatibility and convergence

Evaluate guest mobility across CPU, devices, storage and network paths while distinguishing live migration from guaranteed uninterrupted application behavior.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Identify source and target compatibility requirements.
Explain dirty-memory convergence conceptually.
Review application and connection behavior separately from task completion.

Inventory the mobility contract

Migration moves a guest’s execution or configuration to another host under supported conditions. It requires more than a target node being online. Compare guest architecture, CPU features, package compatibility, devices, disks, bridges and storage access. A passed-through local device can prevent live migration, and a target with the same bridge name can still connect to a different physical network. The first record names these dependencies without issuing a migration command. Separate VM and container behavior: containers share host kernels and have their own relocation constraints, so do not apply a QEMU live-state model indiscriminately.

text Unexecuted mobility checklist

source/target review: architecture + CPU feature baseline
guest-local dependencies: passthrough devices, mounts, disk paths
shared or copied disks: exact volume identity and target capacity
network equivalence: bridge, VLAN, MTU, routing and policy

The checklist establishes review dimensions and no host or guest state is read.

Understand live-state transfer

A live VM migration transfers memory and device state while coordinating a final execution handover. Memory modified during copying can need another pass. If the workload dirties memory faster than the effective transfer path can keep up, convergence becomes difficult and timing can change. Live does not mean mathematically zero interruption, and actual connection continuity depends on network and firewall state as well. The second program models one simplified pass after copying and newly dirtied memory. It is not QEMU’s algorithm or a throughput measurement and deliberately makes no prediction of migration duration.

python A simplified dirty-memory pass

remaining_mib = 1000
copied_mib = 700
newly_dirtied_mib = 200
next_remaining = max(0, remaining_mib - copied_mib) + newly_dirtied_mib
print(next_remaining)

Expected output

Five hundred MiB remain in this toy arithmetic. Real migration overlaps activity and has protocol-specific behavior.

Distinguish storage transfer

Shared storage can avoid copying the same disk bytes during a move, but shared access must refer to the exact volumes and supported locking model. Local disks can require transfer and target space. A storage label alone is insufficient evidence of shared data. Snapshot chains, replication state and external mounts can complicate the plan. Also review temporary capacity and network contention: migration traffic can compete with storage or cluster communication if they share a constrained path. A successful steady-state workload does not establish that the transition has enough bandwidth and spare capacity.

Protect application semantics

Even when the guest continues running, applications can notice latency, brief pauses, changed network paths or connection-state differences. A task completed status should be followed by application-specific evidence, not assumed to imply every session survived. Define acceptable interruption, retry behavior and data-integrity expectations before selecting live or offline movement. Offline movement has an explicit stopped period but can simplify unsupported device and compatibility cases when planned appropriately. Neither choice is universally better; select from the supported guest configuration and the user-facing service contract, with a concrete recovery plan for a failed transition.

Record before-and-after evidence

A review records source and target identities, compatibility evidence, disk handling, network equivalence, capacity assumptions, expected application behavior and ownership after handover. Avoid assuming a timeout tells which side now owns execution; uncertain outcomes need authoritative environment evidence. This course performs no migration, measures no network and contacts no hypervisor. The arithmetic model verifies a limited relationship only. A future authorized test must use release-specific procedures and isolated workloads, and its findings should not be generalized to different CPU families, device attachments or storage backends without a new compatibility review.

Common errors and fixes

Matching bridge names are assumed to guarantee network equivalence

Why it happens: Physical VLAN, routing and policy paths were ignored.
How to fix it: Compare the complete target traffic path with the source contract.
Prevent it next time: Keep network equivalence in the mobility inventory.

Live migration is promised to have zero application impact

Why it happens: Execution handover was confused with all session semantics.
How to fix it: Define and validate acceptable interruption and application retries.
Prevent it next time: Report task, guest and application evidence separately.

A host-specific device blocks an assumed portable guest

Why it happens: Local dependencies were omitted from compatibility review.
How to fix it: Review supported relocation or redesign the device dependency.
Prevent it next time: Inventory passthrough and external mounts before movement planning.

Check your understanding

1. Why can a target be online yet unsuitable for live migration?

Show worked solution

CPU features, architecture, software versions, local devices, storage capacity or network equivalence may be incompatible. Online status covers only one prerequisite. Review the guest’s complete mobility contract and application interruption limits before selecting the move, rather than treating membership as sufficient compatibility evidence.

2. In the toy pass, copying 700MiB from 1000MiB while 200MiB becomes dirty leaves what, and what remains unknown?