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.

[Rene_Mhm]

Es lag offenbar ein HardWare-Defekt vor.
Nachdem die Kiste teilweise schon nach wenigen Stunden "lila" wurde, lief sich mit abgezogenem Gehäuse (Lenovo P3 Ultra) 6 Wochen durch. Also offenbar ein Temperaturproblem.

Levovo hat heute die beiden großen Lüfte incl. der Plate tauschen lassen, ebenso wie das MainBoard (siehe blöder Folgefehler https://vmware-forum.de/viewtopic.php?f=59&t=34795&p=193693#p193693)

[Rene_Mhm]

Es wird nicht besser!

Nach dem o.g. Tausch traten die Pprobleme wieder auf. Und zwar wiederum temperaturabhängig.
Mit geschlossenem Gehäuse lag die mittelre Laufzeit bei 1 - 2 Tagen, offen hingegen bei >1 Woche.
Nach Ausbau der beiden RAM-Module auf der CPU-Seite (64 GB reichen aktuell bequem aus) lief das Ding dann auch 4 Wochen durch, bis ich da mal aus anderen Gründen ran mußte.

Ok, irgendwie war mir die Geschichte dann zu nervig, und ein zweiter, neuer P3 Ultra (jetzt mit Gen14 i9) mußte ran.
Und jetzt, gerade vor ca. 1/2h: Auf die erste Platte war kein Zugriff mehr möglich, die Server standen still.
Außer dass mir die Kapazität im WebGUI weiter korrekt und nicht wieder mit 0 angezeigt wurde exakt der selbe Unsinn, wie es mit dem alten P3 ursprünglich mal los ging.

Das "Altgerät" konnte ich bisher inter Windows quälen wie ich wollte, es war kein Problem produzierbar.

Was kann das für eine Baustelle sein, welche a) temperaturabhängig und b) nur beim ESXi auftritt ?!?!?
Klar, die Büchse ist nicht dafür zertifiziert, schon klar. Damit könnte man aus meiner Sicht fast alles erklären, aber doch keine ganz offenbar temperaturabhängigen Probleme!

[Dayworker]

Der ESXi sieht nur wenig Möglichkeiten zum Stromsparen vor. Intels Core-Prozessoren der Gen 13 und 14 kämpfen aber sowieso mit Instabilitäten aufgrund der Spannungsversorgung sprich zu hoher Spannungen. Laut Intel kann die zu hohe Spannung sowohl unter Last als auch im Leerlauf auftreten.
Es ist also wichtig, die CPUs sowohl mit Microcode-Updates zu versorgen, als auch die korrekten Spannungswerte einzutragen. Sind diese CPUs über längere Zeit mit zu hohen Werten gelaufen, hilft kein MB-Tausch, weil die CPUs bereits Schaden genommen haben können.

Undurchsichtig wird es, wenn der Server/MB-Hersteller noch keine bzw überhaupt keine Bios-Updates liefert. Ausgehend von Confused about amd-ucode - do I need it if I dual-boot with Windows? muß dann jedes OS seine eigenen Microcode-Updates mitbringen. Anscheinend hat das bisher nur Windows integriert und das dürfte zu dem von dir beschriebenen unterschiedlichen Verhalten führen.