Datenfront

Seit dem 21. Juli verdichten sich die Gerüchte um ein großes Treiberproblem innerhalb der Standardtreiber für VMware ESX 4.0.0.
Dabei handelt es sich wohl um ein Problem mit lokal eingebauten und eingebundenen Bus Adaptern zur Massenspeicheranbindung, näher um LSI und Adaptec basierte Controller für SAS, (Parallel-) SCSI und S-ATA Festplatten. Werden diese in einem Host verwendet, so kann es unter Umständen dazu kommen, dass im Falle einer Abschaltung des Servers der Cache der Adapter nicht ordnungsgemäß auf die angeschlossenen Festplatten geschrieben wird. Das führt wiederum unweigerlich zu korrupten Daten, wenn die Batterie der RAID Controller leer läuft und im Fall von lokal angeschlossenen VMFS Laufwerken auf einem Host wahrscheinlich zu Datenverlust!
Da beim ESX 4.0 Server die SC als VMDK Datei auf dem lokalen VMFS Laufwerk vorgehalten wird, sollte der Patch unverzüglich auf alle ESX 4.0.0 Systeme gleich welcher Patch- / Buildstand ausgebracht werden. Der ESXi Server ist davon zur Zeit nicht betroffen.


Der Fehler wurde von VMware bereits veröffentlicht:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012794


Gestern habe ich dazu eine sehr wichtige E-Mail über meine DELL Kanäle erhalten.
DELL geht davon aus, dass in den nächsten Tagen (03.08.) ein ausserplanmäßiges Update bereitgestellt wird, das den Fehler im Treiber behebt.
Die Tests laufen wohl schon, dauern allerdings bis zu 2 x 48h, da der RAID Controller/Cache nur alle 48h eine vollständige Entladung der Batterie erfährt.

Man sollte jetzt nicht panisch reagieren und ein Downgrade auf die Version ESX 3.5.0U4 durchführen, sondern dafür sorgen, dass die Server am (Strom-)Netz bleiben und nicht längerfristig vom Strom getrennt werden. Dazu sollte man die DPM Funktion in vSphere 4.0 temporär auf manuell setzen oder komplett abschalten.

Was unter Windows Vista oder Windows Server 2008 mittlerweile problemlos funktioniert, ist unter allen älteren Windows Betriebssystemen mit Ausnahme der Datacenter Editionen eine echte Herausforderung im Betrieb:
Das Vergrößern der Systempartition.
Gerade wo man doch durch die Systemvirtualisierung einfach die VMDK Datei der VM im laufenden Betrieb vergrößern kann oder bei RDMs die LUN, fehlt dann die Logik das Ganze auch auf der Ebene des Gast Betriebssystems durchführen zu können, denn durch die VMware Werkzeuge werden nur die Festplatten vergrößert und nicht die Partitionstabellen editiert.
Mit Hilfe eines kostenfreien Werkezugs des Herstellers DELL lässt sich die Systempartition eines Windows Servers zur Laufzeit vergrößern und das ohne, dass zuvor für die Anwendung ein Neustart fällig wäre.
Die Installationsquelle und das "Liesmich" Dokument können kostenlos über den DELL FTP Server direkt oder über die Verlinkung im Support Bereich von der DELL Website heruntergeladen werden.

direkter FTP Zugriff:
Installationsarchiv: http://ftp.us.dell.com/app/ExtPart.exe
Liesmich Datei:      http://ftp.us.dell.com/app/ExtPart.txt

Zugriff über den Einstig der Support Webseite:

ExtPart:                 http://support.dell.com/support/downloads/download.aspx?c=us&cs=19&l=en&s=dhs&releaseid=R64398&formatcnt=2&fileid=83929

Ob das Werkzeug auch lizenzkostenfrei auf nicht DELL Systemen genutzt werden darf, darüber schweigt sich DELL dabei an dieser Stelle aus...

Die neuen Pakete für DELL OMSA 6.1.0 erkennen bei einer ESX 4.0.0build164009 Basisinstallation fälschlicherweise eine bestehende OMSA 5.3.0 Installation, da der Installer die Abhängigkeiten in der RPM Datenbank abfragt.



