A Proxmox 2 node cluster works, but two nodes can’t form a majority on their own. As soon as one goes down, the other loses quorum and the cluster goes read-only. The fix is a third vote that isn’t a full Proxmox server: a QDevice, where a small service (corosync-qnetd) on a separate device like a Raspberry Pi casts the deciding vote.
I built my two node Proxmox cluster with a Raspberry Pi as the QDevice at the end of 2024 (on Proxmox VE 8.3.2) and ran it at home through 2025 and into 2026. Everything below was checked against the Proxmox VE 9.2 documentation in October 2026, and QDevice setup is still command-line only.
Disclosure: Some links below are Amazon affiliate links, which means that I earn a percentage of each sale at no cost to you. Thank you for your support.
Why a 2-Node Proxmox Cluster Needs a QDevice
Proxmox gives every node one vote, and the cluster only allows changes while a majority of votes are online, which is called quorum. In a Proxmox cluster with 2 nodes, a majority of two votes is two, so losing either node loses quorum.
That’s the whole Proxmox 2 node cluster quorum problem, and a QDevice solves it by adding a third vote without a third Proxmox server. The QDevice only gives its vote to one side at a time, so if the two nodes lose sight of each other, only one ends up with a majority (by default, the one with the lowest node ID).
Proxmox recommends a QDevice for 2-node clusters and discourages one on clusters with an odd number of nodes. On an even cluster there’s no downside, because if the QDevice itself fails, you’re simply back where you’d be without one.
When I set mine up, I tested exactly this by shutting down the second node with the Raspberry Pi in place. The HA panel still showed quorum as OK, but without that third vote, quorum would have been lost and the whole cluster would have been shot.
What Should You Use as a QDevice?
The QDevice can run on just about anything that’s separate from the two nodes. It only has to reach the cluster over the network and install the corosync-qnetd package, so a Raspberry Pi, a mini PC, a VM on a NAS, or a Proxmox Backup Server on its own hardware will all work.
What it cannot be is a VM on one of the two nodes, because it’ll go down with that node and take its vote with it. It also doesn’t need a fast link, as the QDevice talks to the cluster over TCP/IP and isn’t held to corosync’s low-latency requirements (it can even run outside the cluster’s LAN).
I used a Raspberry Pi because it’s one of the cheapest options there is, and something like a Raspberry Pi 3 Model B+ is plenty for this. The corosync-qnetd package exists for both 64-bit and 32-bit Raspberry Pi OS.
Separating the cluster traffic isn’t required, as the QDevice works on a flat network, but Proxmox recommends a dedicated NIC for cluster traffic, and I kept mine separate. I considered adding a second network card to the Pi, but that was really just complicating things, so I put the Pi and both nodes’ cluster traffic on a VLAN of their own. Then I created a UniFi firewall rule that blocked that VLAN from every other local network (matching only new and invalid connections, so SSH replies to my main network still got through).
How to Create a 2-Node Cluster in Proxmox
Before you start, create the Proxmox cluster and stop at two nodes. Both nodes should be on the same version of Proxmox VE with their final hostname and IP, which cannot change once the cluster exists. The joining node cannot hold any VMs or containers, so back those up and restore them under new IDs after it joins. On the first node, select Datacenter, then Cluster, and click Create Cluster, then Join Information and Copy Information. On the second node, use Join Cluster with that information and the first node’s root password.
The steps below follow my video with a couple of corrections.
Step 1: Set Up the QDevice
1. Install Raspberry Pi OS (or any Debian-based OS) on the QDevice with SSH and password logins turned on and a fixed IP address, then open its SSH configuration. You’ll temporarily allow root to log in with a password, which the setup command in Step 2 needs.
sudo nano /etc/ssh/sshd_configAbove the commented-out #PermitRootLogin line, add the line below, as in the screenshot. Save the file, then restart SSH with the last command.
PermitRootLogin yessudo systemctl restart ssh
2. Set a password for the root user.
sudo passwd root3. Install the QNet daemon.
sudo apt update && sudo apt install corosync-qnetd -yThe corosync-qdevice package goes on the Proxmox nodes, not the Pi. The QDevice also needs TCP port 5403 open to the nodes, as that’s the port the QNet daemon listens on.
Step 2: Add the QDevice From the Proxmox Nodes
1. Select each node, open its Shell, and install the QDevice package.
apt update; apt install corosync-qdevice -y2. Check that both nodes are online, then run the command below on one node only, substituting the IP address of your QDevice.
pvecm qdevice setup [IP ADDRESS]Type yes to accept the QDevice’s host key, then enter the root password you set in Step 1. The command copies the cluster’s SSH key to the QDevice, sets up the QNet daemon and copies its certificate to both nodes before finishing with Done. A line saying the certificate database already exists is normal. If it stops with Host key verification failed., run the first command below and try again. If the retry says the certificate store is already initialised, run the second.
pvecm updatecertspvecm qdevice setup [IP ADDRESS] --forceIf it can’t log in at all, check the PermitRootLogin line and the root password.
3. Verify the setup from either node’s shell.
pvecm statusYou’re looking for Expected votes: 3, Total votes: 3, Quorum: 2 and Flags: Quorate Qdevice, with both nodes listed as A,V,NMW and a third row for the Qdevice. That’s exactly what my cluster showed after I ran the setup on Proxmox VE 8.3.2.
If something is off, the flags tell you what. NA means the node can’t reach the QDevice, so check that TCP port 5403 is open. NR means the QDevice isn’t registered on that node, which is what the second node shows below. If a node shows NR, check the QDevice service on it with the command below, and do not move on until both nodes show A,V,NMW.
systemctl status corosync-qdevice
4. Once both nodes show the QDevice, turn password logins for root back off on the QDevice. Open sshd_config again, change the PermitRootLogin line to the one below, and restart SSH.
PermitRootLogin prohibit-passwordsudo systemctl restart sshThe cluster keeps working, because the nodes reach the QDevice over TCP port 5403 with the certificates the setup installed, and SSH was only needed for the setup itself. Security changes over time and nothing here is a guarantee, so keep the QDevice updated.
At this point, the QDevice is the third vote, so if one node goes down, the other keeps quorum and the cluster stays writable. That’s quorum rather than failover, though, as a VM on the failed node only comes back on the other one if you’ve set up high availability.
Running a 2-Node Proxmox Cluster Without a QDevice
A Proxmox 2 node cluster without QDevice support works fine while both nodes are up, and you can still migrate VMs between them. The problem starts when one goes down: the survivor only has one of two votes, so the cluster filesystem (/etc/pve) goes read-only, and you can’t change configuration or start anything through the cluster until quorum is back.
High availability makes that worse. A node that loses quorum can’t reset its watchdog, so if it’s running HA services, it reboots itself after 60 seconds, and one failed node can take the surviving node down with it. That’s why Proxmox’s HA requirements start at three nodes for reliable quorum.
Using pvecm expected 1
If one node is unreachable, the documented workaround is to lower the expected votes, but it is only safe when that node is actually off.
pvecm expected 1This tells corosync that one vote is enough, so the remaining node becomes quorate (pvecm status shows Quorate: Yes) and you can fix or revert the configuration. Proxmox only documents it as a recovery step, and there’s nothing to undo afterwards, as expected votes go back to 2 when the other node rejoins. If that node is still running and just cut off from the network, its guests keep running there, and starting the same VM on this side leaves two copies running, which is the split-brain situation quorum exists to prevent.
Using two_node in Corosync
Corosync has a two_node: 1 option that sets quorum to one vote in the cluster’s corosync config. It also turns on wait_for_all, so after both nodes have been down, the cluster won’t become quorate until both have been online at the same time. The catch is that each node is quorate on its own, so if the link between them breaks while both are running, both think they’re in charge.
Proxmox doesn’t mention two_node anywhere in its cluster or HA documentation. Back in 2016 (Proxmox VE 4.2), its staff warned on the forum that it’s dangerous and can lead to split-brain. Giving one node two votes in corosync (quorum_votes: 2) is one more option, but the cluster then only survives the other node going down. The current documentation recommends a QDevice instead, and for most people, that’s the right call.
Migrating VMs or Configuring High Availability
Once the cluster is built, you can migrate VMs between the nodes with the VM’s Migrate button (live migration is only supported between CPUs from the same vendor) and configure high availability. High availability needs the VM’s disk on both nodes, so you’ll need shared storage or replication, and replication needs local ZFS storage with the same storage ID on both nodes.
When I ran my cluster, I only had two or three services that needed to stay up, so I used VM replication for those. In my video, a replication run after the initial sync took 4.8 seconds. In my setup, if a node went down, the VM would start on the other node after a minute or so (Proxmox puts typical failover at about 2 minutes). Replication runs every 15 minutes by default, so anything written since the last run is lost when a VM fails over.
Please note that HA groups were deprecated in favor of HA node affinity rules in Proxmox VE 9.0, and existing groups are migrated once every node runs 9. The groups in my video were on 8.3.2, so on a current version, you’d use Add under HA Node Affinity Rules in Datacenter, then HA, then Affinity Rules.
Final Thoughts on a 2-Node Proxmox Cluster
Two nodes and a QDevice gave me most of the benefit of a cluster without the cost or complexity of a third node, and for a long time, that was the right balance for me. If you want full high availability, though, you really do want three nodes.
With that said, by June 2026 I’d replaced my cluster with a single mini-ITX server, which idled at around 40 watts against around 200 for the two nodes. My honest take is that most home lab users don’t need a full cluster, and for them, a single Proxmox server is completely fine. If you do build a cluster, shut a node down to test the QDevice before you trust it.
