Proxmox Cluster 2 Nodes – How a QDevice Can Improve Quorum Stability

Setting up a Proxmox cluster 2 nodes is common in homelab and production environments for small businesses with limited resources. Whether it’s due to budget limitations, power constraints, or simply a lack of space, adding a third physical node isn’t always feasible, especially for non-enterprise environments.

While a two-node Proxmox server cluster is fully supported in Proxmox VE, it comes with a key limitation: if one node goes offline, the remaining node loses quorum, which can affect replication. This can freeze high-availability (HA) workloads and block cluster operations until the failed node comes back online.

In this post, I’ll explain how to solve that problem using a QDevice — a lightweight third vote that helps maintain quorum without needing a third Proxmox server for three nodes. I’ll also share feedback I received from the r/Proxmox community and document my setup using a Debian 12 VM hosted on a separate ESXi server.

Note: A QDevice isn’t mandatory, but it’s a smart, low-effort way to increase cluster reliability — especially when running HA in a resource-constrained environment.

Why 2-Node Proxmox VE Clusters Can Be Unstable

To understand the limitations of a two-node Proxmox cluster, we need to look at how quorum works. In a Proxmox VE cluster, quorum is managed by Corosync, which communicates over knet secure auth channels between each node. Corosync requires a majority of votes to maintain quorum — which is essential to prevent split-brain situations and data corruption.

Proxmox uses a service called Corosync to manage cluster communication and quorum. In addition to tracking the health of nodes, Corosync also handles distributed locking of configuration files, ensuring that only one node at a time can make changes to the shared cluster state. This prevents conflicts or corruption when multiple nodes try to modify the same resources.

You can read more about how clustering works in the official Proxmox Cluster Manager documentation.

In a cluster with only two nodes, each node holds one vote. That means if one node fails or becomes unreachable, the remaining node has just 50% of the votes — and that’s not enough. As a result, the cluster loses quorum, and the surviving node will:

• Freeze all HA-managed virtual machines
• Block configuration changes in the GUI
• Stop responding to cluster-level operations until quorum is restored

You can work around this temporarily by running:

pvecm expected 1

pvecm expected 1

…on the remaining node. But this is a manual override, not a permanent fix. It also doesn’t survive reboots and opens the door to split-brain if both nodes think they’re active, which can lead to severe data issues.

That said, running a Proxmox cluster with two nodes is still better than managing two completely standalone nodes. Even without quorum redundancy, a cluster setup gives you:

• Shared authentication and user management
• Centralized management of VMs and containers from either node
• The option to use HA, if quorum is addressed properly

In other words, the 2-node setup is a solid foundation — it just needs one more piece to make it reliable: a third vote.

What Is a QDevice and How Does It Help?

A QDevice (Quorum Device) is a lightweight component that adds a third vote to your Proxmox cluster, without requiring a full third node running Proxmox VE.

It doesn’t host virtual machines, manage storage, or run any cluster services beyond participating in quorum decisions. Its only role is to act as a neutral tie-breaker in situations where a node becomes unreachable.

Adding a QDevice helps your two-node cluster maintain stability by ensuring quorum can still be reached when one node goes offline. This is especially important if you’re using High Availability (HA), as it prevents services and VMs from freezing or becoming inaccessible due to quorum loss.

Think of it as a virtual referee: it doesn’t run in the game but helps both players agree on the rules when one goes silent.

You can host the QDevice on nearly any always-on system — such as a VM, NAS, Raspberry Pi, or even a low-power LXC container — as long as it’s physically separate from your two Proxmox nodes and has a reachable static IP.

In the next section, I’ll walk through hosting options and explain why Debian is a safe and stable choice, even though Ubuntu can also work with some adjustments.

Where Can You Run a QDevice?

One of the most significant advantages of using a QDevice is that it doesn’t require a full Proxmox node. Instead, it can run on nearly any low-resource Linux system, as long as it’s reachable from both of your cluster nodes through a network interface and is hosted on separate physical hardware.

Popular and proven options include:

• A Raspberry Pi (ideal for homelabs)
• A Linux VM hosted on another server (e.g. ESXi) -see my comparison Proxmox vs ESXi
• A lightweight NAS appliance that supports running Linux services

A Raspberry Pi 5 is more than capable of running the QDevice service.

iRasptek Basic kit for Raspberry Pi 5 RAM 16GB with Case and Active Cooler

View on Amazon

The QDevice must have a static IP address and be reachable over your LAN on TCP port 5403, which is used by the corosync-qnetd service.

Additionally, all Proxmox nodes in the cluster must be able to communicate with each other over UDP ports 5405–5412, which Corosync uses for internal cluster messaging. These ports are critical for the cluster to maintain synchronization and quorum.

While Ubuntu can work, I recommend Debian 12 because:

• It aligns well with Proxmox’s native environment
• It avoids version or packaging mismatches
• It’s commonly used for QDevice setups in the community

That said, the actual certificate generation and configuration commands are executed on your Proxmox nodes. You don’t need to do anything certificate-related directly on the QDevice itself.

