Migrating virtual machines between Proxmox nodes: live and offline

Proxmox migration: where VM transfer between nodes breaks

When migrating virtual machines between Proxmox nodes, the task looks linear: copy memory, switch ownership, shut down the source. In practice, live migration proceeds in several passes — first the main volume is transferred, then changed memory pages are caught up.

If the guest is actively writing to memory (database, cache, queue), catch-up does not converge: the transfer drags on for tens of minutes and ends with the same stop that no one planned.

Typical failures begin before copying finishes. A communication break between nodes halfway through leaves a write lock and an unfinished task on the source: the machine starts neither on the old node nor on the new one until the lock is released manually.

Storage mismatch causes failure after memory transfer — the target node lacks the same pool or volume, and the operation rolls back to the starting point.

Network is a separate source of failures. On the target node there is a different bridge, different VLAN tags, the guest address moves to a foreign segment, and the service becomes unavailable although migration formally succeeded.

A virtualization cluster adds its own layer: the node temporarily leaves voting, and with a small number of participants migration blocks neighboring operations.

Service downtime here is the cost of error. During offline migration, the unavailability window equals disk copy time, and during manual switches the administrator brings the service up before the guest has actually started. Next, we discuss how this is addressed.

What planned migration provides: downtime, integrity, rollback

Planned migration is an operation with a measurable downtime budget, not “let’s reboot and see.” During live migration, the hypervisor catches up with guest memory through iterative passes until the discrepancy becomes minimal, then stops the machine for fractions of a second, transfers the final state, and starts it on the target node — the application connection is not broken.

Offline migration does the opposite: the guest is stopped, disks are copied, and the machine starts again. Downtime here equals transfer time, but any state discrepancies are excluded.

Integrity rests on three checks: disk snapshot on the source, storage fullness check on the target, and size and checksum verification after transfer.

For databases and clusters with quorum, nodes move one at a time, and Proxmox VE lets you set the order and make sure quorum is not lost at any step.

The rollback point is not a backup, but saved VM configuration and its disks on the source node: they are not deleted until the target confirms reception and startup.

If checks fail, the machine returns by reverse migration using the same scheme, and this is a pre-rehearsed scenario, not improvisation at night.

Predictability of migration consists of three numbers that we name before work starts: expected downtime window, disk transfer duration, and number of machines migrated per window.

Then this becomes a plan by nodes with checkpoints — at each step it is clear what has moved, what has been checked, and where to roll back.

Live and offline Proxmox migration: comparison of transfer modes

Both modes solve one task — migrate a running virtual machine to another node — but handle its state differently.

In live migration, memory is copied iteratively: first the entire volume, then only changed pages, and at the end the machine is briefly stopped for final synchronization and starts in the new location.

Offline migration is simpler: the machine is shut down, disk and configuration are transferred as files, after which it is powered on on the new node.

Mode selection is determined not by convenience but by storage type and acceptable service unavailability time. If disks reside on shared network storage accessible to both nodes, only memory state needs to be transferred.

With local disks, disk blocks are added to the state, and then the mode depends on write load: while catch-up is running, the machine continues writing, and with intensive I/O the migration does not converge — it has to be stopped and switched to the offline scenario.

In practice, boundaries between modes blur: some limitations are removed by preparation — moving disks to shared storage in advance, configuring routes, and checking storage availability from the target node. We discuss this at the planning stage, before the actual switch.

Implementation stages: from inventory to handover into operation

The work order is the same for live migration and for migration with a short machine stop — only the composition of the work window and service readiness for a pause differ.

Below is the sequence by which we run a project in Proxmox: each stage closes with a verifiable result, not a completion report.

1. Cluster audit. We take inventory: machines, storage binding, quorum state, network bridges, permissions, guest additions. We separately note dependencies that make migration without downtime impossible.

2. Migration plan. Target node layout, migration type for each machine, batches and order, return points. We agree on the work window — only what truly requires a pause falls into it.

3. Configuration. Shared storage or replication between nodes, network and addressing, load limits, backups before the batch. Nodes pass standard health checks.

4. Test run. Secondary group of machines: we measure switch time, data integrity, service availability, rollback operation. Based on results, we adjust batch composition and window boundaries.

5. Work in the window. We migrate in batches, monitor node and storage load; critical services go first. An engineer on call is responsible for switching and rollback.

6. Acceptance and handover. Service checks by list, data and log reconciliation, recording the result with system owners. We hand over the migration procedure, cluster diagram, and instructions for the on-call shift.

What you keep: cluster map, configurations, procedures

After migration, you keep not a work report but a working set with which the cluster can be maintained and developed without our involvement. All artifacts are in your repository and can be read with standard Proxmox tools and a regular text editor.

