Proxmox Quorum-Verlust bei 2 von 3 Nodes: Ursachen

Ein Proxmox-Cluster mit drei Nodes und jeweils einer Stimme pro Host sollte den Ausfall eines einzelnen Nodes problemlos überstehen, da zwei von drei Stimmen die absolute Mehrheit bilden. Verlieren die verbleibenden zwei Nodes dennoch das Quorum, sollten Sie aufhören, physische Server zu zählen, und stattdessen prüfen, von wie vielen Wählern Corosync intern ausgeht.

Genau das klärte einen verwirrenden Vorfall im August 2026 auf. Das Setup bestand aus drei physischen Servern, doch das Abschalten eines einzigen Nodes brachte das Quorum zum Einsturz. Die Ursache war ein vergessenes QDevice, das unbemerkt in der Voting-Konfiguration verblieben war. Corosync erwartete vier Stimmen, weshalb zwei überlebende Nodes nicht mehr ausreichten. Die Anzahl physischer Server und die Anzahl stimmberechtigter Instanzen können voneinander abweichen.

Sollten zwei Nodes in einem 3-Node-Proxmox-Cluster das Quorum halten?

Ja. In einem regulären Proxmox VE Cluster mit drei Nodes, bei dem jeder Host eine Stimme hat, behalten zwei verbleibende Nodes das Quorum, da zwei mehr als die Hälfte von drei ist.

Die meisten Administratoren gehen von diesem mentalen Modell aus, und in diesem Fall war die Annahme des Administrators prinzipiell völlig korrekt. Drei physische Server waren sichtbar, jeder scheinbar mit einer Stimme; folglich hätte ein Node ausfallen dürfen, ohne das Quorum zu gefährden. Die sichtbare Oberfläche spiegelte jedoch nicht die gesamte Wahrheit wider.

Quorum zählt Stimmen, nicht Server-Gehäuse im Rack. Corosync verwaltet die erwartete Gesamtstimmenzahl und ermittelt daraus die notwendige Quorum-Schwelle. Befindet sich ein weiterer Teilnehmer in der Abstimmung (selbst wenn der Administrator ihn längst vergessen hat), verändert sich die mathematische Grundlage. So verhält sich ein scheinbarer 3-Node-Cluster plötzlich wie ein System mit 4 Wählern.

Falls Sie sich mit der grundlegenden Architektur vertraut machen möchten, erklären die Mr.PlanB Proxmox Ressourcen, wie Clustering, Storage und Host-Management ineinandergreifen, bevor Sie komplexere HA-Probleme analysieren.

Was zeigte die Ausgabe von pvecm status?

Die grafische Weboberfläche ließ das Problem nicht auf Anhieb erkennen, die Konsolenausgabe von pvecm status hingegen schon. Während alle drei physischen Nodes online waren, meldete der Befehl:

• Nodes: 3
• Expected votes: 4
• Highest expected: 4
• Total votes: 3
• Quorum: 3

Im Abschnitt zur Gruppenmitgliedschaft wurden neben den drei regulären Hosts auch ein QDevice-Eintrag aufgeführt. Damit lag der Widerspruch offen zutage: Drei physische Server, während das Quorum-Subsystem weiterhin gegen vier erwartete Stimmen rechnete.

Das QDevice wurde zwar als nicht registriert geführt, zählte aber weiterhin zur erwarteten Stimmkonfiguration; genau das provozierte ein tückisches Fehlerbild. Bei drei aktiven Hosts verfügte der Cluster über drei Stimmen und erfüllte die Quorum-Anforderung von 3 exakt. Alles wirkte vollkommen gesund. Schaltet man jedoch einen Host ab, verbleiben nur noch 2 Stimmen gegen eine unverändert geforderte Schwelle von 3. Der Cluster verliert sofort sein Quorum.

Wenn das Verhalten eines Clusters nicht zu Ihrer geplanten Topologie passt, sollte pvecm status daher stets Ihr erster Diagnosebefehl sein. Die GUI zeigt Ihnen die sichtbaren Hosts; die Konsolenausgabe verrät Ihnen, woran das Konsens-System tatsächlich glaubt.

Wie kann ein altes QDevice einen 3-Node-Cluster lahmlegen?

Ein QDevice steuert eine externe Hilfsstimme für Quorum-Entscheidungen bei. Es kommt meist dann zum Einsatz, wenn eine gerade Anzahl von Nodes andernfalls bei Netzwerktrennungen in ein unentschiedenes Patt (Split-Brain) geraten könnte. Bewusst eingerichtet ist das ein nützliches Werkzeug. Problematisch wird es, wenn sich die Cluster-Topologie ändert, die Voting-Konfiguration jedoch unverändert bleibt.

