XEN Live Migration. Seminararbeit von Jauslin Raphael, I5m

Transkript

1 XEN Live Migration Seminararbeit von Jauslin Raphael, I5m Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuender Dozent: Dr. Harald von Fellenberg Windisch, 1. Juni 2006

2 Zusammenfassung Die Live Migration von XEN ist ein Feature, um virtuelle Maschinen von einer physikalischen Maschine auf eine andere zu migrieren, dies geschieht - aus User Sicht unterbruchsfrei. Dadurch ist es möglich, geplante Hardwarepflege zu betreiben, oder auch einen überlasteten Server zu entlasten und einen bestimmten Service auf eine neue Maschine zu verlagern. Andere Nutzungsmöglichkeiten sind Test- und Entwicklungsumgebungen, Netzwerk- und Cluster-Simulationen oder aus Sicherheitsgründen separierte Ausführungsumgebungen. Die virtuelle Maschine muss vor und nach der Migration auf ihr Dateisystem zugreifen können, dafür braucht sie ein Netzwerkdateisystem oder einen Netzwerkspeicher. Als Netzwerkdateisystem kommt NFS in Frage, im Serverbereich wird häufig ein Netzwerkspeicher über Fibre-Channel zur Verfügung stehen. Eine günstigere Alternative ist iscsi. In dieser Seminararbeit wird zuerst ein Einblick in die Technologie von XEN und der Live Migration gegeben. Dabei wird die Architektur der Live Migration aufgezeigt, Performance Tests analysiert und ein Ausblick über die weitere Entwicklung der Live Migration gegeben. Im zweiten Teil wird eine komplette Installation und Konfiguration auf zwei Debian Systemen durchgeführt und anschliessend eine Migration demonstriert. Windisch, Sommersemester 05/06 Raphael Jauslin Seite 1 von 16

3 Inhaltsverzeichnis 1 XEN Funktionsweise Gastsysteme unter XEN Privilegierte und unprivilegierte Gastsysteme Live Migration Voraussetzungen Überblick Design Lokale Ressourcen Ablauf einer Migration Performance Ausblick Installation und Konfiguration Installation XEN NFS Server und Client einrichten Gastsystem einrichten Starten der virtuellen Maschine Anpassen von Xend Migration Literaturverzeichnis...16 L1. Internet...16 L2. Dokumente und Zeitschriften Abbildungsverzeichnis...16 Raphael Jauslin Seite 2 von 16

4 1 XEN 1.1 Funktionsweise Xen ist ein Virtual Machine Monitor (VMM), der unter der GNU General Public License (GPL) steht und von der Universität Cambridge entwickelt wird. Xen läuft direkt auf der x86-hardware. Diese wird für die darauf laufenden Systeme (Domains) paravirtualisiert. Dabei wird eine sehr hohe Performance erzielt, da die Hardware nicht emuliert wird, sondern diese den Gastsystemen mit einem sehr kleinen Overhead zur Verfügung gestellt wird. XEN unterscheidet privilegierte (Domäne-0) und unprivilegierte Domänen (Domäne-U), d.h. virtuelle Systeme. Die Domäne-0 hat die volle Kontrolle über das System und die anderen Gast-Domänen. Unter einer Linux Distribution wird XEN installiert und eingerichtet. Das sind im Wesentlichen der Kernel und Werkzeuge für die Administration der Domänen. Danach wird der Computer neu gestartet und der XEN-Kernel geladen. Anschliessend wird Domain-0, welche die anderen Domains steuert, gestartet. Mit den XEN-Tools werden andere Domains gestartet, die mit einem XEN-Kernel laufen. Die Anzahl der laufenden Gastsysteme ist nur durch die Ressourcen (CPU, Speicher usw.) des Rechners beschränkt. Die einzelnen Gastsysteme werden voneinander sehr stark isoliert und laufen annähernd so schnell als ob sie direkt auf der Hardware liefen. Diese Eigenschaft unterscheidet XEN von den anderen Verfahren wie UML, VMware-Workstation oder -GSX-Server usw. und entspricht in etwa dem Produkt VMWare ESXServer. 1.2 Gastsysteme unter XEN XEN bringt die Gastbetriebssysteme unter seine Kontrolle, indem es ihnen Rechte nimmt. Der PC bootet zunächst den XEN-Kernel. Der läuft privilegiert auf Ring 0, das heisst, er darf auf den gesamten Speicher, sämtliche Register und I/O-Adressen zugreifen und alle Befehle des Prozessors verwenden. Die xenisierten Kernel der Gastbetriebssysteme laufen nicht mehr auf Ring 0, sondern auf Ring 1 (der am stärksten eingeschränkte Ring 3 bleibt den Anwendungsprogrammen in den Gastbetriebssystemen vorbehalten). Raphael Jauslin Seite 3 von 16

