Purple Screen ESX 5.5

[skrix182]

Hallo zusammen,
wir haben seid einer Ram-Erweiterung bei einem ESX 5.5 das Problem von ständig auftretenden Purple Screens mit Systemabstürzen. Nach erstmaligem Auftreten wurde der Ramtausch wieder rückgängig gemacht, allerdings traten anschließend trotzem weiterhin Fehler auf.
Der ESX ist über ISCSI an ein externes Storage angebunden. Eingebaut ist ein LSI Controller.
Unten ist ein Bild des Purple Screens.
Leider kann ich aus mir nicht ganz erklärlichen Gründen momentan keinen Screenshot des bildschirms hinzufügen..
Vielen Dank für jegliche hilfe hierbei!

Edit: Hier nun ein Link zum PSOD: http://imageshack.com/a/img905/2695/ydtHps.jpg

[~thc]

Moin.

Eine MCE deutet immer auf ein Problem mit der Hardware hin. Du kannst versuchen, die MCE zu dekodieren:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005184

Weiter unten im PS steht, dass dies der 109. Fehler ist - 108 konnte die Hardware selbst korrigieren.

[irix]

Die Hardware ist ja nun schon etwas in die Jahre gekommen aber das Hauptproblem bei Intel Nehalem und spaeter ist das der Speichercontroller in die CPU gewandert ist. Wenn man also Memory im Verdacht hat dann hat man 3 Orte wo man gucken muss:
- CPU
- Board/Steckplatz
- DIMM

Die Frage ob der Server fuer bestimmte DIMM Steckplaetze irgendwas protokolliert hat und wenn ja dann mal einen Kreuztausch des DIMMs machen um zu gucken ob der Fehler mitwandert damit man Board und CPU ausschliessen kann. Wandert der Fehler nicht mit dann die CPUs tauschen.

Wenn der Serverhersteller eine Diagnose CD mit Memorytest hat dann mal laufen lassen.

Ansonsten ist natuerlich die ESXi Installation fast genau so alt wir die Hardware und hat schon seit Jahren kein Update/Patch mehr gesehen.

Nein man kann hier keine Anhaenge machen im Forum.

Gruss
Joerg

[skrix182]

Danke für die schnellen Antworten.
Ja, das es ein Hardwareproblem ist habe ich mir auch schon gedacht.
Das komische ist: Wenn ich den Server bei mir in der Werkstatt aufstelle, läuft er problemlos! Hier kommt dann ein interner Controller mit ein paar HDD´s als Testlösung zum Einsatz. Letzendlich bedeuted das ja, dass das Problem entweder beim Controller, Storage oder bei einer der VM´s liegt, oder..?
Verrückt ist ja auch, wie gesagt, das wir lediglich den Ram getauscht haben!
Die ESX-Installation ist nicht m.M. nach nicht das Problem, zumal genau auf derselben Maschine bis zuletzt ESX 4.1 lief.

[Dayworker]

Bezüglich deiner Werkstatt-Aufstellung liegst du falsch. Wenn der Fehler bereits 108 mal aufgetreten ist und korrigiert wurde, spricht das in meinen Augen für einen Bitfehler entweder in der CPU, weil dort der Speicherkontroller sitzt, oder im RAM-Riegel. Die weitere Vorgehensweise hat dir bereits "irix" genannt.

Bist du dir eigentlich mit iSCSI sicher? Weil im PSOD taucht irgendwas mit NFS auf...

[skrix182]

