Virtualisierungstechniken für IaaS

Transkript

1 1 Virtualisierungstechniken für IaaS Thomas Lechner Abstract Cloudsysteme haben in den letzten Jahren sehr stark an Bedeutung gewonnen. Häufig werden Cloudsysteme eingesetzt, wenn es um die Bereitstellung von Software oder einer Rechner-Infrastruktur geht. Bei der Bereitstellung einer Infrastruktur muss sehr flexibel auf Anforderungen reagiert werden. Ohne den Einsatz von Virtualisierung wäre dies nicht möglich. IaaS-Software greift hierzu auf bewährte Virtualisierungslösungen aus dem Serverbereich zurück. Diese Lösungen basieren nicht nur auf Software. Hardwareunterstützung für Virtualisierung wird zunehmend wichtiger. Dieses Paper erklärt, welche Probleme zu lösen sind, wenn ein Rechner in mehrere virtuelle Rechner aufgeteilt werden soll und wie diese Probleme gelöst wurden. Außerdem werden die bekanntesten Virtualisierungssysteme, die auch in verbreiteten IaaS-Lösungen eingesetzt werden, kurz vorgestellt. Keywords Virtualisierung, IaaS, QEMU, KVM, Xen, libvirt. 1 EINLEITUNG DER Anspruch einer IaaS-Plattform ist es, seinem Nutzer schnell und zuverlässig Zugriff auf eine Infrastruktur von Rechnern zur Verfügung zu stellen. Dazu greifen IaaS-Systeme auf Virtualisierungstechniken zurück. Dabei wird das Rad nicht neu erfunden. Im Serverbereich gibt es bereits erprobte und über Jahre ausgereifte Systeme, die jetzt auch in IaaS-Software Einzug halten. Virtualisierung erlaubt es, einen physikalischen Rechner so aufzuteilen, dass er mehrere virtuelle Rechner betreiben kann. Diese virtuellen Rechner werden Gäste genannt. Die grundlegende Idee ist, die Gäste genau wie normale Anwendungsprozesse im User-Mode laufen zu lassen. Es ist nicht möglich, beziehungsweise sehr kompliziert, mehrere Gastsysteme gleichberechtigt auf einem Hostsystem laufen zu lassen. Ein Betriebssystem geht immer davon aus, die gesamte Hardware für sich allein beanspruchen zu können. Mehrere gleichberechtigte Gastsysteme würden sich gegenseitig die Hardware wegnehmen und kein System würde korrekt laufen. 1.1 Ringe CPUs laufen aus Sicherheitsgründen und zum Schutz vor Fehlern in verschiedenen Modi. So gibt es auf x86 CPUs zum Beispiel den Real Mode und den Protected Mode. Im Real Mode kann auf den gesamten Speicher zugegriffen und die gesamte Peripherie verwendet werden. Im Protected Mode ist der Speicherzugriff eingeschränkt. Dies soll verhindern, dass Anwendungen auf fremden Speicher zugreifen können. Betriebssysteme greifen dieses Konzept auf und lassen Code in Priviligierungsstufen, den sogenannten Ringen, laufen. Im Ring 0 läuft der Betriebssystemkern. Deswegen wird dieser Ring auch häufig Kernel-Mode genannt. Im Kernel-Mode darf sozusagen alles gemacht werden. Die Fig. 1. Ringe anderen Ringe haben mit aufsteigender Nummer immer weniger Berechtigungen. Sie werden zusammenfassend als User-Mode bezeichnet. Anwendungen laufen überwiegend im Ring 3. Ring 1 und Ring 2 werden aus Kompatibilitätsgründen unter Linux gar nicht verwendet. Bei x86-64 Betriebssystemen wurde auf diese Ringe sogar komplett verzichtet. Falls ein Prozess aus Ring 3 einen priviligierten Befehl durchführt, wird eine Exception erzeugt, die dann von einem priviligierterem Ring abgefangen wird. In den meisten Fällen ist dies der Ring 0. Der Ring behandelt die Exception und übergibt danach wieder an den Prozess. Dieser Ablauf wird auch als Systemcall bezeichnet. 1.2 Das Problem Aus diesem Priviligierungssystem folgt ein Problem. Die Kernel der Gastsysteme befinden sich im User-Mode und sind in ihren Handlungen eingeschränkt. Problematische Befehle müssen also abgefangen werden oder dürfen gar nicht erst auftauchen. In jedem Fall wird aber ein zusätzliches Stück Software benötigt, welches die Gastsysteme verwaltet. Diese Software wird Hypervisor