5 1.3 Privilegierte und unprivilegierte Gastsysteme Unter Xen sind nicht alle Gäste gleich: Das erste Gastsystem, das Xen gleich mitstartet, verwaltet die Konsole und enthält die Treiber für alle unterstützte Hardware. Block- und Netzwerkgeräte exportiert der privilegierte Kernel der Domäne 0 über so genannte Backend- Treiber an die weiteren, unprivilegierten Gastsysteme. Die unprivilegierten Gastsysteme greifen über die Treiber der Domäne 0 auf die Hardware zu. Abbildung 1: Gastsysteme mit XEN Denen stellt Xen Block Devices (in erster Linie die Massenspeicher) und Netzwerkgeräte in virtualisierter Form zur Verfügung; sie benötigen keine eigenen Hardwaretreiber, um die Geräte anzusprechen. Das macht ihnen alle von dem Betriebssystem der Domäne 0 unterstützten Block- und Netzwerkgeräte zugänglich - egal, ob die Systeme selbst über passende Treiber verfügen oder nicht. Der Kernel der unprivilegierten Gastsysteme greift über die Xen-Frontend-Treiber auf diese Hardware zu. Aus der Domäne 0 startet, beendet und verwaltet man weitere Gastsysteme, legt sie schlafen und weckt sie wieder auf oder migriert sie auf andere Rechner. Die Gastsysteme können normal auf Festplatte oder in einer Image-Datei installiert sein. Die Xen-Entwickler verstehen ihr System als weiteren Schritt in Richtung Isolation einzelner Prozesse. Moderne Multitasking-Betriebssysteme wie Unix, Linux oder Windows (ab NT), schotten Anwendungen bereits weitgehend, aber doch nicht lückenlos, gegeneinander ab. Ein unkontrolliert forkender oder speicherfressender Prozess kann das ganze System zum Absturz bringen. Konsequent zu Ende gedacht hiesse das dann: Jede Anwendung läuft in ihrem eigenen Betriebssystem - für Server mit einer begrenzten Zahl an Programmen (etwa Intranet-, Datei und Mailserver) ist das durchaus vorstellbar. Raphael Jauslin Seite 4 von 16

6 2 Live Migration 2.1 Voraussetzungen Es gibt einige Voraussetzungen, die erfüllt sein müssen, damit eine erfolgreiche XEN Live Migration durchgeführt werden kann:» Auf beiden XEN Hosts muss XEN installiert sein. Zusätzlich müssen auf beiden Maschinen die benötigten Ressourcen (Speicher) vorhanden sein.» Die XEN Hosts müssen Zugriff auf das gleiche Dateisystem haben, Beispiele dafür sind NFS (Network File System), SAN (Storage Area Network) oder NAS (Network Attached Storage).» Beide XEN Hosts sollten im gleichen Subnet und zusätzlich mit dem Bridge Network Setup (kein privates Netzwerk innerhalb von XEN, sondern öffentliche Adresse) konfiguriert sein (IP und MAC Adresse werden übernommen). 2.2 Überblick Das Interesse an der Virtualisierung hat in den letzten Jahren stark zugenommen. Es gibt verschiedene Nutzungsmöglichkeiten, wie zum Beispiel Test- und Entwicklungsumgebungen oder Netzwerk- und Cluster-Simulationen. Mit der Paravirtualisierung können mehrere virtuelle Maschinen mit einer optimalen Performance isoliert auf einem physikalischen Rechner laufen. Eine weitere Interessante Möglichkeit ist die Live Migration:» Das Betriebssystem und all seine Applikationen werden als eine Einheit migriert.» Der aktuelle Zustand des Speichers kann in einer konsistenten und effizienten Art übertragen werden (siehe später). Dies bedeutet, dass z.b. ein Streaming Server migriert werden kann ohne dass die Benutzer sich neu verbinden müssen.» Benutzer müssen sich nicht an einen physikalischen Server anmelden, sondern an eine virtuelle Maschine, die auf irgendeinem physikalischen Server läuft. Dabei sind immer zwei Aspekte zu beachten:» Die Ausfallzeit (downtime) soll möglichst gering gehalten werden» Die gesamte Migrationsdauer (total migration time) soll möglichst klein sein Raphael Jauslin Seite 5 von 16

