ESX4i Host Absturz

[ms_toon]

Hallo,

habe hier einen ESX4i auf neuer Hardware installiert (Supermicro X7SB4/E mit Xeon E3110 / 3 Ghz und 8GB RAM). Im Prinzip läuft alles wie gewünscht, jedoch stürzt der Host hin und wieder mal mit "Blue Screen" ab (bisher meistens ungefähr 10min nach dem Start). Aus der Meldung werde ich nicht schlau ("PCPU 0 locked up. Failed to ack TLB invalidate.") Aktuelle Patches sind installiert...

Hat jemand eine Idee? Wo würdet ihr ansetzen, um das Problem einzugrenzen?
Danke schon mal im Voraus!

[ms_toon]

Hallo,

nach einigen Tests und Recherchen wird der verbaute Raid-Controller als Fehlerquelle vermutet (Adaptec RAID 2405). Der Controller ist in der Kompatibilitätsliste aufgeführt, dort steht als benötigter Treiber "aacraid version 3.5.10.5vmw". Wenn ich die Logfiles auf dem ESX durchschaue wird dort eine andere Version angegeben. Kann man die verwendete Treiberversion irgendwo einstellen??

Von Adaptec gibt es einen Treiber für den ESX 4, der offenbar ein ähnliches Problem mit "Purple Screen of Death" behebt (siehe http://www.adaptec.com/de-DE/speed/raid ... 68_tgz.htm). Der Download enthält eine vib-Datei. Wie bekomme ich den Treiber auf den Server?

(Edit: Wort vergessen)

[Joe-A-Kim]

Auch wenn's ESXi ist, kannst du ja trotzdem auf die Konsole, und demnach auch auf CD und Diskette zugreifen.
Außerdem hast du die möglichkeit, die Datei auf einen der Datastores zu kopieren, auf welche du ebenfalls über die Konsole zugreifen kannst
Wie man unter Linux Treiber installiert weiß ich leider nicht.

[ideFix]

Aktuelle ESXi Version?

In dem Update werden anscheinend neue Treiberversionen verteilt:

http://kb.vmware.com/kb/1013016


Product Versions ESXi 4.0
Build 181792
Also see KB 1012514
Patch Classification Critical
Host Reboot Required Yes
Virtual Machine Migration or Shutdown Required Yes
PRs Fixed 444934
Affected Hardware RAID controllers
Affected Software megaraid2, megaraid_sas, and aacraid
Related CVE numbers N/A

[ms_toon]

@Joe-A-Kim
Die Konsole könnte evtl. ein Weg sein. Da muss ich "nur" noch rausbekommen, ob und wie ich dem ESXi darüber einen neuen Treiber unterjubeln kann.

@ideFix
Das Update ist schon installiert. Das hat leider auch nicht geholfen.

Falls sonst noch jemand eine Idee hat, dann immer her damit

[ideFix]

Installation des Treibers:

vib = Vsphere Installation Bundle

Instructions when using vSphere CLI:
1. Copy the vib file to a directory on your system.
2. If you are using Microsoft Windows, navigate to the folder where you have installed the vSphere CLI utilities to execute the command mentioned in step 4. If you are using Linux, the command is installed when you install the vSphere CLI RPM.
3. Shut down all guest operating systems on the ESXi 4 host and put the ESXi 4 host in maintenance mode.
4. Execute the command vihostupdate --server <IP address of ESXi 4 host> -i -b <path to vib file>


vSphere CLI: http://www.vmware.com/support/developer/vcli/


Wollte ich eben auch schon posten, aber vorher wollte ich dann doch sicher gehen das du das Update schon installiert hast.

[ms_toon]

Danke für deine Hilfe! Allerdings hatte ich das über die CLI schon probiert. Ich bekomme aber immer eine Fehlermeldung:

Invalid bundle ZIP archive, or missing metadata.zip inside.Bundle.zip [/tmp/upda
tecache/drv.vib]: Error unzipping /tmp/updatecache/drv.vib: File is not a zip file

Anscheinend ist das Update nur mit "richtigen" Bulletins von VMWare möglich. Oder gibt es da noch einen Trick?

Nebenbei hatte ich noch einen Versuch über die Konsole gemacht. Ich habe den Treiber wie vorgeschlagen in den Datastore kopiert und auch über die Konsole gefunden (der Zugriff ist unter ESXi unsupported, geht aber... siehe z.B. http://vmprofessional.com/2008/06/esxi- ... ccess.html). Aber dann hängt es. Bei Adaptec hatte ich eine Anleitung gefunden, nach der man den Treiber im ESX per rpm installieren soll - aber rpm kennt der ESXi gar nicht?! (rpm not found). Vielleicht gibt es da noch einen anderen Weg (meine Linus-Kenntnisse sind eher rudimentär)??

[Dayworker]

"PCPU 0 locked up. Failed to ack TLB invalidate."

Ich glaube, du hast da ein größeres CPU-Problem. Wenn ich das richtig lese, hat Kern_0 bzw CPU_0 ein Problem mit seinem TLB-Cache und das würde einen HW-Fehler in der CPU bedeuten. Der Core i7 hat diesen Bug von seinem Vorgänger Core2Quad geerbt und nur beim Core i7 sollte dieser schon vor dessen Veröffentlichung durch ein Micro-Code-Update gepatcht worden sein. Lies dir dazu auch mal http://www.golem.de/0812/63899.html durch.
Wenn du Glück hast reicht ein Bios-Update deines X7SB4/E-Boards aus.

[ms_toon]

Hallo Dayworker,

habe auch schon ein aktuelles Bios-Update eingespielt - leider ohne Verbesserung. Bist Du sicher, dass die genannten CPU-Probleme auch für den Xeon-Prozessor gelten?

Ich hatte übrigens mehrere Meldungen - mal mit PCPU 0 und mal mit PCPU 1. Vielleicht hat der Prozessor generell ein Problem (der Server ist erst ein paar Wochen alt)? Da ich hier keine Attachments anhängen konnte habe ich hier mal ein paar Fotos von den Fehlermeldungen hinterlegt. Vielleicht willst Du noch mal drauf gucken:
http://www.gmx.de/mc/efqK6MjqHAEcG9gUuLinQSgVgZ06eB

Gibt es irgendwo Infos, wie die Meldungen beim Purple Screen zu deuten sind?

Was für den Raid-Controller sprach sind die Meldungen im Kernel-Log (siehe Bild). Zumindest beim letzten Absturz gab es da entsprechende Fehlermeldungen. Der Hersteller hatte daraufhin die Sache mit dem Raid-Treiber ins Spiel gebracht. Wenn ich den wenigstens mal testweise zum laufen kriegen würde

[Dayworker]

Danke für den Gast-Zugriff.
Jep, bin mir ziemlich sicher. Der Fehler kommt auf beiden Cores und wirft auch jede Menge Register- + Stack-Meldungen neben einigen NMIs aus, dazu kommen einige Heartbeat-Meldungen. Der TLB, Translation Lookaside Buffer, ist übrigens ein Zwischenspeicher, in dem der Prozessor die umgewandelten Adressen zur Verwaltung von Arbeitsspeicherbereichen ablegt. Die Adressen, die per Software angesprochen werden, müssen nämlich erst in ihre realen Partner umgewandelt werden, damit der Prozessor auf den Speicher zugreifen kann. Der TLB dient dabei als tabellenförmiger Cache, da die Umwandlung vergleichsweise rechenlastig ist, wird damit die Performace deutlich gesteigert. Mit anderen Worten schreibt der HDD-Controller oder jedes andere Programm seine eingelesenen Daten in den Arbeitsspeicher und überschreibt dadurch bereits benutzte Speicherbereiche, damit fällt der Controller auch auf die Nase.
Ich glaube irgendwo im ESX-Bereich gab es schon mal so eine Anfrage dazu, hoffentlich findest du über die ForenSuche etwas.

PS: Da dein Board ja auf dem LGA775-Sockel mit FSB1333 beruht, könntest du eigentlich auch jede andere preisgünstige FSB1333-CPU nehmen, solange sie vom Board unterstützt wird. Bei einem Quad der Reihe Q9x50 bedeutet das allerdings 95W TDP und nicht nur 65W wie dein Xeon-Dualcore E3110.

[ms_toon]

Das ganze klingt nicht wirklich gut
Kann man den Prozessor-Fehler auch irgendwie unabhängig vom ESX provozieren (per Stresstest o.ä.)?

[Dayworker]

Kommt drauf an. Bei AMD konnte der unrühmliche TLB-Bug ja sehr schnell nachgewiesen werden. Es sollte eigentlich ausreichen, die CPU unter 100% Last zu setzen und dann zu warten. Ich benutze für Burnin's oder Stabi-Tests immer Orthos Multiprime. Beim AMD-Phenom Quad 9500 im B2-Stepping dauerte das bei einigen Leuten wohl nur 10sec bis der PC einen Reboot hinlegte.

[StevensDE]

Das ganze klingt nicht wirklich gut
Kann man den Prozessor-Fehler auch irgendwie unabhängig vom ESX provozieren (per Stresstest o.ä.)?

Dann würde ich mich aber mal an den Boardhersteller wenden.

Warum kauft ihr denn auch Selbstbauserver?

Große Firmen wie DELL, IBM oder HP sind da viel mehr auf Zack was es betrifft solche Probs im Bios zu lösen.

Ich nehme einfach an, dass Supermirco das verschlafen hat...

[Dayworker]

Die Ursache solcher Problems liegt meist am Verhalten einiger User beim Kauf, nicht umsonst wird meistens nach kürzester Zeit der Support aufgegeben; mehr ist halt bei Geiz ist Schlumpf nicht drin. Allerdings war mir Supermicro eigentlich als Hersteller höherwertiger Produkte bekannt. Ich tippe daher eher auf einen CPU-Defekt. Setz doch mal testweise eine andere unterstützte LGA775-CPU rein und probiers dann nochmal oder teste gleich mit dem schon genannten Multiprime-Prog.
Hier mal die Liste der unterstützten CPUs für das X7SB4:

• Supports Quad-Core Intel® Xeon® X3300/X3200 series
• Supports Dual-Core Intel® Xeon® E3100/3000 series
• Supports Intel® Xeon® processor L3360 and L3110 series
• Supports Intel® Core™2 Quad Q9000/Q8000/Q6000 series
• Supports Intel® Core™2 Duo E8000/E7000/E6000/E4000 series
• Supports Intel® Pentium® E5000/E2000 series
• Supports Intel® Celeron® E1000 and 400 series

Irgendeine dieser CPUs fliegt doch bestimmt noch bei dir rum.

[StevensDE]

Die Kosten sind auch nicht immer ein Argument.

Es gibt bei Ebay VMWARE ESX zeritifzierte Server für unter 1000 EUR.

Das sollte es einem schon Wert sein finde ich...

[Dayworker]

Die Kosten sind auch nicht immer ein Argument.

Es gibt bei Ebay VMWARE ESX zeritifzierte Server für unter 1000 EUR.

Das sollte es einem schon Wert sein finde ich...

Ich meinte damit auch die regulären Einstandskosten bei Kauf beim Hersteller und nicht beim Reseller um die Ecke. Mir ist natürlich sehr wohl bewußt, daß eBay stellenweise eine richtige Fundgrube für preisgünstige, supportete HW ist. Es kommt halt nur auf den angedachten Einsatzzweck an...

[ms_toon]

Bei mir ging es nicht zuerst um den Preis. Ich brauchte ein 19''-Gerät mit halber Bautiefe (also nicht 80, sondern knapp 40cm), was die Auswahl extrem einschränkt. Die Kiste ist zwar eine Individual-Konfiguration, aber auch nicht "vom Schrauber nebenan". Der Hersteller ist mehrfach zertifiziert, u.a. "zertifizierter VMware System Builder und VMware VIP Professional Partner".

Ich würde jetzt noch nicht unbedingt pauschal gegen Supermicro oder den Server-Hersteller wettern wollen (deshalb auch kein Name hier). Der Hersteller ist weiterhin der Ansicht, dass unser Problem am Adaptec-Controller liegt, weil die explizit einen solchen Fehler gemeldet und mit einem speziellen Treiber für ESX reagiert haben. Nur bekomme ich den eben nicht auf die Kiste (siehe weiter oben). Der Server wird heute abgeholt - sollen die sich das nochmal angucken...

Ganz allgemein ist mein Eindruck, dass die Hardware-Hersteller und VMWare ein bisschen wie Hase und Igel sind: Selbst wenn alle Komponenten auf der Kompatibilitäsliste stehen kann es Probleme geben, z.B. weil ein Bios-Update nötig ist oder die Firmware für den Controller eine andere Version braucht. Und wie bei dem Adaptec-Controller geschehen können auch bei kompatibler Hardware im Nachhinein Probleme sichtbar werden, für die es Änderungen an den Treibern braucht, die dann aber erst wieder von VMWare in "ordentliche" ESX-Updates überführt werden müssen usw. Aus meiner Sicht läuft der ganze Kompatibilitäts-/Zertifizierungskram noch nicht richtig rund - sonst wären die Foren nicht voll von genau solchen Problemen...

[Dayworker]

Die halbe Bautiefe ist natürlich ein größeres Problem. Das Pingpong-Spiel haben einige Hersteller verdammt gut raus, da hilft ganz gut eine mittelständische Firma oder ein Global-Player in der Hinterhand. Mit diesen will es sich niemand verscherzen. Welche Auswirkungen das haben kann, sah man ja sehr schön bei Intel und ihrem Vista-Statement.

Egal was euer Systemhaus macht, ich hoffe nur, daß das Treiber-Update auf normalen Wege eingespielt wird und nicht per patchen der OEM.tgz. Ein Update des ESXi könnte ja sonst alles wieder zunichte machen...

[ms_toon]

Egal was euer Systemhaus macht, ich hoffe nur, daß das Treiber-Update auf normalen Wege eingespielt wird und nicht per patchen der OEM.tgz. Ein Update des ESXi könnte ja sonst alles wieder zunichte machen...

Da hast Du recht. Als ich genau die Sorge gestern am Telefon geäußert habe bekam ich die übliche "müsste gehn" Antwort (sinngemäß "wir haben das nochmal besprochen, ein späteres Update des ESXi dürfte kein Problem sein"). Das "müsste gehn" hat sich hier schon ein bisschen zum Running Gag entwickelt...

Ich werde darauf setzen, dass die CPU getauscht wird. Und wegen dem Raid-Controller sollen die lieber einen anderen einbauen, statt irgendwie die Treiber in den ESXi reinzufrickeln...

Auf jeden Fall nochmal vielen Dank für die Hilfe!

[StevensDE]

Hi,

also bei 40cm tiefe kann ich das Problem verstehen.. ich kenne keinen Rackserver der nur "40cm" tief ist...

Ich glaube bei sowas wirds bei IBM, DELL & HP auch schwer. Ich kenn zumindest keine Modelle die da nur 40cm tief sind.

Zum Treiber:

Laut dem was du hier gepostet hast, ist es kein Problem mit dem Treiber.

Das Problem ist

1) CPU Error
2) Bios Update

