I run a two-node Proxmox cluster at home. When the nodes lose contact, neither can tell whether the other machine is down or still running across a network failure. With one vote each, there is no third vote to resolve the split.
I wanted another vote without buying and maintaining another server. My Mac was already on the same network and running Docker, so I used it to host the external voter.
Using the Mac as a QDevice
Proxmox supports an external vote through Corosync QDevice. A qnetd service runs outside the cluster and can give one side an additional vote. It does not run virtual machines or store cluster data.
I asked an AI agent to inspect the live cluster, configure qnetd in Docker on the Mac, connect both Proxmox nodes, and verify the vote from the cluster itself.
The implementation
The public qnetd image we found was built for Intel processors. The agent instead created a native ARM64 container from Debian's corosync-qnetd package. The daemon runs as an unprivileged user, drops its Linux capabilities, requires certificate-authenticated connections, and stores its certificate database in a persistent Docker volume. Docker Compose records the configuration and restarts the service unless I stop it.
The older Proxmox node also referred to a security package that its mirror no longer carried. The agent retrieved the matching Debian build from the snapshot archive, verified its content hash, and installed it without downgrading another library.
Verifying the vote
After both nodes connected, qnetd reported two clients and one cluster. Each Proxmox node reported three expected and total votes, a quorum threshold of two, and an active QDevice.
I had the agent restart the container while monitoring the cluster. The external vote disappeared during the restart, but the two physical nodes remained quorate with their own votes. Both clients reconnected automatically, the total returned to three, and the certificate volume remained intact.
Limits and remaining work
If one Proxmox server fails and the other can reach the Mac, the remaining server can retain quorum. If the Mac and one server are both unavailable, the remaining server has only one of three expected votes and cannot form quorum alone. The Mac supplies a vote, not compute or storage redundancy.
Docker now opens when I sign in, and the Mac stays awake on AC power. I still need to reserve its current address in DHCP. Until then, an address change could disconnect the QDevice even if the container remains healthy.