2 2 genannt. Es wird zwischen 2 Typen von Hypervisoren unterschieden. Zu Typ 1 zählen alle, die direkt auf der Fig. 2. Hypervisortypen Hardware ohne zusätzliches Betriebssystem laufen. Typ 2 Hypervisoren benötigen ein Betriebssystem, in dem sie laufen. Eine Möglichkeit dieses Problem zu lösen, ist den Hypervisor im Ring 0 laufen zu lassen. Falls nun durch den Gast eine Exception durch einen kritischen Befehl aus gelöst wird, wird die Exception vom Hypervisor gefangen und behandelt. Die Behandlung ist nicht ganz trivial, da für jede mögliche Ausnahme entsprechend reagiert werden muss, um die Anforderungen des Gastsystems zu erfüllen. Diese Form der Virtualisierung wird vollständige Virtualisierung genannt. Vorteil ist, dass das Gastsystem nicht verändert werden muss und auch nichts davon mitbekommt, dass es virtualisiert wird. KVM ist einer der bekanntesten Vertreter dieser Form und wird im Abschnitt KVM genauer vorgestellt. Eine andere Möglichkeit, die problematischen Befehle zu vermeiden, ist das Gastbetriebssystem zu verändern. Dieser Ansatz wird Paravirtualisierung genannt. Kritische Befehle im Gastsystem werden durch sogenannte Hypercalls ersetzt. Hypercalls sind mit den Systemcalls vergleichbar. Allerdings gehen die Hypercalls direkt an den Hypervisor. Der bekannteste Hypervisor, der von Paravirtualisierung gebrauch macht, ist Xen. 2 BS-CONTAINER Einen komplett anderen Ansatz zur Virtualisierung eines Systems verfolgen die sogenannten Container. Dieses Verfahren wird auch Virtualisierung auf Betriebssystemebene genannt. Bei diesem Ansatz wird das Problem der Ringe umgangen, indem der Kernel des Hostsystems verwendet wird. Es treten im Gast somit keine problematischen Befehle auf. Es werden auch keine virtuellen Maschinen erzeugt. Es handelt sich vielmehr um virtuelle Laufzeitumgebungen. Diese Umgebungen nutzen den Kernel des Hostsystems. Daraus ergibt sich ein wesentlicher Nachteil. Es können nur Gäste gestartet werden, die in ihrer Kernelversion mit dem Host übereinstimmen. Die Mitbenutzung des Kernels hat aber auch einen entscheidenden Vorteil. Die Laufezeitumgebungen können sehr schnell gestartet werden, sparen Ressourcen und sind performanter als vergleichbare virtuelle Maschinen. Erwähnenswerte Programme, die dieses Verfahren implementieren sind LXC (Linux Containers) OpenVZ Docker Detailiertere Erklärungen zu Containervirtualisierung und Docker gibt es im Paper Container-Virtualisierung mit Docker von Christoph Schröder [19]. Im IaaS-Bereich konnte sich die Containervirtualisierung bisher nicht durchsetzen, da die Einschränkungen für die Gastsysteme zu groß sind. In spezialisierten Anwendungen im Serverbereich hat diese Virtualisierungsform aber ihre Daseinsberechtigung. 3 QEMU QEMU (Quick Emulator) ist ein quelloffener Hardware- Emulator. QEMU kann die gesamte Hardware eines Computers inklusive CPU emulieren. Neben der x86-architektur können unter anderem auch ARM- Prozessoren, SPARC32/64 und PowerPC emuliert werden [2]. Code von QEMU wird in vielen anderen Projekten verwendet. Das Android-SDK verwendet QEMU, um ARM-Prozessoren und Peripherie von Android-Geräten auf einem PC zu emulieren. Auch Virtualisierungssoftware wie Xen, KVM und VirtualBox verwenden Teile des QEMU-Quellcodes. Viele Virtualisierungslösungen nutzen QEMU zum Emulieren der Peripherie oder auch teilweise der CPU. Dabei kann QEMU auch eigenständig ein Gastsystem betreiben. In diesem Fall kann aber nicht von Virtualisierung gesprochen werden. Man spricht stattdessen von Emulation. Vorteil der Emulation ist, dass auch Betriebssysteme für fremde CPUs betrieben werden können. Nachteil ist die im Vergleich zur klassischen Virtualisierung geringere Geschwindigkeit, da der Code nicht nativ auf der Host-CPU ausgeführt wird. QEMU übersetzt den nativen Code des Gastsystems zuerst in Mikrooperationen und dann in für die Host-CPU ausführbaren Code. Bereits übersetzter Code wird im Cache gehalten, um die Ausführungszeit gering zu halten [2]. Bis Version 0.11 unterstützte QEMU den optionalen Beschleuniger KQEMU. KQEMU ermöglichte es, Code des Gastsystems nativ auf der Host-CPU auszuführen. Bedingung war, dass Host und Gast die x86-architektur verwenden. Dies verringerte die Ausführungszeit erheblich, da die Übersetzung des Codes wegfiel. Seit Version 0.12 setzt QEMU auf die Vorteile von KVM. KQEMU wird nicht mehr unterstützt. Teil von QEMU ist das Tool qemu-img. Es hilft beim Erzeugen, Verwalten und Konvertieren von Images. Ein Image dient als (virtuelle) Festplatte für eine virtuelle

