mehrfache Abstürze - lila TodesScreen

[Rene_Mhm]

Hallo,

habe leider in den letzten 3 Wochen, davon 2x heute, einen Totalabsturz des Hosts gehabt.
Kann man anhand irgend eines Logs, oder auch des lila Screens, etwas zur "Todesursache" in Erfahrung bringen?
Anbei die Screen vom ersten Ausfall, und von gerade eben.

[Rene_Mhm]

Niemend einen Ansatz? Schade.

[Dayworker]

Eine Fehlernummer von VMware/BroadCom zu erwarten, scheint abwegig zu sein. Der obere PSOD-Teil bringt irgendwie nicht viel. Sucht man in der Schnittmenge nach "jumpstart plugin restore-networking activation failed" sucht, landet man bei VMware ESXi 8.0 Update 2 Release Notes. Darin wird für "VMware ESXi 8.0 Update 2 | 21 SEP 2023 | GA ISO Build 22380479" aufgeführt:

If IPv6 is deactivated, you might see 'Jumpstart plugin restore-networking activation failed' error during ESXi host boot

In the ESXi console, during the boot up sequence of a host, you might see the error banner Jumpstart plugin restore-networking activation failed. The banner displays only when IPv6 is deactivated and does not indicate an actual error.

Workaround: Activate IPv6 on the ESXi host or ignore the message.

Die normalerweise einfachste Weg zur Problemlösung mit Updaten der vSphere-Umgebung funktioniert leider nicht, weil die Problematik auch bei "VMware ESXi 8.0 Update 3 | 25 JUN 2024 | ISO Build 24022510" noch vorhanden ist.

[JustMe]

Hm, die Frage waere zuerst, ob die Zeitstempel bei "...jumpstart..." ueberhaupt zu den PSoD-Zeiten passen...
Die Abstuerze auf den Screenshots sind ja nach 8 bzw. 16 Tagen Systemlaufzeit erst aufgetreten.

Ich persoenlich wuerde mir eher die VM "Ex-Mhm" mal anschauen, wie die konfiguriert ist, und was sie so zu den Ausfallterminen treibt.

[Rene_Mhm]

Die Abstuerze auf den Screenshots sind ja nach 8 bzw. 16 Tagen Systemlaufzeit erst aufgetreten.

16 Tage stimmt wohl, aber das andere waren ehher nur 14 Stunden

Ich persoenlich wuerde mir eher die VM "Ex-Mhm" mal anschauen, wie die konfiguriert ist, und was sie so zu den Ausfallterminen treibt.

Das ist ein 2016er Ex auf Srv 2016, bis auf die üblichen MS-Updates seit Jahren unverändert.
Meine Vermutung geht aktuell in Richtung von Problemen mit einer 990er Samsung. Hatte bisher bereits mehrfach (!) den Fall, dass die auf dieser laufenden VMs tod waren, und mir im Server-UI dafür eine größe von 0 Byte angezeigt wurde. War jeweils durch ReBoot behebbar. Könnte mir an der Stelle ein termisches Problem vorstellen, und betreibe die Büchse daher gerade testweise gut belüftet und mit offenem Gehäuse.
Hatte hier allerdings auf unvoreingenommene Diagnosen gehofft, und dies deshalb in der fragestellung nicht mit erwähnt.

Welches der Logfiles könnte denn darüber evtl. noch Aufschluss geben?

[JustMe]

Stimmt; ich hätte mir den Screenshot besser in Originalgroesse anschauen sollen. So sah die "0" aus wie eine "8"

Erste Anlaufpunkte sind bei so etwas eigentlich immer vmkwarning.log und vmkernel.log. Theoretisch sollten die Controller-Treiber da ihre grundsaetzlichen Bauchschmerzen hinterlegen. Leider sind die meist ziemlich unuebersichtlich (viele Eintraege...), und am ehesten auf der Kommandozeile zu verarbeiten, aber man kann sie sich selbstverstaendlich auch auf einen Windows-Rechner herunterladen, und dort in einem Editor durchscrollen.

Ich fuerchte allerdings aus den Infos in den Screenshots, dass Du kein persistent Kernel Logging eingerichtet haben koenntest; dann gehen die Informationen in den beiden Dateien immer nur bis zum letzten, d.h. aktuellen Start zurueck...
Falls doch, kannst Du in den alten Dateien (jeweils mit der Nummer.gz statt log) schauen, was jeweils kurz vor'm Absturz noch vermerkt wurde.
Je nach verwendeter Hardware haben auch Treiber ggfs. eigene Logdateien, die man durchforsten koennte, oder bei "echten" Serverrechnern auch deren Management-Chips (BMC/iLO/iRMC/iDRAC/... und was der munteren Bezeichnungen für ASPEED2500's noch so sind).

Ach ja, und zu dem anderen Problem mit der VM-Identifizierung: Ich denke ja, dass es nicht so sehr ein Problem ist, wie der ESXi VMs identifiziert, sondern wie das Deine Backup-Software tut. DIES sollte man mal eruieren, und dann kann man im naechsten Schritt feststellen, wo der ESXi ebenjene verwaltet... (Sorry fuer's Cross-Posting, aber es ist ja nicht wirklich eine Problemloesung...)

[Rene_Mhm]

... aber man kann sie sich selbstverstaendlich auch auf einen Windows-Rechner herunterladen, und dort in einem Editor durchscrollen.

Was, wie sicher zu erwarten, meine erste Wahl wäre. Zumal notepad++ die Übersichtlichkeit manchmal doch recht gut erhöhen kann.

Ich fuerchte allerdings aus den Infos in den Screenshots, dass Du kein persistent Kernel Logging eingerichtet haben koenntest ...

Bilde mir ein, da mal etwas zu eingerichtet zu haben. Bin mir aber nicht sicher. Also mal schauen.

Ach ja, und zu dem anderen Problem mit der VM-Identifizierung: Ich denke ja, dass es nicht so sehr ein Problem ist, wie der ESXi VMs identifiziert, sondern wie das Deine Backup-Software tut.

Ja, das ist sicher ein sehr guter Ansatz. Hatte halt damit gerechnet, dass die Einträge irgend welche IDs haben, welche sich bei Neuregistrierung ändern. Aber dies scheint tatsächlich nicht der Fall zu sein.