ESXi 5.5 startet immer neu

[photographix]

Hallo @ all,

seitdem wir die Version 5.5 U1 (1892794) auf unseren ESXi fahren starten diese unregelmäßig neu, bzw ich denke das - da die VMs dann aus sind. Mit HA werden diese auf einem anderen ESXi neu gestartet. Wir haben die VMs auf einem NFS Store (Nexenta).

Wir haben die ESXi neu aufgesetzt, hatten vorher 4.1 Essentials und nun Standard. Können also vMontion und HA, sowie FT nutzen. Vorher hatten wir diese Probleme mit den ESXi4.1 aber nicht.

Leider finde ich den Fehler in den Logs nicht - daher als Zip anbei. Dieser Server hat gegen 17:45 am 24.08.2014 neu gestartet bz die VMs offline genommen.

http://www.imagenetz.de/f9b7f93d2/syslog2.zip.html

Danke im Voraus für Tips.

LG

[irix]

- Irgendeine USV Steuerung im Einsatz oder eine andere Art von Automatisierung?
- Werden die VMs hart ausgeschaltet oder herunter gefahren?
- Rebootet der Host "sauber" oder startet er brutal einfach neu? Bei letzterem muesste eigentlich HA zuschlagen.
- Welcher Hardwarehersteller? Ich erinnere mich an ein HP ASR Problem welches Hosts unplannmaessig neustartet

Mal davon abgesehen.. bei so einem zentralen Problem wuerde ich mich an den VMware Support wenden weil dafuer bezahlt man den ja mit.

Gruss
Joerg

[photographix]

Hallo,

Danke für die schnelle Antwort. Wir setzen erst seit vier Wochen die 5.5 ein. Ob die Server hart durchstarten oder nicht kann ich nicht sagen. Ich werde aus den Logs nicht schlau. Es ist immer Abends/Nachts oder am Wochenende wo keiner hier ist und eigentlich keine Belastung auf dem Server ist. Die VMs werden hart ausgeschaltet.

Windows VMs schicken dann den normalen Dialog "wurde nicht korrekt runter gefahren - bitte Grund angeben". Mit aktivierten HA werden die VMs auf einem anderen Host neu gestartet. Was aber auch Problematisch ist - gerade bei VMs mit DBs.

USV ist dran aber nicht getriggert. Also nur Steckdose. Sonstiger Zugriff nur von Veeam B&R v7 zum Backup. Das läuft/lief zu dieser Zeit aber nicht. Anderer Serevr die an dieser USV hängen laufen auch weiter. Bsp. die anderen ESXi.

HW ist bei den 2 problematischen Servern von Thomas Krenn. Ungefähr zwei Jahre alt. Maintenance abgelaufen.

Wir haben dann noch einen DELL RowerEdge710 und einen Fujitzu RX300S6.
Mit allem haben wir einen Cluster. Aber nur die Thomas Krenn spinnen so rum.

[irix]

Ich wuerde nen Case bei VMware aufmachen.

Gruss
Joerg

[Dayworker]

Was sind das für Thomas-Krenn-Server?
Das Log enthält einige Einträge der Art "X9DRW-3LN4F+/X9DRW-3TF+" und das läßt schon mal auf Server-HW von SuperMicro schliessen.

Ich hab den genauen Punkt nicht gefunden, aber irgendwie werden Snapshots versucht anzulegen und diese werden wieder abgebrochen, da die VMSN-Datei schon existiert oder die Queue voll ist (Pool 0: Blocking due to no free buffers). Die Suche gestaltet sich algemein etwas schwierig, da wir keinen Zeitrahmen oder zumindest ungefähre Shutdown-Zeiten haben und die mehr als 62-Tausend Zeilen tun ihr übriges.

Wenn ich das Log richtig sehe, ist das des Web-Clients. Was sagen denn die lokalen ESXi-Logs selbst dazu aus.

[irix]

Er hat doch da ein Datum und Zeit genannt. Evtl. noch 2h wegen UTC einbeziehen.

Gruss
Joerg

[Dayworker]

Ja die Zeitangabe stimmt auch wieder, denn das Log beginnt mit:

<166>2014-08-24T15:49:17.860Z esxi04 Hostd: [FF8A75C0 info 'Libs'] Common: MSR 0x3a = 0x7

Interessant wären aber die davor liegenden Einträge. Daher auch meine Hoffnung, daß die ESXi-Logs noch Einträge davor mitgeschrieben haben.

[photographix]

Guten Morgen @ all,

