VMware-Forum

Guten morgen zusammen,

zu unserer Konfiguration:
- wir betreiben ESX4.1 auf HP DL380 G7.
- der ESX ist auf einem lokalen Laufwerk installiert (RAID 1+0)
- es ist ein zusätzliches lokales Laufwerk für VMs eingerichtet (RAID 5)
- die meisten VMs liegen jedoch im SAN, das über FC angeschlossen ist

wir hatten am Freitag an einem ESX4.1 das Problem, dass die Konsole des ESX nichtmehr reagiert hat.
VMs auf dem lokalem Storage wurden nichtmehr ausgeführt. Bei direktem Blick auf dem Server konnten wir feststellen, dass von dem RAID-5 keine LEDs mehr aktiv waren. Die LEDs der System-Platte waren aktiv.
VMs auf einer SAN-LUN wurden weiterhin ausgeführt.
Ein lokaler Loginversuch mit root hat nichtmehr funktioniert. Auf der lokalen Konsole wurde "INIT: version 2.86 reloading" angezeigt, der ESX hat jedoch noch auf einen PING geantwortet.
Im Vcenter wurde dieser HOST als getrennt angezeigt, daher konnten wir die noch aktiven VMs nicht per Vmotion verschieben.

Nachdem wir die noch aktiven VMs kontrolliert per RemoteDeskop heruntergefahren und den ESX resetted haben lief alles wieder normal.

Der Fehler ist aufgetreten, wärend ich auf einer VM auf dem lokalen Storage die VMWare-Tools aktualisiert habe. Ob dies in direktem Zusammenhang mit dem Fehler steht ist fraglich.

In der VMWare-Community wurde schonmal ein ähnlicher Fehler berichtet (leider unbeantwortet): http://communities.vmware.com/thread/263592?tstart=0

Es sind für mich so aus, als ob der ESX nichtmehr auf das RAID5 zugreifen konnte und sich als Folge aufgehangen hat. Alle VMs auf SAN-Storage wurden ja weiterhin ausgeführt.
In den Logs kann ich nur erkennen, dass etwa eine halbe Stunde zuvor syslogd restarted ist, worauf einige Einträge im Log zu finden sind. Ob das ein Standard-Ereignis war, kann ich leider nicht beurteilen.

Jemand eine Idee? Ich habe parallel hierzu einen Case beim Support aufgemacht….

Christian

Hallo
hatten das gleiche Problem. virtuellen Systeme liefen noch, nur der komplette ESX war nicht mehr bedienbar (weder über vCenter, über ssh oder lokal.)
haben dann genauso die virtuellen Systeme beendet und die ESX Kiste durchgestartet, danach war alles wieder OK
das ganze fand auf ner DELL Hardware 2950 statt

die letzten Meldungen loakl am System waren übrigens
...
[51174.684018] SCSI device sdu. drive cache: write through
[51174.691139] sd 3:0:21:0: Attached scsi disk sdu
[51174.697396 sd 3:0:21:0 attached scsi generic sg22 type 0

die können aber auch schon länger da gestanden haben, ich schau da nicht täglich drauf

ist ESX 4.0 Kernel 2.6.18-128

hat sich was aus dem Call ergeben?

Gruss

Der Call hat ergeben dass es kein VMware-Fehler ist.
Das Problem ist laut denen in der Ecke Array-Controller/Festplatten bzw korruptem Filesystem zu suchen. Also wie vermutet nichts konkretes...

Ich lasse die Kiste jetzt mal so weiterlaufen. Fall das nochmal auftritt werde ich die Hardware tauschen....

Danke für die Info
bei uns wars im Mitte Juli, danach kein Problem mehr erkannt

Also bei uns wars leider nicht so, dass danach kein Problem mehr erkannt wurde. Ging ca. 1 Woche gut, aber letztes WE ists dann wieder passiert. Diesmal ist der Server aber nach jedem Reset immer nach ca. 10 min wieder weggeschmiert.
Nach etwas hin und her hat sich herausgestellt, dass eine Festplatte im RAID 5 tatsächlich eine Macke hatte, aber leider von keinem Agent festgestellt/gemeldet wurde.

Ich kann also nur empfehlen die Kisten nach so einem Fall gründlichst zu prüfen.
Der ruhigen Wochenenden zuliebe