The server's name: choose it at install time, then leave it alone

You type a name during installation. At that moment it feels unimportant, because a name is usually a label.

Not here. On Proxmox the server's name is an address, and changing it later is a far bigger job than you expect.

Where the name is used

Configuration lives in a folder named after it. The definitions of your machines sit under that folder. Change the name and the definitions stay under the old one.

The history graph files are named after it. Change the name and a new, empty file is opened for the new name. The old data is not deleted, but nobody looks at it any more. What you see in the panel is a server with no past.

In a cluster, members are known by name. Renaming a node is, as far as the cluster is concerned, destroying that node and putting a new one in its place.

Certificates carry the name. Change it and you get a browser warning, and then you go looking for the reason.

That is why renaming is not a cosmetic operation

On a single server it is laborious: configuration has to be moved, services rearranged, the certificate reissued.

In a cluster, what is actually done is not renaming at all: you remove the node from the cluster and rejoin it under the new name. In other words it is the same job as rebuilding it, only under a different label.

In short, the decision you make at install time is the most expensive one to undo later. It is worth five minutes of thought.

When choosing a name

Short and lowercase. Even if you type a long domain name, it is the first part that gets used; writing the rest buys you nothing.

Make it durable. Do not put the role in the name. The machine that is a backup server today may be the main server tomorrow, and you are left with a main server called "backup". The same goes for rack position, customer name, project name: all of those can move, the machine does not.

Meaningful but neutral. Enough to tell two machines apart, not enough to tell a story.

If the graphs went empty

This is where this article earns its keep. The panel works, the machines are up, but the history graphs look empty.

The first place to look is the server's name. If the name and the name the system expects have drifted apart, the graph file is not found where it is looked for and the screen comes back empty. Nothing raises an error, because technically there is no error: the file being looked for does not exist, that is all.

What Atlas does

Behind this article there is a fault in the product itself, and it is worth telling.

In Atlas the server's name was being resolved in five separate places, and three of them carried the same flaw: when the source was momentarily unreachable, the name was invented. A common default was written down and held in memory for the life of the process.

It was measured, and two things came out.

The first: once the invented value was written, the correct name becoming available later did not help, because the memory check sits at the very top. So a momentary hiccup turned into a permanent wrong answer.

The second, and the sneakier one: the consequence of a wrong name was not the same everywhere. The graphs of the guest machines kept working, because those files are addressed by machine number and the name is never validated. The server's own graphs went empty, because the file path contains the name. Server status and the machine list failed too.

So the symptom was mixed: some graphs full, some empty. Nobody looking at a picture like that suspects the name.

The fix came down to three rules. No inventing: if it is unknown, say it is unknown. Only a verified name is held in memory: a value from the fallback path is used but not stored, so the next call tries again. The fallback is the machine's own name, because on Proxmox the two are already the same.

The general lesson

Elsewhere in this wiki we wrote: an empty answer and a failure to get an answer are not the same thing.

The fault here is one grade worse than that: putting a plausible-looking default in the place of something unknown. An empty list is at least odd, and odd things get noticed. An invented name is not odd, it looks perfectly correct, and so nobody looks at it.

And if it then gets stored, a temporary fault becomes a permanent one.

It can be written as a rule: a default is good where it genuinely is the default; where it stands in for the unknown, it is a lie.