Proxmox dokumentiert die QDevice-Unterstützung im Rahmen des Corosync-Quorums. Die Dokumentation zeigt, wie ein QDevice neben den regulären Nodes in pvecm status aufgeführt wird, und erläutert, wie es bei Netzwerk-Partitionen eine entscheidende Stimme abgibt. Gleichzeitig warnt das Handbuch ausdrücklich vor Topologieänderungen: Werden Nodes zu einem Cluster mit QDevice hinzugefügt oder entfernt, muss das QDevice zwingend vorab entfernt und erst danach bei Bedarf neu eingerichtet werden. Der vorliegende Vorfall zeigt exemplarisch, was geschieht, wenn dieser Schritt unterbleibt.

Der Administrator erklärte, die Umgebung sei jahrelang als 2-Node-Cluster betrieben worden, bevor ein dritter Node hinzukam. An die ursprüngliche Einrichtung des fraglichen QDevice konnte sich niemand mehr erinnern; der Diskussionsverlauf klärte nicht mehr abschließend, wann es hinzugefügt worden war. Entscheidend war allein, dass der Eintrag im Wählerverzeichnis aktiv geblieben war.

Verwaiste Konfigurationsreste überdauern häufig das Gedächtnis ihrer Ersteller. Das geschieht besonders schnell im Homelab, wo Hardware ausgetauscht, Nodes umbenannt oder kurzfristige Experimente zur Dauerlösung werden. Eine jahrelang vergessene Einstellung bleibt aktiv, obwohl ihr ursprünglicher Zweck längst entfallen ist.

Warum funktionierte der Cluster fehlerfrei, bis ein Node ausfiel?

Die fehlerhafte Konfiguration richtete zunächst keinen sichtbaren Schaden an. Solange alle drei Server liefen, meldete das System drei Stimmen bei einer Quorum-Schwelle von drei. Die Bedingung war exakt erfüllt, und der Cluster blieb voll handlungsfähig. Im normalen Tagesbetrieb gab es keinerlei Hinweis darauf, dass die Zahl der erwarteten Stimmen um eins höher lag als die Anzahl physischer Server. Der Fehler offenbarte sich erst beim Ausfalltest.

High-Availability-Setups scheitern erstaunlich oft nach diesem Muster: Eine Fehlkonfiguration bleibt unsichtbar, solange jede Komponente reibungslos arbeitet. Der Fehler tritt erst dann zutage, wenn tatsächlich eine Komponente wegbricht und das System auf die vermeintliche Redundanz zurückgreifen muss. In diesem Fall sollte die 3-Node-Architektur den Ausfall eines Hosts auffangen; die verwaiste vierte Stimme entzog dem Cluster diese Fehlertoleranz jedoch völlig lautlos. Auf dem Papier wirkte das System redundant, die Stimm-Arithmetik sprach dagegen.

Aus diesem Grund sind geplante Ausfalltests unverzichtbar: Fahren Sie einen Node gezielt herunter, während die restliche Umgebung stabil läuft, und beobachten Sie das Verhalten. Prüfen Sie, ob die verbleibenden Hosts ihr Quorum behalten, ob HA-Ressourcen wie geplant migrieren und ob Storage sowie Netzwerk intakt bleiben. Solange Sie ein Redundanzkonzept nicht praktisch getestet haben, beruht es auf einer Annahme.

Wie wurde das verwaiste QDevice entfernt?

Der empfohlene Bereinigungsbefehl lautete pvecm qdevice remove. Er lief zunächst nicht vollständig fehlerfrei durch, da das System meldete, dass corosync-qdevice.service nicht geladen sei, und beim Versuch, den Dienst auf einem Host zu stoppen, ein Fehler auftrat. Dennoch sank der Wert für Expected votes unmittelbar von 4 auf 3, was bestätigte, dass die Bereinigung gegriffen hatte.

Mit drei erwarteten Stimmen reduzierte sich die Quorum-Schwelle wie vorgesehen auf zwei. Ein weiterer Forenteilnehmer merkte an, dass bei drei erwarteten Stimmen zwei überlebende Hosts nun vollkommen ausreichen. Der Administrator bestätigte kurz darauf die Lösung und aktualisierte den ursprünglichen Beitrag, um das vergessene QDevice als Fehlerursache festzuhalten. Das Proxmox-Administrationshandbuch beschreibt genau diesen Bereinigungsbefehl für über pvecm konfigurierte QDevices.