Dazu habe ich einen Call bei DELL eröffnet und zusätzlich in den VMware Foren ein Workaround gefunden:

VMware Community vSphere 4.0 | ESX 4: http://communities.vmware.com/message/1321651#1321651
Alternativ hier als pdf Dokument: dell-omsa-6.1.0-on-esx-4.0.0-classic.pdf (71,51 KB)
Die interessante Passage habe ich mit einem gelben Textmarker markiert.

Der Installer denkt, es gäbe bereits eine alte Version von OMSA auf dem System und kommt aus dem Tritt. Abhilfe schafft hier das direkte installieren der RPM Pakete für "ESX40" und das manuelle öffnen der Firewall. ESX 3.5.0 Update 4 Systeme sind von dem Fehler nicht betroffen. Damit eine Installation des OMSA Clients auf den ESX 4.0.0build164009 reibungslos ablaufen kann muss man zuvor über folgende Befehlszeile als Administrator 'root' absetzen:

OSX-1057-XSTCGN:~ carsten$ ssh root@esx-400-xstcgn.xsteam.eu
root@esx-400-xstcgn.xsteam.eu's password:
Last login: Tue Jul 28 09:11:37 2009 from 10.2.110.121
[root@esx-400-xstcgn ~]# rpm -e --noscripts `rpm -qa | grep srvadmin`

Bei der neuen ESX 4.0.0 ISO Image Installation mit dem Build Stand: esx-DVD-4.0.0-171294.iso klappt die Installation auf Anhieb:

OSX-1057-XSTCGN:~ carsten$ ssh root@esx-400-xstcgn.xsteam.eu
root@esx-400-xstcgn.xsteam.eu's password:
Last login: Tue Jul 28 09:28:53 2009 from 10.2.110.121
[root@esx-400-xstcgn ~]# cd /tmp/
[root@esx-400-xstcgn tmp]# ls -alh
total 104M
drwxrwxrwt  5 root root  28K Jul 30 09:31 .
drwxr-xr-x 26 root root 4.0K Jun 25 12:54 ..
-rw-r--r--  1 root root 1.9K Jul 27 18:54 hostCompatList
drwxr-xr-x  2 root root 4.0K Jul 27 11:06 hsperfdata_root
drwxrwxrwt  2 root root 4.0K Jun 25 12:54 .ICE-unix
-rw-r--r--  1 root root 104M Jul 30 09:32 OM_6.1.0_ManNode_A00.tar.gz
drwxr-xr-x  3 root root 4.0K Jul 30 08:57 sfcb
[root@esx-400-xstcgn tmp]# tar -xvzf OM_6.1.0_ManNode_A00.tar.gz
[root@esx-400-xstcgn tmp]# .linux/supportscripts/srvadmin-install.sh -d -w -r -s <--- !!!Neu!!! Die Option 'd' (DELL agent) ersetzt die alte Option 'b' (base packages)

Installing the selected packages.

warning: srvadmin-cm-6.1.0-648.i386.rpm: Header V3 DSA signature: NOKEY, key ID 23b66a9d
Preparing...                ####################################### [100%]
   1:srvadmin-omilcore      ####################################### [  6%]
     To start all installed services without a reboot,
     enter the following command:  srvadmin-services.sh  start
   2:srvadmin-omcommon      ####################################### [ 12%]
   3:srvadmin-hapi          ####################################### [ 18%]
   4:srvadmin-syscheck      ####################################### [ 24%]
   5:srvadmin-deng          ####################################### [ 29%]
   6:srvadmin-omacore       ####################################### [ 35%]
   7:srvadmin-isvc          ####################################### [ 41%]
   8:srvadmin-omauth        ####################################### [ 47%]
   9:srvadmin-wsmanclient   ####################################### [ 53%]
  10:srvadmin-rac5-component####################################### [ 59%]
  11:srvadmin-jre           ####################################### [ 65%]
  12:srvadmin-cm            ####################################### [ 71%]
  13:srvadmin-iws           ####################################### [ 76%]
  14:srvadmin-omhip         ####################################### [ 82%]
  15:srvadmin-racadm5       ####################################### [ 88%]
  16:srvadmin-racdrsc5      ####################################### [ 94%]
  17:srvadmin-storage       ####################################### [100%]
