VM stürzt ab, Host fährt runter, wo finde ich LOGs

[Rik]

Guten Morgen zusammen!

Ich brauche bitte mal wieder Eure Hilfe!

In letzter Zeit passiert es mir häufiger, das zB eine VM auf meinem Server nicht mehr angesprochen werden kann oder sich abstellt. Es kam auch schon vor das der kompletter Server auf einmal aus war.

Nun dachte ich suche ich mal nach LOGs wo das ganze evt protokolliert wird (auch wenn ich die LOGs wahrscheinlich nicht verstehen werde ).
Könnt ihr mir sagen wo ich die LOGs finden kann und nach was ich Ausschau halten sollte um dem Fehler auf die Schliche zu kommen?

Server: x3650, ESXi

Danke & Gruß
Rik

[kastlr]

Hallo Rik,

Logfiles findest du unter /var/log, interessant sind hier

• vmkwarning.log
• vmkernel.log

Nach einem Server Ausfall sollten sich im Verzeichnis /var/run/log noch Logfiles befinden, welche vor dem Ausfall des Servers erzeugt wurden.

Gruß,
Ralf

[Rik]

okay, die beiden Dateien in /var/log kann ich mittels Putty finden, in /var/run/log steht leider nichts mehr.

edit: in /var/run/log sind doch noch jede Menge Dateien

Wie bekomme ich die beiden Dateien auf meinen "Home-PC" um sie besser sichten zu können?

[kastlr]

Hallo Rik,

zum Beispiel mit WinSCP.

Gruß
Ralf

[Rik]

ich Depp, auf die Idee mein Filezilla zu verwenden bin ich nun erst gekommen, Danke Ralf!

wie kann ich nun am besten dem Problem auf die Spur kommen, nach was soll ich Ausschau halten?

[kastlr]

Na ja,

das ist nicht ganz so einfach zu erklären, hängt auch unter anderem davon ab, wie sich dein Problem mit der VM genau äußert

Ich habe übrigens noch einen wichtigen Log vergessen, es handelt sich hier um den vmware.log im Verzeichnis der virtuellen Maschine.
In dem VM Verzeichnis können mehrere davon existieren, die alten werden archiviert.
Eventuell läßt sich da schon etwas herauslesen oder bekommst zumindest Informationen, was zum entsprechendem Zeitpunkt mit der VM passiert ist.

In jedem Fall findest du dort die von der VM genutzten World ID, danach kannst du dann im vmkernel.log suchen.
Wenn du den Zeitpunkt kennst, an dem das Problem mit der VM aufgetreten ist kannst du auch gleich im vmkernel.log dahin springen.
Die Zeiten im vmkernel.log sind immer UTC, wenn dein Problem z.B. um 14 Uhr auftrat mußt du in dem Log nach 12 Uhr springen.

Wenn dein ganzer ESX Server auch immer mal wieder betroffen ist würde ich auch mal nach SCSI Fehlern Ausschau halten.

Da ich nicht weiß welche Komponenten du einsetzt würde ich zuerst nach H:0x suchen, dieser String ist immer im Log, wenn es Probleme mit dem Zugriff auf Disks gibt.

Failed ist auch eine gute Wahl, kann aber inflationär verwendet werden.

Wie viele Zeilen hat denn dein vmkernel.log File?
vmkwarning.log's sind kleiner, enthalten dafür aber auch nur Fehler und warnings und helfen nicht dabei, die Vorgeschichte zu erkennen.

Viel Spaß beim Logfile lesen

Gruß
Ralf

[Dayworker]

Wenn du die Dateien vmkwarning.log, vmkernel.log und das vmware.log auf einen Freehoster oder eignen Webspace hochlädst, können wir dir bei der Analyse vielleicht helfen.

[Rik]

so, heute Nacht, zwischen 20:10 und ~ 10:30 ist der Server komplett runtergefahren
Habe nun mal die 2 Logs vmkernel & vmkwarning bei CX hochgeladen
vmware.log denke ich ist nicht relevant, da es wohl nicht von einer VM initialisiert wurde, oder?
Hier der Link
LOGs bei CX

