Why a Two-Node Proxmox Cluster Needs a Third Vote for Quorum

The excitement phase: "I built a cluster, now what?"

There's a moment when everything clicks. You've got two machines, decent specs, maybe a NUC paired with a slightly beefier box, and suddenly you've built a cluster. It feels like leveling up, because you're orchestrating infrastructure instead of just running VMs.

That excitement is real. You start thinking about best practices, redundancy, maybe even high availability. You already know the rule that three nodes is ideal, but two feels close enough, right?

That's where the illusion begins, because what looks like a cluster isn't really behaving like one yet.

The first warning: "You need a third node. Seriously."

The most immediate response cuts through everything: you need a third node to avoid split brain.

It sounds like overkill at first. You've got two machines, so why isn't that enough? Because clustering depends on consensus, and the number of machines alone doesn't give you that.

In Proxmox, quorum decides whether the cluster is allowed to function, and quorum requires a majority. With two nodes, there is no majority if one goes down, just disagreement.

One user reinforces it even harder: a third vote, often via a QDevice, is "basically required." Once it sinks in that the third vote is truly required, the excitement starts to shift into caution.

The lockout scenario: when one node goes down and everything stops

Most people don't expect this part. If you're running a two-node cluster and one node goes offline, even for something harmless like a reboot, the other node can lock you out completely because it can't establish quorum.

Think about that for a second. Your "cluster" becomes unusable because one machine restarted.

The system is doing exactly what it's designed to do: prevent split brain, where two nodes act independently and corrupt shared state. In a homelab, though, it feels brutal. You're not thinking about distributed consensus; you're just trying to keep things running, and suddenly the system is working against you.

The workaround: QDevice and the "fake third node"

This is where the clever workaround comes in: a QDevice.

Instead of adding a full third server, you can add a lightweight vote that participates in quorum without running workloads. It's not a full node, but it tips the balance.

That's why someone casually mentions forgetting to "resetup my qdevice" as if it's a critical piece of the setup, which it is.

With a QDevice, your two-node cluster becomes functionally stable. Without it, you're always one reboot away from confusion. It's the smallest fix with the biggest impact, and somehow it's the one most people learn about too late.

The magic moment: "Wait… I can move running VMs?"

Despite all the warnings, there's a reason people stick with clustering: when it works, it feels incredible.

Live migration is the feature that flips everything. Moving a running VM from one node to another without downtime feels like cheating. One user described it as "truly magical" once you decouple workloads from hardware. Another just says it straight: "Your mind will be blown away." They're not exaggerating.

This is where your homelab stops feeling like a collection of machines and starts feeling like a platform.

The reality check: "Do you actually need a cluster?"

Then comes the uncomfortable question of whether you even need this.

One perspective pulls things back to earth: for most people, clusters in a homelab are about learning more than necessity. Real high availability setups (Ceph, HA, zero-downtime upgrades) are powerful, but they also add complexity fast.

Another user hints at an alternative: managing multiple standalone hosts without clustering, especially if some nodes aren't always online.

So the divide looks like this:

• Clusters for experience and advanced features
• Standalone setups for simplicity and reliability

Depending on your goals, one might make way more sense than the other.

The hidden constraint: your weakest node defines everything

Another subtle detail catches people off guard: your cluster is only as flexible as its weakest hardware. One comment points out that the oldest CPU in your cluster determines what can migrate where.

So your shiny new node doesn't unlock new capabilities if your older node can't support them, and migration compatibility becomes a lowest-common-denominator problem.

It's not a dealbreaker, but it's another reminder that building a cluster means aligning machines as well as adding them.

Clusters solve problems you might not have yet

What makes this whole situation so interesting is how quickly people jump into clustering, and how slowly they realize what it's actually for.

Clusters shine when you need:

• High availability
• Seamless failover
• Zero-downtime maintenance

But if you're just running a few services, those benefits might not outweigh the added complexity.

The thread running through all of this is that a two-node cluster feels like progress, but without quorum, it's fragile. Add a third vote, and it becomes stable. Add shared storage and HA, and it becomes powerful.

Until then, it's a learning experience disguised as infrastructure, and maybe that's exactly what it's supposed to be.