Move a Proxmox VM to a New Host Without a Cluster (2026)

qm migrate moves a guest to another node of the same cluster. Between two standalone Proxmox VE hosts there are three routes: qm remote-migrate (or pct remote-migrate) straight to the other host, a backup restored on the new host, or zfs send when both hosts keep guests on ZFS. The table below picks one by downtime, storage type and what each needs. It is written for Proxmox VE 9.2 (released May 21, 2026) against its 9.2.12 manual pages, dated September 18, 2026. (For live migration and high availability inside a cluster, see Proxmox clustering and HA.)

Keep the source until the new copy boots. remote-migrate leaves the source VM stopped and locked unless you pass --delete 1; qm unlock <vmid> gives it back if the move goes wrong. Backup and restore and ZFS send leave the source guest in place.

Which method fits your move

Look up both hosts’ storage type first. Each storage in /etc/pve/storage.cfg starts with a <type>: <STORAGE_ID> line, such as lvmthin: local-lvm or zfspool: local-zfs.

The storage rule comes from pve-storage: a ZFS pool imports only ZFS streams, while LVM, LVM-thin, directory, NFS, CIFS, BTRFS and Ceph RBD storage all exchange raw-format volumes, so a stopped VM, or a container whose root disk is a raw image, can go from local-lvm to a directory storage on the new host but not to local-zfs. A container stored as a subvolume (BTRFS, or a size 0 root disk on directory storage) exports as tar+size, which only storage that takes subvolumes can import; for one of those, back up and restore. Containers never go live. The pct manual lists --online, but the pct chapter says running containers cannot be live-migrated. Offline, the copy time is the downtime. The transfer time calculator opens on a 100 GB disk over gigabit.

Method 1: qm remote-migrate (direct, supports live)

qm remote-migrate arrived in Proxmox VE 7.3 (November 22, 2022), and the 9.2.12 manual still marks it “EXPERIMENTAL feature!”. Proxmox Datacenter Manager, whose first stable release came in December 2025, adds live migration between independent clusters to a web UI.

Syntax (VM):

qm remote-migrate <vmid> [<target-vmid>] <target-endpoint> \
  --target-bridge <bridge> --target-storage <storage> [OPTIONS]

The <target-endpoint> is:

apitoken=PVEAPIToken=user@realm!token=SECRET,host=ADDRESS[,fingerprint=FP][,port=PORT]

Make the token on the target host

pveum user token add root@pam migrate --privsep 0

It prints the secret once. It cannot be shown again. --privsep 0 gives the token root’s full rights. To keep privilege separation on, create it without that flag and grant it a role on /:

pveum acl modify / --tokens 'root@pam!migrate' --roles Administrator

The target’s migration tunnel checks VM.Allocate on /vms/<vmid> and Sys.Incoming on /, and the API reference adds that further checks run during the migration, which is why I would not build a narrow role for a one-off move. In the GUI the token lives under Datacenter → Permissions → API Tokens. Remove it afterwards with pveum user token delete root@pam migrate.

Read the target’s fingerprint on the target:

openssl x509 -fingerprint -sha256 -noout -in /etc/pve/nodes/$(hostname)/pve-ssl.pem

If you installed a custom or Let’s Encrypt certificate, read /etc/pve/local/pveproxy-ssl.pem instead. Leave fingerprint= out and, with the default certificate, the command stops with fingerprint '<value>' not verified, abort!, which hands you the value.

Run it on the source host

Replace <secret> and <fingerprint> with the target’s values, and pick a target VMID that is free there.

qm remote-migrate 134 205 \
  'apitoken=PVEAPIToken=root@pam!migrate=<secret>,host=192.168.1.20,fingerprint=<fingerprint>' \
  --target-bridge vmbr0 --target-storage local-lvm --online

That moves running VM 134 to become VM 205 on 192.168.1.20, with its disks on local-lvm and its network on vmbr0. Keep the single quotes. Inside double quotes an interactive bash reads the ! as history expansion.

