Virtualisierung mit Xen Seminararbeit von Rüfenacht, Dominik, I6m

Transkript

1 Virtualisierung mit Xen Seminararbeit von Rüfenacht, Dominik, I6m Fachhochschule Nordwestschweiz Departement Technik Studiengang Informatik Betreuender Dozent: Dr. Harald von Fellenberg Windisch, 19. Juni 2006

2 Zusammenfassung Die vorliegende Seminararbeit umfasst die Virtualisation mit Xen. Die Schwerpunkte der Arbeit liegen einerseits bei der Konfiguration eines Systems, auf welchem ein privilegiertes und ein unprivilegiertes Gastsystem installiert werden, andererseits wird die Architektur von Xen durchleuchtet, um ein gutes Verständnis über die Funktionsweise zu erhalten. Im Weiteren wird ein Überblick über die aktuellen Virtualisierungstechnologien gegeben, untermauert werden die unterschiedlichen Technologien mit einem Vergleich in Form zweier Performance-Tests. Der Bericht beginnt mit einer Einleitung, bevor im zweiten Teil die Architektur und die Funktionsweise von Xen beschrieben werden. Danach erfolgt ein kurzer Abriss über die Installation der Gastsysteme. Das letzte Kapitel widmet sich dem Performance-Vergleich. Windisch, Sommersemester 05/06 Dominik Rüfenacht Seite 1 von 17

3 Inhaltsverzeichnis 1 Virtualisierungstechnologie Softwarevirtualisierung Hardwarevirtualisierung Funktionsweise von XEN Übersicht Hybride Paravirtualisierung für XEN CPU-Management Device-IO Neuerungen in Xen Installation und Konfiguration von XEN Übersicht Installation des XEN Binary Package Installation XEN Konfiguration des GRUB Bootloaders Gastsystem einrichten Erstellen der virtuellen Partitionen Installieren eines Debian Systems Erstellen der ersten virtuellen Maschine Performance-Vergleich Installation Vmware Vorbereiten eines neuen Kernels Konfiguration von VMware Performance Tests mit Bonnie Performance Tests mit HTTPerf Literaturverzeichnis...16 L1. Internet...16 L2. Dokumente und Zeitschriften Abbildungsverzeichnis...16 Dominik Rüfenacht Seite 2 von 17

4 1 Virtualisierungstechnologie 1.1 Softwarevirtualisierung Virtuelle Maschine Bei Virtualisierung mit einer Virtuellen Maschine wird eine komplett neue Hardwareumgebung simuliert. Auf dieser virtuellen Hardware-Ebene können Betriebssysteme virtuell gestartet werden, ohne dass sie eine Verwaltungsschicht verwenden müssen. Den einzelnen Gast-Systemen wird dabei jeweils ein eigener kompletter Rechner mit allen Hardware-Elementen (Prozessor, Laufwerke, Arbeitsspeicher, usw.) vorgegaukelt. Der prinzipielle Vorteil ist, dass an den Betriebssystemen selbst (fast) keine Änderungen erforderlich sind. Wenn weder diese Hardware-Elemente, noch die Betriebssysteme der Gastsysteme diese Form der Virtualisierung unterstützen, muss die Virtualisierungssoftware eine Emulationsschicht benutzen, um jedes Gast-System zu überzeugen, es hätte die Hardware für sich allein. Diese Emulation ist oft weniger effizient als direkter Zugriff auf die Hardware, was dann zu einer verringerten Geschwindigkeit führen kann. Beispiel: VMWare Paravirtualisierung Bei der Paravirtualisierung wird zwar ein zusätzliches Betriebssystem virtuell neu gestartet, jedoch wird keine Hardware virtualisiert oder emuliert, sondern die virtuell gestarteten Betriebssysteme verwenden eine abstrakte Verwaltungsschicht (Hypervisor) um auf gemeinsame Ressourcen (Netzwerkanbindung, Festplatten-Speicher, Benutzer- Ein/Ausgaben) zuzugreifen. Beispiel: XEN 3 Abbildung 1: Vergleich Hardware-Software Virtualisierung Dominik Rüfenacht Seite 3 von 17

