Absturz des ESXi-Hosts - was war die Ursache?

[osterhase]

Hallo zusammen,

gestern hat sich mein ESXi-Host mitten im Betrieb verabschiedet. Nicht mehr anpingbar, Shell ging nicht mehr, vSphere auch nicht. Leider steht das Gerät nicht gerade um die Ecke, habe mich heute aber auf den Weg gemacht und folgendes auf dem Monitor zu sehen bekommen:

http://img294.imageshack.us/img294/1188/esxifehler.jpg

Könnt ihr mir bei der Ursachenforschung weiterhelfen?
Die Kiste war in den letzten Tagen gut ausgelastet, viele VMs neuinstalliert....

Bin für Ideen dankbar!

EDIT: Es handelt sich um ein privates System, Hardware ist daher auch nicht zertifiziert (Dell Optiplex 755). VMs waren Server 2008/R2 x64bit Maschinen.

[Martin]

Page Fault könnte auf ein RAM-Problem hinweisen. Ich würde mal einen RAM-Test mit memtest86 laufen lassen.

[osterhase]

Page Fault könnte auf ein RAM-Problem hinweisen. Ich würde mal einen RAM-Test mit memtest86 laufen lassen.

Danke für den Hinweis, das werde ich prüfen.
Nur zur Sicherheit, weil ich nicht so tief im ESX drin stecke: Durch eine sehr hohe RAM-Auslastung durch die VMs kann ein solcher Absturz (hoffentlich) nicht ausgelöst werden.?

[Dayworker]

Nö, die RAM-Auslastung ist ja eigentlich immer erwünscht.

[hansfx]

Lasse den MemTest ruhig mal 24h laufen,
bei mir sind teilweise die ersten Fehler nach 6-8h gekommen.
War kein defekt im Ram sondern ein Einstellungsproblem im Bios.

[Dayworker]

Das Dell-Bios ist häufig ein Musterbeispiel für wenig Einstellungmöglichkeiten. Da sollte man definitiv auf die Speichermodul-Liste bei Dell schauen und nur dort verzeichneten Speicher einsetzen.

[osterhase]

Auf jeden Fall ist ein RAM-Problem sehr wahrscheinlich, nun habe ich auch den ersten Blue-Screen in einer VM bekommen (Win 2008 R2)

http://img202.imageshack.us/img202/9559 ... n2k8r2.gif

Brenne gerade die Memtest CD und werde es dann mal ein bisschen laufen lassen...

EDIT: Ist es plausibel, dass Kompatibilitätsprobleme bei RAM Riegeln erst nach gut 2 Monaten auftreten? Konfiguration über die Zeit unverändert und lief stabil, das war jetzt der erste Absturz.

Memtest läuft, bin auf das Ergebnis gespannt.

[osterhase]

So, Fazit: http://img693.imageshack.us/img693/4726/memtets.jpg
Der Test lief zunächst mal mit allen RAM-Riegeln, weil ich mir einen Überblick verschaffen wollte. Nächster Schritt wäre dann nach und nach die Riegel für sich zu testen.

Zwischendurch habe ich mal noch das Dell-Diagnostics-Programm durchlaufen lassen, welcher folgendes anzeigte: http://img19.imageshack.us/img19/4963/delldiag.jpg

Laut Dell-Hotline ein eindeutiges Anzeichen für eine defekte Festplatte, welche nun morgen getauscht wird.
Passt das zum Fehlerbild des ESX?

Interessant ist dazu noch: Im BIOS werden die Platten noch erkannt, er bootet ja auch ohne Probleme, ich kann jedoch mit keinem HDD-Prüf-Tool der Plattenhersteller darauf zugreifen (finden die Platten dann nicht). Allerdings erscheint es mir wenig plausibel, warum nun beide Platten defekt sein sollen. Nunja, mal sehen was ein Austausch bringt - den werde ich leider erst in einer guten Woche durchführen können.

[Dayworker]

Den Speicher komplett zu checken, macht keinen Sinn. Die Gründe dafür sind zum einen das Dualchannel-Interface deines Dell-Hosts der Core2-Reihe und zum anderen ist in deinem Bild http://img693.imageshack.us/img693/4726/memtets.jpg ein aktiver Cache zu sehen. Beides sorgt bei jedem Memtest-Durchlauf für Fehleranzeigen an immer wechselnden Speicheradressen. Selbst wenn du nur 1 Modul steckst, würde der aktive Cache noch immer die genaue Speicheradresse verschleiern und du könntest dir trotzdem nicht sicher sein, ob überhaupt ein Fehler vorliegt oder der Cache irgendwelchen Müll enthält.