3 3 Maschine. Einer der wichtigsten Befehle ist der create Befehl 1. qemu img c r e a t e f qcow disk. img 10G In diesem Beispiel wird ein Image im Format qcow mit dem Namen disk.img und der Größe 10 GByte erstellt. Das qcow Format ist ein vom QEMU-Projekt entwickeltes Format für Imagedateien. Hauptvorteil gegenüber dem raw Format ist, dass bei Erstellung eines Image nicht sofort der ganze Speicher allokiert wird. qemu img convert qcow O qcow2 disk. img disk1. img Dieser Befehl konvertiert 2 unser erzeugtes Image disk.img in disk1.img im Format qcow2. qcow2 bietet gegenüber qcow weitere Vorteile. Ebenfalls unterstützte Formate sind vmdk von VMWare, vdi von VirtualBox und parallels von Parallels Desktop. Von diesem erzeugten (und konvertierten) Image kann eine virtuelle Maschine gestartet werden. qemu kvm no kvm m 1024 cdrom ubuntu. i s o disk1. img monitor s t d i o Dieser Befehl startet eine virtuelle Maschine mit 1024MB Arbeitsspeicher und der Datei disk1.qcow2 als Festplatte. QEMU und KVM werden auf den meisten Distributionen als ein Paket angeboten. In diesem Abschnitt geht es aber nur um QEMU, deswegen wird diese virtuelle Maschine mit dem Parameter -no-kvm explizit ohne KVM- Unterstützung gestartet. Da von der Festplatte nicht gebootet werden kann, weil sie leer ist, muss mit - cdrom ubunutu.iso ein Bootmedium angegeben werden. In diesem Fall wird ein Abbild einer Ubunutu-Installations- CD angegeben. Mit dem Parameter -monitor stdio wird der QEMU-Monitor auf die Standardausgabe umgeleitet. Der QEMU-Monitor erlaubt es QEMU während des Betriebs zu steuern. Hauptsächlich kann man mit dem Monitor Informationen über die Hardware der virtuellen Maschine erhalten und die Hardware auch verändern. Aber es können auch Snapshots angefertigt oder virtuelle Maschinen auf einen anderen QEMU-Host migriert 3 werden. ( qemu) savevm mysnapshot Ein Snapshot speichert den Zustand einer virtuellen Maschine. Es wird der Zustand der CPU, des Arbeitsspeichers, der Peripherie und der Festplatte gespeichert. QEMU speichert diese Informationen auf dem Festplattenimage der virtuellen Maschine 4 [4]. Ein nur auf QEMU basiertes Virtualisierungssystem in einer IaaS-Umgebung einzusetzen ist keine gute Idee. 1. Alle Befehle wurden auf einem CentOS 6.5 System ausgeführt und können auf anderen Systemen abweichen. 2. disk.img bleibt erhalten 3. Live-Migration ist auch möglich 4. Voraussetzung: mindestens Version 0.9 und mindestens ein Image im qcow2-format, alternativ wird in eine seperate Datei geschrieben QEMU bietet wichtige Funktionen wie Migration, die Möglichkeit Snapshots anzufertigen und kann theoretisch jedes denkbare Gastsystem emulieren. Jedoch ist die geringe Geschwindigkeit ein großes Problem. Dieses Problem kann sehr leicht gelöst werden, indem man QEMU mit KVM kombiniert und somit weiterhin die Vorteile von QEMU nutzt und gleichzeitig eine höhere Geschwindigkeit erzielt. 4 KVM KVM (Kernel-based Virtual Machine) ist ein Kernelmodul, das seit Version Bestandteil des Linuxkernels ist. Ursprünglich wurde KVM von der Firma Qumranet entwickelt, welche 2008 von Red Hat gekauft wurde. KVM zählt zu den Typ-2-Hypervisoren. Das bedeutet, dass KVM nicht direkt auf der Hardware läuft sondern ein Betriebsystem benötigt. Da KVM eine Linuxkernelerweiterung ist, kommt als Hostsystem nur Linux in Frage. Üblicherweise führt KVM eine vollständige Virtualisierung durch, indem es die Hardwareerweiterung der CPU benutzt. Wenn im Gastsystem virtio-treiber zur Verfügung stehen, kommt auch Paravirtualisierung zum Einsatz. Unter Linux 5 stehen diese Treiber standardmäßig zur Verfügung. Für Windows existieren mittlerweile auch entsprechende Treiber. Diese müssen allerdings nachträglich installiert werden. virtio-treiber wissen von der Virtualisierung und können direkt mit dem Hypervisor kommunizieren. Durch diese direkte Kommunikation kann die Performance oder Funktion der Hardware des Gastsystems verbessert werden. Aktuell 6 gibt es virtio-treiber für PCI-Geräte, Netzwerkkarten, Festplatten und Arbeitsspeicher. Der virtioballoon-treiber erlaubt es, die Größe des Arbeitsspeichers während der Ausführung zu verändern. Und der virtionet-treiber ermöglicht einen wesentlich höheren Datendurchsatz der Netzwerkkarte. KVM benötigt zwingend eine CPU von AMD oder Intel mit Hardware-Virtualisierung 7. An Portierungen für PowerPC, IA64 und ARM wird derzeit 8 noch gearbeitet. Ob die eigene CPU Hardware-Virtualisierung anbietet, kann mit c a t /proc/ cpuinfo überprüft werden. Bei AMD-CPUs wird dies durch das Flag svm, bei Intel-CPUs durch vmx angezeigt. Als Gastsysteme werden Windows, Linux und Unix- Betriebsysteme in 32-bit und 64-bit Ausführung unterstützt. Die Befehle zum Starten einer virtuellen Maschine sind mit denen aus dem Abschnitt über QEMU nahezu 5. ab Kernelversion Stand: Anfang mehr dazu in Abschnitt Hardware 8. Stand: Anfang 2014