5 1.2 Hardwarevirtualisierung Prozessorvirtualisierung Intel Vanderpool Normalerweise laufen das Betriebssystem und die Treiber im so genannten Ring 0 (Kernel Mode) und Applikationen im Ring 3 (User Mode). Diese "Current Privilege Levels" werden auch mit CPL 0 beziehungsweise CPL 3 bezeichnet. Der Trick beim Erzeugen eines virtuellen Systems besteht darin, dieses mit CPL 3 ablaufen zu lassen. Wenn das Betriebssystem des virtuellen Rechners nun einen Befehl ausführen will, der nur im Ring 0 (CPL 0) gestattet ist, löst der Prozessor eine Exception aus. Routinen zur Behandlung dieser Ausnahmen können dann den privilegierten Befehl emulieren. Dabei behält das Wirtsystem die volle Kontrolle über das System. Die wichtigste Voraussetzung für das Funktionieren dieses Ansatzes ist, dass der Prozessor bei jeder unberechtigt durchgeführten privilegierten Anweisung eine Exception auslöst. Intel unterstützt die Virtualisierung auf Prozessorebene durch eine neue Form von CPU- Operationen mit der Bezeichnung VMX (Virtual Machine Extensions). Dabei gibt es mit "Root" und "Non-Root" zwei Arten von VMX-Operationen. So agiert VM-Software im VMX- Root-Modus. Intel bezeichnet diesen Host auch als Virtual Machine Monitor VMM. Der VMM besitzt die volle Kontrolle über den Prozessor und die übrige Hardware des PCs. Die virtuellen Maschinen beziehungsweise die Gast-Software arbeiten somit im VMX-Non-Root- Modus. Dabei ist es für Gast-Software nicht möglich, seinen Betrieb im VMX-Non-Root- Modus zu erkennen. AMD Pacifica AMD64-CPUs mit der Secure Virtual Machine Architecture erhalten den so genannten SVM- Befehlssatz. Der Befehlssatz funktioniert nach dem gleichen Prinzip wie derjenige von Intel. Jedoch unterscheiden sie sich in Bezug auf den Speicher-Controller, der von Pacifica ebenfalls virtualisiert wird. Normalerweise arbeitet jede VM in einem eigenen Adressbereich, den der Hypervisor/VMM unter Kontrolle behält. Die Adressanfragen einer VM übersetzt der Hypervisor/VMM und lenkt sie auf entsprechend zugewiesene physikalische Adressen um. Werden die Daten aus dem Speicher gelesen, so muss sie die Virtualisierungs-Software erneut für die virtuelle Maschine umleiten. Diese bei Intels Vanderpool praktizierte Lösung ist Software-basierend und kostet Zeit. Pacifica kann diesen Vorgang mit Hardware-Unterstützung erledigen. So gibt es in der SVM- Architektur den neuen Speicher-Modus Nested Paging. Dominik Rüfenacht Seite 4 von 17