danke für die Antworten. Ich werde versuchen ein paar Infos beizusteuern:
unserer 2 Server von Thomas Krenn mit SuperMicro Board:

2x 1HE Intel Dual-CPU RI2108 Server
Zertifiziert für VMware vSphere
2x Intel Xeon 6-Core E5-2630 2,30GHz 15MB 7.20GT/s
192 GB ECC Registered DDR3 1600 RAM 2 Rank ATP (24x 8192 MB)
Intel i350 Quad Port on Board LAN
Intel I350-T4 Quad Port Netzwerkkarte


Die Logs sind aus dem "c:\ProgramData\VMware\VMware Syslog Collector\Data\" Verzeichnis von unserem Vcenter. Wir lassen die ESXi dahin loggen. Ansonsten nutzen wir den (schrecklichen) Webclient.

Ich kann leider die Neustarts nicht mit Veeam in Verbindung bringen. Dieser Job läuft nur Nachts ab 22 Uhr und ist meist gegen 2 Uhr nächsten Tag fertig. Wir sichern 34 VMs. Die ESX starten aber, wenn, dann davor neu.

Anbei das Log vor 15:49Uhr am 24.08.2014
http://www.imagenetz.de/ff940be26/syslog4.zip

[Dayworker]

Das Syslog ist doch sicherlich wieder so ein Mammut-Log und darin verliert man schnell die Übersicht. Verlinke doch boitte mal die Logs des ESXi selber. Darin dürften wir wesentlich schneller eine Ursache finden, hoffentlich.

[irix]

Erstelle ein LogBundle und mach bei VMware einen Case auf. Das ist doch zielfuehrender als das wir hier im Nebel rumstorchern. Wenn ihr "Standard" habt dann habt ihr auch Support. Wenn VMware dann mit dem Finger auf die Hardware zeigt kann man immer noch ueberlegen. Gibt doch bestimmt auch FW Upgrade oder man ruft bei Krenn mal an.

Gruss
Joerg

[photographix]

Hallo @ all

da einer der Server heute Nacht wieder neu gestartet hat haben wir bei VMware einen Case aufgemacht. Diese kümmern sich jetzt drum. Ich melde mich wenn ich mehr darüber weiss.

[photographix]

Das Feedback von VMware ist da.