7 2.3 Design Bei der Live Migration sind die Ressourcen Memory, Netzwerk und Festplatten von zentraler Bedeutung. Die Migration des Memory der virtuellen Maschine kann auf verschiedene Arten durchgeführt werden. Dabei soll immer auf die beiden oben genannten Ziele geachtet werden (kurze down- und migration time). Folgende Methoden können angewandt werden: Push Phase: Die virtuelle Maschine (Quelle) läuft weiter, es werden bestimmte Pages über das Netzwerk zum Ziel transportiert. Die Pages, die während der Übertragung verändert wurden, müssen nochmals gesendet werden. Stop-and-Copy Phase: Die virtuelle Maschine (Quelle) wird gestoppt, die Pages werden über das Netzwerk kopiert und die Maschine wird auf dem Ziel Host neu gestartet. Pull Phase: Wenn beim Start der virtuellen Maschine auf dem Ziel noch Seiten fehlen, erzeugt dies einen Page Fault und die Seiten werden über das Netzwerk von der Quelle übertragen. Es gibt nun verschiedene Lösungen für das Memory Transfer Problem, wobei nachfolgend einige Beispiele genannt werden: Pure stop-and-copy: Hier wird die virtuelle Maschine gestoppt, der Speicher übertragen und anschliessend auf dem Ziel-Host neu gestartet. Dies ist relativ einfach zu implementieren, die downtime und die total migration time sind jedoch relativ hoch (vor allem bei viel alloziertem Speicher). Pure demand-migration: Eine erste kurze stop-and-copy Phase transferiert nur die grundlegenden Memory Strukturen. Alle Pages werden nach dem Start der virtuellen Maschine auf dem neuen Host beim Zugriff auf diese über das Netzwerk wiederhergestellt. Diese Variante hat eine sehr kleine downtime, braucht jedoch lange für die ganze Migration (total migration time). Hier ist ebenfalls die Performance schlecht, da viele Page Faults auftreten und die Pages über das Netzwerk übertragen werden müssen. Pre-copy: Für die XEN Live Migration wurde diese Variante ausgewählt. Hier wird iterativ die Push Phase durchlaufen und danach eine kurze stop-and-copy Phase durchgeführt. Iterativ bedeutet, dass beim Durchgang n alle Pages übertragen werden, die bei Durchgang n-1 verändert wurden (alle Pages werden beim ersten Durchgang übertragen). Die Anzahl Iterationen ist dabei begrenzt, da gewisse Pages sehr oft verändert werden. Raphael Jauslin Seite 6 von 16

8 2.4 Lokale Ressourcen Memory kann direkt kopiert werden, dies ist bei den lokalen Ressourcen wie Festplatten und Netzwerkkarten nicht der Fall. Netzwerk: Für die Netzwerk Ressourcen soll das Betriebssystem alle offenen Netzwerkverbindungen beibehalten, und dies ohne Forwarding-Mechanismus (Weiterleitung der Pakete an den Ziel-Host). Das migrierende System soll zudem die IP und MAC Adresse beibehalten. Bei XEN wurde dies folgendermassen gelöst: Ein ARP Request wird vom migrierenden Host generiert, der ankündigt, dass die IP Adresse (der virtuellen Maschine) an einen neuen Ort gewechselt hat. Somit werden die Netzwerk Pakete an die neue physikalische Adresse gesendet, und nur eine kleine Menge an in-flight Paketen gehen verloren. Festplatte: Für die Migration wird ein Zugriff auf ein gemeinsames Dateisystem vorausgesetzt (siehe Kapitel 2.1). Die Übertragung des Festplatten Inhalts oder des Images ist noch kein Bestandteil von der XEN Live Migration (siehe Kapitel 2.7) 2.5 Ablauf einer Migration Der gesamte Ablauf einer Live Migration ist auf der nachfolgenden Grafik ersichtlich: Abbildung 2: Ablauf der Live Migration Raphael Jauslin Seite 7 von 16

