Es hätte ein so schöner Tag werden sollen.

Endlich stand am Dienstag der schon lange geplante Schritt der Servervirtualisierung bei uns im Krankenhaus an.

Folgende Maschinen, jeweils auf grundverschiedener Hardware lagen zur Virtualisierung auf Xen-Server an:
- 4 Maschinen mit Debian Etch (Schnittstellen-Server und Rechner mit Diensten für die Benutzer im Netz)
- 1 Maschine mit Windows 2000 Prof. (Schnittstellen-Rechner)
- 2 Maschinen mit Windows Server 2003 (ein MSSQL-Server, ein Lizenz- und Printserver)
- 2 Maschinen mit Windows Server 2000 (Domain-Controller)

Alles war fertig vorbereitet, der Zeitplan war erstellt, die Downzeiten im Haus bekannt gemacht, es konnte also losgehen.

9:00 Uhr
Zwei HP DL-380 standen bereit, die in jeweils 15 Minuten mit der aktuellen Citrix-Xen-Server Version 4.0.1 bestückt wurden. Als Speicherort für die virtuellen Maschinen dient das iSCSI-Storage PS-100e von Dell (ehemals Equallogic), das mittlerweile seit Januar zuverlässig seinen Dienst bei uns versieht.

10:00 Uhr
Nach weiteren Vorbereitungen ging es dann los.

Die vier ersten Migrationen, bei der die Debian-Installationen teils über partimage, teils über dd in ihre neue Heimat übertragen wurden, liefen fehlerfrei durch. Nach dem Anpassen der Grub-Konfiguration, der fstab und der Benennungsregeln für die Netzwerkinterfaces von udev fuhren die Kisten einwandfrei hoch.

13:30 Uhr
Jetzt sollten die Windows-Rechner an die Reihe kommen …

… und da fing das Martyrium an …

Erster Versuch:
- Erstellung von virtuellen VMWare-Maschinen aus den Windows-Installationen mit dem VMware-Converter
- Wandlung der VMWare-Server mit dem Xen-Tool “v2xva” in ein Xen-kompatibles Format

Erste Hürde: v2xva behauptete, nicht auf die Datei v2xvadrv.sys zugreifen zu können.

Abhilfe:
- Kopieren des Tools auf eine lokale Platte
- Aufrufen von v2xva /clean
- Maschine konvertieren mit v2xva /config:”o:\rt\der\vmware-config.vmx”

15:30 Uhr
Die ersten Xen-Images (Eine Datei ova.xml und Chunk-Dateien der konvertierten Festplatten) lagen vor und sollten über das Xen-Center Einzug in den Xen-Olymp halten.

Das klappte jedoch nur mit dem Image des MSSQL-Servers. Der war anschließend zwar nicht mehr in der Domäne, aber das war schnell korrigiert.

Die anderen Importvorgänge wurden allesamt (jeweils mit anderen Fehlermeldungen) abgebrochen.

Der Lizenz-Server dümpelte derweil beim VMWare-Converter-Vorgang irgendwo im einstelligen Prozentbereich der Konvertierung.

19:30 Uhr
Also musste für die Windows-2000-Maschinen eine andere Methode herhalten:

- Hochfahren der Windows-Rechner über Knoppix
- manuelles Anlegen von “leeren” virtuellen Maschinen auf Xen-Seite und
- Booten der Xen-Server mit Knoppix
- Übertragen der Festplatten mit dd über netcat.

Auf einem Domain-Controller scheiterte das Starten von Knoppix wohl aufgrund des fehlenden SCSI-Treibers für das CD-Rom in der Initial Ramdisk. Auch grml und andere Live-Distributionen versagten ihren Dienst.

Die Übertragung der zwei verbleibenden Windows-Rechner klappte zwar, doch ein Rechner fuhr unter Xen in einen Bluescreen “Inaccessible Boot Device”, beim anderen (Domain-Controller 2) waren MBR und Bootloader defekt.

Es folgten einige Versuche, die konvertierten Rechner zum Starten zu bewegen, die leider allesamt fehlschlugen.

Der Lizenz-Server dümpelte derweil beim VMWare-Converter-Vorgang irgendwo im einstelligen Prozentbereich der Konvertierung.