Vielen dank für Eure Hilfe, ich verstehe bei den Logs bisher so gut wie nichts, außer das es ein Problem mit den SCSI-Laufwerk(en) gibt...?!

Gruß
Rik

[Dayworker]

So wie sich das für mich darstellt beim Drüberfliegen, ist entweder eine LUN oder ein komplettes Laufwerk nicht ansprechbar.
Poste mal mehr Details zu deiner Server-HW bezüglich Storage etc.

[Rik]

okay, hier die Aufstellung meiner Laufwerke in meinem Server:

* Raid1: ein Raid-1-Verbund aus 2 72,6GB-Festplatten

* Raid2: ein Raid-1-Verbund aus 2 1000GB-Festplatten
dazu ein 1000GB Hotspare

* ein NFS (Synology) dient aber nur für Backups und ist nicht für die VM zur Verfügung gestellt

braucht ihr noch mehr Infos? Wenn ja was, stelle sie gerne zur Verfügung [/list]

[kastlr]

Hallo Rik,

der folgende VMware Artikel bezieht sich auf einige Meldungen, welche sich auch in deinem vmkernel Log finden lassen.
VMware ESXi 5.0, Patch ESXi500-201203211-UG: Updates the VMware ESXi 5.0 scsi-aacraid driver
Vielleicht passt das ja zu deinem Problem.

Folgender KB beschreibt, wie alle Daten zwecks Analyse eingesammelt werden.
Collecting diagnostic information for VMware ESX/ESXi using the vSphere Client

Informationen über deinen Adapter solltest du unter /proc/scsi/aacraid finden, die kannst du ja mal hier posten.

Gruß,
Ralf

[Rik]

Hi Ralf!

der folgende VMware Artikel bezieht sich auf einige Meldungen, welche sich auch in deinem vmkernel Log finden lassen.
VMware ESXi 5.0, Patch ESXi500-201203211-UG: Updates the VMware ESXi 5.0 scsi-aacraid driver
Vielleicht passt das ja zu deinem Problem.

das stimmt, das scheint "irgendwie" zu passen. Nun habe ich allerdings schon auf 5.1 geupdatet, dachte da wären die Patches schon mit drin? Ist das nicht so? Wenn nicht, kann ich die Patches für 5.0 trotzdem für meinen 5.1 verwenden und einspielen?

Folgender KB beschreibt, wie alle Daten zwecks Analyse eingesammelt werden.
Collecting diagnostic information for VMware ESX/ESXi using the vSphere Client

das habe ich nun mal gemacht und die tgz-Datei mit hogeladen: http://share.cx.com/rnkPsC
Mit den Inhalten komme ich nicht mehr klar, das ist mir zu hoch, lerne aber gerne dazu

Informationen über deinen Adapter solltest du unter /proc/scsi/aacraid finden, die kannst du ja mal hier posten.

das Verzeichnis ist bei mir leer...

vielen Dank & Gruß
Rik

[Rik]

hab mal gerade am Server geschaut: eine der Festplatten aus dem "Raid2" ist anscheinend ständig in Arbeit, die Kontroll-LED ist quasi fast ständig an, nicht so wie bei den anderen Festplatten die "nur" immer mal wieder an sind...

[kastlr]

Hallo Rik,

also laut VMware HCL ist das auch der aktuellste Treiber, allerdings ist dein BIOS etwas veraltet.
Laut Logs setzt du Version 5.2.0-16002 (15 Juni 2010) ein, auf der IBM Webseite steht Version 5.2.0-17003 (20. April 2012) zum Download bereit.

Oftmals bilden Treiber und BIOS eine Einheit, daher schlage ich vor, das du das BIOS deines IBM/Adaptec ServeRAID 8k/8k-l8 auf den aktuellen Stand bringst.

Nur mal so am Rande, laut Logs setzt du einen IBM x3650 mit 2 * Intel(R) Xeon(R) CPU 5140@2.33GHz ein, der wird allerdings von VMware für die ESXi 5.1 U1 Version nicht unterstützt.

Gruß,
Ralf

[kastlr]

Hallo Rik,

leider kann ich dazu nichts in den Logs finden, denn die IPMI Logs sind seit dem 19.10.2012 nicht mehr aktualisiert worden, da offenbar vollgelaufen.

