[SOLVED] 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.

 

[vmwombat]

Danke für den richtigen Hinweis mit dem Metrics-Server. Hab den jetzt raus genommen. Hier noch die Infos zu multipath:

root@pve01:~# multipath -ll | head -80
etvmdisk (3600000e00d2c0000002c24a5000d0000) dm-16 FUJITSU,ETERNUS_DXL
size=1.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 10:0:1:13 sdam 66:96 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
`- 10:0:0:13 sdr 65:16 active ready running
etvmdisk3 (3600000e00d2c0000002c24a700130000) dm-99 FUJITSU,ETERNUS_DXL
size=16T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 10:0:4:10 sdbs 68:96 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
`- 10:0:5:10 sdcs 70:0 active ready running
etvmdisk4 (3600000e00d2c0000002c24a500110000) dm-20 FUJITSU,ETERNUS_DXL
size=16T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 10:0:0:17 sdv 65:80 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
`- 10:0:1:17 sdaq 66:160 active ready running
etvmdisk5 (3600000e00d2c0000002c24a500120000) dm-26 FUJITSU,ETERNUS_DXL
size=14T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 10:0:1:18 sdar 66:176 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
`- 10:0:0:18 sdw 65:96 active ready running
etvmdisk6 (3600000e00d2c0000002c24a500130000) dm-28 FUJITSU,ETERNUS_DXL
size=16T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 10:0:0:19 sdx 65:112 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
`- 10:0:1:19 sdas 66:192 active ready running
mpathf (2b66338ab5816cdc66c9ce900b2226a55) dm-82 Nimble,Server
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 10:0:2:109 sdbd 67:112 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
`- 10:0:3:109 sdcd 69:16 active ghost running
mpathj (286cc1631143068c46c9ce900b2226a55) dm-68 Nimble,Server
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 10:0:2:108 sdbc 67:96 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
`- 10:0:3:108 sdcc 69:0 active ghost running
nimvmdisk2 (29cdb6ce6ca1e1f4a6c9ce90048fbad19) dm-4 Nimble,Server
size=5.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 10:0:8:2 sddg 70:224 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
`- 10:0:6:2 sdcv 70:48 active ghost running

root@pve01:~# multipathd show paths format "%d %s %t %T %i"
dev vend/prod/rev dm_st chk_st hcil
sddg Nimble,Server active ready 10:0:8:2
sdr FUJITSU,ETERNUS_DXL active ready 10:0:0:13
sdv FUJITSU,ETERNUS_DXL active ready 10:0:0:17
sdw FUJITSU,ETERNUS_DXL active ready 10:0:0:18
sdx FUJITSU,ETERNUS_DXL active ready 10:0:0:19
sdam FUJITSU,ETERNUS_DXL active ready 10:0:1:13
sdaq FUJITSU,ETERNUS_DXL active ready 10:0:1:17
sdar FUJITSU,ETERNUS_DXL active ready 10:0:1:18
sdas FUJITSU,ETERNUS_DXL active ready 10:0:1:19
sdbc Nimble,Server active ready 10:0:2:108
sdbd Nimble,Server active ready 10:0:2:109
sdcc Nimble,Server active ghost 10:0:3:108
sdcd Nimble,Server active ghost 10:0:3:109
sdbs FUJITSU,ETERNUS_DXL active ready 10:0:4:10
sdcs FUJITSU,ETERNUS_DXL active ready 10:0:5:10
sdcv Nimble,Server active ghost 10:0:6:2
sdhh Nimble,Server undef undef 11:0:7:2
sdhs Nimble,Server undef undef 11:0:8:2
sded FUJITSU,ETERNUS_DXL undef undef 11:0:0:13
sdeh FUJITSU,ETERNUS_DXL undef undef 11:0:0:17
sdei FUJITSU,ETERNUS_DXL undef undef 11:0:0:18
sdej FUJITSU,ETERNUS_DXL undef undef 11:0:0:19
sdey FUJITSU,ETERNUS_DXL undef undef 11:0:1:13
sdfc FUJITSU,ETERNUS_DXL undef undef 11:0:1:17
sdfd FUJITSU,ETERNUS_DXL undef undef 11:0:1:18
sdfe FUJITSU,ETERNUS_DXL undef undef 11:0:1:19
sdga Nimble,Server undef undef 11:0:3:108
sdgb Nimble,Server undef undef 11:0:3:109
sdfq FUJITSU,ETERNUS_DXL undef undef 11:0:2:10
sdgo Nimble,Server undef undef 11:0:5:108
sdgp Nimble,Server undef undef 11:0:5:109
sdhe FUJITSU,ETERNUS_DXL undef undef 11:0:6:10

 

[Bu66as]

@vmwombat,

gut, Metrics-Server raus ist der richtige Schritt. Sind die GUI-Symptome (fehlende VM-Namen, Statistik-Lücken) jetzt weg? Falls ja, war das die Ursache.

Noch offen: 'rz-monitor'

Neben 'pve-monitor' wirft auch rz-monitor alle paar Zyklen 400 Bad Request. Den solltest du ebenfalls in /etc/pve/status.cfg prüfen und fixen oder entfernen — der blockiert pvestatd zwar nicht so hart wie ein Connection Refused, kostet aber trotzdem unnötig Zeit pro Zyklus.

Multipath: Aktive Pfade OK, aber Host 11 ist tot

Die Multipath-Ausgabe zeigt zwei Probleme:

