[SOLVED] PVE 7.3.3 auf TK LESv4 / 3CX VM und OPNsense VM stürzen immer wieder ab

[jsterr]

Hallo Zusammen, die Kollegen auch @wefinet sind dran - 6.2er Kernel ist allerdings nie verkehrt, PVE8 wird ja Mitte Juni wahrscheinlich kommen nach dem Debian Freeze, da wird der 6.2er eh dabei sein, da möchte man eh wissen ob soweit alles klappt. Bisher gabs bei meinen Systemen keine Probleme mit 6.2

Falls alle Stricke reißen finden wir HW-seitig sicherlich eine kulante Lösung.

 

[L_Thomas]

Hallo Jonas,

vielen Dank für deine Antwort.

Ich werde trotzdem einen Schritt nach dem anderen machen, damit ich dann auch sehen kann was den Fehler wirklich behoben hat.

Wenn mit dem Microcode Update alles gut läuft, warum sollte ich dann weitermachen mit Veränderungen?

(Never) change a running system?

Auch in Bezug auf PVE 8.

 

[L_Thomas]

Hallo,

ich habe das Microcode Update jetzt eingespielt:

Vor Microcode Update:
[ 0.190824] SRBDS: Vulnerable: No microcode
[ 1.596567] microcode: sig=0x90661, pf=0x1, revision=0x16
[ 1.596663] microcode: Microcode Update Driver: v2.2.

Nach dem Microcode Update:
[ 0.000000] microcode: microcode updated early to revision 0x17, date = 2022-07-15
[ 0.190433] SRBDS: Vulnerable: No microcode
[ 1.609350] microcode: sig=0x90661, pf=0x1, revision=0x17
[ 1.609422] microcode: Microcode Update Driver: v2.2.

Jetzt heißt es warten...

DANKE AN ALLE!

Thomas

 

[mr44er]

alle Werte stehen auf "Old_age" oder "Pre-fail".

Das allein ist kein Ist-Zustand, sondern als Info/Indikator und auch nur wenn dort jeweils ein Wert stünde. Beispiel klassische Magnetplatte: Defekte und neu zugewiesene Sektoren? Möglicherweise "pre-fail" (eventuell demnächst zum Totalausfall führend), falls der Kopf dort die Schicht abgenagt hat oder war sie nur temporär zu starker Vibration ausgesetzt?
So zumindest mein Verständnis, bitte korrigiert mich.
Was ist aber mit 175 Program_Fail_Count_Chip 0x0032 100 100 000 Old_age Always - 4 ? Finde ich bedenklich für die kurze Laufdauer der SSD...die Tempwerte waren mit 1x 72°C und 1x 75°C ja auch drüber.

Ich drück' jedenfalls mal die Daumen!

Falls alle Stricke reißen finden wir HW-seitig sicherlich eine kulante Lösung.

Mal ein dickes Lob an euch! Zum einen für die schnelle Reaktion, zum anderen weil ihr auf den gängigen Foren vertreten seid.

 

[L_Thomas]

Hallo in die Runde nochmal.

Ich möchte mich nochmal für eure Hilfe in diesem Fall recht herzlich bedanken.

Ohne euch hätte ich es nicht geschafft, dieses Problem zu lösen (ich hoffe es ist gelöst )

Nach dem Microcode Update gab es bislang keine Probleme mehr. Ich hoffe das bleibt so!

Vielen Dank an Alle und Alles Gute!

Thomas

 

[sherminator]

Was ist aber mit 175 Program_Fail_Count_Chip 0x0032 100 100 000 Old_age Always - 4 ? Finde ich bedenklich für die kurze Laufdauer der SSD...

Das steht auf allen SSDs, die ich gerade stichprobenartig angeschaut habe, auf genau diesen Werten. Laut Thomas Krenn ist das der Startwert, stellt also kein Problem dar. Das Beispiel illustriert gut, was ich sagen wollte: Die Interpretation der SMART-Werte (bei SSDs) kann schwierig und von Fall zu Fall unterschiedlich sein.

 

[sherminator]