Versuch mal mit folgendem VMware Artikel die Logs zu clearen
The Host IPMI System Event Log Status alarm is triggered repeatedly

Gruß,
Ralf

[Rik]

Hi Ralf,

seit Deinem Posting bezüglich des Updates versuche ich vergebens dieses durchzuführen.
Die zu erstellende CD ist nicht bootfähig und der Server hat natürlich kein Diskettenlaufwerk mehr... Hast Du nen Tipp für mich wie ich das am besten bewerkstellige?

zu dem Logs: ich habe nun diese Befehle durchgeführt

Code: Alles auswählen

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

wie kann ich kontrollieren das das nun wieder "funktioniert"?

Danke!

[kastlr]

Hallo Rik,

versuche es einfach mit einem bootfähigem USB Stick.
Ich habe letztens ein BIOS Update durchführen müssen und stand vor dem selben Problem.

Geholfen hat mit liveusbcreator oder rufus.

Das Starten der Dienste wird keinerlei Auswirkungen auf die vollgelaufenen IPMI Logs haben.

Gruß,
Ralf

[Rik]

Moin zusammen!

gestern hat es dann nun endlich geklappt: ich konnte das Raid-Controller-BIOS erfolgreich auf Build 17003 updaten - tschaka, was für eine Geburt...

Nun gehts weiter:

- Wo finde ich diese "IPMI Logs"? Möchte ja nun gerne kontrollieren ob diese wieder aktuell sind

- zu dem 5.0-Patch: damit warte ich nun erstmal noch bzw wäre das überhaupt möglich nen ESXi5.1 mit nem Patch für ESXi5.0 upzudaten?

Danke & Gruß
Rik

[kastlr]

Hallo Rik,

mühsam ernährt sich das Eichhörnchen .

IPMI Logs werden vom System selber gesammelt, zum Ansehen oder Löschen mußt du daher in dein System BIOS.
Und wenn du gerade dabei bist, spring doch auch mal in das RAID Kontroller BIOS und lass dir dort den Status deiner Platten anzeigen.

Den Patch für 5.0 kannst du vergessen, dein aktueller RAID Treiber hat eine höhere Versionsnummer als die im Patch bereitgestellte Version.

Gruß,
Ralf

[Rik]

Hi Ralf!

das Kontroller-Bios hat gestern keine Fehler ausgeworfen, hatte ich extra _vor_ dem Update drauf geachtet
Das einzige was während des Starts des Server gemeldet wird, ist das ein Array "revived" ist - das ist auch das Array mit den 1000gb-Samsung-Festplatten. Allerdings bekomme ich dieses "revived" nur weg wenn ich das Array komplett lösche und wieder neu installiere laut Internet, das traue ich mir aber noch nicht zu...

Den Patch "vergesse" ich dann mal Habe gerade die neueren Patches für die 5.1 runtergeladen, zur Zeit ist Build 838463 bei mir installiert, das heißt ich sollte die Patches doch schon einspielen, oder??

[Rik]

so, hier nun mein Update:

habe die Updates für den ESXi nun auch eingespielt, scheint alles geklappt zu haben.

neue LOGs habe ich ebenfalls hochgeladen:
http://share.cx.com/MXxYSJ

Gruß und Danke im Voraus!
Rik

[kastlr]

Hallo Rik,

die IPMI Logs hast du aber immer noch nicht gelöscht.

Was mich an den vmkernel Logs ein bisschen irritiert ist der Umstand, das dein System ungewöhnliche Kommandos einsetzt.
Allerdings sind die Logs ja auch fast unmittelbar nach dem Starten der Server gezogen worden, ob die also auch weiterhin Einzug in die Logs finden kann ich daher nicht sagen.

In den Logs finden sich

• 0x4d Log Sense
• 0x5a Mode Sense
• 0x85 ATA Pass Through

Diese Kommandos habe ich bisher noch nicht oft in vmkernel Logs gesehen.

Korrektur:
Die 0x4d wurden von deiner Windows FTP VM verursacht, diese versuchte auf das CD/DVD ROM Laufwerk des Servers zuzugreifen.
Die beiden letzen Kommandos werden vom /usr/sbin/smartd abgesetzt, offenbar versuchte dieser damit den Status der Platten auszulesen.

