Proxmox VE: QDevice Quorum Witness einrichten

In diesem Artikel erfahren Sie, wie Sie einen externen Witness-Host als Corosync Quorum Device (QDevice / QNetd) für einen Proxmox VE Cluster einrichten, um Split-Brain-Zustände bei 2-Node-Setups zuverlässig zu verhindern.

Warum ein externes QDevice für 2-Node-Cluster?

In einem standardmäßigen 2-Node Proxmox VE Cluster verfügt jeder Node über genau 1 Stimme (Vote). Für ein beschlussfähiges Quorum verlangt Corosync immer die absolute Mehrheit der Stimmen (mehr als 50 % aller Gesamtstimmen):

Quorum-Regel im Vergleich

  • 2-Node-Cluster ohne Witness (Gesamt: 2 Stimmen): Es sind 2 von 2 Stimmen (100 %) erforderlich. Fällt 1 Node aus oder bricht die Verbindung ab, verbleibt 1 Stimme (50 %) – das Quorum ist verloren.
  • 2-Node-Cluster mit QDevice (Gesamt: 3 Stimmen): Es sind 2 von 3 Stimmen (66,7 %) erforderlich. Fällt 1 Node aus, halten der verbleibende Node und das QDevice zusammen 2 Stimmen – der Cluster bleibt voll beschlussfähig.

Ohne Quorum treten bei 2-Node-Clustern gravierende Einschränkungen auf:

  • Das Proxmox Cluster-Dateisystem (pmxcfs) wechselt in den schreibgeschützten Read-Only-Modus (/etc/pve ist gelockt).
  • Virtuelle Maschinen und Container können nicht gestartet, migriert oder konfiguriert werden.
  • Proxmox VE HA (High Availability) stoppt die automatische Ausfallsicherung, um Split-Brain-Szenarien und Datenkorruption zu verhindern.
Lösung durch Corosync QDevice / QNetd

Ein QDevice (Corosync Quorum Device) bindet einen externen, schlanken Witness-Server (z. B. eine kleine Linux-VM, ein Raspberry Pi oder ein Server in einem anderen Brandabschnitt) als Schiedsrichter ein. Der Witness stellt die entscheidende 3. Stimme (Vote) bereit, sodass bei Ausfall eines Knotens weiterhin 2 von 3 Stimmen vorhanden sind und der überlebende Node voll funktionsfähig bleibt.

Voraussetzungen & Architekturübersicht

Für die Einrichtung eines externen Quorum-Witness benötigen Sie:

  • Einen bestehenden 2-Node (oder geradzahligen) Proxmox VE Cluster (aktuelle Version Proxmox VE 8.x).
  • Einen externen Linux-Host (Debian 12 Bookworm, Ubuntu 24.04 LTS oder Proxmox Backup Server), der außerhalb der Cluster-Virtualisierung betrieben wird (keine VM, die auf dem Cluster selbst liegt).
  • Netzwerk-Konnektivität zwischen beiden Proxmox-Knoten und dem Witness-Host (TCP-Port 5403 für corosync-qnetd sowie Port 22 für SSH während des Setups).
  • Root-Zugriff auf allen beteiligten Systemen.

Schritt 1: Vorbereitung der Proxmox Cluster-Nodes (Node 1 & Node 2)

Auf beiden Proxmox VE Knoten muss das Paket corosync-qdevice installiert werden. Führen Sie auf Node 1 und Node 2 folgenden Befehl auf der Root-Konsole aus:

# Auf Node 1 und Node 2 ausführen:
apt update && apt install corosync-qdevice

Das Paket enthält den Client-Dienst, der mit dem externen QNet-Dämon kommuniziert und Statusabfragen durchführt.

Schritt 2: Vorbereitung des externen Quorum-Witness (QNetd)

Melden Sie sich nun auf dem externen Witness-Host an. Wechseln Sie in den Root-Kontext und installieren Sie die erforderlichen Pakete corosync-qnetd (der Server-Dienst) und corosync-qdevice:

# Auf dem externen Quorum-Witness-Host ausführen:
sudo su
apt update
apt install corosync-qnetd corosync-qdevice
Praxishinweis zum Ressourcenbedarf

Der corosync-qnetd Dienst ist extrem ressourcensparend. Er benötigt typischerweise weniger als 20 MB Arbeitsspeicher und minimale CPU-Leistung. Auch ein Raspberry Pi oder ein Single-Core VPS eignet sich hervorragend als Witness.

Schritt 3: SSH-Zugriff auf dem Witness-Host konfigurieren

Das Proxmox Cluster-Tool pvecm richtet die TLS-Zertifikate und Kommunikationsschlüssel automatisch per SSH ein. Hierfür benötigt Node 1 temporär die Berechtigung, sich als root mit Passwort am Witness-Host anzumelden.

Öffnen Sie die SSH-Konfigurationsdatei auf dem Witness-Host:

nano /etc/ssh/sshd_config

Prüfen bzw. setzen Sie folgende Parameter:

PermitRootLogin yes
PasswordAuthentication yes

