IBM: Firmware-Update für LSI 1064e SAS Controller zerstört Systemboard

Die aktuelle Firmware von IBM (Version 2.66) für den LSI 1064e SAS Controller hat mir letzte Woche ein Systemboard eines IBM HS21 XM Blade gekillt. Nach der aktualisierung konnte man nicht mehr von der SSD booten. IBM hat heute ein neues Systemboard und einen Techniker geschickt. Auch das neue Systemboard konnte nach dem einspielen der Firmware nicht mehr booten. Jetzt soll Morgen ein neues, drittes Systemboard kommen. Verteilt IBM hier gerade eine Firmware, die reihenweise Systemboards zerstört?

Kein Linux 2.6 Kernelmodul für die IBM DS3000 Series mehr nach einem RHEL5 Sicherheitsupdate

Nachdem einige schwerwiegende Sicherheitslücken im Kernel von Linux entdeckt wurden habe ich alle unsere Linuxserver aktualisiert. Dabei war auch ein IBM-Server mit RHEL5 (Redhat Enterprise Linux 5), den ich wie von Redhat empfohlen, mit yum update aktualisierte. Nach dem anschließenden Neustart musste ich leider feststellen, dass das Kernelmodul für die IBM DS3000 Series nicht mehr funktionierte.
Wie sich heraus stellte, wird bei Redhat im Gegensatz zu Debian der Pfad der Kernelmodule auch bei Sicherheitsupdates geändert. Der Kernel kann die alten Kernelmodule nicht mehr finden, da die aktuellen Module nicht mehr unter /lib/modules/2.6.18-53.1.14.el5, sondern unter /lib/modules/2.6.18-53.1.19.el5 liegen.
Leider gibt es von IBM kein richtiges Softwarepaket für das Kernelmodul, sondern nur einen Link auf die Webseite von LSI, dem Hersteller der DS3000 Series: http://www.lsi.com/rdac/ds3000.html. Dort gibt es dann nur die Sourcen, mit denen man sich selber ein Kernelmodul kompilieren kann.
Fazit: Sobald ein Sicherheitsupdate den Kernel des RHEL5 aktualisiert, müssen die Treiber für die IBM DS3000 Series neu installiert werden. Bei einem zertifiziertem Betriebssystem und so teurer Hardware kann man eigentlich eine bessere Lösung erwarten.

Chaos beim Support von IBM

Die USV von IBM, die kurz nach Ihrer Lieferung defekt war und von IBM getauscht werden musste, ist schon wieder defekt. Ich habe erneut beim Support den Ausfall gemeldet. Der Suport von IBM hat mich nicht nach dem Standort der USV gefragt und einen Technikereinsatz veranlaßt. Ich habe mir nichts dabei gedacht. Schließlich hatte IBM die USV gerade getauscht und sollte wissen wo sie zu finden ist. Das war allerdings ein Fehler. Das Ersatzgerät und der Techniker rückten in einer falschen und 500 KM entfernten Niederlassung an. Ich frage mich nur woher sie die falsche Adresse hatten. Weder das defekte Gerät noch die Rechnung wurden zu dieser geschickt und die Hausnummer war auch noch falsch.

VM-Ware auf Servern von IBM mit Hindernissen

Ich habe mich jetzt entschlossen einige der Server die ich betreue mit VM-Ware zu virtualisieren, um Kosten zu sparen. Dazu habe ich von Dell, HP und IBM Angebote eingeholt. Letztendlich viel die Wahl auf das Angebot von IBM, da dieses für unsere Belange das beste Preis-Leistungs-Verhältnis bietet. Im folgenden erwies sich die Installation jedoch leider wieder als ein Wenig schwieriger.

Die Server von IBM werden – ähnlich wie bei anderen Herstellern – von einer Partnerfirma vor Ort aufgebaut und eingerichtet. Nachdem VM-Ware installiert wurde, stellt der ausführende Techniker fest:

Die von VM-Ware für das Virtual Center mitgelieferte Microsoft MSDE Datenbank wird nicht supportet, wenn man sie in Produktionsumgebungen einsetzt.

Da ich mit VM-Ware nicht nur testen will, beschließe ich also eine andere Datenbank zu verwenden. Ich entscheide mich für Oracle, da wir viel Oracle einsetzen und VM-Ware dies in der Version 9 und 10 unterstützt. Dazu muss jedoch erst mal die richtige Oracle Version herunter geladen, die Lizensierung geklärt und alle Fragen beantwortet werden, die nicht in der – gerade mal eine halbe Seite langen – Anleitung für die „Installation von Oracle für Virtual Server“ stehen. Die Installation zieht sich also bis mitten in die Nacht. Außerdem endet sie mit dem Fehler:

[2007-11-20 10:10:33.267 'App' 3584 error] "ODBC error: (HY000) - [Oracle][ODBC][Ora]Trigger, procedure or function created with PL/SQL compilation error(s)." is returned when executing SQL statement "/*

Wir geben also erst mal auf und beschließen am nächsten Tag jemanden von VM-Ware anzurufen. Glücklicher Weise kenn der Techniker jemanden bei VM-Ware, den er am nächsten Tag anruft. Dieser leitet Ihn an den Support von VM-Ware weiter. Dieser weigert sich jedoch den Fall zu bearbeiten, ohne das er über die dafür vorgesehene Webseite gemeldet wurde. Auf dieser Webseite können wir mit unseren Zugangsdaten jedoch leider keinen Fall melden.

Nach einem erneuten Anruf bei VM-Ware stellt sich heraus, dass wir keinen Support von VM-Ware bekommen, weil wir über IBM gekauft haben. Wir können deshalb nur von IBM Support bekommen.

Super VM-Ware! Ich habe jetzt ein Problem mit einer Datenbank, die ich brauche, um von VM-Ware Support zu bekommen. Ich bekomme jedoch von VM-Ware keinen Support, um dieses Problem zu lösen. Die 16.000,- EUR für die Lizenz haben sich wirklich gelohnt. Das nächste mal sollte ich vielleicht lieber XEN von Citrix nehmen. Bei Citrix bekommt man auch bei OEM-Versionen Support. Sogar für etwaige mitgelieferten Datenbanken.