9 Stage 0: Pre-Migration Auf dem Host A läuft eine aktive virtuelle Maschine. Nun muss zuerst ein Ziel-Host ausgewählt werden, auf dem die notwendigen Ressourcen vorhanden sind. Stage 1: Reservation Ein Request wird von A an B gesendet, der die vorhandenen und notwendigen Ressourcen auf Host B überprüft und anschliessend einen Container reserviert, der dem Container der virtuellen Maschine auf Host A entspricht. Stage 2: Iterative Pre-Copy In der ersten Iteration werden alle Pages transferiert, anschliessend nur noch solche, die bei der letzen Iteration verändern wurden (dirty pages). Stage 3: Stop-and-Copy Die virtuelle Maschine auf Host A wird gestoppt und der Netzwerkverkehr auf Host B umgelenkt. Danach wird der CPU Zustand sowie die übrig gebliebenen Memory Pages transferiert (solche, die oft verändert wurden). Am Ende dieses Schrittes sind auf Host A und B zwei identische virtuelle Maschinen, Host A ist aber immer noch Primärer Host. Stage 4: Commitment Host B bestätigt, dass er eine identische virtuelle Maschine besitzt, somit kann Host A seine virtuelle Maschine beenden und Host B wird Primärer Host. Stage 5: Activation Die virtuelle Maschine auf Host B ist aktiv. Dieser Ablauf garantiert, dass immer ein Host eine voll funktionsfähige virtuelle Maschine besitzt. Bei möglichen Fehlern können so keine Daten verloren gehen. 2.6 Performance (Übernommen aus Live Migration of Virtual Machines [University of Cambridge, UK & University of Copenhagen, Denmark]) Der Performance Test wird mit zwei Dell PE-2650 Server durchgeführt, die 2GHz Dual XEON Prozessoren (HyperThreading) und 2GB RAM besitzen. Dazwischen ist ein Gigabit Netzwerk vorhanden, dass mit Broadcom TG3 Netzwerkkarten angesprochen wird. Als Speicher wird iscsi verwendet, genauer ein NetApp F840 Storage Server. Die virtuelle Maschine ist mit einem Apache 1.3 Webserver ausgestattet (Statische Aufrufe). Die nachfolgende Grafik zeigt die Ergebnisse des Tests (512KB Files, 100 gleichzeitige Verbindungen): Raphael Jauslin Seite 8 von 16

10 Abbildung 3: Performance der Live Migration Beim Start des Testes ist der Durchsatz 870MBit/s, nach ca. 27 Sekunden beginnt die Live Migration. Dabei sinkt der Durchsatz auf 765Mbit/s, da das Memory zum neuen Host kopiert werden muss. Danach sinkt der Durchsatz nochmals auf 694MBit/s, in diesem Schritt werden die zusätzlichen Iterationen durchgeführt. Anschliessend findet die stop-and-copy Phase statt, der Webserver ist für 165ms nicht verfügbar. Danach läuft die virtuelle Maschine auf dem neuen Host mit dem gleichen Durchsatz weiter. Eine weitere interessante Grafik ist die Übertragung des Memorys bei einer Live Migration. Diese Daten wurden mit SPECweb99 ermittelt und sehen folgendermassen aus (Virtuelle Maschine mit 800MB RAM): Abbildung 4: Memory Transfer Raphael Jauslin Seite 9 von 16

11 2.7 Ausblick Nachfolgend einen Ausblick über besondere Features der Live Migration, die bis jetzt noch nicht implementiert sind: Cluster Management In einer Cluster Umgebung, wo mehrere virtuelle Maschinen auf verschiedenen physikalischen Servern verteilt sind, wäre Load Balancing ein interessantes Feature. So könnten die virtuellen Maschinen, je nach Prozessor, Memory oder Netzwerk-Auslastung der physikalischen Maschine, automatisch auf andere Server verschoben werden. Wide Area Network Redirection Die Live Migration funktioniert effizient und mit sehr kurzem Unterbruch auf lokalen Gigabit Netzwerken (Layer 2 Redirection). Diese Eigenschaften reichen jedoch nicht aus um eine Übertragung auf dem Wide Area Netzwerk durchzuführen: Das Betriebssystem müsste beispielsweise eine neue IP Adresse beziehen, die im Adressbereich des Ziel Subnets liegt. Migrating Block Devices Die Images der virtuellen Maschinen müssen auf einem Dateisystem liegen, auf das alle XEN Hosts Zugriff haben (z.b. iscsi oder NFS). Das Problem einer Migration von Blockgeräten besteht darin, dass die Images meistens grösser sind als das verfügbare Memory. Wenn die ganz Disk (oder Image) zum neuen Host transferiert werden muss, steigt die total migration time drastisch an. Eine mögliche Lösung um dies zu verkürzen wäre eine Spiegelung der Disk bzw. des Images auf verschiedene Hosts (Mirroring). Raphael Jauslin Seite 10 von 16

