Learn Proxmox VE - Storage Replication & VM/CT Migration

#Introduction

Once you have more than one node, the classic question arises: how do you move VMs between nodes without stopping services? The answer lies in two complementary mechanisms: storage replication, which ensures a copy of the data is available on the target node, and migration, which moves the workload itself.

Episode 12 covers both: replicating ZFS-based VM data between nodes, performing online and offline migrations, and understanding the requirements that make all of this run smoothly. These are the direct prerequisites for high availability in episode 13.

#Storage Replication

#The ZFS-Based Replication Concept

Storage replication periodically copies VM disk data from one node to another. The Proxmox implementation is based on ZFS snapshots: at each interval, Proxmox takes a snapshot, sends the changes since the last snapshot to the target node, and creates another snapshot there. As a result, the target node always has an almost-in-sync copy of the data.

Node A (source) --snapshot--> Node B (target)

Replication can run every 15 minutes or more, depending on your needs. The shorter the interval, the smaller the potential data loss at failover — but the heavier the network load.

#Configuring Replication

Replication can be set up per storage or per VM at Datacenter -> Replication -> Add. Select the VM, target node, storage, and interval:

VM       : 100
Target   : node-b
Storage  : zfs-pool
Interval : 15 minutes

Once created, Proxmox executes the replication according to the interval and records the results in the task log. Check the status via the CLI:

pvesr status

The pvesr status command shows the list of replication jobs, target nodes, and the last synchronization status.

#Replication as the Foundation of HA

Replication is the foundation of high availability: when the source node dies, the target node has a fresh-enough copy of the data to bring the VM back up. Without replication (or shared storage), failover is impossible.

#VM/Container Migration

#Online Migration

Online (live) migration moves a running VM to another node without downtime. Proxmox gradually copies the VM's memory to the target node while the VM keeps serving, then when the move is almost complete, performs the final transfer and continues execution on the new node. The user won't feel a thing.

qm migrate 100 node-b --online

The qm migrate 100 node-b --online command moves the running VM 100 to node-b without downtime. For containers, use pct migrate with similar options.

#Offline Migration

Offline migration moves a powered-off VM. The process is simpler — the entire disk is sent to the target node, then the VM is started there. This is useful for planned maintenance or when live migration isn't possible.

#Migration Requirements

Migration can't just happen on a whim. Two main requirements:

• Shared storage: all nodes read the VM's disk from the same storage (NFS, Ceph, iSCSI), so only memory and state need to be moved.
• Active storage replication: the target node has a data copy from replication.

Shared storage OR Active storage replication

Without either of these, Proxmox refuses the migration because the target node has no access to the VM's data.

#Replication vs Backup

Replication and backup are often mistaken for the same thing. In fact, they answer different needs:

• Replication: protects against node failure — data is available on another node, but wrong changes are also copied along.
• Backup: protects against data loss — stores historical points in time that can be rolled back.

Replication : service continuity when a node fails
Backup      : data recovery from a specific point in time

They complement each other: production-grade uses replication for fast failover and backup for long-term recovery.

#Migration Best Practices

A few practices that make migration run smoothly:

• Test live migration on non-critical workloads first.
• Make sure the network between nodes is fast and stable — high latency slows down memory synchronization.
• Avoid migrating workloads with very high I/O during peak hours.
• For VMs with large disks, offline migration can be faster than live.

qm migrate 100 node-b --online --verbose

The --verbose flag shows the migration process details, useful for checking at which point a migration is running slowly.

#Closing

Episode 12 equipped you with the ability to move workloads: understanding ZFS snapshot-based replication, configuring it from the UI or pvesr, performing online migration without downtime, offline migration, and making sure the shared storage or replication requirement is met.

The key takeaways:

• Storage replication copies VM data between nodes via ZFS snapshots.
• Shorter replication intervals reduce data loss at failover.
• Live migration moves VMs without downtime.
• Offline migration moves powered-off VMs.
• Migration needs shared storage or active replication.
• qm migrate --online for live, pct migrate for containers.

In the next episode, episode 13, we will cover Proxmox clusters and high availability — combining nodes into a cluster with pvecm, understanding quorum and voting rules, getting to know the QDevice for two-node clusters, and configuring the HA manager and simulating failover. All the foundations are ready; now it's time to build a real cluster!