How to Rename a Virtual Machine or LXC Container in Proxmox VE

Introduction

You spun up a test VM at 1am, called it test123, and now it's running your Pi-hole. Or maybe you cloned a container and Proxmox tacked -clone onto the end of the name, and it's bugged you every time you look at the resource tree since. Either way, you want to rename it, and the obvious first move — right-clicking the VM hoping for a "Rename" option — doesn't get you very far.

Renaming a VM or an LXC container in Proxmox VE isn't hard once you know where to look, but it trips people up because the "name" you see in the web interface isn't always the same thing as the hostname inside the guest. Get that part wrong and you'll rename the label in Proxmox while the operating system inside keeps calling itself something else entirely.

This guide covers both cases — virtual machines and LXC containers — because they behave differently, and walks through the GUI method, the command-line method, and the handful of things that catch people out.

What You Will Learn

• Where the "Name" field actually lives in the Proxmox VE web interface
• Why renaming a VM doesn't change its internal hostname, but renaming an LXC container usually does
• How to rename both from the GUI and from the shell using qm and pct
• What naming rules Proxmox enforces, and the exact error you'll hit if you break them
• What renaming does not fix — backup job labels, firewall aliases, DNS records, automation scripts
• How to confirm the rename actually took effect

What Is This Feature?

In Proxmox VE, every guest — VM or container — has two identifiers that people tend to confuse: the VMID and the Name.

The VMID is a number, like 101 or 205, assigned when you create the guest. It's permanent. You can't change it later, and a lot of things reference it internally: config files, backup archives, replication jobs. If you want a different VMID, the only real option is cloning the guest to a new one and removing the old.

The Name, on the other hand, is just a human-readable label. It's what shows up in the left-hand resource tree so you don't have to memorize that VM 137 is the one running Nextcloud. Changing it is cosmetic from Proxmox's point of view — but what it actually touches inside the guest depends on whether you're working with a VM or a container, and that's the part worth slowing down for.

A virtual machine (VM) in Proxmox runs on QEMU/KVM and has its own full, independent operating system — its own kernel, its own hostname stored inside its own filesystem. Proxmox's "Name" field for a VM is stored in the VM's configuration file on the Proxmox host (something like /etc/pve/qemu-server/101.conf). It has no connection to whatever hostname the guest OS thinks it has.

An LXC container is different. Containers don't run their own kernel — they share the Proxmox host's kernel and are really just isolated processes with their own filesystem and network namespace. Because of that, Proxmox manages the container's hostname directly, and the "Hostname" field you edit in the container's Options tab genuinely is the container's real hostname, not just a label.

It's also worth knowing that VMIDs are unique across an entire cluster, not just per node. If you have three nodes and VM 101 lives on node pve1, no other node in that cluster can also have a guest numbered 101 — the ID is a cluster-wide reservation, tracked in the shared configuration filesystem. Names have no such restriction. You can have two VMs both named "web-server" on different nodes if you really want to, though for obvious reasons that's a bad idea.

Why Would You Use It?

Most of the time it's simple housekeeping. Homelabbers rename things constantly as a lab evolves — a VM called test-vm becomes plex-server once it's actually doing something useful. Small teams rename VMs after a migration, or after standardizing on a naming scheme (environment-service-number, say, like prod-web-01).

There's also a less obvious reason: clarity during incident response. If your monitoring dashboard or Proxmox's own summary page shows CPU spiking on "VM 214," you want that to read as something meaningful at 2am, not a number you have to look up.

One thing worth being upfront about: renaming won't fix a messy naming scheme by itself if other systems still reference the old name. If you have Ansible inventory files, Terraform state, DNS records, or monitoring configs pointing at the old hostname, you'll need to update those separately — Proxmox has no way to know those exist.

A pretty common real-world case: someone inherits a Proxmox host from a previous admin, or buys a used server that already has a handful of VMs on it, all named things like vm1, vm2, and testbox. Sorting that mess out is usually the very first thing worth doing before touching anything else, since it's a lot easier to reason about backups, firewall rules, and resource allocation once the names actually describe what's running.

Prerequisites