12 3 Installation und Konfiguration Im nachfolgenden Kapitel wird die Installation und Konfiguration der Live Migration mit XEN auf einem Debian Sarge 3.1 System beschrieben. Bei der Installation des Debian Grundsystem werden keine speziellen Einstellungen vorgenommen, deshalb wird hier auf die Dokumentation der Installation des Basissystems von Debian verzichtet. Es werden zwei Computer, die beide die gleiche Hardware besitzen, mit einem Debian 3.1 aufgesetzt und danach XEN installiert (siehe Kapitel 3.1). Eine der beiden Maschinen wird zusätzlich als NFS Server konfiguriert (in diesem Beispiel XEN Server 2). Das Netzwerk sieht somit folgendermassen aus: Abbildung 5: Installation der Live Migration Raphael Jauslin Seite 11 von 16

13 3.1 Installation XEN Zuerst müssen einige Debian Pakete deinstalliert und andere zusätzlich installiert werden, damit XEN voll funktionsfähig ist: # apt-get remove exim4 exim4-base lpr nfs-common portmap pidentd pcmcia-cs pppoe pppoeconf ppp pppconfig # apt-get install screen ssh debootstrap python python2.3-twisted iproute bridge-utils libcurl3-dev Danach kann XEN heruntergeladen und anschliessend installiert werden. Bei Verwendung von XEN sollte TLS (Thread local storage) deaktiviert werden, da dies die Performance verringert: # wget # tar xvzf xen install-x86_32.tgz # cd xen install #./install.sh # mv /lib/tls /lib/tls.disabled Anschliessend werden die RC-Einträge erstellt (automatischer Start der Dienste): # update-rc.d xend defaults # update-rc.d xendomains defaults Danach wird der XEN Kernel in der Datei /boot/grub/menu.lst eingetragen und dieser gestartet: title Xen / XenLinux kernel /boot/xen.gz dom0_mem= module /boot/vmlinuz xen0 root=/dev/hda1 ro console=tty0 3.2 NFS Server und Client einrichten Auf dem NFS Server (in diesem Beispiel XEN Server 2) müssen folgende Pakete installiert werden: # apt-get install nfs-kernel-server nfs-common portmap Diese Pakete müssen auf dem Client installiert sein (XEN Server 1): # apt-get install nfs-common portmap Die Konfiguration des Servers wird in der Datei /etc/exports vorgenommen. Der Eintrag sieht wie folgt aus (Verzeichnis /xen wird freigegeben): /xennfs *(rw,sync,no_root_squash) Raphael Jauslin Seite 12 von 16

14 Damit kann jeder Client (* = Wildcard) auf /xen lesend und schreibend zugreifen. Dieser Zugriff kann auch eingeschränkt werden, indem nur bestimmte IP Adressen Zugriff auf eine NFS Ressource bekommen. Weitere Infos hält die Manpage (man exports) bereit. Damit die Änderungen wirksam werden, sollte nach jeder Änderung immer exportfs -a ausgeführt werden. Auf dem Client wird der Share ganz normal gemountet, in diesem Beispiel sieht der Befehl folgendermassen aus (der Share /xennfs auf dem NFS-Server wird in das lokale Verzeichnis /xen gemountet, das zuvor erstellt wurde): mount -t nfs servername:/xennfs /xen 3.3 Gastsystem einrichten Nachdem XEN erfolgreich installiert ist, kann eine virtuelle Maschine (DomU) erstellt werden. Für die Live Migration spielt die Distribution des Gastsystems keine Rolle, in dieser Installation wird ein Debian 3.1 System verwendet. Die wichtigsten Parameter sind nachfolgend aufgelistet. Zuerst werden zwei Images für die Root und die Swap Partition erstellt: # dd if=/dev/zero of=/xen/images/vm01.img bs=1024k count=1000 # dd if=/dev/zero of=/xen/images/vm01-swap.img bs=1024k count=500 Danach werden beide Images mit einem Dateisystem formatiert: # mkfs.ext3 /xen/images/vm01.img # mkswap /xen/images/vm01-swap.img Anschliessend kann das Image gemountet und mit debootstrap ein Debian installiert werden: # mount -o loop /xen/images/vm01.img /xen/vm01 # debootstrap --arch i386 sarge /xen/vm01 Die virtuelle Maschine ist zu diesem Zeitpunkt ein unkonfiguriertes Basissystem. Folgende Dateien müssen noch angepasst werden:» /etc/fstab» /etc/hostname» /etc/hosts» /etc/network/interfaces» /etc/apt/sources.list Raphael Jauslin Seite 13 von 16

