Adding a Server to Proxmox: Cluster, Datacenter, and the Quorum Trap

In the Proxmox interface, Datacenter is the top-level container in the tree — it is not a thing you add servers to. What you actually want is a cluster, and joining a second node to one has a consequence that catches almost everyone: two nodes cannot maintain quorum, so losing either one leaves the survivor read-only.

That is the single most important thing to know before you start, because it is not obvious, it is not prominently warned about, and the moment you discover it is usually the moment one node has already gone down. Here is how the joining works, what quorum actually requires, and what to do if you only have two machines.

Datacenter, cluster, and what you are actually building
Joining a node, step by step
The two-node quorum problem
Fixing quorum with two machines
What to set up after the cluster is working
How this fits the rest of the stack
FAQ

Datacenter, cluster, and what you are actually building

The terminology is worth settling first because the interface encourages the confusion.

Datacenter is the top item in the navigation tree. On a single machine it is just the root of the view. It holds cluster-wide settings — storage definitions, users, permissions, backup jobs — which is why it looks like a container for servers.
Cluster is the actual grouping. Joining nodes into one gives you a single interface managing all of them, shared configuration, and the ability to migrate virtual machines between them.
Node is one physical or virtual Proxmox host.

So there is no add server to datacenter operation. There is create a cluster on one node, then join the others to it, and afterwards Datacenter shows all of them.

It is also worth knowing what a cluster does not automatically give you. Clustering provides unified management, shared configuration and live migration. It does not provide shared storage, and it does not provide automatic failover unless you configure high availability separately. A cluster where each node has only local disks can migrate a stopped VM by copying it, but cannot fail one over instantly.

If all you want is to manage two independent servers from one screen, a cluster does that — but it also couples them, and the quorum consequence below applies whether or not you use any of the other features.

Joining a node, step by step

The mechanics are straightforward. Do them in this order and on a network you trust.

Prerequisites. All nodes on the same Proxmox major version, with clocks synchronised via NTP, unique hostnames, resolvable names on every node, and a low-latency network between them. Corosync is sensitive to latency and jitter — this is a local network protocol, not a WAN one.
Critical: the joining node must have no virtual machines or containers on it. Joining wipes the joining node’s guest configuration. Any existing VMs must be backed up and restored afterwards, or moved beforehand. This is the second most common way to have a bad afternoon with Proxmox.
On the first node, create the cluster: pvecm create <cluster-name>, or Datacenter then Cluster then Create Cluster in the interface.
Copy the join information. In the interface, Join Information gives you a token containing the address and fingerprint. On the command line, note the first node’s IP and its fingerprint.
On the joining node, Datacenter then Cluster then Join Cluster, paste the token, supply the first node’s root password. Or pvecm add <first-node-ip> from the shell.
Verify with pvecm status, which shows the node count and — importantly — whether the cluster has quorum.

The interface may disconnect during the join as certificates are regenerated. Reload the page and log in again; this is expected rather than a failure.

After joining, either node’s web interface manages the whole cluster. That is the visible payoff.

The two-node quorum problem

Corosync, the cluster communication layer, requires a majority of votes to consider the cluster operational. With N nodes, quorum needs more than half.

One node: needs 1 of 1. Fine, but not a cluster.
Two nodes: needs 2 of 2. Losing either leaves 1 vote out of 2, which is not a majority, so the survivor loses quorum.
Three nodes: needs 2 of 3. One can fail and the remaining two carry on.
Four nodes: needs 3 of 4. Still only tolerates one failure — an even count buys you nothing over the odd number below it.

The consequence for a two-node cluster: when one node goes down, the survivor’s cluster filesystem goes read-only. You cannot start virtual machines, change configuration, or in practice do much of anything, on a machine that is otherwise perfectly healthy.

This is not a bug. It is the mechanism that prevents split-brain — two nodes that cannot see each other both deciding they are in charge and both writing to shared storage, which corrupts it. The read-only behaviour is the safety property working as designed.

But it means a naive two-node cluster is less available than two independent servers, which is the opposite of what most people expected when they built it. Worth knowing before rather than after.