Server nicht mehr in HCL. Nur bis 5.1 zugelassen :_(
Jetzt müssen wir uns mal an Thomas Krenn wenden.

Kann man mit der 5.5er Lizenz auch einen 5.1 betreiben?
Kann ich 5.5 udn 5.1 zusammen in einem Cluster mit FT, HA und vMotion laufen lassen?

[irix]

Das Feedback von VMware ist da.

Server nicht mehr in HCL. Nur bis 5.1 zugelassen :_(
Jetzt müssen wir uns mal an Thomas Krenn wenden.

Kann man mit der 5.5er Lizenz auch einen 5.1 betreiben?

Ja, das geht und ist auch erlaubt. Die Keys haben sich nicht geaendert.

Kann ich 5.5 udn 5.1 zusammen in einem Cluster mit FT, HA und vMotion laufen lassen?

Fuer HA und vMotion kann ich das bestaetigen. Fuer FT kann ich es nicht sagen.

Gruss
Joerg

[JustMe]

Kann man mit der 5.5er Lizenz auch einen 5.1 betreiben?

Ja, die Lizenz kann direkt verwendet werden (oder eine Host-Lizenz aus dem Pool des vCenters zugeweisen werden).

Kann ich 5.5 udn 5.1 zusammen in einem Cluster mit FT, HA und vMotion laufen lassen?

Radio Eriwan wuerde wieder sagen: Im Prinzip ja, zumindest was HA und vMotion angeht. Es duerfen selbstverstaendlich in den VMs keine Features von 5.5 verwendet werden (HW-Version 10, etc.pp.).
FT waere ich jetzt etwas skeptisch...aber da sollte ja eigentlich auch schon Server-HW nicht unterschiedlich sein. Habe ich aber selbst noch nicht probiert.

Edit: Zu spaet

[Dayworker]

Guten Morgen @ all,

danke für die Antworten. Ich werde versuchen ein paar Infos beizusteuern:
unserer 2 Server von Thomas Krenn mit SuperMicro Board:

2x 1HE Intel Dual-CPU RI2108 Server
Zertifiziert für VMware vSphere
2x Intel Xeon 6-Core E5-2630 2,30GHz 15MB 7.20GT/s
192 GB ECC Registered DDR3 1600 RAM 2 Rank ATP (24x 8192 MB)
Intel i350 Quad Port on Board LAN
Intel I350-T4 Quad Port Netzwerkkarte


Die Logs sind aus dem "c:\ProgramData\VMware\VMware Syslog Collector\Data" Verzeichnis von unserem Vcenter. Wir lassen die ESXi dahin loggen. Ansonsten nutzen wir den (schrecklichen) Webclient.

Ich kann leider die Neustarts nicht mit Veeam in Verbindung bringen. Dieser Job läuft nur Nachts ab 22 Uhr und ist meist gegen 2 Uhr nächsten Tag fertig. Wir sichern 34 VMs. Die ESX starten aber, wenn, dann davor neu.

Anbei das Log vor 15:49Uhr am 24.08.2014
http://www.imagenetz.de/ff940be26/syslog4.zip

<166>2014-08-24T15:45:41.474Z esxi04 Vpxa: [B3F32B70 verbose 'VpxaHalCnxHostagent' opID=WFU-28826798] [WaitForUpdatesDone] Completed callback
<182>2014-08-24T15:49:13Z esxi04 vmkernel: VMB: 49: mbMagic: 2badb002, mbInfo 0x101148

Irgendwie dazwischen ist etwas passiert und dann hat der ESXi einen Reboot hingelegt. Das vCenter konnte das aber nicht mehr loggen, der ESXi sollte dennoch Log-Einträge haben.

MicrocodeUpdate: 208: Update signature 70d00000000, Platform ID 0.

Solche Einträge finde ich genau 24 mal und das paßt zu deinen beiden Hexacore-CPUs plus HT.

<30>2014-08-24T15:48:18Z esxi04 watchdog-vobd: Executing '/usr/lib/vmware/vob/bin/vobd group=host/vim/vmvisor/vobd'

Scheinbar gibt es einen Watchdog. Wenn der nicht rechtzeitig angetriggert wird, startet der Rechner/Server halt neu.

<182>2014-08-24T15:48:15.530Z esxi04 vmkernel: cpu23:32831)ScsiCore: 130: Starting taskMgmt watchdog world 32831
<182>2014-08-24T15:48:15.530Z esxi04 vmkernel: cpu20:32980)VSCSI: 2602: Starting reset handler world 32980/1
<182>2014-08-24T15:48:15.530Z esxi04 vmkernel: cpu4:32832)ScsiCore: 130: Starting taskMgmt watchdog world 32832
<182>2014-08-24T15:48:15.530Z esxi04 vmkernel: cpu22:33079)ScsiCore: 63: Starting taskmgmt handler world 33079/1
<182>2014-08-24T15:48:15.530Z esxi04 vmkernel: cpu21:32981)VSCSI: 2796: Starting reset watchdog world 32981

Watchdog geladen.

<14>2014-08-24T15:48:24Z esxi04 vmkdevmgr: main [info]: Found driver vmkernel for device bus=logical addr=pci#p0000:03:00.0#0 id=com.vmware.HBAPort.
<14>2014-08-24T15:48:24Z esxi04 vmkdevmgr: main [info]: Set alias for device 0x336c410961246667
<182>2014-08-24T15:48:24.654Z esxi04 vmkernel: cpu10:33446)VMK_PCI: 720: device 0000:81:00.0 allocated 1 interrupts (intrType 1)
<12>2014-08-24T15:48:24Z esxi04 vmkdevmgr: main [warn]: Failed to set driver for 0x336c410961246667: Sysinfo error on operation returned status : Not found. Please see the VMkernel log for detailed error information
<12>2014-08-24T15:48:24Z esxi04 vmkdevmgr: main [warn]: Error binding driver vmkernel for bus=logical addr=pci#p0000:03:00.0#0 id=com.vmware.HBAPort

Hier wäre das VMkernel-Log interessant zu sehen.

