Proxmox Cluster Troubleshooting

Proxmox Cluster-Join Troubleshooting

Symptome

Nach einem pvecm add ist der neue Knoten:

• Nicht mehr über die Weboberfläche (Port 8006) erreichbar
• Nicht korrekt im Cluster sichtbar
• Im Journal finden sich Fehler zu /etc/pve/local/pve-ssl.key (private key not found / permission denied)

---

Ursachenanalyse

Häufigste Ursache: Falsche /etc/hosts

Wenn der Hostname vor dem Join auf 127.0.0.1 oder 127.0.1.1 gemappt war statt auf die tatsächliche Management-IP, registriert sich der Knoten mit der falschen Adresse im Cluster. Das ist mit Abstand die häufigste Ursache für fehlgeschlagene Cluster-Joins.

SSL-Zertifikate nicht erreichbar

/etc/pve/local/ ist ein Symlink auf /etc/pve/nodes/<hostname>/. Dieses Verzeichnis wird über pmxcfs bereitgestellt, das wiederum auf einer funktionierenden Corosync-Verbindung basiert. Wenn Corosync nach dem Join nicht richtig connected ist, ist /etc/pve nicht oder nur teilweise zugänglich. Damit fehlen:

• /etc/pve/local/pve-ssl.key – der private SSL-Key
• /etc/pve/local/pve-ssl.pem – das SSL-Zertifikat

Ohne diese Dateien kann der pveproxy-Dienst nicht starten → die Weboberfläche auf Port 8006 ist nicht erreichbar.

Weitere mögliche Ursachen

Ursache	Prüfung
Netzwerk-Interface hat sich geändert	ip addr show – stimmt die IP mit der Corosync-Config überein?
Firewall blockiert Corosync-Ports	UDP 5405–5412 zwischen allen Knoten offen? Prüfen mit ss -ulnp | grep corosync
Hostname stimmt nicht	hostname -f muss mit dem Eintrag in /etc/hosts übereinstimmen
Alte Cluster-Konfiguration vorhanden	Vor einem Join muss der Knoten entweder eine frische Installation sein oder sauber bereinigt werden

---

Reparatur

Voraussetzung: Konsolen-Zugang

Da der Host über die Weboberfläche nicht erreichbar ist, wird direkter Zugang benötigt – entweder über Tastatur/Monitor am Server, über IPMI/iDRAC/iLO, oder falls SSH noch funktioniert.

Schritt 1: pmxcfs im lokalen Modus starten

systemctl stop pve-cluster corosync
pmxcfs -l

Das -l startet pmxcfs im lokalen Modus – also ohne Corosync-Verbindung. Jetzt sollte /etc/pve wieder zugänglich sein.

Schritt 2: /etc/hosts prüfen und korrigieren

cat /etc/hosts

Die Datei muss so aussehen (Beispiel):

127.0.0.1       localhost
192.168.1.50    pve-node3.domain.lan pve-node3

Kritisch: Der Hostname darf nicht auf 127.0.0.1 oder 127.0.1.1 zeigen. Er muss auf die tatsächliche Management-IP zeigen.

Schritt 3: SSL-Zertifikate prüfen

ls -la /etc/pve/local/
ls -la /etc/pve/nodes/$(hostname)/

Falls die Dateien pve-ssl.key und pve-ssl.pem fehlen oder leer sind, müssen sie neu generiert werden:

pvecm updatecerts --force

Danach prüfen ob die Dateien vorhanden sind:

ls -la /etc/pve/local/pve-ssl.key
ls -la /etc/pve/local/pve-ssl.pem

Schritt 4: Kaputten Knoten aus dem Cluster entfernen

Wenn der Knoten halb im Cluster hängt, ist es oft am saubersten, ihn komplett zu entfernen und neu zu joinen.

Auf dem bestehenden Cluster-Knoten den kaputten Knoten entfernen:

pvecm delnode <knotenname>

Auf dem kaputten Knoten den Cluster-Zustand zurücksetzen:

systemctl stop pve-cluster corosync
pmxcfs -l
rm -f /etc/pve/corosync.conf
rm -rf /etc/corosync/*
killall pmxcfs
systemctl start pve-cluster

Schritt 5: SSL-Zertifikate neu generieren

Nach dem Zurücksetzen des Cluster-Zustands die Zertifikate erneuern:

pvecm updatecerts --force

Dienste neu starten:

systemctl restart pveproxy
systemctl restart pvedaemon

Prüfen ob die Weboberfläche wieder lauscht:

ss -tlnp | grep 8006

Optional – Zertifikat-Details prüfen:

openssl x509 -in /etc/pve/local/pve-ssl.pem -noout -subject -dates

Schritt 6: Sauber neu joinen

Erst sicherstellen, dass der Knoten standalone wieder voll funktioniert (Weboberfläche erreichbar auf Port 8006). Dann den Join erneut durchführen:

pvecm add <IP-des-bestehenden-Cluster-Knotens>

Schritt 7: Ergebnis prüfen

# Cluster-Status
pvecm status

# Alle Knoten sichtbar?
pvecm nodes

# Quorum vorhanden?
corosync-quorumtool

# Corosync-Ring gesund?
corosync-cfgtool -s

---

Checkliste: Vor jedem Cluster-Join

Diese Punkte vor dem Ausführen von pvecm add prüfen, um Probleme zu vermeiden:

✓	Prüfpunkt	Kommando
☐	Hostname zeigt in /etc/hosts auf Management-IP, nicht auf 127.0.x.x	cat /etc/hosts
☐	FQDN stimmt mit Hostname überein	hostname -f
☐	Alle Knoten können sich gegenseitig per IP erreichen	ping <IP-des-anderen-Knotens>
☐	UDP 5405–5412 ist zwischen den Knoten offen	ss -ulnp | grep corosync
☐	SSH-Zugang vom neuen Knoten zum bestehenden Cluster funktioniert	ssh root@<Cluster-IP>
☐	Keine alte Cluster-Konfiguration vorhanden	ls /etc/corosync/ sollte leer sein
☐	Knoten hat eine frische Proxmox-Installation oder wurde sauber bereinigt	–
☐	Zeitserver konfiguriert und synchron	timedatectl status
☐	Kein anderes Cluster-Dateisystem gemountet	mount | grep pve

---

Zusammenfassung der relevanten Ports und Dienste

Dienst	Port	Protokoll	Beschreibung
Corosync	5405–5412	UDP	Cluster-Kommunikation (Totem-Ring, Quorum)
pveproxy	8006	TCP (HTTPS)	Proxmox Weboberfläche
SSH	22	TCP	Wird für den Cluster-Join und die Verwaltung benötigt
pvedaemon	85	TCP	Proxmox API-Daemon (intern)
Spice	3128	TCP	VM-Konsole via Spice-Proxy
VNC	5900–5999	TCP	VM-Konsole via VNC
Migration	60000–60050	TCP	Live-Migration von VMs zwischen Knoten

Hinweis: Alle diese Ports müssen zwischen den Cluster-Knoten erreichbar sein. Insbesondere UDP 5405–5412 (Corosync) und TCP 22 (SSH) sind für den Cluster-Join zwingend erforderlich.