Changing a Proxmox VMID by Hand, No Backup-Restore Required

1:30 a.m., scrolling the VM list on my homelab node, and my hand stops. VMID 100: a test Ubuntu box I killed two months ago, now just a husk. The ones that actually run every day are 118 and 121, with 103 and 107 scattered in between. Nothing is functionally wrong here. A VMID is just an integer — Proxmox uses it to find a config file and a disk. That's it.

But I can't sleep well after looking at that list. I could call it a thing about order. Honestly it's just my personality.

The textbook answer is settled. Back up the VM, delete it, restore it under the VMID you want. Safe, and Proxmox lines everything up for you. The catch is speed. Move a 400GB file server that way and there goes your whole evening. You're pushing the disk across the wire twice to change one number.

So I did it by hand. After a few runs, the concept turned out to be almost disappointingly simple.

The two places Proxmox holds onto a VM

A VM in Proxmox has its name pinned in two places.

One is the config file: /etc/pve/nodes/<nodename>/qemu-server/100.conf. CPU cores, memory, network interfaces, boot order, and the disk references all live there as plain text. The filename itself is the VMID.

The other is the virtual disk. Depending on your storage backend it might be an LVM logical volume, a ZFS volume, or a qcow2 file sitting in a directory — but either way the VMID is baked into the name. vm-100-disk-0, that sort of thing.

So renaming VM 100 to 101 means lining up those two names. Move 100.conf to 101.conf, fix the vm-100-disk-X references inside it to vm-101-disk-X, rename the actual disk or volume to match. Done. Change only one side and the VM can't find its disk. That's the whole thing — but slip up and it won't boot.

The VM must be stopped before you start. Move the conf while it's running and the references pvedaemon is holding get out of sync, which gets messy fast. I've done exactly that once, and I learned something that night.

Start with the config filename

cd /etc/pve/nodes/$(hostname)/qemu-server/
mv 100.conf 101.conf

/etc/pve is a virtual filesystem mounted by pmxcfs, so an mv here propagates across the whole cluster. Worth remembering if you run more than one node.

Renaming the file doesn't rename what's inside it. Open it and the old VMID is still sitting there.

sata0: local-lvm:vm-100-disk-0,size=32G

Change that line to this:

sata0: local-lvm:vm-101-disk-0,size=32G

The interface name varies by setup. It might be sata0, or scsi0, virtio0, ide0. Multiple disks means fixing all of them. Missing one while eyeballing the file is the most common mistake, so I check before moving on:

grep vm-100 101.conf

Nothing comes back, next step.

Second job: this part depends on your storage backend

From here the commands split based on what you're running.

LVM / LVM-Thin

Check the volumes first.

lvs
lvs -a | grep vm-100

The rename is lvrename.

lvrename /dev/pve/vm-100-disk-0 /dev/pve/vm-101-disk-0

Multiple disks, run it once each.

Snapshots make this longer. Take a snapshot on LVM-Thin and you get a separate volume like snap_vm-100-disk-0_snapshot-name. Pull them all up with lvs -a | grep 100 first.

lvrename pve/snap_vm-100-disk-0_snapshot-name pve/snap_vm-101-disk-0_snapshot-name

If the snapshot captured memory state, there's a state volume too.

lvrename pve/vm-100-state-snapshot-name pve/vm-101-state-snapshot-name

Snapshot names differ per environment. There's a reason I'm spending an extra paragraph telling you not to paste these verbatim: get a snapshot volume name wrong and the VM boots perfectly fine, and only blows up the moment you try to roll back. Weeks later. Tracking that down is genuinely annoying.

ZFS

ZFS is easier, actually.

zfs list | grep vm-100
zfs rename rpool/data/vm-100-disk-0 rpool/data/vm-101-disk-0

Adjust if your pool name or dataset path differs — tank/vmdata/... and similar layouts are common. Repeat per disk.

Directory storage (qcow2 / raw)

With directory storage the VMID is also a directory name. Usually /var/lib/vz/images/<VMID>/.

cd /var/lib/vz/images/
mv 100 101
cd 101
mv vm-100-disk-0.qcow2 vm-101-disk-0.qcow2

For raw format, same steps with a .raw extension. The disk name has to match the config file character for character.

Summarized:

Backend	Check	Rename
LVM / LVM-Thin	lvs -a | grep vm-100	lvrename
ZFS	zfs list | grep vm-100	zfs rename
Directory	ls /var/lib/vz/images/100	mv (directory + files)

Rescan and wake the UI up

Once the names line up, tell Proxmox to look again.

qm rescan --vmid 101

Refresh the web UI and 101 usually shows up right there. If not, give the daemons a shake.

systemctl restart pvedaemon
systemctl restart pveproxy

If the list still looks unchanged, nine times out of ten it's browser cache. Try a hard refresh with Ctrl+F5. I once reopened the conf about three times at this stage before figuring out it was the browser. Burned 30 minutes on that.

What I haven't verified

That's the extent of what I've actually run on my homelab. Single node, LVM-Thin and ZFS, VMs with a couple of snapshots.

There are areas I haven't touched. I don't have a Ceph RBD-backed cluster in front of me, so I can't tell you what else is needed after rbd rename. VMs registered as HA resources, backup jobs that target a specific VMID, replication jobs — all of those presumably hold the VMID as a reference key, and I haven't checked what happens to them after a bare rename. On a cluster you'd also want to confirm no other node already owns the number you're moving to.

So if you're doing this in production, take a backup first. Slightly funny that a procedure I started specifically to avoid backup-restore ends with a backup.

Was it worth it

I mentioned this to Jaehyun on my team last week and they said, "Changing that number isn't going to quiet the fans down."

Fair. Sorting VMIDs into the 100s doesn't make a VM faster or draw less power. There is no upside.

But I've spent enough years on the ops side to have watched what a system with mismatched names costs you later. The number in the doc doesn't match the real number, exactly one person knows that, and that person goes on vacation. In a homelab that person is only me, which makes it worse. If future-me SSHes into this node at 3 a.m. and can recall what 121 is within three seconds, I'll call that enough.

Whether that's justification or just compulsion, I still don't know.