Guten Morgen,
es tut mir Leid, da ist mir wohl in meinem ersten beitrag ein Fehler unterlaufen. ISCSI ist Quatscht, die Verbindung zum Storage erfolgt über eine externe SAS Verbindung (SFF 8088). Auf diesem Storage befinden sich die aktiven VM´s. Das "NFS" im PSOD kommt warscheinlch von der QNAP, welche über NFS verbunden ist. Hier laufen Bacups der virtuellen Maschinen, erstellt mit VEEAM, auf.
IRIX schreibt in seinem Beitrag, ich soll die Speicherriegel und Dimm-Plätze überprüfen. Ich habe jedoch schon geschrieben, dass direkt nach Auftreten des Fehlers alle Riegel noch einmal durchgetauscht wurden, d.h. ersetzt durch komplett neue. Bei diesem Vorgang wurden auch die Plätze getauscht.
Die ESX Version kann, wie gesagt, auch nicht die Ursache sein, da diese schon von 4.1 auf 5.5 geupdated wurde, mit genau demselben Fehlerbild.
Unser nächster Schritt ist wohl ein Austausch des externen SAS-Controllers, wobei ich hier auch nicht 100%ig sicher ist, ob das was nützt.

[skrix182]

was mich etwas irritiert, ist, das im PSOD mehrmals eine VM explizit erwähnt wird. Laut euren Beiträgen deutet dieser Fehler jedoch auf ein Hardwareproblem hin. Bedeuted diese Erwähnung einfach nur, das der Fehler wärend der Ausführung dieser VM auftritt oder kann es auch sein, das die VM die Ursache ist? (z.B. durch fehlerhaftes Dateisystem oder zu viele Snapshots etc.)

[~thc]

Bitte lesen:

https://en.wikipedia.org/wiki/Machine-check_exception

[skrix182]

@~thc Artikel habe ich gelesen. Ich weiß nicht ob du mir damit jetzt etwas bestimmtes nahelegen willst. Ich kann diesem Artikel nichts neues abgewinnen.
Unter dem Abschnitt "Possible Causes" steht letztendlich genau das, was schon genannt wurde + im letzten Satz: "Computer software can also cause MCE errors (normally by corrupting data which programs read or write)"
[/quote]

[~thc]

O.K. - das war dann ein kleines Eigentor. Ich war davon ausgegangen, dass Software keine MCEs auslösen kann. Eine Hardwareursache ist aber wahrscheinlicher (u. a. weil 108 von 109 hardwareseitig korrigierbar waren).

Ich an deiner Stelle würde die MCEs möglichst dekodieren, um mehr über die Ursachen zu erfahren.

[Dayworker]

Neue DIMMs helfen dir aber nicht weiter, wenn entweder die Slots einen Defekt haben oder die DIMMs nicht 100%ig kompatibel mit dem System sind. Es wäre auch möglich, daß die VM bereits einen Schaden auf Bitebene genommen hat und deshalb regelmäßig einen MCE wirft.

Um dem Problem auf den Grund zu gehen, würde ich jeden Riegel einzeln, in jedem Slot (so die Server-HW mitspielt) und mit dem Streßtest von "Prime95" mit Hilfe einer Live-CD beackern. Ob die Memory-Tests auf den Hersteller-CDs von HP & Co dort mehr zu leisten imstande sind, entzieht sich meiner Kenntnis. Die häufig gefahrenen Memtest86-Läufe waren meiner Erfahrung nach nur Zeitverschwendung, da sich Fehler damit nicht stabil reproduzieren lassen. Das wissen Handlern von Endverbraucherprodukten auch und nutzen Memtest86 daher gern zum Abweisen von Ansprüchen.

[skrix182]

@Dayworker
Ja, das wäre auf jeden Fall eine Option. Mein Problem ist nur, dass ich für dafür den Server für einen Langen Zeitraum in Beschlag nehmen müsste. Ich habe 16 Bänke mit 16 Riegeln, bedeuted ich müsste 16*16=256 Optionen durchgehen, mit jeweils Ausführlichem Stresstest.
Was mir an der ganzen Geschichte immer noch nicht ganz klar ist:
Ich habe den Server hier, in unserer Werkstatt, ca. 3 Monate durchlaufen lassen. Mit dem Ram,CPU, Board etc, in der Konstellation, ohne PSODs. Schlussfprlgerung: Das Ding läuft wieder. Ich bringe ihn wieder weg, baue den SasController wieder ein, schließe ihn ans Storage an, 2 tage später - Purple Screen. Ich kann ja nachvollziehen, warum hier im Forum immer auf einen MemoryFehler verwiesen wird. Aber der muss doch dann auch hier im Testbetrieb auftreten?

