How to Change the Hostname in Proxmox VE (The Right Way)

You installed Proxmox VE, picked a hostname on the spot without thinking too hard about it, and now you're stuck with something like pve or proxmox-test showing up in your web interface every time you log in. Maybe you're building out a homelab and want node names that actually mean something, like pve-node1 or hv-rack3. Whatever the reason, you want to change it, and you're about to find out that Proxmox makes this more annoying than it should be.

Here's the short version: Proxmox VE doesn't officially support changing a node's hostname after installation. There's no menu option for it, no wizard, nothing in the web UI. That doesn't mean it's impossible — homelabbers and admins do it all the time — but it does mean you need to understand what's actually tied to that hostname before you start editing files, or you'll end up with a broken web interface and VMs that won't start.

What You Will Learn

• Why Proxmox treats the hostname as something you set once and leave alone
• What breaks if you rename a node carelessly
• The actual step-by-step process for renaming a standalone Proxmox VE node
• Why cluster members need a completely different approach
• How to fix the certificate and web interface errors that show up after a rename
• What to check before you even attempt this

What Is This Feature?

A hostname is just the name a machine uses to identify itself on a network — it's what shows up when you run hostname in a terminal, and it's part of what Proxmox displays in the top-left corner of the web interface. Alongside the hostname, most systems also track a Fully Qualified Domain Name, or FQDN, which is the hostname plus a domain, like pve-node1.home.lan.

On most Linux systems, changing the hostname is a five-second job: edit /etc/hostname, run hostnamectl set-hostname, done. Proxmox complicates this because the hostname isn't just a label. It's baked into the cluster filesystem (pmxcfs), the SSL certificates the web interface uses, the Postfix mail configuration, and — if the node is part of a cluster — the Corosync membership list that keeps every node talking to every other node.

Proxmox uses a special in-memory filesystem called pmxcfs, mounted at /etc/pve, to store cluster-wide configuration and keep it synced across nodes. Inside it, every node gets its own directory under /etc/pve/nodes/, named after its hostname. VM and container configs, storage definitions, and firewall rules all live under that directory. Rename the hostname without touching that directory, and Proxmox has no idea where to find your VMs anymore.

Why Would You Use It?

Most people who go looking for this are in one of two situations. Either they installed Proxmox quickly to test it out, liked it, and now want to give the node a real, permanent name before it becomes part of their actual infrastructure. Or they're standardizing naming across a homelab or small cluster — pve1, pve2, pve3 instead of whatever the installer suggested.

There's also a subtler reason: a clear hostname makes troubleshooting easier. When you're staring at a wall of log entries or SSH'd into three different boxes at once, hostname -f returning hv-rack3-b.lab.internal tells you a lot more than pve does. It sounds cosmetic, but six months into running a homelab you'll appreciate not having three nodes all named some variation of "proxmox."

I'll be upfront about the tradeoff, though: renaming a node that's already running production VMs and is part of a cluster is genuinely risky. If that's your situation, the safer path is almost always to remove the node from the cluster, reinstall it with the new hostname, and rejoin — not to edit files in place. I'll cover both paths below.

Prerequisites

• Root or sudo access to the Proxmox VE host via SSH or the console
• A recent backup of any VMs and containers running on the node — not strictly required for the rename itself, but you want a safety net if something goes sideways
• Physical or out-of-band console access (IPMI, iDRAC, or just being near the machine), in case the web interface breaks and you need to fix it locally
• Knowledge of whether this node is standalone or part of a Proxmox cluster — the steps differ significantly
• About 20-30 minutes, plus a reboot window

Step-by-Step Tutorial

Standalone node (not in a cluster)

This is the common case for homelab users running a single Proxmox box. If you're part of a cluster, skip ahead to the cluster section below — doing this in place on a clustered node will cause problems.

First, check your current hostname and confirm the node has no cluster membership:

hostname -f
pvecm status

If pvecm status returns something like "Error: Corosync config '/etc/pve/corosync.conf' does not exist" or similar, you're standalone and safe to proceed. If it shows cluster members, stop and read the cluster section instead.

Next, edit /etc/hostname and replace the existing name with the new short hostname (no domain, just the name itself — for example pve-node1):

nano /etc/hostname

Now edit /etc/hosts. Look for the line starting with 127.0.1.1 and change the old hostname (and FQDN, if present) to match the new one:

127.0.1.1  pve-node1.home.lan pve-node1

Leave the 127.0.0.1 localhost line alone — that one has nothing to do with your node's hostname. Apply the new hostname to the running system:

hostnamectl set-hostname pve-node1

Now comes the part that actually trips people up: the node's directory inside pmxcfs. Rename it to match:

mv /etc/pve/nodes/oldname /etc/pve/nodes/pve-node1

On most systems this mv works fine because pmxcfs presents itself as a normal filesystem. If it fails or behaves oddly, use cp -a to copy the directory contents to the new name first, confirm everything copied correctly, and only then remove the old directory with rm -rf.

The web interface uses SSL certificates that were generated for the old hostname, so they need to be regenerated:

rm /etc/pve/local/pve-ssl.key /etc/pve/local/pve-ssl.pem
pvecm updatecerts --force

If you use Postfix for email notifications (backup job alerts, for example), update its hostname reference too:

nano /etc/postfix/main.cf

Find the myhostname line and set it to your new FQDN, then restart Postfix:

systemctl restart postfix

Restart the core Proxmox services so they pick up the new name:

systemctl restart pvedaemon pveproxy pvestatd

At this point I'd just reboot the whole box. It's not strictly required, but a handful of services cache the old hostname in memory and a reboot guarantees everything's clean:

reboot

After it comes back up, confirm the change:

hostname -f

Log into the web interface and check that the node listed on the left-hand tree shows the new name, with your VMs and containers still attached underneath it.

Node that's part of a cluster

Proxmox explicitly does not support renaming a node while it's an active cluster member. The Corosync configuration, which keeps nodes talking to each other and maintains quorum, references nodes by name — changing that name out from under a running cluster can knock the node offline or, worse, cause a split in cluster state.

If this node has other cluster members, the safe path is: migrate any VMs off the node, remove it from the cluster with pvecm delnode oldname (run from another node), rename it using the standalone steps above, then rejoin it to the cluster with pvecm add clusterip as if it were a brand new node.

Yes, this means re-adding it from scratch rather than a clean in-place rename. It's more work, but it avoids leaving your cluster in a half-updated state that's much harder to diagnose later.

Commands Explained

Command	What it does
hostname -f	Prints the current fully qualified domain name of the system, useful for confirming a rename actually took effect.
hostnamectl set-hostname NAME	Sets the system's hostname immediately, without needing a reboot, and updates /etc/hostname for you.
pvecm status	Shows whether this node belongs to a Proxmox cluster and, if so, the health of that cluster.
pvecm updatecerts --force	Regenerates the SSL certificates Proxmox uses for its web interface and internal node-to-node communication, forcing new ones even if valid-looking certs already exist.
pvecm delnode NAME	Removes a node from a Proxmox cluster. Run from a different, still-active node — never from the node being removed.
pvecm add IP	Joins the current node to an existing cluster reachable at the given IP address.
systemctl restart pvedaemon pveproxy pvestatd	Restarts the three core Proxmox services responsible for the API backend, the web proxy, and status polling, so they stop using cached references to the old hostname.

Common Errors

"Unable to load access control list: pve-ssl.pem: No such file" — This shows up right after you delete the old certificates but before pvecm updatecerts finishes regenerating them. Just re-run the command; if it still fails, check that /etc/pve is mounted correctly with mount | grep pve.

Web interface shows a certificate warning or won't load at all — Your browser cached the old certificate. Clear it or just open the URL in a private/incognito window to confirm the new certificate is actually being served.

VMs disappear from the web UI after renaming — This almost always means the /etc/pve/nodes/ directory rename didn't fully complete, or you renamed it to something that doesn't exactly match the new hostname (case matters). Double check the directory name against the output of hostname.

"cluster not ready - no quorum?" after a rename on a clustered node — This is the exact scenario the warning above is trying to prevent. Rejoin the node using pvecm add from scratch rather than trying to patch the Corosync config by hand.

Troubleshooting

If the web interface won't come back after a reboot, SSH into the box directly and check the Proxmox services:

systemctl status pveproxy pvedaemon pve-cluster

pve-cluster is the service that runs pmxcfs. If it's failed, the web interface and API will be unreachable no matter what you do to pveproxy — always check pve-cluster first. Look at its logs with journalctl -u pve-cluster -n 50 for the actual error.

If VM configs seem to have vanished, don't panic and don't delete anything. The actual config files usually still exist somewhere under /etc/pve/nodes/ — either under the old name (if the rename didn't complete) or misplaced during a copy. Find them with:

find /etc/pve/nodes/ -name "*.conf"

and move them into the correct qemu-server or lxc subdirectory under the new node name if needed.

Best Practices

• Pick your hostname during installation if you possibly can. It takes thirty seconds at install time and avoids all of this.
• Never rename a node that's actively running production VMs without a maintenance window — plan for at least a short outage.
• Take a full backup of running VMs before you start, using whatever backup storage you've already got configured. If something breaks badly, you want a way back that doesn't involve re-creating VMs by hand.
• Use lowercase hostnames without underscores. Proxmox and the underlying Debian tools are picky about DNS-valid names, and underscores in particular cause weird, hard-to-diagnose issues.
• For clusters, always go through pvecm delnode and pvecm add rather than editing Corosync's config by hand. It's slower, but it's the difference between a clean rejoin and a corrupted cluster state.

Frequently Asked Questions

Can I change the hostname without rebooting?

hostnamectl set-hostname applies immediately, but Proxmox services cache the old name in a few places. A reboot isn't mandatory, but it's the most reliable way to confirm nothing's still referencing the old hostname.

Will renaming break my existing VMs?

The VMs themselves are unaffected — their disks, configs, and settings don't change. What can break is Proxmox's ability to locate them if the /etc/pve/nodes/ directory rename isn't done correctly.

Does the domain part of the FQDN matter if I don't have a real domain?

Not much for a homelab. Something like .home.lan or .local works fine as long as it's consistent across /etc/hosts and any certificates you generate. Just avoid .local if you're also running mDNS/Avahi, since that suffix has special meaning there.

Is there an official Proxmox tool for this?

No. There's no pve-rename-node command or equivalent GUI option. Everything here is the community-tested manual process, which is exactly why taking a backup first matters.

What if I only want to change the domain, not the hostname itself?

Same process, but you only need to touch /etc/hosts and Postfix's main.cf — the short hostname and the /etc/pve/nodes/ directory stay the same, so you can skip the certificate regeneration and directory rename steps entirely.

Conclusion

Renaming a Proxmox VE node isn't hard once you know what actually depends on that hostname — pmxcfs, the web certificates, and Corosync membership on clustered setups. Follow the order above: hostname files first, then the pmxcfs node directory, then certificates, then a restart. Skip the directory rename and you'll spend an hour confused about why your VMs vanished from the UI.

If you're about to spin up a fresh install, save yourself the trouble entirely and pick a real hostname during setup. But if you're already past that point, the steps above will get you there without losing anything, as long as you don't skip the backup.