Außerdem sehe ich APD (All Path Down) Events zum Device vmhba32:C0:T0:L0.
Hierbei handelt es sich höchstwahrscheinlich um ein per USB angebundenes Device.
Path 'vmhba32:C0:T0:L0': Vendor: 'PLATINUM' Model: 'My Drive 3.5'
Das solltest du mal überprüfen.

Weiterhin sind deine beiden VMFS5 Filesysteme zu fast 100% belegt, aber das ist dir sicherlich schon bekannt gewesen.
Filesystem Bytes Used Available Use% Mounted on
VMFS-5 999385202688 987476525056 11908677632 99% /vmfs/volumes/Samsung1000GB
VMFS-5 67914170368 64597524480 3316645888 95% /vmfs/volumes/IBM72GB

Sonst sieht das für mich soweit ganz gut aus.

Gruß,
Ralf

[Rik]

so, nun glaube ich, habe ich die IPMI-Logs gelöscht, hatte das in den Anleitungen wohl falsch verstanden. Lasse die Maschine nun nen bißchen laufen und dann stelle ich neue Logs ein.

Ja, es gibt noch eine externe-USB-Festplatte für Daten einer VM die die dort mittels PureSync hinschaufelt.

Ich habe den möglichen Festplattenplatz den VMs zur Verfügung gestellt - wird das zum Problem?

Danke und Gruß
Rik

[Rik]

Hi Ralf, Hi zusammen,

ich habe nun - nach ein paar Tagen Laufzeit des Server - die LOGs hocgeladen:
http://share.cx.com/Vg5rqh
Wäre jemand so nett und könnte sich die mal anschauen? Probleme sind mir im Moment nicht aufgefallen, alles scheint so zu laufen wie es sollte..
Danke!!

Gruß
Rik

[kastlr]

Hallo Rik,

die IPMI Logs sind immer noch nicht gelöscht.
Vielleicht hilft dir dieser Link weiter.
Clearing the hardware-log information

Auch die aacraid Fehler treten immer mal wieder auf, hier mal nur die aktuellsten.
2013-05-30T06:02:55.844Z cpu3:2174)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver AAC, for vmhba1
2013-05-30T06:02:57.845Z cpu3:2174)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver AAC, for vmhba1
2013-05-30T06:02:59.846Z cpu3:2174)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver AAC, for vmhba1
2013-05-30T06:03:01.846Z cpu2:2174)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver AAC, for vmhba1
2013-05-30T06:03:03.652Z cpu0:2064)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver AAC, for vmhba1
2013-05-30T06:03:03.652Z cpu0:2064)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver AAC, for vmhba1
2013-05-30T06:11:32.154Z cpu2:2174)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver AAC, for vmhba1
2013-05-30T06:11:34.154Z cpu3:2174)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver AAC, for vmhba1
2013-05-30T06:11:36.155Z cpu3:2174)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver AAC, for vmhba1
2013-05-30T06:11:38.156Z cpu3:2174)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver AAC, for vmhba1
2013-05-30T06:11:40.156Z cpu3:2174)WARNING: LinScsi: SCSILinuxAbortCommands:1816:Failed, Driver AAC, for vmhba1

Es gibt zwar von Adaptec aktuellere Treiber, allerdings sind die noch nicht von VMware zertifiziert.
AACRAID Driver v1.2.1-29900 for VMware
AACRAID Driver v1.2.1-30200 for VMware

Man könnte auch noch die Verwendung von MSI (Message Signaled Interrupts) anstelle vom klassischem IRQ Handling aktivieren, die aacraid Treiber bieten dafür eine Funktion.

Ob das alles allerdings erfolgreich sein könnte, kann ich nicht beurteilen.
Denn offenbar ist das Zusammenspiel zwischen Adaptec und VMware schon seit langem ein Problem.
"aacraid: Host adapter abort request" endless errors

Du solltest mal deine VM's überprüfen, vielleicht führen diese zu den entsprechenden Zeiträumen intensive Disk IO's aus, z.B. verursacht durch einen Virenscan oder durch das zeitgleiche Einspielen von Windows Hotfixes.

Gruß,
Ralf