Fixing quorum with two machines

There are three real options and one that is a foot-gun.

Add a QDevice. This is the right answer. A third vote comes from a small external machine running corosync-qnetd — a Raspberry Pi, a small VM elsewhere, anything that stays up. It does not run Proxmox and hosts no guests; it only votes. Install corosync-qdevice on both nodes and corosync-qnetd on the third box, then pvecm qdevice setup <ip>. You now have three votes and can lose either real node.

Add a third node. Best if you have the hardware, since it adds capacity as well as a vote.

Do not cluster at all. If the machines do not need shared management or migration, running them independently avoids the whole problem. Two standalone Proxmox hosts are more available than a naive two-node cluster.

The foot-gun: setting two_node: 1 or manually lowering expected_votes so a single node retains quorum. It works, and it disables the protection against split-brain. On shared storage this can genuinely corrupt data when both nodes come back and disagree about what happened. Use it only for a temporary recovery, and undo it immediately afterwards.

For the temporary case — one node is down and you must start a VM on the survivor — pvecm expected 1 lowers the expectation for the current boot only. Do it knowingly, fix the failed node, and let the setting expire.

What to set up after the cluster is working

A cluster on its own is management. These are the things that make it useful.

A dedicated corosync network. Cluster traffic on the same link as storage or VM traffic means a burst of storage I/O can delay heartbeats enough to trigger a false node failure. A separate physical link, or at minimum a separate VLAN, is standard practice.
Shared storage, if you want live migration and high availability. Ceph is built in and works well from three nodes; NFS or iSCSI from an external array is simpler. Without shared storage, migration means copying disks.
High availability groups, if you want automatic restart of VMs elsewhere on node failure. This is a separate configuration from clustering and requires fencing to be working — a node that is unreachable but still running must be forcibly stopped before its VMs restart elsewhere.
Backups to somewhere off-cluster. A cluster protects against a node failing. It does not protect against a mistake, a compromise, or the room the cluster is in.
Monitoring on quorum status, not just on node reachability. Losing quorum is the failure that makes everything else stop working.

And keep versions aligned. A cluster running mixed Proxmox major versions is only supported during an upgrade window; leaving it in that state is asking for behaviour nobody has tested.

How this fits the rest of the stack

A cluster answers hardware failure; it does not answer capacity planning, and it adds quorum, fencing, storage and network design to the list of things you own. The RunxBuild hosting calculator covers the managed alternative across the service, database, storage and bandwidth so the comparison is against a real number. On RunxBuild, services deploy from a repository and autoscale between a floor and ceiling plan you set, with managed Postgres or MySQL alongside — redundancy as a plan setting rather than a third machine to vote.

Useful related references:

FAQ

How do I add a server to a Proxmox datacenter?

Datacenter is the top of the navigation tree rather than something you add servers to. Create a cluster on the first node with pvecm create, then join the second with pvecm add or the Join Cluster dialog using the join token. Afterwards Datacenter shows all nodes.

Do I lose my VMs when joining a Proxmox cluster?

Yes, on the joining node. Joining wipes the joining node’s guest configuration, so it must have no virtual machines or containers on it. Back them up and restore after joining, or move them to the first node beforehand.

Why does my two-node Proxmox cluster stop working when one node fails?

Quorum requires a majority of votes. With two nodes you need both, so losing one leaves the survivor without a majority and its cluster filesystem goes read-only. This prevents split-brain corruption and is working as designed — but it makes a naive two-node cluster less available than two independent servers.

What is a QDevice in Proxmox?

An external tiebreaker that provides a third vote without running Proxmox or hosting guests. Any small always-on machine works. Install corosync-qdevice on both nodes and corosync-qnetd on the third box, then run pvecm qdevice setup. It is the correct fix for a two-node cluster.

Is it safe to set two_node or lower expected_votes?

Only as a temporary recovery measure. It lets a single node keep quorum by disabling the split-brain protection, which on shared storage can corrupt data when both nodes return and disagree. Use pvecm expected 1 for the current boot if you must start a VM during an outage, then fix the failed node.