Alles andere ist meiner Meinung nach nicht die Ursache. Es kann auch sein du baust eine andere CPU ein und es gibt immernoch Probleme. Weil evtl. auch eine andere CPU genau dieses Bios Update braucht.

Zum Raidcontroller nochmal:

Der wird ja normalerweise (bei zertifizierter HW) auch von VM geupdated.. mit den Patches und Update von VMWare kommen da ja auch oft neue Versionen der einzelnen Storage Treiber usw.

[ms_toon]

Kurze Notiz für die Nachwelt:
Das Problem war, das der Raid-Controller (Adaptec RAID 2405) in dem Servergehäuse zu wenig Luft bekommen hat und zu warm geworden ist. Das hat die Abstürze verursacht...

[Dayworker]

Das erklärt aber in meinen Augen immer noch nicht das PCPU-Problem. Wenn irgendwo ein Platten-Controller zu warm wird, ist das unabhängig von der CPU und der TLB sitzt mit auf dem CPU-Die.

Wie hoch waren denn die CPU-Temperaturen zum selben Zeitpunkt gewesen?
Vorstellbar für mich wäre, daß die CPU aus externen Thermalgründen (wesentlich erhöhte Gehäuseinnentemperatur des Rackeinschubs durch den fehlerhaften Controller) ans Throtteln kam und aus unerklärlichen BIOS-Gründen letztendlich nicht den sicheren Shutdown vollzogen hat. Damit wären alle Boardkomponenten stärker thermisch belastet worden, als üblich...

[ms_toon]

Hallo Dayworker,

vielleicht liegst Du ja auch richtig mit Deiner Einschätzung zur CPU. Ich habe im letzten Posting verschwiegen, dass ich nach dem nachgewiesenen Temperatur-Problem mit dem Controller gleich auch noch die CPU habe tauschen lassen - insbesondere aufgrund Deiner Einschätzung hier Statt der Xeon E3110 ist jetzt die L3110 drin. Das die Problematik aber insgesamt thermisch bedingt war lässt sich daran festmachen, dass die Kiste bei einem längeren Lauftest mit offenem Gehäuse nicht abgestürzt ist. Ob die CPU zum Hitze-Problem auch zusätzlich noch ein anderes Problem hatte lässt sich aber nicht (mehr) ausschließen

[bla!zilla]

Wie wäre es mit besser Belüfung und Klimatisierung des Raumes?