6 2 Funktionsweise von XEN Übersicht Besonders teuer bei der Virtualisierung ist die Emulation der CPU, welche jeden einzelnen Maschinenbefehl interpretieren muss. Denn selbst wenn sie nur Rechner derselber CPU- Architektur imitiert, muss der Emulator alle Hardware-Zugriffe abfangen und die Speicherbereiche der virtuellen Maschinen voreinander abschirmen. Das ist nötig, weil die Betriebssysteme nichts von ihrer virtuellen Umgebung wissen und in dem Glauben handeln, sie hätten die exklusive Verfügungsgewalt über die Ressourcen. Emulatoren, die in dieser Weise ihre Gäste kontrollieren, bezeichnet man als Hypervisor. Eine Modifikation dieses Modells besteht darin, privilegierten virtuellen Maschinen die direkte Kommunikation mit der Hardware zu erlauben und die Zugriffe der anderen Instanzen an sie weiterzureichen. Auf diese Weise kommt der Hypervisor selbst mit wenigen Gerätetreibern aus. hybride Virtualisierung Der Hypervisor kann nicht damit rechnen, dass ihn die CPU bei kritischen Instruktionen automatisch ins Spiel bringt. Das kostet erheblich Performance. Dies wird erst mit den Befehlssätzen von Intel und AMD (Vanderpool, bzw. Pacifica) in naher Zukunft auf HW- Ebene gelöst. Eine Möglichkeit, diesen Performance-Verlust wieder teilweise auszugleichen, ist die Strategie der Paravirtualisierung. Dem Hypervisor wird der zu überprüfende Code mundgerecht aufbereitet. Die x86-hardware wird direkt an die Gastsysteme durchgeleitet, statt sie für das Gastsystem zu emulieren. Jedoch hat diese Strategie den Nachteil, dass Anpassungen am Kernel der Gastsysteme erfolgen müssen. Dies stellt z.b. für Windows eine kaum überwindliche Hürde dar. 2.2 Hybride Paravirtualisierung für XEN 3 Seit der Version 2 wurde der Hypervisor klein und sicher gemacht. Nur noch privilegierte Domains haben Zugriff auf die Hardware. Dies entspricht dem hybriden Modell. Zudem hat die erste "Domain 0" besondere Rechte. Sie hat das Recht, andere virtuelle Maschinen zu konfigurieren, zu starten und wieder anzuhalten. Die Domain 0 fährt direkt nach dem Starten des Hypervisors hoch. Sie enthält die Treiber für alle unterstützte Hardware. Die erforderlichen Geräte exportiert der Kernel der Domäne 0 über Backend-Treiber an die unprivilegierten Domänen. Die unprivilegierten Domänen werden "domu" genannt. Dominik Rüfenacht Seite 5 von 17

7 2.2.1 CPU-Management Ein zentraler Punkt in der Paravirtualisation ist das CPU-Management. Die Strategie dabei ist, den Gastsystemen nicht zu erlauben, Code auf dem Ring 0 auszuführen. Nur das Host- OS hat die Erlaubnis, Code auf dem höchsten Ring auszuführen. Da die x86-architektur 4 Ringe aufweist, ist hier eine effiziente Virtualisation möglich. Applikationen laufen normalerweise im Ring 3, also auf der niedrigsten Privilegierungs-Stufe. Die Ringe 1 und 2 sind normalerweise nicht gebraucht (Ausnahme OS/2). Jedes Betriebssystem, das nach diesem Schema funktioniert, kann auf XEN lauffähig gemacht werden. Hier muss die Modifikation gemacht werden, dass das zu erstellende Gast-Betriebsystem auf dem Ring 1 laufen wird. So wird einerseits verhindert, dass es Zugriff auf den Ring 0 und somit auf den Host hat, aber auch isoliert wird vom Ring 3, von den Applikationen Device-IO Gewöhnliche Virtualisierungs-Technologien emulieren die vorhandenen Hardware-Geräte, so dass die Gast-Systeme darauf zugreifen können. XEN liefert ein Set von einfachen Geräte- Abstraktionen, welche eine Schnittstelle erlauben, die zugleich effizient und sicher ist. IO-Daten werden zu und von den Gast-Systemen über shared-memory via XEN übertragen. Abbildung 2: Paravirtualisierung Dominik Rüfenacht Seite 6 von 17

8 2.3 Neuerungen in Xen 3 Unterstützung von virtuellen SMP-Maschinen Während XEN schon vorher mehrere Prozessoren unterstützte, war jedoch pro Domain nur ein Prozessor nutzbar. Nun kann die Anzahl der Prozesse sogar zur Laufzeit verändert werden. ACPI-Support Nun steht ein Grossteil der ACPI-Funktionalität der Domäne 0 zur Verfügung HW-Unterstützung AGP und DRM-Unterstützung 64-Bit Support XEN 3 unterstützt nun auch 64-Bit Betriebssysteme Nutzung der neuen CPU-Befehlssätze Mit dem Kommen der neuen Befehlssätze "Vanderpool" und "Pacifica" werden auch nicht paravirtualisierte Betriebsysteme unterstützt. Damit wird wohl auch bald Windows mit XEN betrieben werden können. (Wenn es überhaupt verlangt wird) Dominik Rüfenacht Seite 7 von 17

