Maar misschien kijk je er tegen op om al je operating system deployments opnieuw uit te voeren in virtuele machines.

Gelukkig kun je je bestaande deployments met wat handigheid migreren naar virtuele machines, zonder dat je het besturingssysteem en je softwarestack erboven helemaal opnieuw moet installeren. Het proces heet physical-to-virtual conversie (P2V). In dit artikel tonen we hoe dit gaat met een Linux-distributie. Er bestaan allerlei dure tools voor deze taak, maar we tonen hier dat het ook kan met alleen open source software.

Klonen

De eerste stap bestaat uit het klonen van de harde schijf van de fysieke server waarop je Linux-distributie geïnstalleerd is. Een vaak gebruikte oplossing hiervoor is Clonezilla Live, een live-cd die je helpt om een harde schijf of partitie naar een image te schrijven. Vanuit Clonezilla kun je het image over het netwerk via SSH, Samba of NFS wegschrijven naar de virtualisatieserver.

Maar het kan nog eenvoudiger met een willekeurige rescue-cd, live-cd of installatie-cd. Neem dus de dichtstbijzijnde cd van een Linux-distributie en start je server hiervan op. Start de live-omgeving of (als het een installatie-cd is) open de rescue-modus, en start hierin een shell. Controleer nu de device-aanduiding van de harde schijf die je wil klonen (bijvoorbeeld /dev/sda voor een SATA-schijf of /dev/hda voor een IDE-schijf) en kopieer die over het netwerk naar de virtualisatieserver. Bijvoorbeeld:

$ dd if=/dev/sda | ssh [email protected] 'cat > /var/lib/libvirt/images/guest.img'

Hetzelfde kan met netcat (of ncat). Eerst laat je netcat op de virtualisatieserver luisteren:

$ netcat -l -p 9000 > guest.img

Op de originele server stuur je de inhoud van de harde schijf via netcat naar de virtualisatieserver:

$ dd if=/dev/sda | netcat 192.168.1.100 9000

Op welke manier je het ook doet, afhankelijk van de grootte van de originele harde schijf en de snelheid van je netwerk kan het klonen over het netwerk enkele minuten tot uren duren. Uiteraard kun je ook een externe harde schijf op de originele server aansluiten en het image daarop schrijven, waarna je de schijf op de virtualisatieserver aansluit en het image er vanaf kopieert. In alle gevallen is het resultaat een image op de virtualisatieserver die bit per bit identiek is aan de originele harde schijf.

Boot de virtuele machine

De volgende stap is het booten van een virtuele machine vanaf de image. Het juiste proces hangt uiteraard af van welke hypervisor je gebruikt. We geven enkele scenario's. Als eerste scenario gebruiken we de recentste Red Hat, CentOS of Fedora met KVM als hypervisor. Recente versies van virt-install hebben een optie --import waarmee je rechtstreeks een image van een schijf kunt importeren als virtuele machine.

Een andere manier is zelf een libvirt XML-configuratiebestand aanmaken voor de virtuele machine. Kopieer daarvoor een bestaande XML-configuratie van een andere gast met "virsh dumpxml gast" en pas deze uitvoer aan. Verwijs naar het juiste image en zorg ervoor dat je volledige virtualisatie ("hvm") gebruikt. Schrijf dit configuratiebestand weg naar guest.xml en start de virtuele machine met:

$ virsh define guest.xml

Wil je de virtuele machine in VirtualBox draaien, dan kan dat door eerst het image dat je met dd gemaakt hebt om te zetten naar het vdi-formaat:

$ VBoxManage convertdd guest.img guest.vdi

Daarna maak je een nieuwe virtuele machine aan in VirtualBox en ken je guest.vdi hieraan toe als schijf om van te booten.

Voor VMware geldt hetzelfde procédé. Een bit-voor-bit image omzetten naar het VMDK-formaat kan met het programma qemu-img:

$ qemu-img convert -f raw guest.img -O vmdk guest.vmdk

Wat je in alle gevallen ook kunt doen is een nieuwe virtuele machine aanmaken met een nieuwe virtuele harde schijf, waaraan je dan het image toevoegt en van een ISO-bestand van CloneZilla Live of een rescue-cd opstart. Dan restore je het image naar de nieuwe virtuele harde schijf. Op deze manier zijn ook flexibeler restore-manieren mogelijk. Nadien ontkoppel je het ISO-bestand en het originele image van de virtuele machine en boot je de machine van de virtuele schijf die nu een kopie bevat van de originele schijf.

Wat er mis kan gaan

In de praktijk verloopt een P2V-migratie niet zo eenvoudig als het door de stappen hierboven lijkt. De kans is groot dat de virtuele machine niet boot en dat je rescue-taken moet uitvoeren. Enkele redenen hiervoor bij een Linux-distributie zijn:

1. Hardgecodeerde namen van partities

