Purple Screen

[bolder]

Hallo!

Wir haben eine Fujitsu-Siemens TX 600 mit ESX 3.0.2 (build 77863), die vor einigen Tagen einen Purple Screen hatte. Dabei wurde am Bildschirm folgendes angezeigt:

Code: Alles auswählen

VMware ESX Server [Releasebuild-75615]
Exception type 14 in world 1121:mks:wkshvbgp @ 0x6ce4b2
gate=0xe frame=0x3587e74 eip=0x6ce4b2 cr2=0x3197ef4 cr3=0xb4041000 cr4=0x168
eax=0xbad0002 ebx=0xbad0002 ecx=0x0 es=0x1584028 ds=0x4028
fs=0xbad0000 gs=0x3580000 ebp=0x3597ee8 esi=0x3 edi=0x3e7945a8 err=0 ef=0x10246
cpu 0 1120 vmm0:wksh: cpu 1 1025 idle1: cpu 2 1067 vmm0:srvh: CPU 3 1121 mks:wks
hv:
cpu 4 1069 mks:srvhv: cpu 5 1095 vmware-vm: cpu 6 1090 vmm1:srvh: cpu 7 1092 mks
:srvhv:
0x3597ee8:[0x6ce4b2]UserObjPollNonBlock+0x8a(0x0, 0x0, 0x0)
VMK uptime: 34:14:12:31.52S TSC: 8937254009129908
Starting coredump to disk using slo1 1 of 1... 98766666543210 Disk dump successf
ul.
Debugger is listening on serial port ...
Remote debugger activated. Local debugger no longer available

Das Problem trat am 20.11.2008 um 03:30 Uhr auf. Die Datei /var/log/vmkernel hat den letzten Eintrag am 17.11.2008, dann wird am 20.11.2008 um 7:59 Uhr der Neustart dort gelistet.
Auch in der /var/log/vmksummary scheinen mir nur normale Einträge zu sein. Hier ein Auszug aus dem betreffenden Zeitraum:

Code: Alles auswählen

Nov 20 03:01:01 srvhvbgvifd0001 logger: (1227146461) hb: vmk loaded, 2986953.64, 2986939.802, 6, 75615, 75615, 0, webAccess-63116, vmware-h-32840, eecd-29404
Nov 20 07:58:56 srvhvbgvifd0001 vmkhalt: (1227164336) Starting system...

Die einzige Fehlermeldung, die mir wichtig erscheint, steht in /var/log/vmkwarning:

Code: Alles auswählen

Nov 20 07:59:38 srvhvbgvifd0001 vmkernel: TSC: 1899969192 cpu0:0)WARNING: MPS: 289: ignoring duplicate int for bus 0 slot 4, busIRQ 16

Ich hatte einen Call bei der Firma aufgemacht, die unsere Hardwarestörungen bearbeiten. Es wurde mir jedoch mitgeteilt, dass nach Auswertung des ServerView-Archives keine Hardwareprobleme vorgekommen sind. Weiterhin wurde mir mitgeteilt, dass ich von FSC auch keine anderen Informationen bekommen werde (einen Call direkt bei VMware darf ich nicht aufmachen, ich muss mich direkt an FSC wenden).
Hat jemand eine Idee?

Vielen Dank schon mal,
Olaf

[storageguru]

Hallo,

Ich lese in dem PSOD immer wieder Hinweise auf mks (mouse, keyboard, screen),
sodass ich einen Softwarefehler nicht ausschließen kann.

Ich würde weiter FSC auf den Geist gehen, wenn die den Service für VMware
machen, müssen die auch die PSODs auswerten. Wenn die das nicht hinbekommen,
sollen die es gefälligst an VMware weiterreichen.

Hattest du das schon öfters?

Mfg Marco

P.S.: Halt mal auf dem laufenden was da so passiert, weil alles Positive und Negative
über FSC und VMware interessiert mich sehr. Danke dir.

[Tschoergez]

Hi,

prinzipiell schließe ich mich dem Marco an: FSC muss den PSOD analysieren, oder, wenn sie selber keine Lösung haben, das an VMware weitergeben.

Ein kurzer googel gab folgendes:
http://communities.vmware.com/message/1 ... B198286C07

Ist zwar für ESX3.5, hilft aber vielleicht weiter.

Hast Du alle Patches eingespielt für den 3.0.2?