Nach dem Microcode Update gab es bislang keine Probleme mehr. Ich hoffe das bleibt so!

Yeah, das sind gute Neuigkeiten! Ich drück' ebenfalls die Daumen, dass das so bleibt.

Wenn mit dem Microcode Update alles gut läuft, warum sollte ich dann weitermachen mit Veränderungen?

(Never) change a running system?

Auch in Bezug auf PVE 8.

Ein Update auf PVE 8 ist auch dann ratsam und empfohlen, wenn es gerade keine Probleme zu lösen gibt. Vielleicht nicht gleich am ersten Tag, aber so im Laufe der 2-3 Monate nach Erscheinen werden wir unseren PVE-Cluster sicherlich upgraden.

 

[mr44er]

Ja, das ist auch je nach firmware schwierig zu sagen. Vielleicht war ich auch nur deshalb so auf die temps fixiert, da ich seit kurzem meine ersten NVMEs am Start habe und die ganz schon heiß werden. (vorher keine Erfahrung mit sowas gehabt)

Jedoch hier zwei consumer-SATA SSDs:

Device Model:     SAMSUNG MZ7TE128HMGR-000L1
175 Program_Fail_Count_Chip -O--CK   100   100   010    -    0

Device Model:     SAMSUNG MZ7LN128HCHP-000L1
171 Program_Fail_Count_Chip -O--CK   100   100   010    -    0

 

[L_Thomas]

Yeah, das sind gute Neuigkeiten! Ich drück' ebenfalls die Daumen, dass das so bleibt.


Ein Update auf PVE 8 ist auch dann ratsam und empfohlen, wenn es gerade keine Probleme zu lösen gibt. Vielleicht nicht gleich am ersten Tag, aber so im Laufe der 2-3 Monate nach Erscheinen werden wir unseren PVE-Cluster sicherlich upgraden.

Die Frage ist warum machst du das?
Wenn die Hardware gleich bleibt und die BS Version der VMs sich nicht verändern, warum sollte man das riskieren?

Meiner Meinung nach nur, wenn mit der bestehenden Hardware die bestehenden VMs besser laufen würden.

Wenn sich die Hardware ändert oder die VMs neuer werden ist es klar, dass eine bessere Unterstützung durch den Host gut wäre.

Schöne Grüße,

Thomas

P.S. Immer noch kein Ausfall

 

[sherminator]

und die BS Version der VMs sich nicht verändern

Die verändern sich bei uns gefühlt ständig.
Ich gebe Dir recht: Solange sich das Umfeld nicht entscheidend ändert, besteht kein Grund zur Eile. Nichtsdestotrotz wird der Tag kommen, an dem 7.x EoL ist. Darüber hinaus bringt jedes Software-Update potentiell Verbesserungen. Neue Features, mehr Stabilität, bessere Performance... Ja, ich kann Dir nicht sagen, was für uns ganz konkret an PVE 8/Debian 12 besser sein soll als an PVE 7/Debian 11. Aber ich vertraue den Entwickler:innen, dass sie die Software verbessert haben und freue mich darüber. Kleine Randnotiz: Wir haben mit unserem Cluster bereits ein Upgrade von 6 auf 7 vollzogen; das lief reibungslos.

P.S. Immer noch kein Ausfall

Das ist sehr schön zu hören! Es scheint, als sei das Problem gelöst. Wenn Du magst, dann klicke oben beim Thread-Titel gerne den "SOLVED"-Knopf.

 

[mow]

Das steht auf allen SSDs, die ich gerade stichprobenartig angeschaut habe, auf genau diesen Werten. Laut Thomas Krenn ist das der Startwert, stellt also kein Problem dar.

4 soll der Startwert sein? Wo liest Du das da raus?

Das allein ist kein Ist-Zustand, sondern als Info/Indikator und auch nur wenn dort jeweils ein Wert stünde. Beispiel klassische Magnetplatte: Defekte und neu zugewiesene Sektoren? Möglicherweise "pre-fail" (eventuell demnächst zum Totalausfall führend), falls der Kopf dort die Schicht abgenagt hat oder war sie nur temporär zu starker Vibration ausgesetzt?
So zumindest mein Verständnis, bitte korrigiert mich.