Je Linux-distributie kan hardgecodeerde namen van partities gebruiken, bijvoorbeeld in /etc/fstab, in het initrd-bestand voor het booten en eventueel in scripts die de harde schijf ontsleutelen bij het booten. Gebruik je in je virtuele machine geparavirtualiseerde drivers, dan krijgen deze schijven ineens andere namen, zoals /dev/xvda in Xen of /dev/vda voor de standaard Linux virtio-drivers. In /etc/fstab van het zojuist gemigreerde image staat echter nog altijd een verwijzing naar /dev/sda1, waardoor de distributie niet boot. Maar ook zonder geparavirtualiseerde drivers kan er een naamsverandering voorkomen, bijvoorbeeld als je van fysieke IDE-schijven naar virtuele SATA-schijven gaat, waardoor /dev/hda1 /dev/sda1 moet worden.

Dit oplossen kan door de verwijzingen aan te passen. We tonen verder hoe dat kan. Een andere oplossing is om op voorhand labels of UUID's te gebruiken voor de partities. Veel recente Linux-distributies gebruiken dit sowieso al. Ook LVM-partitienamen zouden geen problemen mogen geven bij een P2V-migratie.

Vergeet ook niet de verwijzingen aan te passen in /boot/grub/device.map en /boot/grub/menu.lst. Let vooral op de regel boot= en de parameter root=. Installeer de bootloader grub opnieuw met grub-install.

2. X start niet op

Dit is natuurlijk enkel een probleem voor desktopsystemen die je migreert naar een virtuele machine. Alle hypervisors emuleren een virtuele grafische kaart, zoals een Cirrus Logic. Als je X geen gebruik maakt van autoconfiguratie en een specifieke driver instelt in /etc/X11/xorg.conf, kan dit ervoor zorgen dat je X crasht in de virtuele omgeving. Verwijder dus liefst je xorg.conf voordat je de migratie uitvoert, zodat X via autoconfiguratie in gang raakt in de virtuele machine. Daarna kun je een nieuw configuratiebestand aanmaken met verwijzing naar de juiste drivers, bijvoorbeeld de versnelde paravirt-drivers.

3. Een andere processor

Het spreekt voor zich dat je niet moet proberen een 64-bit Linux-distributie die op de originele 64-bit hardware draaide te migreren naar een 32-bit virtuele machine. Subtielere verschillen kunnen echter ook voor problemen zorgen. Heb je in de originele machine softwarepakketten gecompileerd met optimalisaties voor CPU-uitbreidingen zoals SSE of vectoren en zijn deze uitbreidingen niet beschikbaar in de virtuele machine, dan kunnen bepaalde programma's om schijnbaar onverklaarbare redenen crashen. Het beste gebruik is dus om in de originele machine enkel zogenaamde generic-versies van de pakketten te gebruiken.

4. Drivers

Normaal zal de Linux-kernel dynamisch drivers laden voor de juiste (virtuele hardware), maar sommige zaken kunnen nog hardgecodeerd zijn, bijvoorbeeld drivers in het initrd-bestand. Maak daarom een nieuw initrd-bestand aan met mkinitrd -v. Of misschien heb je in /etc/modprobe.d/aliases aliassen gemaakt voor netwerkdrivers die in de virtuele omgeving verschillend moeten zijn. Vervang deze aliassen dan door verwijzingen naar drivers die in de hypervisor die je kiest ondersteund zijn.

Hoe los je problemen op

De hiervoor vermelde en andere problemen kun je op twee momenten oplossen: ofwel vóór ofwel na de migratie. Vóór de migratie kun je dit ofwel in het draaiende Linux-systeem zelf doen (bijvoorbeeld in single-user mode) ofwel door van een rescue-systeem op te starten en je Linux-systeemschijf te mounten en erin te chrooten. Dit laatste gaat eenvoudig:

# mkdir /mnt/system

# mount /dev/sda1 /mnt/system

# chroot /mnt/system

Na de migratie kan dit eveneens door je virtuele machine van een rescue-systeem op te starten en je Linux-systeemschijf te mounten en erin te chrooten. Maar eenvoudige zaken zoals de inhoud van configuratiebestanden aanpassen kun je ook door je image op je virtualisatieserver te mounten. Sinds Fedora 11 kan dat zelfs eenvoudig met het programma guestfish, waarover we in een volgend artikel op Techworld ook gaan schrijven. Wil je bijvoorbeeld enkele regels in /etc/fstab aanpassen, dan kan dat als volgt:

$ guestfish -i guest.img

$ virt-edit guest.img /etc/fstab

Succes

Het succes van deze procedure voor een P2V-migratie hangt van allerlei factoren af en de details verschillen per distributie en hypervisor. Recentere distributies zijn over het algemeen beter bestand tegen migratie. Een beetje systeembeheerder draait zijn hand echter niet om voor de kleine aanpassingen die meestal slechts nodig zijn om een gemigreerde Linux-distributie draaiende te krijgen in een virtuele omgeving. Volgende week tonen we je hoe we Windows-machines virtueel maken. Bron: Techworld