Changing VMID of a VM in Proxmox: Backup/Restore vs Config Edit

Changing VMID of a VM in Proxmox is one of those things that’s easy until it isn’t. The backup/restore method is the sane default, but if you’d rather not wait through a full restore, editing the config manually works too — you just have to know what breaks. Snapshots, symlinks, and a few other things will bite you if you’re not careful.

The safe way: backup and restore

This is the method Proxmox itself recommends, and for good reason. It’s boring and predictable. Back up the VM, delete it, restore it with the new ID. That’s it.

# Backup VM 100 to local storage
vzdump 100 --storage local --mode snapshot

# Delete the VM (after confirming the backup exists!)
qm destroy 100

# Restore as VM 101
qmrestore /var/lib/vz/dump/vzdump-qemu-100-2026_08_15-12_00_00.vma.zst 101

If you’re using Proxmox Backup Server, even better — the restore is faster and you can restore to a different VMID directly from the PBS GUI. But the catch is obvious: for a big VM, the backup and restore takes time and disk space. If you’re just reorganizing your VM numbering and don’t want to shuffle hundreds of gigabytes, there’s another way.

The quick way: edit the config and rename the disks

Proxmox stores VM configs in /etc/pve/qemu-server/ as plain text files named by VMID. The disks live on your storage, usually in a directory named after the VMID too. So changing the ID means renaming both.

1. Stop the VM.
2. Rename the config file: mv /etc/pve/qemu-server/100.conf /etc/pve/qemu-server/101.conf
3. Edit the new config file and update any references to the old ID. This includes the name, any ide/scsi/virtio lines that point to disk images, and any hookscript or args that reference the ID.
4. Rename the disk images on your storage. For directory storage, that means moving the files. For LVM-thin, you’d use lvrename. For ZFS, zfs rename.
5. Update the storage references in the config to point to the new disk names.

Here’s an example for a VM on local ZFS storage:

# Rename the config
mv /etc/pve/qemu-server/100.conf /etc/pve/qemu-server/101.conf

# Rename the ZFS dataset
zfs rename rpool/data/vm-100-disk-0 rpool/data/vm-101-disk-0

# Edit the config: change the scsi line to match
# scsi0: local-zfs:vm-101-disk-0,size=32G

That works, but here’s the part the old forum threads skip: snapshots break. If you have snapshots on the VM, the disk images aren’t just single files — they’re chains. Renaming the base image while snapshots still reference it will leave you with a VM that won’t start or, worse, starts with corrupted data. You’d have to rename every snapshot dataset too, and even then the snapshot metadata inside the config might not match. Honestly, if you have snapshots, just do the backup/restore. It’s not worth the headache.

Also watch out for symlinks. Some storage types (like directory storage with qcow2) use symlinks for disk images, especially if you’ve moved disks around before. Renaming the target file but not the symlink, or vice versa, leads to a VM that can’t find its disk. Check with ls -l before you start renaming things.

Which one should you use?

If the VM is small or you have PBS, backup/restore is a no-brainer. It’s clean, it’s supported, and it’s hard to screw up. If the VM is huge and you’re impatient, the config edit works — but only if you have no snapshots and you’re careful about symlinks. And either way, make a backup first. You’re changing a fundamental identifier; if something goes wrong, you want a way back.

One more thing: if the VM is part of a cluster, the config file lives on the shared filesystem, so the rename will propagate. But the disk rename has to happen on the node where the storage actually lives. If you’re not sure which node that is, check the storage definition before you start moving things around.

If you’re dealing with a VM that has snapshots and you don’t want to lose them, check out the LVM snapshot chain gotcha — it’s a related mess that’s easy to stumble into.