Eén van de bedoelingen van virtualisatie is om abstractie te kunnen maken van de onderliggende hardware. Idealiter zou je de virtuele machine dan ook zonder problemen moeten kunnen verplaatsen van één fysieke machine naar een andere, en liefst zo snel mogelijk. Dat kan om verschillende redenen noodzakelijk zijn: je hardware is bijvoorbeeld niet meer krachtig genoeg, of je moet er onderhoud op uitvoeren, of je wil load balancing implementeren.

Xen biedt de mogelijkheid om een virtuele machine in zijn totaliteit te migreren naar een andere machine, waarna hij daar zijn werk kan voortzetten. Dat kan omdat de volledige toestand van de virtuele machine wordt overgezet, onder andere de kerneltoestand, alle processen, kortom het hele virtuele RAM. Deze migratie kan 'cold' of 'live' gebeuren. Bij een koude migratie wordt de virtuele machine gepauzeerd en naar de andere fysieke machine overgezet, waarbij de downtime significant kan zijn. Bij een live migratie blijft de virtuele machine tijdens het migreren draaien, waardoor de downtime vrijwel nihiel is.

De meest primitieve manier is gewoon de virtuele machine stopzetten, de virtuele harde schijf naar een andere fysieke machine overzetten en daarna de virtuele machine opnieuw creëren. Dit is alleen nodig voor grote wijzigingen, zoals het migreren naar een andere hypervisor. Daar gaan we hier dus niet op in. We illustreren eerst het verloop van een koude migratie, waarbij de virtuele machine niet stopgezet maar gepauzeerd wordt, en daarna live migratie, wat hier een geavanceerdere vorm van is.

Save en restore

De idee achter de migratie van een virtuele machine is dat je ze savet op de ene fysieke machine en restoret op de andere fysieke machine. Het saven van een virtuele machine is te vergelijken met de slaapstand van een computer: daarbij wordt een kopie van het hele RAM naar schijf geschreven en wordt de computer uitgeschakeld. Wanneer de computer weer opstart, wordt de kopie van de harde schijf geladen en bit per bit terug in het RAM geladen. Het resultaat: de computer gaat gewoon verder waar hij was.

Xen kan hetzelfde doen met virtuele machines: daarvoor heeft het de opdrachten 'xm save' en 'xm restore'. Zo save je bijvoorbeeld de virtuele machine met de naam testvm naar een bestand testvm.sav:

# xm save testvm testvm.sav

Hierna is de virtuele machine gestopt en vind je zijn volledige toestand in het bestand testvm.sav, dat ongeveer zo groot is als het geheugen dat toegekend was aan de virtuele machine. Nu kun je op een later moment de virtuele machine restoren:

# xm restore testvm.sav

De virtuele machine draait nu opnieuw en gaat verder waar hij was op het moment van het saven. Het save-bestand blijft overigens bestaan, zodat je er altijd opnieuw van kunt restoren als er iets misloopt.

Koude migratie

Het saven en restoren vormt de basis van een koude migratie. Het enige wat we nog missen is dat we het save-bestand naar de nieuwe fysieke machine moeten overzetten, én dat we de storage voor de virtuele machine moeten overzetten, bijvoorbeeld een virtueel block device. Beide bestanden kopiëren we dus naar de andere machine, bijvoorbeeld met dd, rsync of scp.

Welke manier je ook kiest, zorg ervoor dat je de virtuele schijf bit voor bit kopieert, en probeer niet het bestandssysteem van de virtuele machine te mounten en te kopiëren, want dan werkt het restoren niet. Na het overzetten van het save-bestand restore je gewoon op de nieuwe fysieke machine de virtuele machine, en als alles goed gaat zet de virtuele machine daar zijn werk verder.

Live migratie

Tot hier verloopt alles nog vrij simpel, maar wat als we onze virtuele machine willen migreren zonder downtime? Xen laat live migratie toe, waardoor een virtuele machine fysiek gemigreerd kan worden zonder dat buitenstaanders hier iets van merken. Het vereist wel dat de storage van de virtuele machine op beide fysieke machines via het netwerk bereikbaar is onder dezelfde naam. Hiervoor kun je NFS gebruiken, maar ook iSCSI of ATA-over-Ethernet (AoE).

Eerst moet je op beide servers instellen dat de service xend luistert naar aanvragen voor migratie. Dit kan met de volgende regel in /etc/xen/xend-config.sxp:

(xend-relocation-server yes)

Beide servers luisteren nu standaard op poort 8002 (ingesteld in xend-relocation-port). Pas je firewallregels indien nodig aan, en/of vul computers die mogen verbinden in na xend-relocation-hosts-allow in het configuratiebestand. Herstart na de wijziging van de configuratie ook het xend-proces op beide computers. Je start nu op de broncomputer een live migratie naar de doelcomputer (hier met IP-adres 192.168.1.100) met de volgende regel:

# xm migrate --live testvm 192.168.1.100

Normaal krijg je na het commando na enkele seconden weer de command prompt, waarna je op beide computers met "xm list" in het oog kunt houden waar de virtuele machine draait.

Hoe werkt dit?

Xen begint een live migratie door een aanvraag voor een reservatie naar de doelcomputer te sturen. De doelcomputer controleert dan of hij de benodigde resources heeft om de virtuele machine aan te nemen. Accepteert hij de aanvraag, dan begint Xen geheugenpagina's van de virtuele machine naar de doelcomputer te sturen. Terwijl dit gebeurt, blijft de virtuele machine de hele tijd nog draaien op de broncomputer. Daardoor veranderen de geheugenpagina's die al gekopieerd zijn nog altijd, waarna ze telkens opnieuw gekopieerd worden.

Dit proces van kopiëren en herkopiëren bij wijzigingen blijft doorgaan tot er nog slechts een klein aantal geheugenpagina's overblijft dat frequent verandert. Op dat moment pauzeert Xen de virtuele machine en kopieert die laatste geheugenpagina's ook naar de doelcomputer. Daarna begint de virtuele machine op de doelcomputer te draaien.

De netwerkverbindingen blijven overigens behouden tijdens deze migratie, omdat de virtuele machine na de migratie een 'unsolicited ARP reply' stuurt om zijn nieuwe locatie te adverteren. Dat werkt alleen als de bron- en doelcomputer zich op hetzelfde fysieke subnet bevinden, want het IP-adres blijft identiek. Je kunt tijdens het migreren dus een ping-commando naar de virtuele machine uitvoeren, of vanaf de virtuele machine naar buiten, en normaal zou er geen packet loss mogen zijn.

Als je de optie --live van het commando xm migrate weglaat, voert Xen overigens een koude migratie uit. Dit ene commando savet de virtuele machine, zendt het naar de doelcomputer en restoret het daar. Dit vereist natuurlijk ook wel dat de storage via het netwerk bereikbaar is op beide computers.

En verder

Onder Red Hat Enterprise Linux kun je de live migratie van virtuele machines onder Xen ook uitvoeren met virsh, dat van de libvirt API gebruik maakt. Ook third-party tools zoals ConVirt maken live migratie mogelijk. Volgende week bekijken we hoe je live migratie doet in KVM en kijken we ook naar de libvirt-manier.

Bron: Techworld