<182>2014-08-24T15:48:25.081Z esxi04 vmkernel: cpu4:33466)<6>IPMI System Interface driver.
<182>2014-08-24T15:48:25.081Z esxi04 vmkernel: cpu4:33466)PCI: driver ipmi_si is looking for devices
<182>2014-08-24T15:48:25.081Z esxi04 vmkernel: cpu4:33466)PCI: driver ipmi_si claimed 0 device
<182>2014-08-24T15:48:25.081Z esxi04 vmkernel: cpu4:33466)<6>ipmi_si: No BMC IRQ configured in SMBIOS. Operating in polling mode
<182>2014-08-24T15:48:25.081Z esxi04 vmkernel: cpu4:33466)<6>ipmi_si: probing via SMBIOS
<182>2014-08-24T15:48:25.081Z esxi04 vmkernel: cpu4:33466)<6>ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0
<182>2014-08-24T15:48:25.081Z esxi04 vmkernel: cpu4:33466)<6>ipmi_si: Adding SMBIOS-specified kcs state machine
<182>2014-08-24T15:48:25.081Z esxi04 vmkernel: cpu4:33466)<6>ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca2, slave address 0x0, irq 0
<182>2014-08-24T15:48:25.728Z esxi04 vmkernel: cpu4:33466)<6>ipmi_si ipmi_si.0: Found new BMC (man_id: 0x 002a7c, prod_id: 0x 0630, dev_id: 0x20)
<182>2014-08-24T15:48:25.728Z esxi04 vmkernel: cpu4:33466)<6>ipmi_si ipmi_si.0: IPMI kcs interface initialized

Für das BMC wurde kein IRQ konfiguriert und damit ist das BMC sicherlich auch nicht vollständig konfiguriert. Das bedeutet für ein SuperMicro-MB meines Wissens eigentlich, daß das BMC auf allen verbauten Nic's (der Treiber "igb" deutet schon auf die verbauten Intel-Nic's hin) lauscht und ggf aktiv wird. Wenn ich das bei SuperMicro noch richtig in Erinnerung habe, hilft eine BMC-Deaktivierung hier auch nichts, da das BMC wegen der fehlenden Config und somit Einschränkung auf die "Broadcom NetXtreme II" immer auf sämtlichen verbauten Netzwerkkarten mitlauscht. Die Broadcom-Nic ist auch in meinem Dell-Server in Form von "iDRAC express" im BMC enthalten. Wenn das BMC mitlauscht, wäre es daher durchaus denkbar, daß der Reboot von aussen über das BMC getriggert wird. Soweit ich weiß, hat Supermicro einige BMC-Probleme bei seinen MBs beseitigt und der Rest besteht weiterhin. Supermicro sagt aber relativ deutlich, daß sich ihrer Meinung nach BMCs nicht 100%ig absichern lassen und man daher den Einsatz nur in einem abgesicherten Netzwerk empfiehlt. Wenn der ESXi jedoch irgendwo beim Hoster steht und somit vor dem ESXi keine HW als Absicherung mehr davorstehen kann, trennt nur noch die eingebaute ESXi-Firewall diesen von der Aussenwelt.

<166>2014-08-24T15:49:17.693Z esxi04 Hostd: [FF8A75C0 info 'Hostsvc.AutoStartManager'] VM autostart configuration: /etc/vmware/hostd/vmAutoStart.xml
<166>2014-08-24T15:49:17.694Z esxi04 Hostd: [FF8A75C0 warning 'Hostsvc.StorageSystem'] HandleCoreDumpConfigurationIssue: Failed to remove host config issue: esx.problem.coredump.unconfigured2
<166>2014-08-24T15:49:17.694Z esxi04 Hostd: [FF8A75C0 verbose 'Hostsvc.HostConfigSyncManagerImpl'] Install device is '/vmfs/devices/disks/mpx.vmhba32:C0:T0:L0'
<166>2014-08-24T15:49:17.764Z esxi04 Hostd: [FF8A75C0 info 'Hostsvc.HostConfigSyncManagerImpl'] Backing of /bootbank is USB

Verstehe ich das richtig, daß der ESXi von USB startet?
Dazu würden dann meiner Meinung nach die folgenden Log-Einträge passen:

<13>2014-08-24T15:49:13Z esxi04 usbarbitrator: unclaiming USB devices
<13>2014-08-24T15:49:13Z esxi04 usbarbitrator: Found reserved USB device vmhba32
<182>2014-08-24T15:49:14.010Z esxi04 vmkernel: cpu1:34087)<6>usb passthrough enabled; all eligible devices will be unclaimed by kernel drivers except for ESXi boot device vmhba32
<13>2014-08-24T15:49:14Z esxi04 usbarbitrator: rescanning to complete removal of USB devices

[photographix]

Hallo und guten Morgen @ all,

Ja der ESX startet von einem internen USB Stick. Das konnte man "damals" bei Thomas Krenn so erwerben.

Den BMC nutzen wir nicht da der Serverraum von unserem Büro nur 5 Meter entfernt ist und wir - wenn es Probleme gibt - hin laufen. Ist also von uns auch nicht eingerichtet worden. Da müsste man mal nachsehen was man dort einstellen kann und welche Optionen es gibt.

Laut VMware haben wir aber keinen Support da außerhalb der HCL.