Eine einfachere Möglichkeit solchen Fehlern auf die Spur zu kommen, besteht in der Primzahlberechnung. Die stehen bis zu einer sehr großen Zahl ja fest und jede noch so geringe Abweichung bedeutet dann immer ein HW-Problem. Ich nehme für solche Tests und das Burn-in jedes meiner Rechner immer Orthos Multiprime, daß auf Prime95 für Windows beruht und zumindest 2 Instanzen dessen mit einer kleinen GUI auffrischt. Damit kannst du maximale Last auf CPU, Speicher oder auch beides erzeugen. Auf einer Multicore-CPU mußt du dann natürlich die entsprechende Anzahl von Multiprime-Instanzen starten. Der Vorteil dieses Programms liegt in der Schnelle seiner Ergebnisse. Wenn du einen HW-Problem hast, fällt dieser Fehler dann je nach Speichermodulgröße innerhalb von Sekunden bis wenigen Minuten auf. Wenn du einen Fehler angezeigt bekommst, heißt es natürlich wieder alle Module einzeln testen. Aber das ist ja dank der schnellen Ergebnisse kein Problem mehr.

PS: Ich habe damit bisher alle HW-Probleme gefunden, egal ob es defekte Module (sehr ärgerlich bei Speicherkits) oder Mainboardsteckplätze waren und man erfährt zudem, wie hoch die Lautstärke sämtlicher Systemlüfter unter Volllast werden kann.

[osterhase]

Danke, den Tipp werde ich gleich mal ausprobieren - memtest86 ist ja wirklich ein langatmiges Testverfahren

[bico]

hey hatte genau das gleiche problem und war tage mit beschäftigt herauszufinden dass es ein defektes rammodul war

mach doch auch mal stress tests, aus nem mix aus memtest86+ und nem stresstest konnte ich ziemlich schnell den defekten ramriegel ausfindig machen. der host ist immer nach 1 minute spätestens abgestürzt als ich eine vm mit memtest86+ und eine mit stress laufen lies. seitdem überprüf ich jede neue hw und ramriegel auf die art und weise zu aller erst

[osterhase]

hey hatte genau das gleiche problem und war tage mit beschäftigt herauszufinden dass es ein defektes rammodul war

mach doch auch mal stress tests, aus nem mix aus memtest86+ und nem stresstest konnte ich ziemlich schnell den defekten ramriegel ausfindig machen. der host ist immer nach 1 minute spätestens abgestürzt als ich eine vm mit memtest86+ und eine mit stress laufen lies. seitdem überprüf ich jede neue hw und ramriegel auf die art und weise zu aller erst

Macht memtest in einer VM denn Sinn?!

Aktueller Stand ist folgender:
Noch mal das Dell-Diagnose-Programm ausgeführt, inkl. ausführlichem Speichertest.
Ergebnis: http://img411.imageshack.us/img411/3733/delldiag2.jpg (sorry, unscharfes Bild)
Interessant dabei ist die Angabe, welcher Riegel den Fehler verursacht haben soll.
Um dies zu überprüfen, habe ich alle anderen Riegel entfernt - den Fehler konnte ich bisher in verschiedenen Steckplätzen nicht reproduzieren. Gerade läuft mal wieder memtest86+ nur mit diesem Riegel alleine... Seit 2 Stunden bisher, ohne Fehler.

Evtl. wäre ja auch ein Mainboard defekt denkbar?
Für Prime95 und Co muss ich mir erstmal noch eine bootfähige Windows-Umgebung/CD bauen....

[Dayworker]

In einer VM macht Memtest logischerweise keinen Sinn, da die Speicherbereiche ja quer über alle Module verteilt sein können.
Ein Test-Windows kannst du recht einfach mit BartPE zusammenbauen oder mit dem "Microsoft Diagnostics and Recovery Toolset 5.0" (MSDaRT50Eval.msi) müßte es nach erweitern um benötigte Treiber und Anwendungen auch gehen...

[osterhase]

Also das ist schon merkwürdig... bei dem RAM-Riegel, wo die Dell-Software angesprungen ist, läuft nun seit 9 Stunden memtest fehlerfrei, 2 Std Primzahlen rechnen verlief auch ganz normal..

EDIT: Ich ersetze gerade die zweite Festplatte in dem System (nicht die System-Platte des ESX), hier beschwert sich das Dell-Diagnose Programm immer mit der Meldung "Drive self-test failed" - auch wenn es sonst keine weitere Anzeichen für Probleme mit der Platte gibt (SMART auch ok), probiere ich das nun einfach mal aus... Wer weiß...

[osterhase]

So, heute Nacht liefen auf der neuen Festplatte 2 VMs und haben unter maximaler Auslastung fleißig Primzahlen gerechnet - ohne Probleme. Werde nun mal meine durch den Absturz des Hosts kaputt gegangenen VMs wieder neuinstallieren und dann das ganze mal beobachten - vielleicht habe ich ja Glück und das Problem ist mit der neuen Platte behoben. Der Host lief auch ~7 Stunden mit Primzahlenrechnerei in XP-Umgebung fehlerfrei.