Starten Sie anschließend den SSH-Dienst neu, um die Änderungen zu übernehmen:

systemctl restart sshd
Sicherheitshinweis nach der Ersteinrichtung

Sobald die Kopplung in Schritt 4 abgeschlossen ist, werden für den laufenden Betrieb keine SSH-Verbindungen mehr benötigt. Die laufende Quorum-Abfrage erfolgt ausschließlich über den verschlüsselten Port 5403/tcp. Sie können den SSH-Root-Zugriff auf dem Witness-Host anschließend wieder deaktivieren.

Schritt 4: Initialisierung und Kopplung über Node 1

Wechseln Sie zurück zu Node 1 Ihres Proxmox VE Clusters. Führen Sie den Setup-Befehl aus und übergeben Sie die IP-Adresse des externen Witness-Hosts:

# Auf Node 1 ausführen:
pvecm qdevice setup <IP-VON-QUORUM-DEVICE> -f

Parameter-Erklärung:

  • <IP-VON-QUORUM-DEVICE>: Die erreichbare IP-Adresse oder der FQDN Ihres Witness-Servers.
  • -f (Force): Veranlasst pvecm, die Schlüssel automatisch zu initialisieren, die Zertifikatskette auf dem Witness zu generieren und die Konfiguration clusterweit in /etc/pve/corosync.conf einzutragen.

Während der Ausführung werden Sie nach dem Root-Passwort des Witness-Hosts gefragt. Nach erfolgreicher Authentifizierung verteilt Proxmox VE die Konfiguration automatisch an alle Nodes im Cluster.

Schritt 5: Verifikation & Quorum-Status prüfen

Um zu verifizieren, dass das QDevice korrekt eingebunden wurde und aktiv am Quorum teilnimmt, rufen Sie auf einem beliebigen Cluster-Knoten den Status ab:

pvecm status

Eine erfolgreiche Konfiguration liefert folgende Ausgabe:

Cluster information
-------------------
Name:             pve-cluster
Config Version:   4
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Mon Sep 14 14:30:00 2026
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          1.1a
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2  
Flags:            Quorate Qdevice 

Membership information
----------------------
    Nodeid      Votes    Qdevice Name
0x00000001          1    A,V,NMW 192.168.10.11 (local)
0x00000002          1    A,V,NMW 192.168.10.12
0x00000000          1    A,V,NW  Qdevice
Erfolgs-Indikatoren in der Ausgabe

  • Expected votes: 3 und Total votes: 3: Der Cluster zählt 2 physische Nodes + 1 QDevice-Stimme.
  • Flags: Quorate Qdevice: Das Quorum Device ist aktiv eingebunden.
  • 0x00000000 1 A,V,NW Qdevice: Der Witness antwortet stabil und hält eine gültige Stimme (Vote).

Zusätzlich können Sie den detaillierten Verbindungsstatus des QDevices abfragen:

pvecm qdevice status

QDevice sauber aus dem Cluster entfernen

Soll das QDevice wieder entfernt werden (z. B. vor der Erweiterung auf 3 vollwertige Proxmox-Knoten), führen Sie folgenden Befehl auf einem beliebigen Node aus:

pvecm qdevice remove

Dadurch wird der Eintrag aus corosync.conf entfernt und die Gesamtstimmenanzahl wieder auf die Anzahl der regulären Cluster-Nodes zurückgesetzt.

Häufig gestellte Fragen (FAQ)

Kann ein einzelnes QDevice mehrere Proxmox Cluster gleichzeitig bedienen?
Ja. Der corosync-qnetd Dienst ist multicluster-fähig. Sie können denselben externen Witness-Server als Schiedsrichter für mehrere unabhängige 2-Node Proxmox Cluster nutzen.
Darf das QDevice als VM auf dem Proxmox Cluster selbst laufen?
Nein, hierbei handelt es sich um ein klassisches Henne-Ei-Problem: Fällt der Knoten aus, der die Quorum-VM beherbergt, geht das Quorum verloren und es kommt zu einem kompletten Stillstand. Das QDevice muss daher zwingend auf einer externen Hardware oder einer unabhängigen Infrastruktur betrieben werden.
Was passiert, wenn der Witness-Host offline geht?
Solange beide regulären Proxmox-Nodes (Node 1 & Node 2) online sind, verfügt der Cluster über 2 von 3 Stimmen und bleibt voll quorate. Der Ausfall des QDevices führt nicht zum Cluster-Stopp, sondern wird lediglich als Warning im Monitoring vermerkt.


ProxForge Proxmox Experte

Sie benötigen professionelle Unterstützung bei Ihrem Cluster?

Direkter Experten-Support, Audits und zertifizierte Trainings für Ihr IT-Team.

ProxForge Consulting & Schulungen

Ob akute Disaster-Recovery-Fälle, Performance-Tuning für Ceph & ZFS oder ganzheitliche Enterprise-Audits: Wir unterstützen Systemhäuser und Rechenzentren schnell, praxisnah und lösungsorientiert.