• A running Proxmox VE installation you can log into (this guide applies to Proxmox VE 8.x and 9.x — the rename process hasn't changed between them)
• At least one existing VM or LXC container to practice on
• An account with VM.Config.Options permission on the guest (the root user has this by default; if you're on a shared cluster with restricted users, check with whoever manages permissions)
• SSH or console access to the Proxmox host, only if you want to use the command-line method instead of the GUI

Step-by-Step Tutorial

Renaming a Virtual Machine (GUI)

1. Log into the Proxmox VE web interface.
2. In the left-hand resource tree, click on the VM you want to rename.
3. Open the Options tab.
4. Find the row labeled Name and double-click it (or select it and click Edit).
5. Type the new name and click OK.

That's it — no reboot, no downtime. The change is visible in the resource tree immediately, even if the VM is running.

Renaming a Virtual Machine (Command Line)

SSH into the Proxmox node hosting the VM and run:

qm set 101 --name plex-server

Replace 101 with your actual VMID and plex-server with the new name. Verify it took effect with:

qm config 101 | grep name

Renaming an LXC Container (GUI)

1. Click the container in the resource tree.
2. Open the Options tab.
3. Double-click the Hostname row.
4. Enter the new hostname and confirm.

If the container is running, Proxmox applies the new hostname to it directly. In practice, some running processes and shell sessions inside the container may still show the old hostname until you restart the container — a quick pct reboot <ctid> clears that up if it bothers you.

Renaming an LXC Container (Command Line)

pct set 101 --hostname plex-server

Check it with:

pct config 101 | grep hostname

If the container is running, you can also confirm the live hostname from inside it:

pct exec 101 -- hostname

Commands Explained

Common Errors

The most common one is a naming rule violation. Proxmox requires both VM names and container hostnames to look like valid DNS hostnames: letters, numbers, and hyphens only, and it can't start or end with a hyphen. Spaces, underscores, and most punctuation are rejected. Try to set a name like my server 2 and you'll get something along the lines of:

parameter verification failed for /nodes/pve/qemu/101/config
  name: value does not look like a valid DNS name

Swap the spaces for hyphens (my-server-2) and it'll go through fine.

Another one people run into: trying qm rename as a command. It doesn't exist — there's no dedicated rename subcommand for either qm or pct. Renaming is just a config change, done through set.

If you're on a cluster and get a permission-denied error while a lower-privileged user, that usually means the account is missing VM.Config.Options on that specific guest or pool. That's a permissions problem, not a bug — check the user's role assignment under Datacenter > Permissions.

Troubleshooting

If you changed a VM's name and don't see it update anywhere useful — that's actually expected once you remember the name is Proxmox-only. If you were hoping the OS inside the VM would also pick up the new name, it won't. You have to set that separately, inside the guest: hostnamectl set-hostname new-name on Linux, or the Rename This PC option in Windows settings, followed by a reboot in either case.

If a container's hostname change doesn't seem to have applied inside a running shell session, that's usually a stale session rather than a failed change. Open a fresh pct enter <ctid> session or reboot the container, and it should be current.

On a cluster, if one node still shows the old name in its resource tree, give it a minute — cluster configuration syncs through pmxcfs, the shared cluster filesystem, and there's a brief propagation delay. If it's still stale after a couple of minutes, check that the node is actually part of a healthy quorum (pvecm status) rather than assuming the rename itself failed.

If you've renamed a guest and now a scheduled backup or replication job description in the GUI still shows the old name, that's usually a display caching quirk in the browser rather than a real problem — reload the page. If it persists, check the job under Datacenter > Backup or Replication directly, since those jobs are stored against the VMID and will always resolve to whatever the current name is once the page refreshes properly.

If a Windows VM's name looks wrong in RDP or in your monitoring tool even after you've renamed it both in Proxmox and inside Windows, remember DNS and any local hosts files cache old names too. Flush your DNS resolver cache and check for stale entries in C:\Windows\System32\drivers\etc\hosts or your router's DHCP reservation list.

Best Practices

• Pick a naming scheme before you have thirty VMs, not after. Something like role-service-number (prod-db-01) scales a lot better than naming things after whatever you were thinking about that day.
• Rename the guest OS's actual hostname too, not just the Proxmox label — otherwise you'll have a VM named "plex-server" in the GUI that still answers to "ubuntu-server" over SSH, which is its own kind of confusing.
• Update anything external that hardcodes the old name: DNS records, monitoring dashboards, Ansible inventories, backup job descriptions. Proxmox's rename is local to Proxmox.
• Avoid renaming a VM or container while a backup job targeting it is actively running. It's unlikely to break anything, but there's no reason to introduce the variable.
• Use the Notes field (also on the Options tab) for longer descriptions instead of stuffing detail into the name itself — names get truncated in narrow UI panels, notes don't.

Frequently Asked Questions

Can I rename a VM while it's running?

Yes. Changing the Name field, or the VM's --name config, works whether the VM is running or stopped, with no downtime.

Does renaming change the VMID?

No. The VMID is fixed at creation and can't be changed. If you need a different ID, clone the guest to a new VMID and delete the original.

Will renaming break my backups?

No. Backup jobs in Proxmox reference the VMID, not the name, so a rename doesn't affect existing backup schedules or archives.

Why does my container's hostname show correctly, but my VM's doesn't?

Because a container shares the host's kernel and Proxmox manages its hostname directly, while a VM has its own independent OS that keeps its own hostname completely separate from what Proxmox displays.

I get a "value does not look like a valid DNS name" error — what's wrong?

Your new name has a space, underscore, or other character that isn't allowed. Stick to letters, numbers, and hyphens, and don't start or end with a hyphen.

Can I rename multiple VMs at once?

Not from the web interface — there's no bulk-rename option. If you're dealing with a large cluster, a short script looping qm set over a list of VMIDs is the practical approach.

Does renaming affect firewall rules or IP address assignments?

No. Firewall rules and network configuration are tied to the VMID and the VM's virtual NIC, not its display name. Renaming a guest has zero effect on its networking.

Conclusion

Renaming a VM or container in Proxmox VE takes about ten seconds once you're in the right tab — the part that actually matters is knowing that a VM's name is cosmetic while a container's hostname is real. Get that distinction straight, remember to update the guest OS separately if you care about it matching, and you won't run into surprises later when something still answers to its old name over SSH.