A Proxmox cluster with two ordinary one-vote nodes needs both votes for a majority. An external QDevice can supply arbitration for a two-node design, but it does not supply VM disks, spare compute capacity or a successful application recovery. Plan those dependencies separately before relying on HA.
This article is a failure-model worksheet, not a cluster creation or QDevice installation recipe. It covers two PVE nodes plus one independent arbitrator, default one-vote nodes, and the intended steady-state majority model. Customized voting rules and transition timing need their own review.
Validation: primary documentation reviewed November 10, 2026. Vote tables are calculated models; no cluster, partition, watchdog event or failover has been run. The HA documentation recommends at least three cluster nodes for reliable quorum. A two-node/QDevice worksheet is not evidence that a particular two-node deployment meets your availability requirement.
Distinguish three things a cluster may provide
| Capability | Question to answer |
|---|---|
| Cluster configuration | Can this partition safely make cluster state changes? |
| Guest placement and disks | Can a permitted node obtain the required data, network and devices? |
| Application recovery | Can the service start correctly and use a sufficiently recent recovery point? |
Centralized management alone does not automatically configure HA. A VM has to be managed through the intended HA workflow, and eligible nodes must meet its dependencies. Use the HA manager documentation for the supported storage, resource and fencing requirements of the selected build.
Calculate the baseline majority
For the simplified model used here:
quorum = floor(expected_votes / 2) + 1
partition is quorate when available_votes >= quorum
With two one-vote nodes and no external vote, expected votes are 2 and the threshold is 2. Powering off node A does not turn node B into a new, independent one-node cluster.
| No QDevice: condition | Votes present in the relevant partition | Model result |
|---|---|---|
| A and B connected | 2 of 2 | Quorate |
| A unavailable; B alone | 1 of 2 | Not quorate |
| A/B communication split | 1 of 2 on each side | Neither side quorate |
The cluster manager manual describes quorum loss and read-only cluster configuration. Do not interpret that as a universal claim that every running guest instantly stops. HA-managed resources have additional watchdog and fencing behavior, which must be tested for the actual deployment.
Place the arbitrator outside the protected failure
In the documented arrangement, the PVE nodes use corosync-qdevice and an
external machine provides corosync-qnetd. Include that machine’s power,
network path and administrative access in the failure diagram.
Hosting the arbitrator only as a VM on node A ties its availability to the node whose loss you are trying to tolerate. A separate machine still needs a dependency review: the same failed switch or power source may remove both the surviving node’s connectivity and the external vote.
The following table assumes the configured third vote can be awarded as indicated and that membership/arbitration has converged:
| Two nodes plus QDevice | Available votes | Quorum outcome |
|---|---|---|
| A and B connected, external vote available | 3 of 3 | Quorate |
| A and B connected, arbitrator unavailable | 2 of 3 | Quorate; another node loss is not covered |
| A unavailable, B receives external vote | 2 of 3 | B’s partition quorate |
| A unavailable, B cannot obtain external vote | 1 of 3 | B not quorate |
| A/B split, external vote awarded to A | A: 2 of 3; B: 1 of 3 | A quorate; B not quorate |
| A/B split, external vote unavailable | 1 of 3 on each side | Neither side quorate |
“The witness is reachable” is not permission to count its vote on both sides. The configured QDevice algorithm and its current decision matter. The Corosync votequorum manual also documents options that alter ordinary quorum behavior; those options are outside this worksheet’s assumptions.
Check whether a quorate survivor can run the VM
Suppose VM 220 ran on A. B and the external vote can form a majority after A fails. Before expecting recovery, answer:
- Are the required VM disks accessible to B through a supported storage design?
- Is the failed instance safely fenced before another instance is started?
- Does B have enough CPU/RAM for the guests selected for recovery?
- Do the same bridges/VLANs and required devices exist on B?
- Do resource eligibility rules permit B, and does the application work there?
A local-only disk on failed A does not appear on B because quorum exists. Shared storage and replication have different failure and recovery-point properties. Check the specific supported design rather than assuming that all storage entries with the same name contain the same data. The storage-type guide explains those boundaries.
For a transparent capacity example, assume B has 32 GiB of installed RAM and you choose an illustrative 8 GiB host/operating reserve. That leaves a 24 GiB planning budget. Two recovery guests allocated 12 and 16 GiB total 28 GiB, exceeding that chosen budget by 4 GiB. These are allocation arithmetic, not measured memory requirements or a universal 8 GiB reserve recommendation.
Record evidence before enabling availability promises
On an authorized lab cluster, these read-only interfaces help collect the configured membership and HA status:
pvecm status
pvecm nodes
ha-manager status
Record actual expected/total votes, quorum threshold, membership and QDevice state on both nodes. Do not paste an invented status output into the runbook. Keep an independent console and the cluster’s recovery plan available before any failure rehearsal.
Start with disposable guests and one fault at a time. For each permitted lab case, record the affected links/nodes, vote observations, fencing evidence, disk access, guest placement, application marker and recovery point. A partition test can deliberately trigger fencing and must not be attempted by casually disconnecting a production network. No failover duration is assumed here.
Do not reduce expected votes as a routine repair or manually start another copy while the original node’s state is unknown. Emergency recovery requires establishing the failed side’s state and following the documented procedure for the installed build. Keep independent VM backups and restores available even when the cluster’s normal recovery mechanisms are unusable.