23:00 Uhr
Also gingen wir wieder zu “Los”, auf zur nächsten Variante:

Mister “Inaccessible Boot Device” wurde noch einmal mit dem VMWare-Converter bearbeitet.

Das VMWare-Image ließ sich dann sogar über einen eigens dafür eingerichteten VMWare-Server erfolgreich booten.

Also starteten wir noch einmal den Versuch und übertrugen die Festplattendaten mittels dd und netcat auf eine neu angelegte Xen-Maschine.

Auch diese fuhr erfreulicherweise hoch, war aber arschlangsam (und das kann durchaus als untertrieben aufgefasst werden).

Der Versuch, die Xen-Source-Tools auf dem Rechner zu installieren wurde mit der Meldung quittiert, dass mindestens Servicepack 4 installiert sein müsse. Das war aber eigentlich drauf.

Alle weiteren Versuche, die Kiste wieder in den Normalbetrieb zu bekommen, wurden nach einiger Zeit vorerst zurückgestellt.

03:00 Uhr
Da das gerade durchgeführte Prozedere den letzten Rechner zumindest zum Booten gebracht hatte, wurde auch für den ersten Domain-Controller mit Hilfe des VMWare-Converters noch einmal ein VMWare-Image erstellt.

Auch hier starteten wir noch einmal den Versuch die Festplattendaten mittels dd und netcat auf eine neu angelegte Xen-Maschine zu übertragen.

Und was soll man sagen: die Kiste fuhr anschließend in ihrer neuen Umgebung anstandslos hoch, ließ sich mit den Xensource-Tools bestücken und versah von da an seinen Dienst unfallfrei.

Der Lizenz-Server dümpelte derweil beim VMWare-Converter-Vorgang irgendwo im einstelligen Prozentbereich der Konvertierung.

irgendwann seeehr spät
Zurück zum Domain-Controller, die sich nicht überreden ließ, eine Live-CD zu booten:

Wir fanden letztendlich eine bootbare CD von “Acronis True Image”. Mit dieser konnten wir ein mit “TBI” bezeichnetes Image der Systemplatte in das Netzwerk legen.

Dieses TBI-Image ließ sich anschließend wiederum mit dem Acronis-Tool in ein VMWare-Image umwandeln.

Und was soll man sagen: dieses ließ sich auf dem VMWare-Server auch hochfahren. Es lief zwar langsam, aber es lief.

früh morgens
Der erste Übertragungsversuch des gerade erstellen VMWare-Servers per dd in die Xen-Umgebung schlug nach ca. 1 Stunde fehl, wir hatten versehentlich die unter Xen angelegte Festplatte nicht 18GB sondern nur 16GB groß angelegt.

Also noch einmal, diesmal auf eine ausreichend groß dimensionierte Platte.

irgendwann noch später
Die dd-Übertragung war abgeschlossen, der Xen-Server wurde neu gestartet…

… “Inaccessible Boot-Device” …

FEIERABEND

Resultat der Aktion:
Die 4 Linux-Kisten konnten unkompliziert migriert werden, zwei Windows-Boliden mit viel Überredungskunst.

Den Domain-Controller, der sich nicht migrieren ließ, setzen wir z.Zt. unter Xen neu auf.

Der Windows-2000-Rechner arbeitet zwar momentan, aufgrund der fehlenden Xensource-Tools lässt sich die Maschine aber nicht mit Xen-Motion zwischen den Xen-Servern verschieben. Also wird der auch neu aufgesetzt.

Der Lizenzserver wird z.Zt. (also erst heute) dem ersten Xen-Import-Versuch unterzogen, ich drück ihm die Daumen, denn wenn das fehlschlägt, nehm’ ich mir nen Strick.

Denn der Rechner verwaltet sowohl die Microsoft-, als auch die Citrix-, als auch die Lizenzen für weitere Anwendungen, und dient als Printserver für ca. 100 Drucker.

Den setz’ ich nicht neu auf.

Vielleicht hilft ja auch die neue Xen-Server-Version 4.1, die ist gestern, wohl als Easteregg, rausgekommen.