1. Aktive Pfade sind gesund — alle Nimble- und ETERNUS-LUNs haben funktionierende Active/Ghost- bzw. Active/Enabled-Paare über Host 10. Das passt.

2. Host 11 Pfade sind komplett down:

sdhh Nimble,Server       undef  undef  11:0:7:2
sdhs Nimble,Server       undef  undef  11:0:8:2
sded FUJITSU,ETERNUS_DXL undef  undef  11:0:0:13
sdeh FUJITSU,ETERNUS_DXL undef  undef  11:0:0:17
sdei FUJ...

Alle Pfade über HBA Host 11 sind undef/undef — das bedeutet der zweite FC-Port/HBA hat keine funktionierende Verbindung zum SAN-Fabric. Aktuell laufen alle LUNs nur über Host 10 (single path mit ALUA-Fallback). Das ist kein Redundanz-Zustand.

Prüfe:

# FC-Port Status
cat /sys/class/fc_host/host11/port_state

# Alle FC-Ports vergleichen
for h in /sys/class/fc_host/host*; do echo "$(basename $h): state=$(cat $h/port_state) speed=$(cat $h/speed)"; done

# Stale Paths bereinigen (erst nach SAN-Check!)
multipathd show paths format "%d %s %t %T %i %o"

Die massiven SCSI-Fehler im Journal (target port in standby state) kommen von den Nimble Ghost-Pfaden — das ist bei ALUA grundsätzlich normal, aber die Menge deutet darauf hin, dass etwas diese Pfade aggressiv pollt (z.B. Checkmk, Veeam Transport, oder multipath path checker). Sobald Host 11 wieder funktioniert und die Pfade richtig verteilt sind, sollte sich das beruhigen.

Priorität: Zuerst klären ob GUI jetzt stabil ist, dann den FC-Port von Host 11 mit eurem SAN-Team prüfen.

 

[vmwombat]

D

@vmwombat,

gut, Metrics-Server raus ist der richtige Schritt. Sind die GUI-Symptome (fehlende VM-Namen, Statistik-Lücken) jetzt weg? Falls ja, war das die Ursache.

Noch offen: 'rz-monitor'

Neben 'pve-monitor' wirft auch rz-monitor alle paar Zyklen 400 Bad Request. Den solltest du ebenfalls in /etc/pve/status.cfg prüfen und fixen oder entfernen — der blockiert pvestatd zwar nicht so hart wie ein Connection Refused, kostet aber trotzdem unnötig Zeit pro Zyklus.

Multipath: Aktive Pfade OK, aber Host 11 ist tot

Die Multipath-Ausgabe zeigt zwei Probleme:

1. Aktive Pfade sind gesund — alle Nimble- und ETERNUS-LUNs haben funktionierende Active/Ghost- bzw. Active/Enabled-Paare über Host 10. Das passt.

2. Host 11 Pfade sind komplett down:

sdhh Nimble,Server       undef  undef  11:0:7:2
sdhs Nimble,Server       undef  undef  11:0:8:2
sded FUJITSU,ETERNUS_DXL undef  undef  11:0:0:13
sdeh FUJITSU,ETERNUS_DXL undef  undef  11:0:0:17
sdei FUJ...

Alle Pfade über HBA Host 11 sind undef/undef — das bedeutet der zweite FC-Port/HBA hat keine funktionierende Verbindung zum SAN-Fabric. Aktuell laufen alle LUNs nur über Host 10 (single path mit ALUA-Fallback). Das ist kein Redundanz-Zustand.

Prüfe:

# FC-Port Status
cat /sys/class/fc_host/host11/port_state

# Alle FC-Ports vergleichen
for h in /sys/class/fc_host/host*; do echo "$(basename $h): state=$(cat $h/port_state) speed=$(cat $h/speed)"; done

# Stale Paths bereinigen (erst nach SAN-Check!)
multipathd show paths format "%d %s %t %T %i %o"

Die massiven SCSI-Fehler im Journal (target port in standby state) kommen von den Nimble Ghost-Pfaden — das ist bei ALUA grundsätzlich normal, aber die Menge deutet darauf hin, dass etwas diese Pfade aggressiv pollt (z.B. Checkmk, Veeam Transport, oder multipath path checker). Sobald Host 11 wieder funktioniert und die Pfade richtig verteilt sind, sollte sich das beruhigen.

Priorität: Zuerst klären ob GUI jetzt stabil ist, dann den FC-Port von Host 11 mit eurem SAN-Team prüfen.

Guten Morgen und Danke! Host PVE11 hat gar keine FC/Multipath-Anbindung. Aber der fliegt eh demnächst wieder aus dem Cluster raus. Der war nur zu Testzewcken drin. Die GUI ist bzgl. der Statistik-Daten wieder stabil (Ressourcen-Graphen der VMs sind wieder durchgängig) ich beobachte das heute mal. Den zweiten Metrik-Server nehme ich auch noch mal raus und richte den in Ruhe nochmal ein. ICh nutze Grafana zum Monitoring, evtl. kommt der Server am anderen Ende nicht hinterher mit der Annahme des Datenstreams in die InfluxDB.

 

[vmwombat]

Hier war tatsächlich das Forum (in persona Bu66as) schneller als der offizielle Support mit der Analyse und dem richtigen Hinweis. Und ich habe wieder etwas dazu gelernt. Vielen Dank nochmal!