Anbei noch ein Log Bundle auf FTP
http://fotowelt.biz/tmp/esxi04.photo24. ... -36-18.tgz

[irix]

Frag halt bei Krenn mal nach ob sie was sagen koennen zum Thema. Wobei ein E5-2630 kann doch noch nicht viel aelter als 3 Jahre sein oder?

Wenn beide betroffen sind wuerde ich mal einen zum Test auf eine fuer dich supportete ESXi Version downgraden in dem man neu installiert.
Gruss
Joerg Behrens

[photographix]

So der Fasching geht weiter. Thomas Krenn verweist mich auf ein Dokument von Supermicro wo unser System mit einer neuen Revision des Prozessors (v2) vSphere 5.5 zertifiziert ist. Thomas Krenn sieht hier leider keine Möglichkeit uns zu helfen. "..Wir könnten uns ja mal an Supermicro wenden und dort nachfragen was der Unterschied ist..."

Aktueller Stand:
VmWare -> kein HCL -> Thomas Krenn -> Board nur eingekauft -> Supermicro -> (Prozessor von Intel) ...

Alles in allem keine Lösung :_(

Wir werden zu 5.1 zurückrollen.

[irix]

...
Wir werden zu 5.1 zurückrollen.

Vorher gucken ob ich schon vHW 10 einsetzt fuer VMs weil dann ist es Essig mit einem Downgrade.

Gruss
Joerg

[photographix]

Hahah ....
Mist!

und nun? Ist der Converter mein Freund oder eher auch nicht.

[irix]

Hahah ....
Mist!

und nun? Ist der Converter mein Freund oder eher auch nicht.

Ich mach dir gerne ein Angebot ueber 2 neue Dell Server . Naechte Woche kommen die neuen Intel "v3".

Gruss
Joerg

[photographix]

Galgenhumor ^^

Danke für das Angebot. Aber unsere Thomas Krenn haben sich noch nicht wirklich rentiert. Die müssen noch etwas arbeiten für ihr Geld.

[Dayworker]

Hahah ....
Mist!

und nun? Ist der Converter mein Freund oder eher auch nicht.

Entweder der Converter, was ich für sinnlosen Aufwand halte, oder VMX und VMDK bearbeiten...

So der Fasching geht weiter. Thomas Krenn verweist mich auf ein Dokument von Supermicro wo unser System mit einer neuen Revision des Prozessors (v2) vSphere 5.5 zertifiziert ist. Thomas Krenn sieht hier leider keine Möglichkeit uns zu helfen. "..Wir könnten uns ja mal an Supermicro wenden und dort nachfragen was der Unterschied ist..."

Aktueller Stand:
VmWare -> kein HCL -> Thomas Krenn -> Board nur eingekauft -> Supermicro -> (Prozessor von Intel) ...

Alles in allem keine Lösung :_(

Ausgehend von deinen bisher verlinkten Logs und den dort immer wieder aufgeführten Microcode-Updates, geh doch mal den anderen Weg und laß die ESXi-Rechner mal mit einer Linux-basierten, möglichst aktuellen Live-CD booten. Ich hatte auf meinem inzwischen verstorbenen Dell-Desktop schwer nachvollziehbare, da nicht reproduzierbare CPU-Probleme und die verschwanden wie von Geisterhand, nachdem ich einfach mal ne aktuellere Linux-CD gebootet hatte. Die vorher immer geloggten Microcode-Updates, wurden danach auch bei meiner älteren Distri nicht mehr geloggt und da sich zwischenzeitlich weder am OS noch am Bios etwas geändert hatte, kann eigenlich nur die Live-CD die Lösung gebracht haben. Falls es damit nicht klappt, frag bei Supermicro nach, wo das Problem genau liegt. Intel hält seine Erratum-Liste immer sehr aktuell und von daher sind die MB-Hersteller auch in der Pflicht von Bios-/FW-Updates. Speziell SM ist dort als relativ pflegeleicht bekannt.

[moo2102]

Hi habt ihr da eine lösung bekommen?
Wir haben ein ähnliches Problem aber bei uns sind die Server wohl auf der HCL.

[Supi]

Hi habt ihr da eine lösung bekommen?
Wir haben ein ähnliches Problem aber bei uns sind die Server wohl auf der HCL.

Nunja, auf die doch sehr unkonkrete Frage ( welche HW? Welche ESXI Version und Patchlevel) kann die Antwort nur lauten:
So ihr auf VMWARE Support und Subscription habt, dann bei VMware einen Fall aufmachen.