15 3.4 Starten der virtuellen Maschine Für die virtuelle Maschine (DomU) kann nun eine Konfigurationsdatei erstellt werden. In dieser sind die Boot Optionen und die Netzwerkeinstellungen der Gast-Domäne definiert: # /etc/xen/vm01.sxp name ="vm01" kernel ="/boot/vmlinuz xenu" root ="/dev/hda1 ro" memory =128 disk = ['file:/xen/images/vm01.img,hda1,w','file:/xen/images/vm01- swap.img,hda2,w'] #network nics=1 dhcp="off" ip=" " netmask=" " gateway=" " hostname="xen-vm01.cs.fh-aargau.ch" Nun lässt sich die virtuelle Maschine starten: # xm create /etc/xen/vm01.sxp Mit dem Befehl xm list können die verschiedenen Domänen angezeigt werden: # xm list Name ID Mem(MiB) VCPUs State Time(s) Domain r vm b Anpassen von Xend Damit die XEN Live Migration einwandfrei funktioniert, müssen zusätzliche Anpassungen am Dienst Xend vorgenommen werden. Die Änderungen sind nachfolgend dokumentiert und werden auf beiden Servern durchgeführt: # /etc/xen/xend-config.sxp (xend-relocation-server yes) (xend-relocation-address ' ') (xend-relocation-hosts-allow ' ') # Standardmässig nur localhost Durch diese Einstellungen können nun alle Hosts auf die Relocation Server (Live Migration) zugreifen. Auch hier können bei Bedarf nur bestimmte IP s zugelassen werden. Raphael Jauslin Seite 14 von 16

16 3.6 Migration Jetzt kann die Live Migration gestartet werden: # xm migrate --live vm01 <ziel> Wenn das --live Flag nicht eingestellt ist, wird die Domäne gestoppt, eine Kopie des Arbeitsspeichers auf den neuen Server kopiert und dort wieder gestartet. Der Unterschied ist bei einem Test mit Ping sehr gut erkennbar ( ist die IP Adresse der virtuellen Maschine): Abbildung 6: Ping Live Migration (pre-copy) MIGRATION LIVE MIGRATION Abbildung 7: Ping Migration (stop-and-copy) Raphael Jauslin Seite 15 von 16

17 4 Literaturverzeichnis L1. Internet Live Migration of Virtual Machines Stand NSDI 2005 Xen and the Art of Virtualization Stand NSDI 2005 HowToForge - The Perfect Xen 3.0 Setup For Debian Stand NFS unter Debian einrichten Stand Wikipedia: XEN Stand L2. Dokumente und Zeitschriften XEN User Manual Documentation XEN v3.0 XEN Virtual Machine Monitor Semesterarbeit von Raphael Jauslin und Andreas Häni, 3. März 2006 Virtualisierung mit XEN Seminararbeit von Dominik Rüfenacht, 11. Mai 2006 Linux Magazin: Virtualisierung Kurt Garloff, Ausgabe 04/06 5 Abbildungsverzeichnis Abbildung 1: Gastsysteme mit XEN... 4 Abbildung 2: Ablauf der Live Migration... 7 Abbildung 3: Performance der Live Migration... 9 Abbildung 4: Memory Transfer... 9 Abbildung 5: Installation der Live Migration...11 Abbildung 6: Ping Live Migration (pre-copy)...15 Abbildung 7: Ping Migration (stop-and-copy)...15 Raphael Jauslin Seite 16 von 16