Erfahrungsbericht: P2V von zwei Alt-Linux-Servern auf ESXi 5

[~thc]

Letzte Woche habe ich zwei essentielle Linux-LAMP-Server bei einer auf Spendengelder angewiesenen Hilfsorganisation erfolgreich auf ESXi 5.0 virtualisiert. Besonderes Schmankerl: Keiner weiß mehr, wie diese Server genau funktionieren. Die Generationen von Studenten, die daran rumgebastelt haben (darf ja alles nichts kosten), sind nicht mehr greifbar oder weigern sich, auch nur noch ein Bit zu verdrehen. Eine Neuprogrammierung ist projektiert, aber wird noch ein Jahr dauern (darf ja nichts kosten). Die Hardware stirbt aber schon jetzt und daher müssen die Server virtualisiert werden (darf dann auch was kosten). Der Plan war, die Server 1:1, also möglichst ohne Änderungen, umzutopfen.

Nach dem Feststellen der Eckdaten (RAM, Festplatte(n), Architektur) wurden unter ESXi 5.0U3 zwei passende leere VMs (Other Linux) angelegt. In der SSH-Shell habe ich die FLAT-Files gleich wieder gelöscht und die VMDKs auf die exakten Werte der physischen Volumes angepasst.

Der ältere ("kleine") Server lief auf einem (vermutlich seit Jahren) degradeten Hardware-RAID1-Volume und besitzt nur eine 100MBit-Netzwerkkarte. Das Image der Festplatte wurde daher auf eine direkt angeschlossene, mit ext3 formatierte USB-Festplatte über "dd" gezogen:

Code: Alles auswählen

init 1
mount /dev/sdb1 /mnt
dd if=/dev/sda of=/mnt/server.ddimage bs=1M

"dd" schneidet dabei den letzten 1MB-Block korrekt ab, so dass die Dateigröße exakt der Summe aller Sektoren entspricht. Auf einer Windows 7 Maschine mit dem vSphere-Client und einem freien ext3-Treiber wurde das Image in den Datastore hochgeladen. Etwas krude, aber bei 150 GB noch machbar.

Der neuere ("große") Server lief auf einem Boot-Software-RAID1 aus zwei 500GB-Platten und hat eine GB-Netzwerkkarte. Daher lässt sich hier (bei eingeschaltetem SSH auf dem ESXi) das Volume in akzeptabler Zeit direkt in den Datastore hochladen:

Code: Alles auswählen

init 1
dd if=/dev/sda bs=1M | gzip -c | ssh root@esxiserverip "gzip -c -d > /vmfs/volumes/datastore2/server/server.ddimage"

Dummerweise stieg die Broadcom-Karte einmal nach 1,5 und noch einmal nach 3 Stunden komplett aus. Somit musste auch hier auf die USB-Methode ausgewichen werden. Der Datastore-Upload wurde aus Zeitgründen mit dem Trilead VM Explorer durchgeführt. Nach dem Umbenennen der Images in FLAT-Files (servername-flat.vmdk) folgten die ersten Test-Bootvorgänge.

Der kleine Server stoppte mit einer "Unable to mount root" Kernel panic. Eine genauere Analyse des OS ergab, dass es sich um ein 32-Bit Debian 4.0 (Etch) handelt, dessen Kernel selbstkompiliert war (2.6.8.1) und ohne Initial RAMDisk gestartet wurde. Zudem war als Bootloader noch "Lilo" aktiv, was dafür spricht, dass der ursprüngliche Server mal unter einer noch älteren Distribution lief.

In einer zusätzlichen Referenz-VM habe ich Debian Etch 32-Bit installiert, die Festplatte des kleinen Servers als zweite mit in die Referenz-VM eingehängt und das Boot- und Kernel-Subsystem komplett übertragen:

Code: Alles auswählen

mount /dev/sdb1 /mnt
cd /mnt
mv boot oldboot
cp -a /boot .
mkdir lib/modules/2.6.18-6-686
cd lib/modules/2.6.18-6-686
cp -a /lib/modules/2.6.18-6-686/* .
cd
touch /mnt/boot/mark
grub
find /boot/mark (ergibt die grub-Kennung der Zielpartition: "(hd1,0)")
root (hd1,0)
setup (hd1)
exit
rm /mnt/boot/mark
umount /mnt

Nach dem Aushängen der Platte aus der Referenz-VM lief der kleine Server über grub und den Standard-Etch-Kernel fehlerfrei an. Der große Server zeigte beim Starten erhebliche Verzögerungen (möglicherweise durch das halbierte RAID1). Das Auflösen eines Boot-RAIDs ist nicht ganz so einfach - nach dem Starten der gleichen Distribution von CD (Debian 5.0 Lenny x64) im "Rescue"-Modus startet man nach der korrekten Angabe der Ziel-root (target) eine Shell im Installer-Environment:

Code: Alles auswählen

umount /target/sys
umount /target/proc
umount /target/dev
umount /target
mdadm --stop /dev/md0
mdadm --stop /dev/md1
mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sda2

Über "fdisk" wurden die Kennungen der Partitionen ("82" und "83" statt "fd") korrigiert und über den Editor "nano" der root-Parameter des grub-Bootloaders und die fstab-Einträge angepasst:

Code: Alles auswählen

mount /dev/sda1 /target
nano /target/boot/grub/menu.lst
nano /target/etc/fstab
umount /target


Der Server bootete danach verzögerungsfrei durch. Zuletzt sollte man noch das "mdadm"-Paket entfernen:

Code: Alles auswählen

apt-get --purge remove mdadm

[irix]

Du hast geschrieben das du die VMDK auf die exakt. phys. Werte angepasst hast. Im Klartext du hast die Geometrie veraendert oder?

Bitte teste mit dem evtl. nicht vorhandenem Backupprogramm ein Backup und Restore! Das Programm welches wir primar verwenden scheitert am Restore bzw. das Ergebnis bootet nicht, weil nicht das Original sondern eine Interpretation dessen wieder hergestellt wird. Das bedeutet das ueber die API eine VM und die Devices erstellt werden und dann sind keine Geometrie Anpassungen drin.

Gruss
Joerg

[rprengel]

Bitte teste mit dem evtl. nicht vorhandenem Backupprogramm ein Backup und Restore!

Gruss
Joerg

Für die schnelle Löisung:
Windows 7 Vm Demo aufsetzen und mit trilead vm-explorer Demo kopien ziehen.
Zudätzlich mit rsnapshot versionsweise die Daten und configs sichern.
Dann zeitnah ein sauberes Backupkonzept erarbeiten.

Gruss

[~thc]

Du hast geschrieben das du die VMDK auf die exakt. phys. Werte angepasst hast. Im Klartext du hast die Geometrie veraendert oder?

Ja. Wenn man eine gleich große Festplatte im vSphere-Client anlegt, ist die physische z.B. 200 Sektoren kleiner. Also wurden, wie hier im Forum schon mehrfach besprochen, die Geometriedaten der VMDK-Datei auf die der physischen Disk korrigiert.

Bitte teste mit dem evtl. nicht vorhandenem Backupprogramm ein Backup und Restore!

Danke für den Tipp. Ich werde das an den Vor-Ort-Admin weitergeben.