Column 1
Skip to content
Column 1

Efficient VM Migration Between Proxmox Servers Using Rsync

Proxmox Upgrade Chain

Proxmox upgrades are chained. If you are catching up from an older host, work forward instead of jumping blind: 7.4 to 8.0, 8.2/8.3 to 8.4, 8.4 to 9.1, then the Proxmox VE 9.2 upgrade checklist. For new hardware, use the separate Proxmox VE 9.2 fresh install guide.

2026 migration update

Use rsync migration when you are moving between standalone hosts and can safely stop the guest or carefully control changed blocks. For clustered Proxmox, prefer native migration. For safer standalone moves, consider Proxmox Backup Server restore workflows. After any rsync move, verify VM config, disk paths, NIC mapping, boot order, guest services, and backup jobs.

Introduction

Migrating Virtual Machines (VMs) between Proxmox servers can be a routine task, but doing it efficiently and securely is crucial. This guide will walk you through how to use rsync for VM migration, which offers both efficiency and security.

Why Use Rsync?

Rsync is a utility for efficiently transferring and synchronizing files across systems. It only sends the differences between the source and destination files, reducing the amount of data transferred. This is particularly useful for migrating large VMs.

Prerequisites

  • SSH keys set up for password-less authentication between the source and destination servers.
  • Root access to both the source and destination Proxmox servers.

On the Source Proxmox Server

Step 1: Shutdown VM

qm stop [VM_ID]

Step 2: Export VM Configuration

qm config [VM_ID] > /tmp/vm_[VM_ID].conf

Step 3: Rsync Disk Image

rsync -av --progress /var/lib/vz/images/[VM_ID]/ root@[DEST_IP]:/var/lib/vz/images/[NEW_VM_ID]/

Step 4: Rsync Configuration File

rsync -av --progress /tmp/vm_[VM_ID].conf root@[DEST_IP]:/tmp/

On the Destination Proxmox Server

Step 1: Create New VM

Create a new VM but don't start it. Make sure the storage and network configurations match the source VM.

Step 2: Import Configuration

cat /tmp/vm_[VM_ID].conf > /etc/pve/qemu-server/[NEW_VM_ID].conf

Step 3: Fix Permissions

chown root:root /var/lib/vz/images/[NEW_VM_ID]/*

Step 4: Start VM

qm start [NEW_VM_ID]

Step 5: Verify

Log into the VM to ensure everything is functioning as expected.

Conclusion

Using rsync for VM migration between Proxmox servers not only makes the process more efficient but also more secure. By following this guide, you can ensure a smooth migration process while minimizing the risk of data loss or corruption.

Current Migration Planning Note

This rsync method is still useful for controlled moves, but for current Proxmox environments you should also verify the source and destination version path. If the move is part of a Proxmox VE 9.1 upgrade or hardware refresh, review the current upgrade guide before moving production VMs.

2026 Proxmox migration refresh

Rsync can help in a Proxmox migration, but it should not replace the normal safety work. Confirm backups, snapshots, VM shutdown order, storage health, target capacity, network reachability, guest drivers, and rollback steps before moving production workloads.

For clusters, also check quorum, HA state, migration order, shared storage expectations, and whether any backup jobs or replication tasks need to be paused. After the move, verify boot, network, application health, backups, monitoring, and customer-facing services before deleting the old copy.

Related Fix I.T. Phill reading

2026 Support Update: Proxmox VM Migration Checklist Between Servers

Current action path: Proxmox VM migration should prove the backup, storage path, network identity, expected downtime, DNS behavior, and post-move service state.

What to verify before production changes

  • Confirm source backup, destination storage, network identity, and expected downtime.
  • Move one low-risk VM or test workload before critical production services.
  • Verify guest boot, IP/DNS, application health, backups, and monitoring after migration.

Source-backed references and next reads

For support tickets, keep the exact system touched, backup timestamp, changed setting, public URL, and post-change verification result in the notes. That is the difference between a tutorial and an operational recovery path.