• VM placement map — a “machine → node → storage” table with current consumption and free reserve on each node. It immediately shows where load can be added and where the next migration will hit the limit.
• Node configurations — network bridges, traffic filtering rules, storage parameters, and backup jobs exported in a form suitable for comparison and recovery.
• Switchover procedure — step-by-step order for live and cold migration: what we check before starting, which commands we execute, when we move the load, and how we record the result.
• Rollback plan — predefined return points (snapshot, configuration copy, old node in reserve), conditions for initiating rollback, and who makes that decision.
• Documentation and change log — network and storage diagram, node roles, configuration revision history. A new engineer gets up to speed in hours, not weeks.
• Verification scenarios — a short set of checks after each migration: service availability, response, replication state, backup integrity.

The set lives with the cluster: we update it during work so that on the next expansion or planned migration you rely on your documents rather than reconstructing the picture from memory.

Case: a multi-node cluster was migrated without prolonged downtime

A Proxmox cluster of six nodes served production and test environments.

VM disks were local on the nodes, so migration without downtime was impossible in principle: each machine was shut down, we waited for locks to be released, started it on the target node, and manually checked service availability.

One planned maintenance session — 9 manual operations per machine and a 30–40 minute window, always scheduled at night.

First, we mapped the fleet: what requires live memory and minimal downtime, what migrates in batches, where a local disk is essential.

For first-type machines, we brought in shared storage with replication to a second node — each had an up-to-date image before migration began, so state transfers without a restart.

For large machines with local disks, we left managed offline migration with preliminary conversion and readiness checks via an agent inside the guest OS.

After the changes, downtime for machines on shared storage dropped to 1–2 seconds — the network connection moves with the address, and clients see at most a short interruption.

Batch migration of a large machine takes 6–8 minutes instead of 40 and is launched with one command instead of nine manual actions.

A separate class of failures disappeared: disk desynchronization between nodes and stuck locks after abnormal migration termination no longer surface.

Work no longer tied to night windows — maintenance runs during business hours, and rollback to the source node remains available until service readiness on the target is confirmed.

How does live migration differ from offline, and when is each mode needed?

The difference is not speed but what happens to the running machine. In live mode, memory is copied in cycles while the guest continues serving requests, and the virtual machine is stopped only at the final switch.

In offline mode, the machine is shut down, the disk is transferred entirely, and downtime equals copy time.

Disk type determines mode choice. If the volume resides on shared storage, the target node sees it immediately, and switching reduces to transferring memory state.

Local volumes must be copied over the network: live migration of a large disk takes hours and completes only when the guest’s write rate drops.

In Proxmox VE, both operations are standard, so the acceptable window and machine state decide.

Services without their own state can get by with an offline switch in a maintenance window, while DBMSs require a coordinated shutdown order — unwritten cache in memory is lost during a hard shutdown.

Practical criterion: there is shared storage and a pause is unacceptable — live; volumes are local or a window is agreed — offline.

Before switching, we check cluster quorum, compatibility of node CPU instructions, and resource headroom on the target side — this is what makes migration a planned operation with a predictable window.

Common technical concerns: compatibility, work windows, rollback

Engineering concerns before migration usually come down to four questions: will the guest OS configuration transfer without manual editing, how long will the work window take, what to do in case of failure, and how migration will affect neighboring virtual machines. Below are short answers to what is most often raised before kickoff.

How much work window is needed, and can downtime be avoided?

Live migration keeps the service available: memory pages are transferred to the target node, and the final switch takes fractions of a second and fits into a pause imperceptible to users.

Cold migration requires stopping the guest OS, but removes restrictions on load and disk volume. We plan the window so that groups of machines are migrated sequentially and related services are not taken down at the same time.

What happens during a failure, and what is the rollback order?

Before switching, the source machine remains a working copy, so rollback is returning control to it, not restoring from backup. We save configuration and state snapshots before migration, and after switching we check service availability and data integrity on the target node.

If checks fail, returning takes minutes: the guest OS starts on the source node in its previous form.

How does migration load neighboring nodes?

During live migration, the target node receives an additional disk write stream and network traffic, while the source gets load on the transfer channel. Therefore migration is planned outside peaks and one or two machines at a time, not as a batch.

Before starting, we look at disk I/O and memory headroom on both nodes and spread migration waves so that headroom remains.

Let’s discuss your task: we’ll select a mode and come back with a plan

To base the work estimate on facts rather than assumptions, we need a snapshot of the current environment: number of nodes in the Proxmox cluster, storage types involved, network diagram, and which services are critical to stopping.

This is already enough to divide the VM fleet into those migratable live and those that will have to be shut down in an agreed window.

Once the description is ready, we come back with a working set, not general words:

• migration plan by waves — from low-risk machines to production ones, with windows and order of actions;
• VM map with a mode for each: live migration, migration with stop, or rebuild;
• team composition for the work period and responsibility zones — who manages storage, who manages network, who accepts services after migration;
• list of checks before and after: availability, data integrity, application response, behavior under load;
• rollback scheme and return points in case a machine does not start on the new node;
• communication procedure and reporting mode during migration.

If some data has not yet been collected, that is not a reason to postpone: we will discuss the task to the extent available and clarify what is missing along the way. Describe the environment and acceptable downtime — then we will come back with an estimate and migration plan.