How to Change a VM's VMID in Proxmox VE (Renumber a Virtual Machine or Container Safely)

Introduction

Sooner or later you end up with a VM numbered 106 sitting next to a pile of guests numbered 100 through 104, and it bugs you every time you open the resource tree. Maybe you imported it from another node, maybe Proxmox just grabbed the next free ID when you weren't paying attention, or maybe you're trying to keep a naming scheme where VMs live in the 100s and containers live in the 200s. Whatever the reason, you go looking for a way to just change the number — and there isn't one. No right-click option, no field in the Options tab, nothing in qm set.

That's not a bug. The VMID in Proxmox VE is baked into the config file name, the disk image names, and anything else on the host that references that guest, so there's no safe way to swap it in place. The workaround Proxmox actually supports is to create a copy of the guest under the new ID and get rid of the old one — which sounds more disruptive than it is once you've done it a couple of times.

This guide walks through both ways to do that: cloning through the web interface, and the backup-and-restore method for when cloning isn't available (for example, moving a guest to different storage at the same time). We'll cover VMs and LXC containers, since the commands differ slightly between the two.

What You Will Learn

• Why Proxmox VE has no direct "change VMID" button, and what actually references that number behind the scenes
• How to renumber a VM or container using a full clone, including the exact qm clone and pct clone commands
• How to do the same thing with vzdump and qmrestore/pct restore when a clone won't do
• How to find a free VMID before you start, so you don't collide with an existing guest
• What to check before deleting the original, so you don't lose the guest if something goes wrong
• The errors people run into most often, and what each one actually means

What Is This Feature?

Every VM and LXC container in Proxmox VE gets a VMID — a number between 100 and 999999999 — the moment you create it. Proxmox uses that number as the primary key for basically everything related to the guest. The configuration lives at /etc/pve/qemu-server/<vmid>.conf for a VM, or /etc/pve/lxc/<vmid>.conf for a container. Its disks are named things like vm-106-disk-0 on whatever storage you picked. Backups land in /var/lib/vz/dump/ (or your PBS datastore) with the VMID stitched into the filename, like vzdump-qemu-106-2026_07_29-10_15_00.vma.zst.

None of that is editable in place. You can't just rename the config file and expect Proxmox to follow along — the disk references inside the config, the storage layer's own bookkeeping, and the cluster filesystem all still expect that number to match. So "changing a VMID" in Proxmox really means: build a new guest with the new ID that has identical disks and configuration, confirm it works, then remove the original.

There are two supported ways to do that build step. A clone (via qm clone or pct clone) copies the guest directly, live, without needing to shut it down first for the source, and lets you type in the new VMID as part of the command. A backup and restore cycle (via vzdump and then qmrestore or pct restore) does the same thing indirectly — it dumps the guest to an archive, then rebuilds it from that archive under whatever ID you tell it to use. Both end up in the same place; which one you reach for depends on your situation, and we'll cover when each makes more sense.

Why Would You Use It?

The most common reason is organization. If you've been running Proxmox for a while without a plan, you end up with VMs and containers scattered across random IDs with no pattern — 100, 106, 142, 205 — and it gets harder to guess what's what at a glance. A lot of homelab users settle on a scheme like 100-199 for VMs, 200-299 for containers, and 900+ for templates, and renumbering lets you fit existing guests into that scheme instead of starting over.

The second common reason is migration. If you're bringing a VM in from a different Proxmox cluster, or restoring an old backup, there's a decent chance the VMID it arrives with is already taken on your target node. You have to give it a new number one way or another, and it might as well be one that fits your scheme.

Honestly, if you're just starting out with one or two guests, I wouldn't bother — it's not worth the time for a homelab with three VMs. It starts paying off once you've got a dozen-plus guests and the ID list stops making sense at a glance.

Prerequisites

Before you start, make sure you have:

• Shell access to the Proxmox VE host, either through the web interface's Shell button on a node, or over SSH
• Enough free space on the target storage to hold a second full copy of the guest's disks — check this with pvesm status before you commit to anything with a large disk
• A free VMID to move to (more on finding one below)
• A recent backup of the guest, just as a safety net in case something goes sideways during the clone
• A short maintenance window if the guest is a VM you'd rather not clone live, or if you're using the backup/restore method (which does require stopping the source, or at least suspending it)

Step-by-Step Tutorial

First, find a VMID that isn't already in use. Proxmox can tell you the next free one:

pvesh get /cluster/nextid

That returns the lowest unused ID across the whole cluster, which is usually good enough. If you want a specific number instead — say, 205 to fit a container range — just check it's free with qm list and pct list before using it.

Method 1: Clone to a New VMID (the easy way)

This is the method to reach for almost every time. From the GUI, right-click the VM or container in the resource tree and choose Clone. In the dialog that opens:

• Set VM ID to the new number you picked
• Set Name if you want to rename it at the same time
• Set Mode to Full Clone — this is the important one. A linked clone shares disk data with the original through a snapshot, which defeats the whole point if you're planning to delete the original afterward
• Pick the target storage and target node if you're moving it somewhere else while you're at it

From the shell, the equivalent for a VM is:

qm clone 106 205 --full --name my-vm-renamed --storage local-lvm

For an LXC container, the command is pct clone instead, and full clone is specified a little differently:

pct clone 106 205 --full 1 --hostname my-container-renamed --storage local-lvm

Both commands run as a background task — watch it in the GUI's task log, or just wait for the shell prompt to return. For a VM with a 20 GB disk on SSD-backed storage, this usually takes a minute or two. A few-hundred-gigabyte disk on spinning rust will take noticeably longer, since every block gets copied.

