🧬 How to Migrate a Proxmox VM to a New Server

John Jestin

— 2 min read

Migrating virtual machines from one Proxmox VE host to another doesn't require the full cluster setup — and can be done cleanly with zero configuration loss and minimal downtime, even without shared storage.

This guide walks you through how to migrate a standalone VM (or multiple VMs) from one Proxmox node to another, preserving IDs, MAC addresses, passthrough devices, and storage layout — just like in production.

🧭 Overview

  • Source Node: server1.local (the old Proxmox server)
  • Target Node: server2.local (the new server with fresh Proxmox VE)
  • VM ID: 101
  • Backup File: vzdump-qemu-101-YYYY_MM_DD-HH_MM_SS.vma.zst

We use vzdump to snapshot and export the VM, then qmrestore it on the new node.

✅ This method works across different storage types (LVM, ZFS, directory), and doesn’t require a cluster or HA.

📦 Step 1: Backup the VM on the Source Node

SSH into the old Proxmox host and stop the VM:

qm shutdown 101

Then run a compressed backup using vzdump:

vzdump 101 --compress zstd --storage local --mode stop
This creates a file in:
/var/lib/vz/dump/vzdump-qemu-101-YYYY_MM_DD-HH_MM_SS.vma.zst

📡 Step 2: Transfer the Backup to the New Node

From the old node, copy the backup file to the new node:

scp /var/lib/vz/dump/vzdump-qemu-101-*.vma.zst root@<new-node-ip>:/var/lib/vz/dump/

If the folder doesn't exist on the new server:

mkdir -p /var/lib/vz/dump

💾 Step 3: Restore the VM on the New Node

On the new Proxmox server, run:

qmrestore /var/lib/vz/dump/vzdump-qemu-101-*.vma.zst 101 --storage <target-storage>

To find available storage names, run:

pvesm status

Example for ZFS:

qmrestore vzdump-qemu-101-2025_06_16-00_26_37.vma.zst 101 --storage nvme-zfs

🔍 Step 4: Verify Configuration Before Power-On

Inspect the restored VM config:

qm config 101

Check for:

  • net0: — bridge name (e.g. vmbr0) and MAC
  • Disk buses (e.g. scsi0, virtio0)
  • PCI passthrough devices (hostpciX)

Edit manually if needed:

nano /etc/server1/qemu-server/101.conf

🚀 Step 5: Power On and Validate

Start the VM:

qm start 101

Then:

  • Open the console in the Web UI
  • Verify network connectivity (ping, SSH)
  • Check that all services start correctly
  • Confirm expected MAC/IP/DNS behaviour

🧹 Step 6: Retire or Repurpose the Old VM

Once you’ve confirmed that everything is running correctly on the new node, delete the original VM on the old node to prevent accidental conflicts:

qm destroy 101

Or leave it powered off as a cold backup.

💡 Pro Tips

  • Use --mode snapshot if your VM supports online backups (QEMU guest agent recommended).
  • You can bulk transfer multiple backups using rsync or scp with wildcards.
  • Restore with a different VMID to test in parallel without affecting production.
  • Match storage type (ZFS to ZFS, LVM to LVM) to avoid errors during restore.

🧰 Troubleshooting

Issue Solution
VM won’t start Check PCI passthrough settings, MAC/IP conflicts, disk paths
Disk missing or corrupted Ensure target storage pool has enough space and same storage type
Restored with wrong MAC Manually set correct MAC in 101.conf before booting
VM boots but no network Verify correct bridge (vmbr0, etc.) is assigned and UP

🧾 Summary

Migrating standalone Proxmox VMs from one node to another is fast, safe, and requires no shared storage or HA config. By backing up with vzdump, transferring, and restoring with qmrestore, you can preserve your exact VM setup without breaking services.

Want to automate this process for multiple VMs with a shell or Ansible script? Stay tuned for the automation edition.

thedev.uk — © 2025 John Jestin

Read more