[root@esx-400-xstcgn supportscripts]#
[root@esx-400-xstcgn supportscripts]# mv /vmfs/volumes/esx-400-xstcgn-local/DELL_OMSA.xml /etc/vmware/firewall/.
[root@esx-400-xstcgn supportscripts]# esxcfg-firewall -e 'DELL OpenManage Request'
[root@esx-400-xstcgn supportscripts]# service mgmt-vmware restart
Stopping VMware ESX Management services:
   VMware ESX Host Agent Watchdog                          [  OK  ]
   VMware ESX Host Agent                                   [  OK  ]
Starting VMware ESX Management services:
   VMware ESX Host Agent (background)                      [  OK  ]
   Availability report startup (background)                [  OK  ]
[root@esx-400-xstcgn supportscripts]# ./srvadmin-services.sh start
Starting Systems Management Device Drivers:
Starting dell_rbu:                                         [  OK  ]
Starting ipmi driver: Already started                      [  OK  ]
Starting snmpd:                                            [  OK  ]
Starting Systems Management Data Engine:
Starting dsm_sa_datamgr32d:                                [  OK  ]
Starting dsm_sa_eventmgr32d:                               [  OK  ]
Starting dsm_sa_snmp32d:                                   [  OK  ]
Starting DSM SA Shared Services:                           [  OK  ]
Starting DSM SA Connection Service:                        [  OK  ]
[root@esx-400-xstcgn supportscripts]#

Danach kann man wie gewohnt die lokale DELL OpenManage Installation über einen unterstützten Webbrowser aufrufen:
https://esx-400-xstcgn.xsteam.eu:1311

In der jüngeren Vergangenheit hatte ich über die Problematik mit der Installation von DELL OMSA unter VMware ESX 3.5.0 bereits berichtet. Das Problem liegt dabei an zwei Stellen. Zum Einen unterstützt DELL offiziell RHEL 3 Update9 nicht mehr als Plattform und zum Anderen nutzt VMware eine eigene IPMI Integration in den ESX Server und damit in das speziell für VMware geschnittene RHEL 3U9. Daraus ergibt sich zwangsläufig eine Sackgasse, wenn man den bisher gültigen Weg der Installationsanweisung folgte und das DELL IPMI Paket mit dem Kernel verheiraten wollte. Das Ergebnis, eine nicht mehr funktionierende Hardwareüberwachung, die sich nicht mehr deinstallieren lies!

Die Lösung war so einfach, wie überraschend, denn DELL veröffentlichte ohne Benachrichtigung ein Update seines Installationsleitfadens, indem diese Prozedur einfach ausgelassen wurde und siehe da, OMSA funktioniert. Manchmal sind es die kleinen Dinge im Leben, auf die es ankommt. Für alle die keine Lust haben zu warten, so geht's:

1. DELL OMSA Paket für Linus von der bekannten Website support.dell.com herunterladen
2. Das Archiv auf den ESX Server kopieren, ambesten nach /tmp oder /root
3. Das Archiv entpacken

root# tar -xvzf OM****.tar.gz

4. In der ESX Server Firewall sowohl snmp als auch den OMSA Port freigeben:

root# esxcfg-firewall -e snmpd
root# esxcfg-firewall -o 1311,tcp,in,OpenManageRequest

5. OMSA Module installieren

root# ./linux/supportscripts/srvadmin-install -b -w -r -s
root# ./linux/supportscripts/srvadmin-services start
!!!Die Option -r nur verwenden wenn eine DRAC Karte im Server installiert ist!!!

6. Webbrowser starten und die Installation kontrollieren, das war's

Heute hat DELL ein weiteres BIOS Update für seine Serverbaureihe PowerEdge 29x0 herausgegeben.
Das Update ist wie gewohnt über die Support Seite des Herstellers erreichbar und kann sowohl lokal (Windows / Linux), als auch über die DELL Tools zur Systemwartung ausgeliefert werden.


Updatepaket für PE2900

Updatepaket für PE2950