Name the storage. One storage ID sends every disk there, and source:target pairs map each one, as in local-lvm:local-zfs,tank:tank. Onto local-zfs, only a running VM’s attached disks make it; see the table. The special value 1 is refused with remote migration requires explicit storage mapping!; qm(1) still documents 1 as a self-map, and the API refuses it for remote migration. --target-bridge 1 is accepted and keeps each bridge name. Other options: --online for a running VM, --delete 1 to remove the source after a successful move, and --bwlimit in KiB/s.

What it refuses:

• A guest with snapshots: remote migration with snapshots not supported yet. Delete them, or use Method 2.
• An ISO in the CD drive: local cdrom image. Set the drive to “Do not use any media” first.
• An offline disk going between ZFS and anything else: no matching import/export format found for storage. Proxmox staff confirmed on July 3, 2025 that the ZFS plugin only accepts volumes exported from ZFS.

Without --delete 1 the source VM stays stopped and locked afterwards. Proxmox staff gave qm unlock as the way out on December 2, 2024.

Containers take the same endpoint, --target-bridge and --target-storage:

pct remote-migrate 120 220 \
  'apitoken=PVEAPIToken=root@pam!migrate=<secret>,host=192.168.1.20,fingerprint=<fingerprint>' \
  --target-bridge vmbr0 --target-storage local-lvm --restart

--restart shuts the container down, kills it if it is still running after --timeout seconds (180 by default), copies it offline and starts it on the target. Because that copy is offline, a container never moves between ZFS and non-ZFS storage this way. Use Method 2 instead.

New hardware is where a live move bites. A VM with CPU type host can stop on arrival if the new CPU lacks a flag it was started with, and the qm chapter gives live migration between Intel and AMD hosts no guarantee. Move such a VM offline, or switch it to a generic type such as x86-64-v2-AES and restart it before the move.

Method 2: vzdump + qmrestore / pct restore (most reliable)

This route works between any two storage types.

Shut the guest down first. The default snapshot mode backs up a running guest while it keeps running, and stop mode starts a VM again as soon as the backup begins. Either way, anything written after that point stays on the old host.

qm shutdown 777
vzdump 777 --compress zstd --dumpdir /var/lib/vz/dump

For a container, pct shutdown 777 comes first. Continue only after shutdown succeeds, and keep the source guest stopped. The file name carries the guest type, VMID and backup time: vzdump-qemu-777-2026_09_26-07_10_00.vma.zst for a VM, .tar.zst for a container. Replace the example archive paths below with the actual file produced by your backup.

Copy it:

rsync -avP /var/lib/vz/dump/vzdump-qemu-777-2026_09_26-07_10_00.vma.zst root@192.168.1.20:/var/lib/vz/dump/

Restore it on the new host, a VM and then a container:

qmrestore /var/lib/vz/dump/vzdump-qemu-777-2026_09_26-07_10_00.vma.zst 500 --storage local-zfs
pct restore 600 /var/lib/vz/dump/vzdump-lxc-777-2026_09_26-07_10_00.tar.zst --storage local-zfs

Always pass --storage here. Without it, qmrestore allocates each disk on the storage named in the backup, which fails when the new host has no storage by that name. Pick a free VMID, or add --force to overwrite one. --unique gives the guest a new random MAC address: use it only if the old copy will run again on the same network, since a DHCP reservation keyed to the old MAC stops matching.

Restoring from Proxmox Backup Server

If both hosts can reach one PBS datastore, add it on the new host (Datacenter → Storage → Add → Proxmox Backup Server) and restore from its backups. There is no file to copy. Shut the source guest down and take a final PBS backup before restoring, then keep the source stopped. For encrypted backups the new host needs the same key, because without it the backups are inaccessible. A VM can start at once with --live-restore (or the GUI checkbox) while the data copies in the background, but reads stay slow until the data arrives and a failed live-restore leaves the VM in an undefined state. With --live-restore, the downtime is that final backup plus a boot.

Method 3: zfs send and zfs receive (ZFS on both hosts)