Kannst Du den Fehler reproduzieren, oder zumindest rausfinden, welche VM die world-ID 1121 zum crashzeitpunkt hatte?

viele grüße,
jörg

[bolder]

Hallo!

Zunächst mal vielen Dank für die Antworten.
Hat jetzt einen Moment gedauert, weil ich dienstlich abwesend war.

Ich lese in dem PSOD immer wieder Hinweise auf mks (mouse, keyboard, screen),
sodass ich einen Softwarefehler nicht ausschließen kann.

Ich würde weiter FSC auf den Geist gehen, wenn die den Service für VMware
machen, müssen die auch die PSODs auswerten. Wenn die das nicht hinbekommen,
sollen die es gefälligst an VMware weiterreichen.

Ich werde das mit mks mal weiter leiten, schaun mer mal ...

Hattest du das schon öfters?

Insgesamt jetzt dreimal, zuletzt etwa 5 Wochen vorher. Ich kann aber nicht sagen, ob es sich um den gleichen Fehler handelt.

Ist zwar für ESX3.5, hilft aber vielleicht weiter.

Hast Du alle Patches eingespielt für den 3.0.2?

Nein, ist nicht ganz aktuell.
Es soll aber ohnehin ain Upgrade auf ESX 3.5 U3 gemacht werden, voraussichtlich am 12. Dezember. Vielleicht löst das ja das Problem.

Kannst Du den Fehler reproduzieren, oder zumindest rausfinden, welche VM die world-ID 1121 zum crashzeitpunkt hatte?

Reproduzieren kann ich den Fehler nicht.
Wie kann ich nachträglich herausfinden, welche VM die world-ID 1121 hatte?

Ich bin die nächsten drei Tage weg, komme erst am Freitag wieder. Da mache ich das Upgrade. Mal sehen, was da rauskommt.

Olaf

[MisterX]

Hallo Bolder,
bei uns trat das Problem im Zusammenhang mit dem ServerViewAgent auf, den man ja für den Support von FSC auf den ESXsen installieren sollte. Der Reboot kam schon nach der Basisinstallation (update3) und anschließender Installation vom Serverview zum "hängen" bzw. zum PurpleScreen.

Nach längerem Kontakt mit dem Support von FSC kam heraus, dass der Defaultwert für den Speicher der ServiceConsole (272) zu klein war. FSC hatte auch VMware mit im Boot und die hatten empfohlen den Speicher für die ServiceConsole auf 800MB zu erhöhen.

Ich habe das auf unseren ESXen durchgeführt und habe nun keine Probleme mehr.

Wenn du also auch ESX mit dem ServerView-Agent nutzt, wäre das eventuell auch bei dir eine Lösungsmöglichkeit.

[bolder]

Hallo MisterX,

ja, ich hatte auch schon immer die Vermutung, dass es irgendwie mit ServerView zusammen hängt. Deine Antwort bestätigt mich darin.

Wir haben auf allen Systemen 512 MB für die Service-Console zugewiesen. Den Wert werde ich erhöhen und hoffe, dass dann Ruhe einkehrt.

Im übrigen habe ich jetzt auf ESX 3.5 U3 upgedated.

Danke an alle, die mir hierbei geholfen haben!

Gruß
Olaf

[MisterX]

die 512 sind ja schon recht hoch.

Wenn irgendwas bei unseren ESXen mal nicht klappt, installiere ich die gerne mal komplett (mit dem letzten Iso) neu. Das hat mir in der Vergangeheit oft geholfen.
Und die Updates, die durch den Updatemanger zur verfügung stehen, spiele ich immer im Paket ein. Immer die Update von einem ReleaseDate in einem Stück. Dann, wenns geklappt hat, die von nächsten. (kann nat. zu viel des guten sein, aber damit fahre ich ganz gut)

ich bin seid 3Tagen am patchen, mitlerweile beim 17ten Host erfolgreich.
Einen musste ich komplett neu machen, weil, warum auch immer, der Ordner "/opt/vmware/aam" leer war und ich den HA-Agent daher nicht aktivieren konnte.

Neu aufsetzen dauert bei mir mitlerweile ca 45min. Suchen dauert länger

[bolder]

Na ja, da die meisten unserer ESX-Server Standalone in verschiedenen Lokationen sind kann ich dort kein VMotion nutzen. Somit ist mir die Ausfallzeit für das neu Aufsetzen zu groß.

Olaf