Es ist die Kategorie des SMART-Attributes. Power On Hours ist eindeutig ein Indikator für Old_age, und Available_Reserved_Space für Pre-fail. Andere sind nicht so eindeutig.

 

[wefinet]

Hallo Thomas,

sorry, dass ich mich so spät hier erst melde.

Die Ursache liegt hier darin, dass bislang bei Elkhart Lake Systemen das SATA Link Power Management nicht vom Linux Kernel aktiviert wird.

Ich habe dazu soeben einen Patch an die linux-ide Mailing Liste geschrieben, der das ergänzt:
https://marc.info/?l=linux-ide&m=169322413915221&w=2

Durch das fehlende Link Power Management zieht das System zwischen 1,6 bis 1,8 Watt mehr als eigentlich erforderlich. Durch den höheren Energieverbrauch steigt auch die Temperatur des SSD Controllers. Das kann bis zu 30 °C an höherer Temperatur im SSD Controller bringen. Ich habe das in letzten Wochen intensiv getestet:
https://www.thomas-krenn.com/de/wiki/SATA_Link_Power_Management#Beispiel_LES_v4

Deine SSD ist so nehme ich an eine von ATP. In der drivedb.h der smartmontools fehlte die bislang. Ich hab mit tatkräftiger Unterstützung von ATP einen Eintrag und Pull Request erstellt - die SSD sollte in das nächste offizielle Update der drivedb.h kommen:
https://github.com/smartmontools/smartmontools/pull/191
Bis dahin kannst du den Eintrag auch manuell ergänzen: https://www.thomas-krenn.com/de/wiki/Not_in_smartctl_database

Dein SSD Controller hatte in der Ausgabe 84 °C, der Höchstwert war 104 °C:
231 Unknown_SSD_Attribute 0x0022 084 104 000 Old_age Always - 1729822804

Das deutet darauf hin, dass der SSD Controller in den throttling mode geschaltet hat. Das bedeutet, dass er die Taktfrequenz reduziert um weniger Hitze zu erzeugen und damit einem hitzebedingten Ausfall der SSD vorzubeugen. Das ist ein normales Verhalten und das sollte auch jede SSD so implementieren. Es führt hier dazu, dass die Übertragungsrate der SSD spürbar sinkt, was deine Probleme vermutlich erklärt.

Bis mein Patch in den Linux bzw. Proxmox Kernel kommt, kannst du manuell nach jedem Boot das LPM einfach aktivieren (host0 ist dabei der onboard-M.2 SATA Port, host1 der andere SATA Port):
# echo "med_power_with_dipm" > /sys/class/scsi_host/host0/link_power_management_policy

Ich hoffe die Info hilft weiter. Sorry nochmal für meine späte Antwort hier.

Viele Grüße,
Werner

 

[L_Thomas]

Hallo Werner,

vielen Dank für deine Antwort.

Das überfordert einen Proxmox Neuling und Linux Anfänger natürlich

Ich habe die aktuelle drivedb.h heruntergeladen und konnte sie erfolgreich auf den Host kopieren. Die Daten werden jetzt korrekt angezeigt.

Die temporäre Aktivierung des LPM habe ich durchgeführt und einen Cron-Job @reboot eingerichtet.

Die Auswirkung war sofort sichtbar:

Vorher:

194​

Temperature_Celsius

0x0022

66​

78​

0​

Old_age

Always

-

66​

231​

Controller_Temperature

0x0022

85​

104​

0​

Old_age

Always

-

85​

Nachher:

194​

Temperature_Celsius

0x0022

55​

78​

0​

Old_age

Always

-

55​

231​

Controller_Temperature

0x0022

56​

104​

0​

Old_age

Always

-

56​

Das ursprüngliche Problem wurde ja mit dem Microcode Update bereits behoben.

Aber ein kühleres Köpfchen kann ja nie schaden

Vielen Dank für deine Hilfe!

Thomas