[JustMe]

Was genau heisst denn "Testbetrieb"?
Wurde der verfügbare Hauptspeicher mit Test-VMs zugepflastert, die allesamt und dauerhaft Memory-Tests laufen hatten?

Die Geschichte mit dem Speicher wird gern genommen (und ist es auch meist), weil bei den heutigen Mengen an (Speicher-)Transistoren in Servern schon lange nicht mehr JEDER Fehler auch tatsaechlich von der Hardware "nach aussen" gemeldet wird.

Was hat es denn mit dem Aus- und Einbau des LSI-Controllers auf sich? Gibt's fuer den vielleicht Firmware-Updates? Wenn der auch in 4.x schon verwendet wurde, ist der sicher ebenfalls nicht mehr so ganz taufrisch, wie der Rest...

Von meiner persoenlichen Seite her warte ich jedenfalls immer noch darauf, dass mal irgendwann wirklich in der freien Wildbahn ein MCE auftritt, der tatsaechlich von einer Software (unbeabsichtigt) herbeigefuehrt wurde, und eben NICHT durch den Tausch der fehlerhaften Hardware beseitigt werden konnte.

[Dayworker]

Speichertests in einer VM sind aufgrund der Virtualisierung nutzlos, daher hatte ich ja den Test über eine Live-CD empfohlen.
Speziell mit dem Streßtest von Prime95 kann ich nur sagen, daß sich damit etwaige RAM- und CPU-Fehler sowie mangelhafte Kühlkapazitäten der eingesetzten HW (Server, PC, NB) bereits innerhalb weniger Sekunden materialisieren und Primzahlen lassen keine noch so kleine Abweichung zu.

Bezüglich des SAS-Controllers könnte neben diesem auch Slot und/oder Kabelage beeinträchtigt sein. SAS-Controller können mit SAS-Platten aufgrund von Prüfsummen ja wenigstens kontrollieren, ob die auf die Reise geschickten Daten unterwegs Schaden genommen haben (und ggf eine Retransmission anfordern) oder korrekt gesendet wurden. Mit SATA-Laufwerken kann man sowas gleich ganz vergessen und solche Funktionalität muß dann notfalls der Filer garantieren. Eine Zusatzkarte nimmt es auch unterschiedlich übel, wenn die Spannungsversorgung nicht stabil genug ist oder es ihr zu warm wird. LSI beispielsweise gibt je nach Chipsatz maximal 55°C ohne und 50°C mit BBU als zulässige Temperatur an und einen Lüfter bringen die wenigsten LSI-Controller mit, da dieser ja ein bestehendes Termalmanagement in der HW stören könnte. Daran sieht man schon, wie komplex das noch werden kann und von daher würde ich zuerst beim RAM anfangen. Dank DMA ist eine CPU ja nur noch bedingt an einer Übertragung beteiligt und instabiler Speicher ist meist die Ursache Nummer Eins.

[JustMe]

Ein Speichertest in einer VM ist NICHT per se nutzlos.

Er ist nutzlos, wenn man damit eine fehlerhafte Stelle im Hauptspeicher IDENTIFIZIEREN bzw. lokalisieren moechte. Soweit waere das richtig.

Wenn aber der Test darin besteht, den Speicher im Rechner auch zu VERWENDEN, dann ist das sehr wohl ein probates Mittel, weil damit dann diese MCEs (so sie denn auf einem Speicherfehler beruhen) genau dadurch getriggert werden koennen.

OK, wenn der fehlerhafte Speicherbereich nicht von VMs sondern von anderen Komponenten verwendet wird, hilft's auch nicht, aber dem kann man sich ja sukzessive naehern.