4 4 identisch. Der einzige Unterschied ist, dass die virtuelle Maschine diesesmal mit KVM-Unterstützung 9 startet. qemu img c r e a t e f qcow2 disk. img 10G qemu kvm m 1024 cdrom ubuntu. i s o disk. img monitor s t d i o Auch eine virtuelle Maschine, die mit KVM gestartet wurde, kann auf andere KVM-Hosts migriert werden. Snapshots können ebenfalls angefertigt werden. Genau wie bei reinen QEMU-Maschinen gibt es auch die Möglichkeit zur Live-Migration. Für einen Administrator bieten beide Virtualisierungsformen die gleichen Optionen zur Verwaltung. KVM alleine ist kein vollständiges Virtualisierungssystem. Es kann zum Beispiel keine Netzwerkkarten oder andere Peripherie emulieren. Dazu werden weiterhin Programme wie QEMU benötigt. Es herrscht eine starke Abhängigkeit zu diesen Programmen. Es gibt schon seit längerem Bestrebungen QEMU durch das schlankere Native Linux KVM Tool zu ersetzten. Das Native Linux KVM Tool soll in Benchmarks sogar bessere Ergebnisse geliefert haben [11]. QEMU ist aber bisher noch der meistgenutzte Hardware-Emulator in Verbindung mit KVM. 5.2 CPU Im Abschnitt KVM wurde bereits erwähnt, dass KVM von der Hardwarevirtualisierung der CPU Gebrauch macht. Intel nennt diese Erweiterung Intel-VT und AMD nennt sie AMD-V. Durch Erweiterung des Befehlssatzes, Veränderung des TLB und weitere Optimierungen wird die Performance von virtuellen Maschinen verbessert. Mittlerweile bieten alle CPUs aus dem Serverbereich und dem Desktopbereich von Intel und AMD diese Erweiterung an. 5.3 Peripherie Auch für Peripherie gibt es mittlerweile Hardwareerweiterungen zur Unterstützung von Virtualisierung. Intel nennt seine Technik Intel VT-d. Bei AMD heißt es AMD-Vi. Grundgedanke ist, analog zur MMU eine IOMMU (Input/Output Memory Managment Unit) zu verbauen. Diese IOMMU erlaubt es Peripherie, zum Beispiel eine Netzwerkkarte, an eine virtuelle Maschine weiterzureichen. Das Gastsystem kann dann direkt mit der Netzwerkkarte kommunizieren. Dies erhöht die Performance im Vergleich zu einer emulierten Netzwerkkarte enorm. 5 HARDWARE Reine Softwarelösungen sind meistens immer langsamer als Lösungen in Hardware. Deswegen hat sich in den letzten Jahren sehr viel an der Hardware im Bezug auf Virtualisierung getan. Viele Hardwarehersteller bereiten ihre Produkte darauf vor, virtualisiert zu werden. Dabei steht die CPU und der Arbeitsspeicher im Vordergrund. Es existieren mittlerweile aber auch Ansätze zur Virtualisierung der Peripherie. Durch spezielle Eigenschaften der Hardware unterstützt die Hardwarevirtualisierung den Hypervisor beim Betreiben der virtuellen Maschinen. Dies kommt vor allem der Performance der virtuellen Maschinen zugute. 5.1 Speicher Für die Virtualisierung des Speichers ist die MMU (Memory Management Unit) zuständig. Die MMU verwaltet die Zugriffe auf den Arbeitsspeicher. Hauptaufgabe der MMU ist die Umrechnung von virtuellen Speicheradressen in physische Speicheradressen. Aber auch der Schutz des Arbeitsspeichers gehört zu den Aufgaben der MMU. Die MMU verhindert, dass ein Prozess auf einen nicht für ihn zugeteilten Speicherbereich zugreifen kann. Diese Form der Hardwarevirtualisierung kommt nicht nur virtuellen Maschinen zugute. Jeder Prozess und auch das Betriebssystem profitieren stark von der MMU. 9. dazu wird der Parameter -no-kvm weggelassen 6 XEN Xen ist ein Hypervisor, der unsprünglich an der Universität von Cambridge entwickelt wurde. Im Jahr 2007 wurde die für Xen gegründete Firma XenSource von Citrix Systems gekauft, welche seither die kommerzielle Version XenServer vertreibt. Die kostenlose Open- Source-Version von Xen wird vom Xen-Project gepflegt. Xen ist ein Typ 1 Hypervisor. Das bedeutet es wird kein Betriebssystem benötigt. Der Hypervisor läuft direkt auf der Hardware. Bei Xen werden die Gastsysteme Domänen genannt. Es gibt eine spezielle Domäne Dom0. Die andere Domänen werden DomU genannt. Aus der Domäne Dom0 wird das Virtualisierungssystem administriert. Von hier aus können neue virtuelle Maschinen gestartet werden. In Dom0 liegen auch die Treiber für Fig. 3. Ringe