9 3 Installation und Konfiguration von XEN In diesem Kapitel wird beschrieben, wie ein XEN-System unter Debian Sarge installiert und konfiguriert wird. Zusätzlich zur Domäne 0 wird ein erstes Gast-System aufgesetzt, ebenfalls auf Debian Sarge Basis. Auf die Beschreibung des Grundsystems (Normale Installation eines Debian-Systems) wird in dieser Anleitung verzichtet. 3.1 Übersicht Versionen: Verwendete Hardware: - Debian Sarge 3.1a DVD-Version - XEN Binary Package (28 MB) CPU: Intel Pentium IV, 2.8 GHz RAM: 512 MB NIC: 3Com 3c905c-TX/TX-M HD: 80.0 GB Western Digital Grafik: ATI Radeon 9600 Partitionierung: /boot 100 MB bootable flag on swap 1 GB / 5 GB /xen 20 GB 3.2 Installation des XEN Binary Package Damit XEN korrekt verwendet und eingebunden werden kann, sind einige Modifikationen am Grundsystem notwendig. # 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 Installation XEN Zuerst muss das Binary Package in das Verzeichnis /usr/src heruntergeladen werden, danach wird die Datei entpackt und installiert. Bei Verwendung von XEN sollte TLS deaktiviert werden, da dies die Performance verringert. # cd /usr/src # wget # tar xvzf xen install-x86_32.tgz # cd xen install #./install.sh # mv /lib/tls /lib/tls.disabled Dominik Rüfenacht Seite 8 von 17

10 Damit XEN beim nächsten Booten gestartet wird, müssen die RC-Einträge gemacht werden. # update-rc.d xend defaults # update-rc.d xendomains defaults Konfiguration des GRUB Bootloaders In der Datei /boot/grub/menu.lst muss ein eigener Eintrag hinzugefügt werden, damit anschliessend mit XEN Unterstützung gestartet werden kann.... title Xen / XenLinux kernel /xen.gz dom0_mem=64000 module /vmlinuz xen0 root=/dev/hda6 ro console=tty Gastsystem einrichten Erstellen der virtuellen Partitionen Erstellen der beiden Ordner für die Images: # mkdir /xen/vm_base # mkdir /xen/images Nun werden zwei Image Dateien für das Gastsystem erstellt, ein 1GB grosses Image für die Root-Partition und ein Image von 512MB für die SWAP Partition. # dd if=/dev/zero of=/xen/images/vm_base.img bs=1024k count=1000 # dd if=/dev/zero of=/xen/images/vm_base-swap.img bs=1024k count=500 Danach werden die erstellten Images formatiert. # mkfs.ext3 /xen/images/vm_base.img # mkswap /xen/images/vm_base-swap.img Installieren eines Debian Systems Das erstelle Basis-Image kann jetzt gemountet werden, um ein Debian System zu installieren # mount -o loop /xen/images/vm_base.img /xen/vm_base # debootstrap --arch i386 sarge /xen/vm_base Dann wird mit dem Befehl chroot in die neue Umgebung gewechselt # chroot /xen/vm_base # apt-setup Dominik Rüfenacht Seite 9 von 17

11 Nun muss ein Archiv ausgewählt werden. Wir verwenden den Mirror mirror.switch.ch, als Archive access method for apt muss also http verwendet werden. Die /etc/apt/sources.list sollte danach etwa so aussehen: deb stable main deb-src stable main deb stable/updates main Nun sollte noch ein Update durchgeführt werden, um danach mit der base-config fortzufahren. # apt-get update # base-config Folgende Punkte müssen bei der System-Konfiguration eingestellt werden, alles andere ist in unserem Fall unwichtig. Bei den Paketen wurde nichts ausgewählt. 1. Configure timezone 2. Set up users and passwords 3. Select and install packages 4. Finish configuring the base system Als nächsten Schritt wird nfs-common und der Hostname entfernt # apt-get remove nfs-common # rm -f /etc/hostname Die Datei /etc/fstab sollte nach dem Editieren der neuen Partitionen etwa so aussehen: /dev/hda1 / ext3 defaults 1 2 /dev/hda2 none swap sw 0 0 /dev/pts devpts gid=5,mode= none /dev/shm tmpfs defaults 0 0 Ebenfalls angepasst wird /etc/network/interfaces: auto lo iface lo inet loopback address netmask /etc/hosts: localhost.localdomain localhost Nun kann die Gast-Umgebung wieder verlassen werden. Zum Schluss werden die Kernel Module ins neue Gast-System geladen und das Laufwerk aufgelöst. # cp -dpr /lib/modules/ xenu /xen/vm_base/lib/modules/ # mv /xen/vm_base/lib/tls /xen/vm_base/lib/tls.disabled # umount /xen/vm_base Nun ist unser erstes Gast System bereit und kann in Betrieb genommen werden. Dominik Rüfenacht Seite 10 von 17