Once it finishes, start the new guest (VMID 205 in this example) and check that everything looks right: the OS boots, the network comes up, and any services inside are running. Don't touch the original yet.

Method 2: Backup and Restore (when you need more control)

Sometimes a clone isn't the right tool — maybe you're moving between storage types that don't support the clone operation directly, or you just prefer working from an archive you can keep around. In that case, back up the guest first:

vzdump 106 --mode stop --storage local --compress zstd

The --mode stop flag shuts the guest down for a clean, consistent backup — use snapshot instead if you need it to stay running and your storage supports snapshots. That drops an archive into /var/lib/vz/dump/ (or wherever your backup storage points).

Restore it under the new VMID. For a VM:

qmrestore /var/lib/vz/dump/vzdump-qemu-106-2026_07_29-10_15_00.vma.zst 205 --storage local-lvm

For a container:

pct restore 205 /var/lib/vz/dump/vzdump-lxc-106-2026_07_29-10_15_00.tar.zst --storage local-lvm

Same as with cloning: boot the restored guest, confirm it works, and leave the original alone for now.

Removing the Old VMID

Once you've genuinely verified the new guest — not just that it powered on, but that its actual workload runs correctly — shut down the original and remove it:

qm stop 106
qm destroy 106

For a container, swap in pct stop 106 and pct destroy 106. This deletes the guest's disks along with its configuration, so there's no undo once it's done. That's exactly why you keep the original around, powered off, for a day or two before running this step — if the new one turns out to be missing something, you still have a working fallback.

Commands Explained

Common Errors

"unable to create VM 205 - VM 205 already exists" (or the CT equivalent) means the target ID you picked isn't actually free. Run pvesh get /cluster/nextid again or check qm list / pct list — someone (or some automation) grabbed that number since you last checked.

"unable to create VM 205 - locked (clone)" shows up if a previous clone attempt to that ID got interrupted and left a lock behind. Clear it with qm unlock 205, then check whether a half-finished disk from the failed attempt needs cleaning up first.

"no space left on device" during a full clone almost always means the target storage ran out of room mid-copy. This is the exact scenario pvesm status is there to prevent — check available space against the source disk size before you start, not after it fails halfway through a 200 GB copy.

"permission denied - missing 'VM.Clone' privilege" comes up if you're logged in as anything other than root or a user without the right role assigned. Clone requires the VM.Clone and VM.Allocate permissions on the relevant pool or path.

Troubleshooting

If the clone or restore finishes but the new guest won't boot, start with qm config 205 (or pct config 205) and compare it against the original's config side by side. Full clones normally preserve everything, but it's worth confirming the boot disk and boot order carried over correctly, especially if you changed storage backends during the clone.

If networking looks broken on the new guest, remember that a full clone copies the MAC address as-is. If both the original and the clone are running on the same network segment at the same time, you'll get IP conflicts or ARP weirdness that looks like a networking bug but isn't. Shut the original down before testing the clone's network, or change the clone's MAC address in its Hardware tab if you genuinely need both running simultaneously for a while.

If the task seems to hang at "cloning drive" for a long time, check the Task Log for the actual progress rather than assuming it's frozen — some storage backends (particularly network-backed ones like NFS) are simply slower for full block copies than local SSD, and a stall isn't always a stall.

Best Practices

Pick your VMID ranges early, before you've got thirty guests to sort through — something like 100-199 for VMs, 200-299 for containers, 900-999 for templates works for most homelabs and scales fine into a small cluster.

Do renumbering while disks are still small. A full clone copies every block, so a 10 GB disk takes a couple of minutes and a 500 GB one takes considerably longer. Renumbering a fresh VM costs you nothing; renumbering one that's been running for two years with a bloated disk is a bigger commitment.

Keep the original guest, powered off, for a few days after the switch instead of destroying it immediately. It costs you disk space you were about to delete anyway, and it's the only real rollback path if the new one turns out to be missing a cron job or a mount point you forgot about.

Update anything that still points at the old VMID — backup job selections, HA resource lists, firewall security groups scoped to that guest, and any Ansible or Terraform state referencing the old number. Renumbering the guest itself is the easy part; forgetting to update the backup job that quietly stopped covering it is how people lose data six months later.

Frequently Asked Questions

Can I just rename the config file instead of cloning?
Technically, yes — stop the guest, move /etc/pve/qemu-server/106.conf to 205.conf, rename the disk images to match, and edit the disk lines inside the config. It works, but it's unsupported, and one typo in a disk path leaves you with a guest that won't start. Clone or restore instead unless you're comfortable debugging storage paths by hand.

Does cloning keep my IP address and MAC address?
Yes, a full clone copies the network configuration exactly, MAC address included. Don't run the original and the clone on the same network at the same time, or you'll get address conflicts.

Will my old backups still work after I renumber?
Existing backup archives keep the original VMID in their filename and stay restorable — to that ID or a different one — using qmrestore or pct restore. They won't automatically reappear linked to the new VMID in the GUI's backup list.

Does this work the same way for containers?
Yes. Swap qm commands for pct commands and the process is identical — clone or backup/restore, verify, then destroy the original.

Is there a downside to full clones besides time?
Just temporary disk space — for a short while you'll have two full copies of the guest's disks on your storage. Make sure pvesm status shows enough headroom before you start.

Conclusion

There's no shortcut around the fact that a VMID is permanent once assigned — but cloning to a new one and retiring the old is a five-minute job for most guests, and it's the only method Proxmox actually supports. Pick a free ID, full-clone or backup-and-restore to it, verify the new guest thoroughly, and only then get rid of the original. Do that, and the only real cost is a little disk space and a few minutes of waiting on a copy job.