Ein Linux RHEL 5.1 Server wurde mittels Acronis-Image in eine VMware Workstation VM gewandelt. Die VM war startfähig, hatte aber keine Tools und die vDisk war am IDE Controller (0:0) angebunden. Sie sollte künftig auf einem vSphere 4.1 Cluster zum Einsatz kommen. Dafür ist es zwingend notwendig die vDisk mit einem virtuellen SCSI Controller anzusprechen. Wie das mit einem Windows XP Gastsystem funktioniert hatte ich in einem älteren Blogeintrag bereits geschildert. Mit Linux Gastsystemen gestaltet sich die Durchführung etwas anders.
Schritt 1: vmware-tools installieren
Zunächst muß in den Einstellungen der VM das korrekte Betriebsystem registriert sein. Das wirft die Frage auf, um welches System es sich bei der importierten Maschine handelt und ob es eine 32 oder 64 Bit Installation ist.
uname -p
Liefert die Kernelversion des installierten Systems. Alternativ: “uname -a“. Die Version des installierten Systems kann man (bei vielen Distributionen) abfragen mit:
lsb_release -i -r
Mit den gesammelten Ergebnissen lässt sich in den einstellungen der VM die richtige Wahl treffen. Hier ein 32 Bit RHEL 5.1.
Dies stellt sicher, daß der VM bei der Tools Installation das korrekte Image bereitgestellt wird. Das tar.gz File der Tools kopiert man praktischerweise vom CD-Image nach /tmp und entpackt es dort.
tar -xzf <toolsarchiv>.tar.gz
Wechsel in den entpackten Ordner “vmware-tools-distrib”. Ggf. ist für die Ausführung ein sudo oder ein su root notwendig.
cd vmware-tools-distrib/ sudo ./vmware-install.pl
Bei der ausführung wird man aufgefordert den Konfigurationsassistenten auszuführen. Diesen kann man auch später jederzeit aufrufen mit
/usr/bin/vmware-config-tools.pl
Schritt 2: Sichtung des Systems
Nach Konfiguration und ggf. Reboot sollte ein Blick auf den Bootloader, fstab und etwaige Aliase für Mountpoints geworfen werden. Dazu starten wir die VM noch mit IDE vDisks.
cat /etc/fstab
Hier sind keine Devices eingetragen wie in vielen Linux Distributionen üblich, sondern Labels. Die Zuordnung kann man anzeigen lassen mit dem Befehl blkid.
Hier sieht man, welches Device sich hinter welchem Label verbirgt. Die Devicebezeichnung hda deutet auf die erste IDE Disk im System. hda1 ist die erste Partition auf dieser Disk. die erste SCSI Disk heisst sda und deren Partitionen werden mit sda1, sda2 usw. bezeichnet.
Labels kann man per Befehl e2label auflisten, anpassen oder neu setzen. Läßt man den Paramter <neues Label> weg, so wird nur das aktuelle Label angezeigt.
e2label <device> [<neues Label>]
Schliesslich sollte man noch einen Blick in die Konfiguration des Bootloaders werfen (hier Grub) und das aktive Kernelimage notieren.
cat /boot/grub/grub.conf
Schritt 3: Controller umstellen
Dazu muß die VM ausgeschaltet sein. Eigenschaften der VM öffnen und den Speicherort aller vDisks (falls mehrere) notieren. Danach alle virtuellen Festplatten von der VM entfernen (nicht löschen!).
Nun wird der Deskriptor der vDisk heruntergeladen. Eine virtuelle Festplatte besteht immer aus zwei Dateien. Dem Flatfile und dem Deskriptor. Letzterer ist nur ein kleines Textfile. Sobald der Deskriptor geladen ist, kann man den Download abbrechen, denn das große Flatfile kann an Ort und Stelle verbleiben. Im VMDK Deskriptor sucht man die Zeile:
ddb.adapterType = “ide”
und ersetzt “ide” durch “lsilogic”
Danach das VMDK File wieder hochladen und das Original überschreiben. Die Festplatte kann nun wieder zur VM hinzugefügt werden.
Anhand der OS Vorgaben und dem Controllertyp in der vDisk entscheidet vSphere welcher SCSI Controller zum Einsatz kommen soll. Das ist im gezeigten Fall nicht unbedingt die beste Wahl.
Nach einigen Fehlversuchen stellte sich heraus, daß nicht LSI Logic Parallel, sondern LSI Logic SAS das Mittel der Wahl ist. Man markiert den SCSI Adapter und wechselt den Adaptertyp (rechts).
Schritt 4: Boot in Rescuemode
Unser System startet so nicht. Daher muß nun ein Live-Linux oder besser noch die Setup-CD der verwendeten Distribution her. Mir half in diesem Fall eine ältere Fedora Version. Wer diese allerdings auf der Homepage fedoraproject.org sucht, wird keinen Erfolg haben, denn dort wird nur die aktuelle Version zum Download angeboten. Ältere Installstionsmedien findet man dagegen im Archiv.
Das iso File der ersten Setup-CD bindet man in das virtuelle CD-Laufwerk der VM ein. Wer aber jetzt meint, er könne die VM so booten, wird wieder eine Überraschung erleben.
Klar, die VM hatte zuvor eine Festplatte an IDE0:0 (Master) und das CD-Laufwerk an IDE0:1 (Slave). Die Festplatte ist nun am SCSI-Controller und der Master damit leer. Wer die alte IDE-Ära noch selbst miterlebt hat, wird sich vielleicht erinnern: Kein Slave ohne Master! 🙂
Also muß man in den VM-Einstellungen das CD-Laufwerk von IDE0:1 nach IDE0:0 umziehen.
Empfehlenswert ist auch, die VM zunächst mal ins BIOS booten zu lassen. Hier kann man ggf. die Bootreihenfolge korrigieren, damit das System auch mit dem Rettungsmedium hoch kommt. Am Bootbildschirm gibt man den Bootparameter linux rescue ein. Damit versucht das Rettungslinux bereits beim Start eventuell vorhandene Datenträger unter /mnt/sysimage einzubinden. Nähere Info zum Rescuemode gibt es in der Fedora-Documentation. Nach dem Boot von CD und Konfiguration von Tastaturlayout, schaltet man das Rootverzeichnis um auf das eingebundene Sysimage.
chroot /mnt/sysimage
Wir bringen unser System dazu, beim Systemstart die richtigen SCSI-Adaptertreiber zu laden. Ab RHEL4 befinden sich die Anweisungen dazu in der Datei /etc/modprobe.conf.
nano /etc/modprobe.conf
Die VM enthielt mehrere SCSI-Treiber, die im ursprünglichen physischen System zum Einsatz kamen. Ich habe sie alle ersetzt durch folgende Werte:
alias scsi_hostadapter mptbase alias scsi_hostadapter1 mptscsih alias scsi_hostadapter2 mptfc alias scsi_hostadapter3 mptspi alias scsi_hostadapter4 mptsas
(TNX to LoneSysadmin for the very important hint!)
Die veränderte Datei modprobe.conf speichern und den Editor (nano oder vi) verlassen. Nun muss ein neues Bootimage erstellt werden. Zur Erinnerung, welches Kernelimage wir vorliegen haben, sehen wir nochmal in /etc/grub.conf nach.
cat /etc/grub.conf
Mit mkinitrd erstellen wir das neue Bootimage (vgl. unterste Zeile im Screenshot). Der Kernelname steht in Klammern hinter der Systembezeichnung.
mkinitrd -v -f <Pfad zum initrd*.img> <Kernelversion>
In unserem Beispiel lautet der Befehl..
mkinitrd -v -f /boot/initrd-2.6.18-53.el5PAE.img 2.6.18-53.el5PAE
Der Befehl hängt von der jeweiligen Systemkonfiguration ab. Zur Überprüfung, ob das Kernelimage aktualisiert wurde listet man dessen Eigenschaften auf und schaut, ob sich Datum und Uhrzeit verändert haben. Wenn dieses erst einige Augenblicke alt ist, dann hat es geklappt.
ls -l /boot/initrd-2.6.18-53.el5PAE.img
Abschließend habe ich nochmals ein kudzu über das System laufen lassen. Ich bin aber nicht sicher, ob dies wirklich notwendig war.
Anschließend das Live-Linux herunterfahren und das CD-Image aushängen. Die VM kann normal gestartet werden. Kurz Luft anhalten, Daumen drücken und über den Loginscreen freuen. 🙂