5 5 die Hardware. Sie hat als einzige Domäne vollen Zugriff auf alle Ressourcen. Der Xen-Hypervisor läuft im Kernel-Mode. Die Gastbetriebssysteme laufen im User-Mode. Xen verwendet Paravirtualisierung. Die Gastbetriebssysteme müssen so modifiziert sein, dass priviligierte Befehle durch Hypercalls an den Hypervisor ersetzt werden. Falls die CPU über Hardwarevirtualisierung verfügt, können sogar unmodifizierte Gastsysteme verwendet werden. Mit Unterstützung der Hardware sind bei priviligierten Befehlen keine Hypercalls mehr nötig. Die CPU kann sich direkt um den Befehl kümmern. 7 LIBVIRT libvirt ist eine API zur Steuerung von Hypervisoren und zur Verwaltung von virtuellen Maschinen. libvirt unterstützt eine Reihe von populären Hypervisoren. Unter anderen: Xen LXC OpenVZ VMWare ESX VirtualBox Hyper-V Alle diese Hypervisoren haben natürlich selbst Werkzeuge und Befehle, um virtuelle Maschinen zu starten und zu verwalten. Diese sind aber von Hypervisor zu Hypervisor unterschiedlich. Sie sind nicht immer komfortabel zu bedienen. libvirt unterstützt den Administrator bei der Verwaltung, indem grundlegende Aufgaben vereinfacht werden. Außerdem bietet libvirt einen einheitlichen Befehlssatz, um alle Hypervisoren zu steuern. Die Kommunikation erfolgt über den Dämon libvirtd, der unter Linux normalerweise beim Systemstart mitgestartet wird. libvirt bietet eine Shell namens virsh. Von ihr können Befehle zum Administrieren von virtuellen Maschinen abgesetzt werden. Der Virtual Machine Manager erfüllt die gleichen Funktionen und bietet zusätzlich eine grafische Oberfläche. virt-install ist ein Werkzeug, das beim Einrichten einer neuen virtuellen Maschine hilft. Die Schritte zum Starten einer virtuellen Maschine sind die gleichen wie beim direkten Weg über den Hypervisor. Zuerst muss wieder ein Image angelegt werden. Dies geschieht über die virsh-shell. virsh ( virsh ) vol create as d e f a u l t disk. qcow2 10G format qcow2 ( virsh ) e x i t Mit dem Befehl virsh wird die Shell geöffnet und ein Festplattenimage der Größe 10 Gigabyte mit dem Namen disk.qcow2 erstellt. libvirt verwaltet Images in sogenannten Pools. In diesem Fall liegt das Image im Pool default. Als nächstes wird eine neue virtuelle Maschine eingerichtet. Dazu wird virt-install 10 benutzt. v i r t i n s t a l l name t e s t ram 1024 cdrom ubuntu. i s o disk vol= d e f a u l t / disk. qcow2 Die Einstellungsmöglichkeiten sind ähnlich zum qemukvm Befehl und selbsterklärend. Zurück in der virsh- Shell kann die virtuelle Maschine beliebig administriert werden. virsh ( virsh ) setmem t e s t Dieser Befehl verändert die Größe des Arbeitsspeichers der virtuellen Maschine. In diesem Fall auf Kilobyte. An dieser Stelle kommen die virtio Treiber zum Einsatz. Genauer gesagt der virtio-balloon Treiber. Ist dieser nicht im Gastsystem vorhanden, kann die Veränderung nicht vorgenommen werden. Weitere interessante Befehle sind start, shutdown, suspend, resume, migrate und snapshot-create. libvirt ist ein umfangreiches Werkzeug, das dem Administrator viel Arbeit abnimmt. Insbesondere wenn mit verschiedenen Virtualisierungslösungen gearbeitet wird, erspart libvirt die Einarbeitungszeit in jedes einzelne System, indem es von dem jeweiligen System abstrahiert. 8 POPULÄRE IAAS IaaS-Software oder IaaS-Anbieter benutzen diese vorgestellten Techniken und Programme, um eine stabile, sichere und leistungsfähige Infrastruktur an ihre Kunden auszuliefern. In der nachfolgenden Aufzählung lässt sich erahnen, dass KVM und Xen sehr beliebte und verbreitete Lösungen im Serverbereich sind. Dies entspricht auch der Wirklichkeit. Xen bietet zwar oftmals mehr Performance als KVM, dennoch gewann KVM in den letzten Jahren immer mehr an Beliebtheit. Ein Grund dafür ist, dass KVM sehr früh den Weg in den Linuxkernel gefunden hat. Erste Codeteile von Xen hielten in Version Einzug, jedoch war es nicht ohne weitere Patches möglich Gastsysteme zu starten. Vollständige Unterstützung gibt es erst mit Kernel 3.0.x. Dies ist mehr als 4 Jahre nach KVM [21][20]. Amazon benutzt für ihre Elastic Compute Cloud eine stark angepasste Version vom Xen Hypervisor[13]. Einer der Gründe für diese Wahl ist, dass die Gastsysteme durch Paravirtualisierung komplett ohne höhere CPU- Befehle auskommen. Dadurch sind Hypervisor und Gastsystem klar getrennt und die Systeme insgesamt sicherer. Openstack bietet Unterstützung für eine Vielzahl von Hypervisoren. Darunter: Xen 10. dieser Befehl ist nicht Teil der virsh-shell