12 3.4 Erstellen der ersten virtuellen Maschine Zuerst wird das vorher erstellte Image kopiert, damit die virtuelle Maschine angepasst werden kann. Zuvor wurde lediglich das Base-Template dazu erstellt. # cp -pf /xen/images/vm_base.img /xen/images/vm01.img # cp -pf /xen/images/vm_base-swap.img /xen/images/vm01-swap.img Anschliessend wird ein XEN Konfigurations-File erstellt werden, wo die Boot Optionen und die Netzwerkeinstellungen der Gast-Domäne definiert sind. # /etc/xen/vm01-config.sxp name ="vm01" kernel ="/boot/vmlinuz xenu" root ="/dev/hda1" 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="xen01.cs.fh-aargau.ch" Zu Beachten gilt, dass alle Pfadangaben übereinstimmen! Nun lässt sich die virtuelle Maschine starten: # xm create -c /etc/xen/vm01-config.sxp Nun, wenn alles korrekt läuft, erscheint ein Login-Promt, an dem man sich nun anmelden kann, um sich danach frei in der neuen Umgebung zu bewegen. Wenn das Gast-System nicht mehr gebraucht wird, kann man sie mit diesem Befehl wieder herunterfahren. # xm shutdown vm01 Dominik Rüfenacht Seite 11 von 17

13 4 Performance-Vergleich XEN wird überall, auch in dieser Arbeit als eine revolutionäre, schnelle Virtualisierungstechnologie angepriesen. Damit diese Aussage auch verifiziert werden kann, erfolgt nun ein direkter Vergleich mit dem Konkurrenzprodukt Vmware. Getestet werden dabei die durchschnittliche Übertragungsrate und die CPU-Auslastung mittels des Performance Test-Programmes Bonnie. 4.1 Installation Vmware Vorbereiten eines neuen Kernels Damit wir VMware unter realistischen Umständen vergleichen können, d.h., nicht unter dem modifizierten XEN-Kernel, muss nun zuerst ein neuer Kernel erstellt werden. Dies geschieht in folgenden Schritten: Kernel-Download unter entpacken in das Source Verzeichnis In das Linux Source Verzeichnis wechseln (/usr/src/) make menuconfig ausführen (Dabei wird die Standard-Konfiguration übernommen, keine zusätzlichen Module werden aktiviert) make make modules_install Neu erstellten Kernel kopieren cp arch/i386/boot/bzimage /boot/vmware ) Grub anpassen (/boot/grub/menu.lst) Konfiguration von VMware Auf der Homepage von VMware ist die Installation unter Linux detailliert beschrieben. Daher wird hier auf die Installations-Anleitung verzichtet und stattdessen auf das Quellenverzeichnis hingewiesen, wo sich der Link zur VMware-Anleitung finden lässt. Für die Installation des Gast-Systems wurden ebenfalls 128 MB verwendet und die gleiche Kernel- Version, wie beim XEN-Gastsystem, um möglichst wenige Differenzen zwischen den beiden Systemen aufzuweisen. Dominik Rüfenacht Seite 12 von 17