The full copy runs while the guest is up; the incremental stream after shutdown contains the changes since the first snapshot. On a default ZFS install the local-zfs storage is the rpool/data dataset. The example uses rpool/data/vm-134-disk-0; check the disk names in /etc/pve/qemu-server/134.conf and substitute your actual volumes. Choose a free target VMID and destination volume names that do not already exist.

Send the full copy with the VM running:

zfs snapshot rpool/data/vm-134-disk-0@move1
zfs send rpool/data/vm-134-disk-0@move1 | ssh root@192.168.1.20 zfs receive rpool/data/vm-205-disk-0

Then shut it down and send only what changed:

qm shutdown 134
zfs snapshot rpool/data/vm-134-disk-0@move2
zfs send -i @move1 rpool/data/vm-134-disk-0@move2 | ssh root@192.168.1.20 zfs receive rpool/data/vm-205-disk-0

Do both sends for every disk in /etc/pve/qemu-server/134.conf, EFI and TPM-state disks included. Finish all full sends before shutdown, and take every final snapshot only after shutdown succeeds. Keep the source stopped. An incremental receive needs the target’s newest snapshot to match the stream’s source. Do not touch the received volume in between.

Copy the config across:

scp /etc/pve/qemu-server/134.conf root@192.168.1.20:/root/134.conf

On the target, put it in place:

cp /root/134.conf /etc/pve/qemu-server/205.conf

Edit 205.conf so each disk line names the new volume, for example scsi0: local-zfs:vm-205-disk-0,size=32G, and start it with qm start 205.

pve-zsync runs the same sends from cron, every 15 minutes by default, and keeps the guest config on the target under /var/lib/pve-zsync/. Version 2.4.0 is the Debian 13 build that Proxmox VE 9 uses. Its wiki page was last edited in December 2020. The tool needs IP addresses rather than host names; the guest restores by the same manual steps as above.

The pitfalls that bite

• ZFS on one side only. A stopped VM, every container and a running VM’s TPM-state disk copy offline, and an offline copy between ZFS and other storage fails. Inside a cluster the same limit reads cannot migrate from storage type 'lvmthin' to 'zfspool'.
• --target-storage 1. Refused for remote migration. Name the storage.
• Bridge naming. The new host needs the bridge the guest uses, or map it with --target-bridge. A VM whose bridge is missing does not start, and the task log names the bridge.
• VMID conflicts. qmrestore and pct restore refuse a VMID that exists unless you add --force.
• Snapshots and ISOs block remote-migrate. Remove them first.

If you are moving guests off a host so you can rebuild it, read the PVE 8 to 9 upgrade gotchas before you reinstall.

Sources

Read September 26, 2026.

• Proxmox qm manual, pct manual, qmrestore manual and vzdump manual, version 9.2.12, September 18, 2026
• Proxmox VE chapters: QEMU/KVM (online migration, CPU type), containers (migration), backup and restore, storage (storage.cfg, PBS encryption), user management (API tokens)
• Proxmox VE API viewer (remote_migrate and mtunnel permissions)
• Proxmox source at git HEAD: QemuMigrate.pm and API2/Qemu.pm (qemu-server), LXC/Migrate.pm (pve-container), Storage.pm and ZFSPoolPlugin.pm (pve-storage)
• More Proxmox source at git HEAD: BTRFSPlugin.pm and RBDPlugin.pm (raw-image formats), Network.pm (missing bridge), LWP.pm (fingerprint check), and the web UI labels in CDEdit.js, dc/Config.js and Utils.js
• Certificates for API and web GUI (pve-ssl.pem, pveproxy-ssl.pem) and the pve-zsync changelog (2.4.0 for Debian 13, June 17, 2025)
• Proxmox VE Roadmap (7.3 on November 22, 2022; 9.2 on May 21, 2026) and the PVE-zsync wiki
• OpenZFS 2.4 zfs-send(8) and zfs-recv(8)
• Proxmox forum, staff replies: source VM locked after remote-migrate (December 2, 2024) and ZFS accepts only ZFS exports (July 3, 2025)