So you've got two Proxmox VE boxes sitting on the same network — maybe an old desktop you turned into a test node, and the "real" server you actually run things on — and you need to get a VM from one to the other. You open the docs and everything talks about clusters, shared storage, and qm remote-migrate with API tokens and certificate fingerprints. That's overkill for moving one VM between two machines that have never even heard of each other.
There's a much simpler path, and it's the same one Proxmox admins have used for years before live migration and remote-migrate existed: back the VM up, copy the backup file over, and restore it on the other side. No cluster join, no shared storage, no quorum to worry about. It takes a bit longer than a live migration, and the VM will be offline for a few minutes, but it works between any two Proxmox VE hosts that can reach each other over SSH.
What You Will Learn
By the end of this guide you'll know how to take a full backup of a VM with vzdump, move that backup to a second, completely unrelated Proxmox VE server, and bring the VM back to life there with qmrestore. You'll also see the GUI equivalent of every step, so you're not stuck at a terminal if you'd rather click through it.
Along the way you'll pick up why VMIDs matter, what happens when the destination host doesn't have the same storage or network bridge names as the source, and the handful of errors that trip up almost everyone the first time they try this.
What Is This Feature?
vzdump is the backup utility built into every Proxmox VE install. It reads a VM or LXC container's disks and configuration and writes them out as a single archive file — a .vma.zst for VMs, or a .tar.zst for containers. qmrestore is the other half of the pair: it reads that archive back in and recreates the VM, disks and all, on whatever host you run it on.
Neither command cares whether the source and destination are in a cluster together. vzdump doesn't even know a second host exists — it just produces a file. Where that file ends up afterward is entirely up to you: scp it, drop it on a USB stick, sync it with rsync, whatever gets it from A to B.
This is different from live migration, which needs both nodes in the same cluster with matching storage, and different from qm remote-migrate, which moves a VM directly between two clusters over an API connection without ever writing a backup file to disk. Backup-and-restore is slower and involves downtime, but it's also the most forgiving method — if something goes wrong halfway through, you still have an intact backup file sitting there and nothing on the source VM has been touched.
Why Would You Use It?
Honestly, most homelab setups don't have a cluster, and setting one up just to move a single VM once is a lot of effort for very little payoff. Clustering brings its own baggage — Corosync needs a stable low-latency network link between nodes, and a two-node cluster without a QDevice can lose quorum in ways that catch people off guard. If you're not planning to run HA or live migration long-term, don't bother joining a cluster just for this.
This method also works when the two hosts are on completely different networks, behind different routers, or even at different physical locations, as long as you can get the backup file from one to the other somehow. And it's the same mechanism you'd use to restore a VM from a scheduled backup anyway, so you're not learning a throwaway skill — you're learning the thing you'll also use for disaster recovery.
Prerequisites
Before you start, make sure you have:
- Two Proxmox VE hosts (any reasonably recent 7.x, 8.x, or 9.x install — they don't need to match versions exactly, though staying within the same major version avoids surprises)
- Enough free disk space on the source host's backup storage to hold the archive, and the same again on the destination
- SSH access between the two machines, or some other way to move a large file (a shared NAS, a USB drive, an NFS mount you can point vzdump at directly)
- The VM's ID number (VMID) — you'll see it in the Proxmox web UI next to the VM's name, like 100 (ubuntu-server)
- A rough idea of how big the VM's disks are, so you're not surprised when the backup takes forty minutes instead of four
You don't need root access to both boxes through some shared identity — separate root passwords on each host are completely fine, since you're just using regular SSH or scp between them.
Step-by-Step Tutorial
Step 1: Shut down or note the VM's state
You can back up a running VM using snapshot mode, and most people do exactly that. If the VM has the QEMU Guest Agent installed, Proxmox can briefly freeze the filesystem for a clean, consistent snapshot before it resumes. If it doesn't, the backup still works, it's just the same as if you'd pulled the power cord mid-write — usually fine for a Linux VM with journaling, riskier for anything doing heavy database writes at that exact moment.
If the VM is not doing anything mission-critical, shutting it down first and using stop mode is the safest option and removes any doubt.
Step 2: Back up the VM on the source host
From the source host's shell:
vzdump 100 --storage local --mode snapshot --compress zstdReplace 100 with your VM's actual VMID. This creates a file under /var/lib/vz/dump/ (assuming local storage) named something like vzdump-qemu-100-2026_08_06-14_32_01.vma.zst.
Prefer the GUI? Click the VM, go to Backup in the left menu, and click Backup now. Pick your storage, set the mode to Snapshot, and hit Backup. Same result, no terminal required.
A typical 32 GB VM disk with normal compression takes somewhere around five to fifteen minutes to back up, depending on how much of that space is actually used and how fast your storage is. Empty space compresses to almost nothing, so a mostly-empty 100 GB disk backs up a lot faster than you'd expect.
Step 3: Copy the backup file to the destination host
The straightforward way is scp, run from the source host:
scp /var/lib/vz/dump/vzdump-qemu-100-2026_08_06-14_32_01.vma.zst root@192.168.1.50:/var/lib/vz/dump/Swap in the destination host's actual IP address. For a VM with a 20 GB compressed backup over a gigabit LAN, expect somewhere around three to five minutes — a lot longer over Wi-Fi or the internet, obviously.
You can also upload the file through the web interface: go to the destination host's storage, open the Backups tab, and use the Upload button, if that storage has the "VZDump backup file" content type enabled. For anything over a gigabyte or two I'd stick with scp — browser uploads are more likely to stall or time out on a flaky connection, and there's no resume if it drops partway through.
Step 4: Restore the VM on the destination host
SSH into the destination host and run:
qmrestore /var/lib/vz/dump/vzdump-qemu-100-2026_08_06-14_32_01.vma.zst 100 --storage local-lvmThe 100 here is the VMID you want the restored VM to have on this host — it can be the same as the source or different, whatever's free. The --storage flag tells Proxmox where to put the restored disks; it doesn't have to match the storage name used on the source host at all.
Prefer clicking through it? On the destination host, open the storage where you uploaded or copied the file, click the Backups tab, select the archive, and click Restore. You'll get a dialog asking for the VMID and target storage — fill those in and go.
Step 5: Fix up networking and boot it
Before you power the VM on, click into Hardware and check the network device. If the source host's bridge was named vmbr0 and the destination also has a vmbr0, you're fine. If the destination uses a different bridge name, or has multiple bridges for different VLANs, you'll need to change it here or the VM simply won't have a network device to attach to.
Once that's sorted, start the VM and log in to confirm everything looks right — check that services came up, that the IP address is what you expect, and that any mounted drives are still there.
Commands Explained
| Command | What it does |
|---|---|
vzdump 100 | Backs up the VM with VMID 100 using the default settings from /etc/vzdump.conf |
--storage local | Tells vzdump which storage to write the backup archive to |
--mode snapshot | Backs up the VM while it keeps running, using an LVM or QEMU-level snapshot instead of pausing it |
--compress zstd | Compresses the archive with Zstandard, which is fast and gives good compression ratios — this is the default on current Proxmox VE anyway |
qmrestore <file> <vmid> | Recreates a VM from a backup archive, using the VMID you specify |
--storage local-lvm | Tells qmrestore which storage to place the restored disks on, on the new host |
pct restore | The LXC equivalent of qmrestore — same idea, but for containers instead of VMs |
For containers, the whole process is identical, just swap vzdump's target for the container's VMID and use pct restore <vmid> <file> --storage <storage> on the destination instead of qmrestore.
Common Errors
"unable to restore VM 100 - VM already exists" — the VMID you picked is already in use on the destination host, maybe by a different VM entirely. Pick a free VMID with qmrestore file.vma.zst 105 --storage local-lvm instead, or remove the conflicting VM first if it's actually meant to be replaced.
"no such logical volume" or "storage 'xyz' does not exist" — the backup's config references a storage name from the source host that doesn't exist on the destination. This happens if you don't pass --storage and let qmrestore try to guess. Always specify --storage explicitly and point it at something that actually exists on the new host.
"TASK ERROR: command 'qm start 100' failed" after restoring — nine times out of ten this is the network bridge issue from Step 5. Check Hardware > Network Device and make sure it points at a bridge that actually exists on this host.
scp hangs or drops partway through a large transfer — usually a flaky Wi-Fi link or an aggressive firewall closing idle connections. Running the transfer over a wired connection fixes this most of the time. For very large backups, rsync with -P at least lets you resume instead of starting over.
Troubleshooting
If the VM boots but has no network inside the guest, don't assume it's a Proxmox problem before checking the obvious: does the destination host's bridge actually have a physical NIC attached and a cable plugged in? A bridge that exists but isn't connected to anything will still let the VM boot — it just won't reach anything.
If the restore finishes but the VM won't start with a disk-related error, double check the target storage has enough free space. qmrestore will sometimes get partway through writing a large disk image before hitting an out-of-space error, which leaves a half-written disk behind. Delete the failed VM, free up space, and restore again — don't just retry on top of the broken attempt.
Restoring a backup that was taken with a newer Proxmox VE version onto a much older host can occasionally fail if the VM config uses hardware options the older QEMU version doesn't support yet — things like a newer machine type or CPU flag. If you hit this, open the backup's .vma.zst won't help since it's compressed, but you can extract just the config with vma config file.vma against the uncompressed archive, or more simply, just downgrade the machine type in the VM's Options after restore and try booting again.
Best Practices
Don't delete the source VM until you've actually booted the destination copy and confirmed it works. It sounds obvious, but it's the single most common regret people have with this process — the backup looked fine, the restore said "TASK OK," and then the VM wouldn't come up cleanly for some unrelated reason.
Keep the source VM powered off (or at least disconnected from the network) once you've confirmed the destination is running properly. Two VMs with the same static IP or MAC address fighting over the same network is a genuinely annoying thing to debug, and it's easy to forget you left the old one running in the background.
If you find yourself doing this more than once or twice, it's worth setting up Proxmox Backup Server as a shared backup target both hosts can point at — it deduplicates data between backups and makes repeat restores noticeably faster, since it only needs to pull the chunks that changed. For a one-off move, though, plain vzdump and scp is simpler and doesn't require standing up another service.
Frequently Asked Questions
Do I need to set up a cluster for this to work?
No. This method is specifically for hosts that aren't clustered and don't share storage. If you already have a cluster, live migration or qm remote-migrate will usually be faster and involve less downtime.
How long will the VM be offline?
Just during the restore and boot on the new host — typically a few minutes, depending on disk size. The backup itself can happen while the VM keeps running in snapshot mode, so the actual downtime window is much shorter than the total time the process takes.
Can I do this between different Proxmox VE major versions?
Generally yes going from older to newer — Proxmox VE is good about backward compatibility for VM configs. Going from a newer version down to a much older one is the riskier direction and can occasionally hit compatibility issues with machine types or CPU flags.
Will the VM's IP address change?
Not if it's configured with a static IP inside the guest OS. If it uses DHCP, it'll pick up whatever address the destination network hands out, which may well be different from before.
Does this work for LXC containers too?
Yes, the exact same pattern applies — back up with vzdump, copy the .tar.zst file over, restore with pct restore instead of qmrestore.
Conclusion
Clustering is great once you actually need it — HA, live migration, shared storage across nodes. But needing to move one VM from an old box to a new one isn't a clustering problem, it's a backup-and-restore problem, and Proxmox has had good tools for that since long before remote-migrate existed. vzdump, scp, qmrestore. Three steps, no shared infrastructure required, and you end up with a backup file you can hang onto afterward anyway.
Next time you're staring down a "move this VM to another server" task and dreading the idea of setting up a cluster for it, remember you probably don't have to.