6 6 VMWare ESX LXC Hyper-V CloudStack verwendet: Xen VMWare vsphere Eucalyptus verwendet: VMWare ESXi 9 ZUSAMMENFASSUNG Es gibt eine Vielzahl von Virtualisierungslösungen, die für den Einsatz in IaaS-Software hervorragend geeignet ist. Jede Lösung hat ihre Vorteile und Nachteile. Es ist jeweils immer genau abzuwägen, welche Lösung am besten geeignet ist. Dabei sind verschiedene Aspekte in Betracht zu ziehen vorhandene Hardware Gastbetriebssystem Hostbetriebssystem Performance Peripherie libvirt ermöglicht dabei im Zweifelsfall einen unkomplizierten Umstieg. Die Entwicklungen im Bereich der Virtualisierung sind dabei noch längst nicht abgeschlossen. Sowohl bei der Software als auch bei der Hardware wird es in den nächsten Jahren interessante Entwicklungen geben. Dies wird unter anderem auch durch den steigenden Stellenwert von Cloudsystemen vorangetrieben. Es bleibt auch abzuwarten, welche Virtualisierungsform sich durchsetzt. Die Tendenz geht stark in Richtung Hardwarevirtualisierung. In diesem Bereich haben die Hardwarehersteller mit Anpassung der CPU und Verwendung einer IOMMU vorgelegt. Diese Features müssen nun durch die Softwareentwickler in der Virtualisierungssoftware aufgenommen werden. [10] QEMU-Buch: KVM-Buch/ KVM Tool [11] KVM-Tool html [12] [13] [14] [15] [16] [17] [18] Page [19] C. Schröder, Container-Virtualisierung mit Docker. mit Docker.pdf [20] [21] Linux html [22] [23] Abbildung 1: ring scheme.svg [24] Abbildung 2: [25] Abbildung 3: REFERENCES [1] QEMU-Buch: KVM-Buch/ Grundlagen [2] QEMU-Buch: KVM-Buch/ Virtuelle Hardware/ Prozessoren [3] QEMU-Buch: qemu-img [4] QEMU-Buch: KVM-Buch/ Speichermedien/ VM-Snapshots [5] QEMU-Buch: KVM-Buch/ Anhang/ QEMU-Monitor [6] M. Kofler und R. Spenneberg, KVM für die Server-Virtualisierung. [7] QEMU-Buch: KVM-Buch/ Virtuelle Hardware/ Paravirtualisierte Gerätetreiber [8] [9]