Renaming Hosts #

What any rename of a host has to reckon with, whether it is one host or the estate. A rename is a change: open a change record for it. The 2026-09-05 host rename, CHG-0003, is the worked example, with the phase order that made it survivable.

A hypervisor installed from the Proxmox ISO arrives named pve, and needs Rename a Proxmox Node.

Two hazards nothing guards against #

Both were worked around in the 2026-09-05 rename rather than fixed, and are waiting for the next one.

**Automation never renames a Proxmox VM.** `proxmox_vm` decides existence by name (`selectattr('name', 'equalto', proxmox_vm_name)`), so a renamed host looks new and it attempts a clone onto an occupied VMID. `vm_identity`'s audit fails first, which is the safety net — but clearing it means `qm set --name` by hand. **`git mv` the whole `host_vars//` directory.** Moving only `vars.yml` and leaving `identity.yml` behind makes the allocator treat the host as new: fresh VMID, fresh MAC, duplicate DHCP reservation, orphaned VM. Nothing asserts against this.

What the roles handle, and what they need #

• DNS removes stale names only when asked. opnsense_dns deletes records inventory no longer declares only with dns_delete_unmanaged: true. The default is false, so a rename run with the default leaves every old A record and PTR in place, reported but not removed.
• DHCP reconciles on MAC, which a rename does not change, so reservations update in place. A host deleted from inventory is pruned only with dhcp_delete_unmanaged: true, which also defaults to false.
• dnsmasq and GRUB regenerate cleanly. dnsmasq is a whole-file template, and GRUB configs are keyed by MAC.
• The inventory path has no runtime effect. Nothing on a running host reads it.
• Appliances name themselves. No role sets a device’s own hostname. The switch takes its name from switch_vlans; OPNsense, the AP and the travel router are set by hand in their web UIs.
• A Proxmox node name has no supported rename — see Rename a Proxmox Node.