14 4.1.3 Performance Tests mit Bonnie Bonnie (in der Version 1.03a) misst die Performance von File System Operationen und erstellt dabei eine beliebig grosse Datei auf der Festplatte. Neben den unterschiedlichen Schreib- und Lesestrategien wird auch die anfallende CPU-Last festgehalten. Die Testdatei sollte mindestens doppelt so gross wie den real im Rechner vorhandenen RAM-Speicher gewählt werden, da sonst nicht die Geschwindigkeit der Festplatte, sondern das Cacheverhalten von Linux gemessen wird. Messwerte auf VMware: #time bonnie -u root -s 450 Using uid:0, gid:0. Writing with putc()...done Writing intelligently...done Rewriting...done Reading with getc()...done Reading intelligently...done start 'em...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version Sequential Output Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP deb-vmware 450M Sequential Create Random Create Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP debvmware,512m,17915,77,27553,34,15828,30,24307,82,72780,76,1183.8,57,16,1400,99,+++++,+++,+++++,+++, 1222,97,+++++,+++,2261,78 Messwerte auf XEN: #time bonnie -u root -s 450 Using uid:0, gid:0. Writing with putc()...done Writing intelligently...done Rewriting...done Reading with getc()...done Reading intelligently...done start 'em...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version Sequential Output Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP xen-vm01 450M Sequential Create Random Create Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP xenvm01,512m,27319,94,36486,10,18044,5,25396,80,47648,7,152.5,0,16,3180,98,+++++,+++,+++++,+++,3344,9 9,+++++,+++,10336, 99 Dominik Rüfenacht Seite 13 von 17

15 Auswertung Bonnie Seq. Output Seq. Input Time (real) Time (user) Time (sys) 0 XEN VMware Anhand der Grafik ist ersichtlich, dass die Performance-Werte von XEN diejenigen von VMware bis zu 30% übersteigen. In diesem Diagramm nicht ersichtlich ist die CPU-Last. Diese ist im XEN-System jeweils bis zu 80% kleiner. Dieser Umstand lässt sich sehr wahrscheinlich auf die hybride Paravirtualisierung zurückschliessen, welche von XEN betrieben wird Performance Tests mit HTTPerf Um die Performance als Webserver zu Vergleichen, benutze ich das kleine Tool HTTPerf. HTTPerf testet Webserver, indem es beliebig viele Clients simuliert. Dazu kann eingestellt werden, wie viele calls ein einzelner Client anfordern soll. Mit einem optionalen Timeout- Parameter kann man die Ergebnisse herausfiltern, welche unter einer bestimmten Antwortzeit liegen. Getestet wurde mit den folgenden Argumenten: #httperf --server num-conn num-call 20 --timeout Es werden Clients simuliert, welche je 20 Mal auf den Server zugreifen. Zusätzlich wurde ein Timeout-Limit angegeben, so dass alle Anfragen, die nicht innerhalb einer gewissen Zeit zurückkommen, als Fehler gewertet werden. Dominik Rüfenacht Seite 14 von 17

16 Der Test mit HTTPerf zeigt zum Teil sehr überraschende Werte: Der XEN-Webserver ist im Vergleich zum VMWare-Server durchschnittlich 10% effektiver. Die Fehlerrate ist bei beiden Systemen nahezu identisch. Ausser Konkurrenz wurde noch ein Laborrechner geprüft, welcher jedoch über eine viel höhere Hardware-Leistung verfügt. Dies ist besonders bei der extrem niedrigen Fehlerrate ersichtlich. Dominik Rüfenacht Seite 15 von 17

17 5 Literaturverzeichnis L1. Internet HowToForge - The Perfect Xen 3.0 Setup For Debian Stand XEN and the Art of Virtualization Tecchannel - Intels Vanderpool virtualisiert CPUs Stand Tecchannel - AMD Pacifica: Virtualisierung von CPU & Speicher Stand Wikipedia: XEN Stand Installing Workstation on a Linux Host L2. Dokumente und Zeitschriften XEN Virtual Machine Monitor Semesterarbeit von Raphael Jauslin und Andreas Häni, 3. März 2006 Linux Magazin: Virtualisierung Kurt Garloff, Ausgabe 04/06 6 Abbildungsverzeichnis Abbildung 1: Vergleich Hardware-Software Virtualisierung...3 Abbildung 2: Paravirtualisierung...6 Dominik Rüfenacht Seite 16 von 17