Cluster & live migration

One node lays down, the others follow

The obvious alternative — let every node change things and resolve contradictions afterwards, younger timestamp wins — presupposes clocks that run alike, loses one of two simultaneous changes silently, and is noticed only when the nodes have drifted apart.

With a primary node that class of fault does not exist: there is exactly one source, and a reconciliation is always one direction and never a negotiation.

Definitions, not gigabytes

What travels the cluster channel is small and descriptive: this storage lies under that path, this network hangs on that bridge, this image comes from that URL. Where a node needs a file it gets it the short way — it is already there because the storage is shared, or it has an address and the node downloads it itself.

Where it has neither, as with an uploaded file, that is reported and nothing is written. An entry pointing at a file that is not there would otherwise only come to light when somebody wanted to build a guest from it.

Two things are deliberately not reconciled: port forwards and fixed addresses. Both point at one guest on one node, and copying them to the others would be wrong rather than helpful.

Trust that does not switch itself off

Nodes speak HTTPS with a self-signed certificate. Simply switching the check off would mean letting everyone on the network join in. Instead the certificate's fingerprint is held on to when the node is entered and compared at every connection afterwards — whoever pushes in between has a different one.

If a node changes its certificate it has to be entered anew. That is on purpose and not an inconvenience.

Shared storage, and the fence that has to be there

A plain filesystem on a LUN mounted by two nodes at once corrupts within seconds, because each caches what is free and neither can see the other. A cluster filesystem is coordinated by a lock manager instead, so several nodes share one LUN safely.

That rests on two pieces, and both are mandatory here: the lock manager with the cluster membership underneath it, and fencing — before a node may take over another's locks, the suspect node is forcibly powered off or resets itself. Without it, a hung but still living node causes split-brain, and split-brain on a shared filesystem means corruption.

So Phillux refuses to format or mount such a storage until quorum and a verified fence device are in place. That gate is not a warning dialogue; it is a refusal.

Moving a running machine

With the shared ground in place, a running VM migrates live from one node to the other and keeps its definition on the target. Its disk does not move — both nodes already see it, which is the whole reason the storage had to be shared first.

What cannot be tested on one machine is real membership with real fence hardware. The guardrails are built to stay fail-safe until that is true, which is a better answer than a feature that works on a demo and not on a Tuesday.