Here is a screenshot with QDevice quorum information. In my case, I run it on Debian 12 on an ESXi VM. You can use the VM for other needs, too. I use it as a Samba file server.

Note: You won’t see the QDevice listed in the Proxmox GUI. It doesn’t appear in the cluster node list, but it plays a critical role in quorum voting. To verify its presence, use pvecm status from the command line.

When one Proxmox node is offline, the cluster still maintains quorum because the QDevice provides the third vote. This is precisely the kind of fault tolerance that makes using a QDevice worthwhile in a two-node cluster.

What the Proxmox Community Says (Reddit Feedback)

Before setting up my own QDevice, I asked the r/Proxmox community about their experience running a Proxmox cluster with 2 nodes and whether a QDevice really makes a difference.

The responses confirmed what the documentation suggests: while not strictly required, adding a QDevice is a widely recommended best practice — even in homelab or small office environments. Users shared their setups, what worked well, and the few pain points to be aware of.

Commonly mentioned pros:

• Quorum stability without needing a third full node
• Works reliably with almost no resource usage
• Easy to host on anything from a Pi to a NAS or an old firewall appliance
• No impact on performance or VM operations
• Prevents quorum loss without compromising live migration or HA

“You don’t really need a minimum of 3 devices. It’s not optional if you want a cluster that doesn’t break itself every time you reboot/shutdown a node.”

“A QDevice is good enough for the 3rd vote. You can run that on an older laptop, Pi, or even a clipped-out old NUC.”

“I use a VM on my NAS — works like a charm.”

Challenges or considerations:

• Requires TCP port 5403 open on the QDevice to allow communication from Proxmox nodes
• Certificate setup can be slightly tricky at first, especially if you’re unfamiliar with Corosync
• Ubuntu-based QDevices may need tweaks — Debian is the safer choice

“Just remember to open port 5403 on your firewall to allow comms from the nodes to the QDevice.”

“Ubuntu didn’t work as easily for me. Switched to Debian 12 and everything just worked.”

Other practical insights:

• Some users run QDevices on firewall boxes or low-end hardware
• A few noted that manual quorum override (pvecm expected 1) works, but still preferred to automate it properly
• One clever user gave their firewall VM two votes, effectively mimicking a QDevice

“What I did was go to the one node that will absolutely always be online… and gave it 2 votes instead of the default 1.”

Overall, the tone of the discussion was clear: you don’t need a powerful third node, but you do need a third vote — and a QDevice is the simplest, most stable way to do that.

You can read the full discussion here on Reddit.
(Thanks to the r/Proxmox community for the helpful responses!)

How to Set Up a QDevice (External Guide)

If you’re ready to set up a QDevice, you’ll be happy to know it’s a lightweight and straightforward process. You don’t need a full third Proxmox node — just a Linux system (I used a Debian 12 VM on an ESXi host) that’s reachable from both cluster nodes.

There are already several well-written guides covering the setup process. Rather than duplicate what’s been done, I recommend following this one:

How to Set Up a QDevice for a Proxmox Cluster – External Guide

Once installed, you’ll run a single command on your Proxmox node to connect the QDevice:

pvecm qdevice setup <ip-address-of-qdevice>

pvecm qdevice setup <ip-address-of-qdevice>

Please ensure that the user root is enabled for SSH. Proxmox will prompt for a password, which is the root password. Afterward, you can disable root access again.

pvecm status

pvecm status

A properly configured QDevice will increase the expected votes from 2 to 3 and ensure quorum is maintained, even if one node goes offline.

Screenshots earlier in this post show exactly what that looks like in action.

The corosync-qnetd service is running on my Debian 12 VM. This lightweight daemon enables the system to act as a QDevice and cast quorum votes for the Proxmox cluster.

What’s Your Setup?

Are you running a 2-node Proxmox cluster too? Did you go with a QDevice, or are you managing quorum another way?

I’d love to hear how you solved it — feel free to share your setup or any lessons learned in the comments. Let’s help each other build more resilient homelabs and small business clusters!

Final Thoughts – Is a QDevice Worth It?

Suppose you’re running a Proxmox cluster with two nodes. In that case, adding a QDevice is one of the smartest things you can do as a backup, especially if you use High Availability (HA) or want to avoid unexpected downtime.

A QDevice doesn’t require a lot of resources, is easy to set up, and gives your cluster the ability to maintain quorum even when one node goes offline. It’s a simple, low-risk solution to a standard limitation in two-node clusters.

TL;DR: Yes — for any 2-node Proxmox cluster, a QDevice is a no-brainer.

To be clear: you can run a two-node Proxmox cluster without a QDevice, and in some homelab environments, that might be enough. But if you care about stability, uptime, or HA, the extra five minutes to configure a QDevice is well worth it.

Whether it’s a Raspberry Pi, a small VM, or even a NAS — if you can dedicate a system with a static IP and Debian (or similar Linux), you’re all set.

I would love to get some feedback from you. Was this article helpful? Please share your opinion with me in the comment section below. Or, if you prefer a more personal touch, feel free to email me directly at info@edywerder.ch. Your thoughts and insights are always appreciated. Additionally, you can connect with me on Reddit at Navigatetech.