Der fehlgeschlagene Servicestopp mahnt dazu, Wartungsbefehle nicht allein anhand ihres Exit-Codes zu beurteilen. Führen Sie nach jeder Modifikation an Cluster-Mitgliedschaft oder Quorum erneut pvecm status aus und verifizieren Sie die entscheidenden Zustände: Haben sich die Expected votes angepasst? Ist das unerwünschte QDevice verschwunden? Ist der Cluster quorat? Wenn diese Werte stimmen, war die Anpassung erfolgreich.

Warum besteht das Proxmox-Quorum so strikt auf Mehrheiten?

Das Quorum verhindert, dass getrennte Teile eines Clusters zeitgleich davon ausgehen, die autoritative Instanz zu sein. Ein ausgefallener Server ist das einfachste Szenario; eine Netzwerk-Partitionierung (Split-Brain) ist das ungleich gefährlichere. Zwei Nodes können beide aktiv laufen und dennoch die Verbindung zueinander verlieren. Aus Sicht jedes einzelnen Hosts lässt sich oft nicht feststellen, ob der Partner ausgefallen ist oder lediglich die Netzwerkverbindung zwischen ihnen unterbrochen wurde. Laufen auf beiden Seiten dieselben virtuellen Maschinen unabhängig weiter, drohen Dateninkonsistenzen und Dateisystembeschädigungen, die weitaus schwerer wiegen als ein vorübergehender Ausfall. Aus diesem Grund agiert das Konsensmodell bewusst konservativ: Ein Cluster-Teil muss zwingend die absolute Mehrheit der Stimmen auf sich vereinen, um den produktiven Betrieb fortzusetzen.

Die Diskussion im Community-Forum verhedderte sich anfangs, weil mehrere Teilnehmer auf die Faustregel verwiesen, dass Cluster mit gerader Knotenzahl zu Pattsituationen neigen. Diese Regel ist zutreffend, traf hier jedoch nicht den Kern. Zwei Nodes stellen in einem korrekt konfigurierten Drei-Stimmen-Cluster eine saubere Mehrheit dar; die unerwartete vierte erwartete Stimme verfälschte die Rechnung. Führen Sie bei Quorum-Problemen daher immer die exakte Arithmetik durch, anstatt sich auf Faustregeln zu verlassen.

Was sollten Sie prüfen, bevor Sie einem Proxmox-Cluster vertrauen?

Dass alle Server im Web-Interface grün angezeigt werden, genügt als Nachweis nicht. Kontrollieren Sie den Stimmstatus immer im regulären Normalbetrieb.

Führen Sie pvecm status aus und prüfen Sie gezielt vier Kennzahlen:

• Expected votes
• Total votes
• Quorum
• Membership information

In einem Basis-Setup mit 3 Nodes, einer Stimme pro Host und ohne QDevice müssen diese Zahlen exakt aufgehen. Wenn Sie drei physische Nodes sehen, Corosync jedoch vier erwartete Stimmen ausweist, identifizieren Sie den vierten Wähler, bevor Sie sich auf den unterbrechungsfreien Betrieb bei einem Node-Ausfall verlassen.

Wiederholen Sie diese Prüfung nach jeder baulichen Änderung am Cluster: Das Hinzufügen oder Entfernen eines Nodes, das Stilllegen eines Witness-Servers, die Neuinstallation eines Hosts oder der Umbau eines 2-Node- in einen 3-Node-Cluster können die mathematischen Annahmen Ihres Quorum-Designs unbemerkt ungültig machen.

Wenn Hochverfügbarkeit den Aufwand wert war, ist sie auch den Test wert. Der Proxmox Health Check von Mr.PlanB unterstützt Sie dabei, den Clusterstatus regelmäßig zu validieren, bevor ein unvorhergesehener Ausfall Sie dazu zwingt.

Die maßgebliche Kennzahl lautet Expected votes

Das Bemerkenswerte an diesem Fall war, dass das theoretische Verständnis des Administrators über 3-Node-Cluster völlig richtig war: Ein Host hätte problemlos ausfallen dürfen. Der Irrtum bestand in der Annahme, dass drei physische Server automatisch drei Wählern entsprechen, während Corosync intern vier Stimmen einforderte.

Diese einzelne Zahl erklärt das gesamte Fehlerbild: Bei vier erwarteten Stimmen lag das Quorum bei 3, sodass nach dem Ausfall eines Servers nur noch 2 Stimmen verblieben. Das Entfernen des veralteten QDevice setzte die erwarteten Stimmen auf drei zurück und stellte die gewünschte Ausfalltoleranz für einen Node wieder her.

Wenn sich ein Proxmox-Cluster nicht so verhält, wie es Ihr Architekturdiagramm vorsieht, prüfen Sie die Stimmentabelle in der Konsole, bevor Sie Hardware oder Netzwerke umbauen. Häufig liegt die Ursache in alten Konfigurationsresten, während die physischen Server vollkommen intakt sind.