Wie inoffiziell bestätigt wurde existiert zur Zeit ein Installationsproblem mit DELL OpenManage Server Administrator (OMSA) auf der aktuellen ESX Server Version. Die angebotenen Skripte, die unter anderem einige Kernelmodule rekompilieren laufen dabei ins Leere, bzw. verursachen einen Installationsfehler, der dazu führt, dass die interne Open IPMI Schnittstelle des ESX Servers nicht mehr fehlerfrei startet.
Erst mit der Version 5.5.0_A00 soll dieses Problem behoben sein.

Workaround I:
Installiert man neue ESX Server kann man einfach "nur" die Version 3.5.0 Update 1 installieren - verrückt? Vielleicht, bei näherer Betrachtung aber durchaus praktikabel, denn wenn der UpdateManager zum Einsatz kommt, lädt dieser eh alle Patches für die Versionen ESX 3.0.3 und ESX 3.5.0 seit deren Erscheinen herunter und stellt diese bereit zur Installation, unabhängig davon, ob das Paket installiert werden muss oder nicht.
Für alle Kunden mit weniger als 2 MBit Internetanbindung empfehle ich die kompletten Updatepakete "zuhause" herunterzuladen und dann einfach in die existierende Ordnerhierarchie zu kopieren und den UpdateManager Dienst neu zu starten.

Workaround II:
Seit der Version 3.5.0 hat VMware eine eigene IPMI Schnittstelle integriert. diese kann die komplette Hardware auslesen und auch überwachen, gerade in kleineren Umgebungen kann diese Hardware Überwachung die "große" Lösung durchaus ersetzen, dann man kann im VirtualCenter Alarme für die Hardware Überwachung einstellen und auch die Seriennummer auslesen (wird angezeigt). Das funktioniert sehr gut mit den Systemen von DELL und auch von FSC.

Als Alternative bleibt nur: Warten!

Das will niemand sehen, aber es passiert! Der PSOD schlägt zu und der ESX Server steht, wie einst das gute alte Windows NT 4.0.
Im Gegensatz zu Windows NT damals, tritt der PSOD (Purple Screen Of Death) zum Glück sehr selten beim ESX Server auf, aber wir wollen es nicht verheimlichen, es gibt ihn diesen Albtraum eines Systemadministrators! Leider gibt es einen echten Bug in VMware ESX Sever Version 3.5.x.

Dieser Fehler tritt in folgender Hardwarekonfiguration auf:
DELL PE 29x0 III Server mit PERC/6i S-AS Controller.

Von VMware gibt es dazu keinen Knowledgebase Eintrag, lediglich ein Eintrag im VMware Forum deutet auf das Problem hin.

Scannt man unter dem VI Client unter Configuration / Hardware / Storage Adapters die HBAs nach neuen VMFS Volumes oder LUNs, so stoppt der ESX Server mit einem PSOD!
Dieser Fehler ist bereits bei VMware bekannt und adressiert. Laut VMware wird dieser Fehler mit dem anstehenden Update 3 für VMware ESX 3.5.0 behoben. Bis dahin gibt es einige obskure Anleitungen in den VMware Communities für dieses Problem, die soweit gehen in Systemdateien des ESX Servers einzugreifen, dass ist unnötig und hilft in Abhängigkeit zur verwendeten BIOS Version der Servr auch überhaupt nicht.

Lösung:

Im BIOS der DELL Server ist nach der Basisinstallation der integrierte S-ATA Controller auszuschalten. Dadurch verliere ich zwar den Zugriff auf das lokale CD-ROM Laufwerk (S-ATA seit Version III der PE 29x0 Server), aber dafür kann man im laufenden Betrieb nach neuen SAN LUNs suchen und diese gefahrlos mounten. Diese Lösung funktioniert mit den genannten DELL PE Servern mit den BIOS Versionen 2.1.0, 2.2.6 und 2.3.1.

Alternative:

Wer unbedingt auf das integrierte CD-ROM Laufwerk nicht verzichten kann, der muss zur SAN Erweiterung jeden Host einmal neu starten. Beim Systemstart scannt der Server die SAN auf verfügbare / konfigurierte LUNs ab und kann in dieser Prozedur ohne Absturz auch neue LUNs persistent mounten.