VM Name und Statistic Daten zeitweise nicht verfügbar

[vmwombat]

Hallo zusammen, wir haben hier einen 3-Node Cluster mit CEPH. Alle Nodes sind auf der aktuellen PVE Version pve-manager/8.4.16. Alle Nodes wurden heute nochmal aktualisiert und neugestartet. Trotzdem bleib folgendes Problem.

Seit gestern ca. 15:00 Uhr sehe ich wechselnd bei verschiedensten VMs folgendes:

* VM Name in der GUI ist weg und das Symbol hat ein Fragezeichen (siehe auch Screenshots)
* Die Statistiken der VM haben fehlende Daten über längere Zeiträume
* Der beschriebene Zustand ändert sich ständig und zieht sich über alle drei Knoten hinweg und trifft quasi immer mal andere VMs egal ob die auf CEPH-Storage oder auf FC-SAN liegen
* die Konsole ist zugreifbar
* IP-Adresse via guest-agent wird in der GUI angezeigt
* Es gibt keine Gemeinsamkeiten der betroffenen VMs.
* die VMs selbst laufen zuverlässig
* CLuster und Corosync sind stabil soweit ich das sehe. Wir haben einen redundanten Corosync Ring über zwei versch. Netzwerke.

Ich vermute dass aus irgendeinem Grund die Kommunikation zwischen QEMU und dem pveproxy (der GUI) gestört ist. Ich betreibe den Cluster schon über ein Jahr und hatte diese selstsamen Effekte bisher noch nie. Das Update auf PVE 8.4.16 hatte ich am Freitag gemacht.

Wo kann ich suchen?

Danke!

 

[Bu66as]

Hallo @vmwombat,

das Fragezeichen und fehlende VM-Namen deuten darauf hin, dass pvestatd zeitweise die VM-Konfigurationen nicht lesen kann. Das läuft über pmxcfs (/etc/pve).

Bitte auf allen drei Nodes prüfen:

# pvestatd Status und Logs
systemctl status pvestatd
journalctl -u pvestatd --since "2025-02-24 14:00" | tail -100

# pmxcfs / pve-cluster Logs (das ist meist der eigentliche Übeltäter)
journalctl -u pve-cluster --since "2025-02-24 14:00" | tail -100

# Prüfen ob /etc/pve responsiv ist (wenn langsam = pmxcfs-Problem)
time ls /etc/pve/nodes/

# Corosync-Status
pvecm status

# Allgemeine Systemlast zum Zeitpunkt der Probleme
dmesg | grep -i -E "oom|blocked|hung"

Wenn ls /etc/pve/nodes/ zeitweise hängt oder langsam ist, liegt das Problem bei pmxcfs/Corosync und nicht bei QEMU ↔ pveproxy.

Poste bitte die relevanten Log-Auszüge, dann kann man das eingrenzen.

 

[vmwombat]

Danke @Bua66as

 

[Bu66as]

Die Logs sind eindeutig — pmxcfs und Corosync sind nicht das Problem. ls /etc/pve/nodes/ antwortet in 0.003s, pve-cluster loggt nur normale "received log" und "data verification successful" Meldungen.

Die Ursache sind zwei Dinge:

1. Externer Metrics-Server 'pve-monitor' ist down

Auf allen drei Nodes spammt pvestatd alle 10 Sekunden:

metrics send error 'pve-monitor': failed to send metrics: Connection refused
metrics send error 'rz-monitor': 400 Bad Request

Ihr habt unter Datacenter → Metric Server einen externen Metrics-Empfänger konfiguriert (InfluxDB/Graphite o.ä.) der nicht erreichbar ist. Wenn pvestatd bei jedem Zyklus auf den Timeout wartet, verzögert sich die gesamte Status-Aktualisierung — daher die fehlenden VM-Namen und Statistik-Lücken.

Prüfe auf einem Node:

cat /etc/pve/status.cfg

Dann entweder den Metrics-Server wieder starten oder die Konfiguration vorübergehend entfernen/deaktivieren. Danach auf allen Nodes:

systemctl restart pvestatd

2. Massive FC-SAN SCSI-Fehler (sekundär)

Im Journal von pve01 und pve02 sehe ich hunderte SCSI-Fehler:

Sense Key: Not Ready - Logical unit not accessible, target port in standby state

Das betrifft zahlreiche LUNs (sdce, sdcf, sdcg, sdcu, sdcw, ... auf pve01; sddi, sddj, sdcd, ... auf pve02). Das sind ALUA-Standby-Pfade die Fehler werfen. Das ist zwar bei ALUA mit Passive-Pfaden nicht ungewöhnlich, aber die schiere Menge (alle 10-11 Sekunden) deutet auf ein Multipath-Problem hin — entweder ist ein SAN-Pfad ausgefallen oder die ALUA-Konfiguration stimmt nicht.

Prüfe:

multipath -ll | head -80
multipathd show paths format "%d %s %t %T %i"

Priorität hat Punkt 1 — der unerreichbare Metrics-Server ist mit hoher Wahrscheinlichkeit die direkte Ursache für die GUI-Symptome.