Haupseminar Virtualisierungstechnologien

Transkript

1 Technische Universität München Institut für Informatik Lehrstuhl für Rechnertechnik und Rechnerorganisation Prof. Dr. Arndt Bode Haupseminar Virtualisierungstechnologien Paravirtualisierung, Vanderpool Eingereicht von: Christian Kern Abgabe: Betreuer: Daniel Stodden, Josef Weidendorfer

2 Inhaltsverzeichnis 1 Einleitung Motivation Einordnung ins Themengebiet X86 Architektur XEN Einführung Übersicht über XEN Lösung des Ringproblems Kommunikation zwischen Hypervisor und Betriebssystem Speicherverwaltung Balooning I/O Subsystem Live Migration Performancevergleich zu anderen Systemen Aufwand der Portierung UML Einführung Aufbau eines standard Linux Kernels UML Kernel Tracing Thread SKAS Patch Hardware Virtualisierungslösungen Einführung Erweiterungen an der x86 Technologie Registerübersicht VMCS Struktur Kontroll Feld Befehlsübersicht [1] Schluss i

3 Abbildungsverzeichnis 1.1 Einordnung ins Themengebiet Links: Hypervisor VM Rechts: Hosted VM Privilegierte und Sensitive Befehle Ringstruktur des X Übersicht über den XEN Hypervisor Belegung der Ringe des x86 unter XEN Skizze des Adressraums eines Linux Systems Skizze des Adressraums eines Linux Systems mit eingeblendeten XEN Memory Mapping I/O Subsystem von XEN I/O Ring Zeitlicher Ablauf der Live Migration Performancevergleich Zu modifizierenden Quellcode Zeilen Vanilla Linux Kernel Struktur UML Kernel auf i386 Linux Kernel Virtualisierung zeitlich VMCS VMCS Kontrollfeld ii

4 1 Einleitung 1.1 Motivation Virtualisierung bezeichnet definitionsgemäß Methoden um die Resourcen eines Computers aufzuteilen. Somit ist ein Betriebssystem auch eine Art Virtualisierungssoftware. Es setzt eine Abstraktionsschicht zwischen Nutzer und tatsächlicher Hardware und spielt dem Nutzer vor er hätte die volle und einzige Kontrolle über das System, genauso wie das Betriebssystem den Anwendungen vorspielt, sie hätten volle Kontrolle über das System. Es kann von Vorteil sein dieses Konzept der zwiebelartig aufgebauten Abstraktionen eines Systems weiterzuführen, und weitere Abstraktionsschichten einzuführen. Bei der Systemvirtualisierung spielt man dabei einem kompletten Betriebssystem vor, es hätte die absolute und einzige Kontrolle über die Hardware eines Systems. Dies kann in vielen Bereichen extrem von Vorteil sein. Heutzutage sind Computer sehr schnell, und selten ausgenutzt. Computer gehen mehr und mehr in die Richtung sich zu spezialisieren. Beispielsweiße kann ein Haushalt mehrere Computer haben, einer wird vielleicht Beruflich genutzt, ein anderer vielleicht für Multimedia und Entertainment, ein weiterer wiederum für Computerspiele. Dabei wird die Hardware in den seltensten Fällen komplett ausgenutzt, aber gegen eine Zusammenfassung der einzelnen Anwendungen unter ein Betriebssystem sprechen entweder Sicherheitsbedenken (Kompromittieren des Arbeitscomputers durch Viren ist auf in jedem Fall zu vermeiden) oder schlichtweg ist es nicht möglich alle Anwendungen unter einem Betriebssystem auszuführen, beispielsweise kann man den TV-Festplattenrecorder VDR nicht unter Windows laufen lassen, aber genau sowenig Microsoft Office unter Linux. Genau dort setzt die Systemvirtualisierung an, sie erlaubt es diese Anwendungen alle zusammen auf einer Hardwarekomponente auszuführen. Ebenso im Server- und Professionellen Bereich kann die Systemvirtualisierung von großen Nutzen sein. So kann man günstig das Verhalten von Systemen testen, sogar ganze Infrastrukturen von Betriebssystemen und deren Verhalten untereinander kann untersucht und simuliert werden. Beispielsweiße bietet die LMU ein Praktikum zur Systemsicherheit an, für das vor einem Jahr noch ca. 30 Computer nötig waren. Mittlerweile werden alle diese Systeme und deren Verhalten untereinander auf einer einzigen Maschine simuliert. Ebenso kann man seine Systemsicherheit extrem steigern, in dem man Server Services wie z.b. imap, ssh oder http nicht auf einem System zur Verfügung stellt, sondern sie auf virtuelle Betriebssysteme verteilt. Wird ein Service dabei kompromittiert, beispielsweiße durch eine Sicherheitslücke, sind nicht alle Services in Gefahr, sondern nur dieser eine Service. Man hat eben eine Sicherheitsschicht mehr zur Verfügung. 1.2 Einordnung ins Themengebiet Die Paravirtualisierung ist eine Untermenge der Systemvirtualisierung. Wir können sie also folgendermaßen ins Themengebiet einordnen: 1

5 1.2 Einordnung ins Themengebiet Abbildung 1.1: Einordnung ins Themengebiet Bei der Virtualisierung von Systemen unterscheidet man im Allgemeinen drei Verfahren. Hardware Emulation Hierbei wird die komplette Hardware abstrahiert und emuliert. Sehr langsam. Wird meistens eingesetzt wenn das Gastsystem eine andere Hardwarearchitektur benötigt. Beispiel: Microsoft Virtual PC. Native Virtualisierung Hierbei wird nur genau soviel der Hardware emuliert, das ein komplett unmodifiziertes Betriebssystem laufen kann. Die restliche Hardware wird über eine Verwaltungsschicht direkt genutzt. Beispiel: VMWare Paravirtualisierung Bei der Paravirtualisierung wird nichts emuliert, sondern alle Befehle werden über eine Verwaltungsschicht direkt ausgeführt. Funktioniert in den meisten Fällen nur durch eine Modifikation des Betriebssystems. Aber: Bester Kompromiss zwischen Aufwand und Geschwindigkeit. Beispiel: XEN, UML Diese Systemvirtualisierungen kann man auch noch anders in zwei Gruppen aufteilen: Hosted VM Hierbei wird das Gastsystem in einem anderen Betriebssystem ausgeführt, das die komplette Kontrolle über die Hardware besitzt. Fallstudie bei der Paravirtualisierung: UML Hypervisor VM Bei diesem System setzen alle Gast Betriebssysteme auf einem soggenannten Hypervisor oder Virtual Machine Monitor auf. Dieser Hypervisor ist zuständig für die Kontrolle der Gastsysteme und die Verteilung der vorhandenen Hardware Ressourcen. Fallstudie bei der Paravirtualisierung: XEN 2

6 1 Einleitung Anwendungen Anwendungen Anwendungen Privilegiertes Betriebssystem Betriebssystem Betriebssystem Kontrolliert/Steuert 1..n Virtual Machine Monitor 1..n Virtual Machine Monitor Betriebssystem Intel IA-32 Hardware Intel IA-32 Hardware Abbildung 1.2: Links: Hypervisor VM Rechts: Hosted VM 1.3 X86 Architektur Die Frage die sich als erstes bei der Paravirtualisierung stellt ist, wieso die Gastsysteme überhaupt modifiziert werden müssen, um als Gast ausgeführt werden zu können. Die Antwort ist, das die x86 Architektur nicht zur Virtualisierung ausgelegt ist. Dies sieht man daran, wenn man die von der CPU gestellten Befehle in zwei Gruppen einteilt, nämlich in die der sensitiven und nicht sensitiven Befehle. Sensitive Befehle, sind welche die den Zustand der Maschine verändern können. Ein Gast System darf niemals einen solchen Befehl direkt auf der CPU ausführen. Es könnte dabei nämlich die Isolation der verschiedenen Gastsysteme verletzen, beispielsweiße deren Daten verändern, oder herausfinden das es virtualisiert ist, also nicht vollen Zugriff auf die CPU hat. Bei den verschiedenen Architekturen gibt es Privilegierte Befehle, das sind Befehle die im Anwendungsbereich einen soggenannten Trap auslösen, einen Sprung aus dem aktuellen Ausführungskontext hinzu mehr privilegierten Bereichen, beispielsweiße dem Betriebsystem oder einem Hypervisor, so das diese privilegiertere Schicht dann Prüfen kann, ob dieser Befehl direkt auf der CPU ausgeführt werden darf, also das dabei keine Richtlinien verletzen werden. Idealerweise sind die sensitiven Befehle eine Untergruppe der Privilegierten Befehle (Popek und Goldberg Theorem [2] ). Aber: Benutzer Programmbefehle Priveligiert Sensitiv Abbildung 1.3: Privilegierte und Sensitive Befehle Letzteres ist bei der x86 Architektur nicht der Fall, es gibt also sensitive Befehle, deren Ausführung keinen solchen Trap auslösen würden. Desweiteren verhindert schon die Ringstruktur des X86 die perfekte Virtualisierbarkeit: 3

7 1.3 X86 Architektur Ring 0 Betriebssystem Ring 1 Ring 2 Ring 3 Anwendungen Abbildung 1.4: Ringstruktur des X86 Im X86 hat man verschiedene Ringe, andersgesagt Modi, unter denen bestimmte Befehle ausgeführt werden können und auf bestimmte Speicherbereiche zugegriffen werden kann. Ring0 ist der Ring mit allen Rechten. Hier sitzt normalerweise das Betriebssystem. Es darf auf alle Speicherbereiche zugreifen, und selbst privilegierte Befehle ausführen. Anwendungsprogramme haben diese Rechte natürlich nicht, sie liegen in Ring3. Wenn eine Anwendung einen privilegierten Befehl ausführen will, muss der Befehl an das Betriebssystem in Ring0 übergeben werden. Will man unmodifiziert mehrere Betriebssystem laufen lassen, würden diese sich Ring0 teilen, was natürlich zwangsläufig zu Problemen führt. Deswegen ist ohne weitere Maßnahmen eine Virtualisierung auf x86 Hardware nicht möglich. Die zwei Maßnahmen, mit denen man diesen Problemen begegnen kann, sind entweder die Emulation von bestimmten Befehlen, oder eben die Anpassung des Betriebssystem, also Paravirtualisierung. 4

8 2 XEN 2.1 Einführung XEN ist ein OpenSource Hypervisor, der von der Universität von Cambridge entwickelt wird. Er steht unter GPL und Paravirtualisiert seine Gastsysteme. XEN ist erschienen für die x86 Architektur. Als Gastsysteme im paravirtualisierten Sinn kommen zur Zeit nur OpenSource Betriebssysteme in Frage, da für XEN die Betriebssysteme angepasst werden müssen. Der Hypervisor unterstützt aber auch neue Technologien von Intel und AMD, bei denen eine Modifikation von Gastsystemen nicht nötig ist. Dafür sind aber spezielle CPUs notwendig. Mehr dazu in Kapitel 4 ab Seite 17. Am weitesten verbreitet sind modifizierte Linux Systeme wie zum Beispiel XenoLinux. Diese Gastsysteme werden bei XEN Domains genannt. 2.2 Übersicht über XEN VM1 - Domain 0 VM2 VM3 Anwendungen XEN Kontroll Software Gast System - Privilegiert (XenLinux) Anwendungen Gast System (XenLinux) Anwendungen Gast System (XenLinux) Back-End Treiber Front-End Treiber Front-End Treiber Treiber Sichere Hardware Schnittstelle Kontroll Schnitstelle Event Channel Virtuelle Speicher Verwaltung Virtuelle CPU Hypercall Schnittstelle Timer Schnitstelle XEN - "Virtual Machine Monitor" oder "Hypervisor" Hardware Abbildung 2.1: Übersicht über den XEN Hypervisor Der XEN Hypervisor besteht aus zahlreichen Subsystemen. Grundsätzlich ist XEN ziemlich schlank designet. Alles was möglich war sollte nicht der XEN Hypervisor übernehmen. So unterscheidet man bei XEN zwei verschiedene Arten von Domains: welche die privilegiert sind, und welche die das nicht sind. 5

9 2.4 Kommunikation zwischen Hypervisor und Betriebssystem Diese Privilegierten übernehmen Aufgaben wie z.b. andere Domains zu starten/stoppen, die Speicherverwaltung, Domains Scheduling Algorithmen oder bereitstellen von Treiber Schnittstellen für unpriveligierte Domains. 2.3 Lösung des Ringproblems Wie schon in Kapitel 1.3 auf Seite 4 angesprochen, muss das Ringproblem gelöst werden. Dabei werden unter XEN die Betriebssysteme so angepasst das sie nicht mehr in Ring0 laufen, sondern in Ring1. Der Hypervisor selbst läuft in Ring0. Somit hat er die komplette Kontrolle über das System, und trotzdem ist das Betriebssystem gut von den Anwendungen in Ring3 isoliert: Ring 0 XEN Hypervisor Ring 1 Gast Betriebssystem Ring 2 Ring 3 Anwendungen Abbildung 2.2: Belegung der Ringe des x86 unter XEN 2.4 Kommunikation zwischen Hypervisor und Betriebssystem Da natürlich Daten zwischen Hypervisor und den verschiedenen Domains ausgetauscht werden müssen, muss der XEN Hypervisor dafür effiziente Schnittstellen zur Verfügung stellen. Für beide Richtungen des Datenaustausches (von und zu Hypervisor) bietet XEN Schnittstellen an: Hypercalls Hypercalls werden verwendet für die Komminikation von den Domains zu dem Hypervisor. Es sind synchrone Aufrufe, die einem Systemcall unter unvirtualisierten System entsprechen. Benutzt werden sie, um Privilegierte Befehle über den Umweg des Hypervisors ausführen zu können. Event Channels Event Channels sind das Gegenstück zu Hardware Interrupts unter unvirtualisierten Systemen. Die Domains können für gewünschte Events, also Ereignisse 6

10 2 XEN wie zum Beispiel Timer oder Hardware Ereignisse, einen Eventchannel einrichten. Ein Event Channel ist nur ein Bit in einem Bitarray. Wenn ein Event auftritt, den eine Domain behandeln will, setzt der Hypervisor dieses Bit auf 1. Beim nächsten Kontextwechsel prüft die Domain seine Event Channel Tabelle, behandelt dieses aufgetretene Ereignis, und setzt anschließend das Bit wieder zurück. Somit kann es durch den Hypervisor wieder aktviert werden. Analog zu dem Bitarray das für die Ereignissanzeige verwendet wird, existiert noch ein Bitarray, in dem der Gast bestimmen kann, bei welchen Ereignissen er benachrichtigt werden soll. Zusammen mit geteilten Seiten ergibt sich dann ein soggenannter Device Channel, mit dem Kommunikation mit echter Hardware möglich wird. Doch dazu später mehr. 2.5 Speicherverwaltung Ein sehr wichtiges Gebiet ist die Speicherverwaltung. Wie diese implementiert ist entscheidet maßgeblich über die Performance, die ein virtualisiertes Betriebssystem später leisten kann. Es gilt wieder die XEN Devise, das Betriebssystem soll soviel wie möglich machen, der Hypervisor soll sowenig eingreifen wie möglich! Moderne Betriebssysteme verwenden für ihre Speicherverwaltung meistens Paging (Segmentierung wird von XEN auch unterstützt, darauf soll hier aber nicht näher eingegangen werden). Paging - Kurzgesagt: Es steht dem Betriebssystem ein virtueller Adressraum zur Verfügung, der viel größer sein kann als der tatsächlich vorhandene reale Speicher. Bei einem 32-Bit System 4 GB. Dieser Speicher ist unterteilt in 4KB große Seiten. Diese können nun tatsächlich im Hauptspeicher vorhanden sein, aber auch auf die Festplatte ausgelagert werden, wenn sie z.b. längere Zeit nicht benutzt werden. Soll jetzt auf eine Seite zugegriffen werden, die nicht im Hauptspeicher eingelagert ist, wird eine Seitenfehler Ausnahme ausgelöst, und die betreffende Seite wird in den Hauptspeicher eingelagert. Nun kann das Betriebssystem diese Seite benutzen. Um nun diese Prozedur mit sowenig Änderung wie möglich weiterhin durchführen zu können, erlaubt man dem Betriebssystemen nun weiterhin ihre Speicherverwaltung selbst zu machen. Wenn es zu einem Seitenfehler kommt, wird immer automatisch eine Ausnahme ausgelöst. Die Adresse die den Seitenfehler ausgelöst hat steht in Prozessorregister cr2. Nur der Hypervisor kann diese Adresse auslesen, dies gibt das Ringmodell des x86 vor. Nur in Ring0 kann Register cr2 ausgelesen werden. Der Hypervisor muss nun diese Adresse an die Domain weitergeben. Diese Prozedur ist aber sehr teuer, Seitenfehler treten sehr häufig auf. Immer wenn ein Seitenfehler auftritt, muss zum Hypervisor gewechselt werden. Beim x86 gibt es einen TLB (Transition Allocation Buffer), ein Cache, mit dem kurzgesagt eine virtuelle Adresse sehr schnell einer realen Adresse zugeordnet werden kann, ohne die komplette Seitentabellenstruktur immer wieder durchlaufen zu müssen. Die Beschleunigung durch den TLB ist enorm, da hintereinander wahrscheinlich sehr häufig auf die gleichen Adressen zugegriffen werden muss. Da der Adressraum normalerweiße von jedem Anwendungsprogramm ein anderer ist, muss bei einem Wechsel auch dieser Cache gelöscht und neu beschrieben werden. Dieses neu beschreiben kostet Zeit. Es wäre unglaublich ineffizient diesen Cache nach jedem Wechsel zum Hypervisor neu beschreiben zu müssen. Deshalb behilft man sich mit einem Trick, der es ermöglicht aus jeden Adressraum den Hypervisor ohne Kontextwechsel aufrufen zu können. Dazu schauen wir uns die Struktur des Speichers bei einem Linux System an: 7

11 2.5 Speicherverwaltung 4 GB 3,936 GB 3 GB Ungenutzter Kernelspeicherbereich Kernel Anwendungsbereich 0 GB Abbildung 2.3: Skizze des Adressraums eines Linux Systems Der Kernel wird dabei in das oberste GB des virtuellen Adressraums eingeblendet. Der Kernel nutzt aber nicht das ganze GB, irgendwo in diesem GB sucht man nun 64 MB freien Speicher, und blendet dort XEN ein: 4 GB 3,936 GB 3 GB XEN Kernel Anwendungsbereich 0 GB Abbildung 2.4: Skizze des Adressraums eines Linux Systems mit eingeblendeten XEN Somit kann man immer auf den Hypervisor zugreifen, ohne das ein Kontextwechsel durchgeführt werden muss, und somit spart man sich die sehr teure Neubefüllung des TLB. Bei einem unvirtualisierten Betriebssystem hat dieses Zugriff auf einen Block realen Speicher. Bei vielen virtualisierten Gastsystemen kann aber der Hypervisor nicht für einen kontinuierlichen Block an Speicher garantieren. Die meisten Betriebssystem bieten aber keine gute Unterstützung für fragmentierten Speicher. Somit hält der Hypervisor, für das Gastsystem zuggreifbar, eine Tabelle für das Mapping von Pseudo Realen Speicher, was für das Gastsystem ein kontinuierlicher Block Speicher ist, zu realem Speicher: 8

12 2 XEN Realer Speicher Gast System Realer Speicher auf der Maschine Abbildung 2.5: Memory Mapping Der Hypervisor hält für sich auch noch ein Mapping in die andere Richtung. Diese beiden Mappings sind in 4 KB Schritte unterteilt, also genau die Größe einer Seite. Die Gastsyteme führen nun basierend auf den bis jetzt besprochenen Konzepte selber Seitenverwaltung durch. Lesen von Seiten und Seitentabellen ist nun ohne Eingriffe des Hypervisors erlaubt. Auch das schreiben von Daten, in Datenseiten die schon durch die Seitentabellen referenziert sind, sind kein Problem. Jedoch das Schreiben von Seiten in Seitentabellen muss unbedingt überwacht werden, weil dabei die Möglichkeit besteht, die Seitentabellen auf Speicherbereiche zeigen zu lassen, auf die das Gastsystem aufgrund der Isolationspolitik keinen Zugriff haben darf! Für diese Validierung stellt XEN zwei Möglichkeiten zur Verfügung: Sofortige Validierung Das Betriebssystem ruft bei einem kritischen Schreibbefehl eine Hypercall Funktion auf. XEN überprüft nun diese Anfrage auf Gültigkeit. Wenn alles in Ordnung ist, wird der Schreibbefehl ausgeführt. Dafür ist aber eine Anpassung des Gastsystems nötig. Verzögerte Validierung Diese Methode zur Validierung setzt keine Modifikation des Betriebssystemcodes voraus. Schreibzugriffe werden dabei nicht verhindert. Aber zugleich mit dem Schreibbefehl wird die beschriebene Seite aus der aktiven Seitentabellenstruktur ausgehangen. Somit wird sichergestellt das eine Zugriff auf diese Seite einen Seitenfehler auslöst. Da dieser Seitenfehler auch ein Wechsel in den Hypervisor auslöst, kann dieser jetzt die geschriebene Seite validieren. Ist alles in Ordnung wird die Seite wieder in die aktuelle Seitenverwaltungsstruktur eingehängt. 2.6 Balooning Als nächstes will man nun den Speicher einen Gastsystems auch dynamisch anpassen können. Dies gestaltet sich aber in der Hinsicht schwer, da der Hypervisor zwar schon fähig wäre Seiten selber ein/auszulagern, aber der Hypervisor natürlich nicht wissen kann welche Seiten er ein/auslagert. Also könnte er natürlich Seiten des Gastsystems auslagern, die sehr häufig benutzt werden. Das wäre ziemlich ineffizient. Somit benutzt 9

13 2.7 I/O Subsystem man wiederum einen kleinen Trick. Man setzt das Gastsystem unter Druck, indem der Hypervisor über einen Balooning Treiber im Gastsystem Speicher reserviert, der gar nicht benutzt wird. Somit beginnt das Gastsystem nun selber damit Seiten auszulagern, und zwar genau die Günstigsten. Will man dem Gastsystem Speicher zurückgeben, kann man nun den Speicherdruck natürlich auch wieder verkleinern. Diese Methode nennt man Balooning, da es Bildlich gesprochen einem Aufblasen eines Luftballons im Gastsystem entspricht. 2.7 I/O Subsystem Priveligiertes Gastsystem Geräte Treiber Treiber Backend Gastsystem 2 Treiber Frontend Gastsystem 3 Treiber Frontend Sichere Hardware Schnittstelle Gerät 1 Gerät 2 Gerät 3 I/O Space 1 I/O Space 2 I/O Space 3 Abbildung 2.6: I/O Subsystem von XEN Das I/O Subsystem von XEN zeichnet sich dadurch aus, das man I/O Speicherbereiche über die sichere Hardware Schnittstelle anbietet. Nur privilegierte Domains können auf diese abgesicherten Speicherbereiche über Treiber zugreifen. Meistens hat man genau eine privilegierte Domain, genannt Dom0. Die Anderen Domains implementieren keine echten Treiber, sondern nur sogenannte Frontend Treiber. Das Gegenstück dazu sind die Backend Treiber. Sie sind auf der privilegierten Domain implementiert, und enthalten fast die komplette Treiberintelligenz und Absicherung gegen Fehlverhalten. Das Frontend selber ist schlicht gehalten, sowenig wie möglich ist dort implementiert. Die Kommunikation zwischen Frontend und Backend läuft über Device Channels. Das sind die schon besprochenen Event Channels, kombiniert mit Seiten, auf die mehrere Domains Zugriff haben können. So genannte geteilte Seiten. Das ganze wird dann über I/O Ringe koordiniert, die eigentlich nichts weiter als Warteschlangen in Ring Form sind, auf denen Anfragen plaziert werden können, die vom Hypervisor geprüft und beantwortet werden. Zum Beispiel bei einem Netzwerktreiber hat man dann zwei solche Ringe, einen für Senden und einen zum Empfangen. 10

14 Asynchrone I/O Ring Struktur 2 XEN Abbildung 2.7: I/O Ring 2.8 Live Migration Ein sehr populäres Feature von XEN ist die Möglichkeit der Live Migration von Systemen. Dabei ist es möglich ein Gastsystem das auf einem Host läuft, mit einer Ausfallzeit von unter einer Sekunde bis zu wenigen Sekunden auf einem anderen Host fortzusetzen. Dieses bietet wunderbare Möglichkeiten der Skalierung von Systemen. Beispielsweiße kann man einen Webserver sehr schnell auf eine andere Maschine verschieben, und die andere Maschine jetzt warten. Oder wenn viele Domains hohe Last erzeugen kann man dynamisch diese Last gut auf andere Maschinen verteilen, in dem man die Virtuellen System verteilt. Vorraussetzung dafür ist nur eine verteilte Speicherlösung wie z.b. SAN. Möglich macht dieses Verfahren die Methode der Shadow Page Tables. Dabei hält XEN während der Migration neben der Seitenverwaltung des Gastsystems eine Kopie dessen Seitenverwaltungsstruktur (Shadow Page Tables), und kann dadurch schreiben auf Seiten und dirty Seiten sehr gut überwachen. XEN beginnt nun in mehreren Runden nach und nach Seiten von dem Quellhost auf den Zielhost zu kopieren. Es verbleiben eigentlich nur noch die Seiten zu kopieren, die noch seit der letzten Kopierrunde auf dem Quellsystem verändert wurden. Jetzt wird das Gastbetriebssystem paussiert, die verbleibenden Seiten werden auf das Zielsystem kopiert, und das Gastsystem auf dem Zielsystem fortgesetzt. Hier der Beispielverlauf einer solchen Migration. Der Graph zeigt die maximal mögliche Datenübertragunsrate des Server (Da der Server unter Vollast steht), die bei der Migration etwas sinkt, da ja der Speicher des Quellsystems übertragen werden muss. Dann kommt es zu einer 165 ms Ausfallzeit, in der das Quellsystem pausiert wird, und die restlichen Speicherseiten übertragen werden. Anschließend wird das System auf dem anderen Host fortgesetzt. Jetzt steht wieder die volle Übertragungsrate zur Verfügung. 11

15 OSDB-OLTP(tup/s) Rate Limited Migration 2.9 Performancevergleich zu anderen Systemen C6"6D > E7<.7')&+57%5,&.17) Effect of Migration on Web Server Transmission Rate st precopy, 62 secs further iterations " F6K F6! Throughput (Mbit/sec) 870 Mbit/sec F6C secs 765 Mbit/sec F6J F6I Mbit/sec F6H 400 F6D 165ms total downtime F6G 200 F6" 512Kb files 100 concurrent clients Sample over 100ms Sample over 500ms F 0 B.7/L M'7 70 NOP5+' QOB Elapsed time (secs) Abbildung 2.8: Zeitlicher Ablauf der Live Migration ",0*%(<0=6%-'&(+*.+-4;(70*(>?@(1&*70*'46+& #1/+,'3)M'7!" #$%&'(%)*+,-.&',&/+' 0+1/2 -&&2344% (5&.96-/:;'+<.76='!! "#$%&'$()*+,-%&+%.*& /*0.1,%%1233$4*5-670*'4%-85,.9:&*;-65<& 2.9 Performancevergleich zu anderen Systemen Xen Performance (2.x) The Cost of Porting an OS to Xen L X V U Linux Xen/Linux VMware Workstation User Mode Linux C D&%E"F 4%(&4*;#($%4G&!D #$%&'(%)*+,-.&',&/+' 0+1/2 -&&2344% (5&.96-/:;'+<.76=' H4$(07($1*-6G(IJJKL!B Abbildung 2.9: Performancevergleich "#$%&'$()*+,-%&+%.*& /*0.1,%%1233$4*5-670*'4%-85,.9:&*;-65<& Man erkennt das die XEN Virtualisierung bei den verschiedenen Benchmarks knapp hinter einem unvirtualisierten System liegt. Es ist auch schneller als VMWare, das darauf angewiesen ist bestimmte Befehle zu emulieren. Außerdem viel Schneller als die Paravirtualiserungslösung UML, die im nächsten Kapitel genauer besprochen wird. 12

16 !!!A "#$%&'$()*+,-%&+%.*& /*0.1,%%1233$4*5-670*'4%-85,.9:&*;-65<& 2 XEN 2.10 Aufwand der Portierung The Cost of Porting an OS to Xen SPEC INT C O06G(* '1.%4%-0 411;-+4%-06 C );'0$%(4;;(%.$&*9$14+& Abbildung 2.10: Zu modifizierenden Quellcode Zeilen C D&%E"F 4%(&4*;#($%4G& H4$(07($1*-6G(IJJKL Bei einem Linux System sind ca Zeilen zu modifizieren. Bei dem experimentellen Port von!bmicrosoft XP durch Microsoft waren 4620 zu modifizieren. "#$%&'$()*+,-%&+%.*& /*0.1,%%1233$4*5-670*'4%-85,.9:&*;-65<& 13 "0.*+&2(U&6 AJ

17 3 UML 3.1 Einführung Die Abkürzung UML steht für User Mode Linux. Eigentlich war die aussagekräftigere Bezeichnung Linux on Linux geplant, wurde aber wegen der witzigen Abkürzung LOL wieder verworfen. UML ist ein modifiziertes Linux das als Benutzerprozess in einem anderen Linux laufen kann. Entwickelt wurde es 1999 von Jeff Dike, und ist mittlerweile in den Vanilla Linux Kernel aufgenommen worden. Man wollte nicht die Entwicklung einer virtuellen Maschine sondern die Entwicklung eines virtuellen Betriebssystems. Ziel war nämlich nicht ein virtualisiertes System laufen lassen zu können, sondern es wurde eine Möglichkeit gesucht, den Linux Kernel einfacher debuggen zu können. UML ermöglicht genau das, man kann damit einen Linux Kernel mit Hilfe von z.b. dem Tool gdb sehr schön und einfach debuggen. 3.2 Aufbau eines standard Linux Kernels Prozesse Generischer Kernel mit Syscall Schnitstelle i386-arch-spezifische Elemente Treiber Kernel Hardware Abbildung 3.1: Vanilla Linux Kernel Struktur Der Linux Kernel wurde relativ modular geplant. Der Linux Kernel hat einen generischen, Hardware unabhängigen Teil, mit einer generischen Syscall (Systemaufruf) Schnittstelle. Auf dieser Schnittstelle setzen die Prozesse auf. Sie brauchen sich nicht um die verschiedenen Architekturen kümmern, da sie die generische Syscall Schnittstelle benutzen. Für jede Architektur die im Linux Kernel implementiert ist, existiert im Quellcode des Kernels ein arch Verzeichniss. In diesem ist der gesamte Architekturspezifische Teil des 14

18 3 UML Linux Kernels enthalten. Es gibt Implementationen für i386, ppc, arm, etc. Nur die Treiber sind sonst noch Platformspezifisch. 3.3 UML Kernel Anwendungsbereich Prozesse Generischer Kernel Prozesse UML arch Elemente Kernel emulierte Treiber Generischer Kernel mit Syscall Schnitstelle i386-arch-spezifische Elemente Treiber Kernel Hardware Abbildung 3.2: UML Kernel auf i386 Linux Kernel Kurzgesagt, der UML Kernel ist nun eine neue Architektur für Linux. Es gibt im schon angesprochenen arch Verzeichnis neben den Architekturen i386, PPC usw. eben auch noch eine Architektur um, stehend für UML Kernel. Diese Architektur musste so angepasst werden das sie als Benutzerprozess in einem anderen Linux System läuft. Außerdem müssen emulierte Treiber für Beispielsweiße Netwerkkommunikation oder Dateisystemzugriffe geschaffen werden, da der UML Kernel natürlich keinen direkten Zugriff auf die Hardware hat. Dabei ergeben sich ein paar Probleme Tracing Thread Normalerweiße, wenn ein Prozess einen Systemaufruf ausführt, wird dieser Systemaufruf im Linux Kernel behandelt. Jedoch wird der Systemaufruf einer Anwendung des UML Kernels nicht im UML Kernel landen, da der UML Kernel und alle darin enthaltenen Anwendungen nur Prozesse auf dem Host Kernel sind. Es ist aber nicht 15

19 3.3 UML Kernel gewünscht das Systemaufrufe von Anwendungen des UML Kernels im Host Kernel landen, denn der UML Kernel soll diese ja behandeln. Dieses Problem löst man mit Hilfe eines soggenannten überwachenden Tracing Thread : Für Kernel Debugging existiert im Linux Kernel schon längere Zeit die ptrace [3] Schnittstelle. Sie ermöglicht einem Prozess einen anderen Prozess zu kontrollieren. Über diese Schnittstelle ist es möglich einen Anderen Prozess unterbrechen zu lassen, wenn dieser einen Systemaufruf ausführt. Bei UML wird genau diese Schnittstelle ausgenutzt. Der ttrace thread registriert sich bei allen Anwendungsprozessen, überwacht diese, und fängt somit alle Systemaufrufe ab. Will ein Prozess nun einen Systemaufruf durchführen, erhält der Tracing Thread die Kontrolle, und verwandelt den Systemaufruf in einen harmlosen getpid() Systemaufruf, der nichts weiter macht, als die Prozess ID des Prozesses zurückzugeben der den Systemaufruf gemacht hat. Dieser landet im Host Kernel. Den eigentlichen Systemaufruf kann aber jetzt ohne Probleme der UML Kernel behandeln SKAS Patch Bei der Standardimplementation von UML gibt es aber ein gravierendes Sicherheitsproblem. Der Kernel und die darauf laufenden Anwendungen teilen sich einen Adressraum, da sie ja nur Prozesse auf einem Host sind. So kann Anwendung A auf den Speicher des UML Kernels zugreifen, und Daten verändern. Außerdem kann über den UML Kernel dann auf das Host System zugegriffen werden. Das ist nicht weiter tragisch wenn man UML bloß zu Kernel Debugging einsetzen will. Jedoch will man das System beispielsweiße als Honeypot oder Webserver verwenden, ist dieser Mangel an Sicherheit untragbar. Deswegen wurde der SKAS Patch entwickelt. SKAS steht für Separate Kernel Address Space. Er erlaubt des den Speicherbereich des UML Kernels zu schützen. Jedoch muss dieser Patch manuell ausgeführt werden, er ist nicht im Linux Kernel integriert. Außerdem sorgt der Patch als angenehmer Nebeneffekt noch zusätzlich für die Erweiterung der ptrace Schnittstelle. Prozesse können sich damit selbst unterbrechen, und ein überwachender Ttrace Thread ist nicht mehr notwendig, was die Performance steigert. 16

20 4 Hardware Virtualisierungslösungen 4.1 Einführung Wie schon in Kapital 1.3 auf Seite 3 besprochen, ist die Architektur des x86 nicht auf Virtualisierung ausgelegt. Das Theorem von Popek und Goldberg sagt aus, soll eine Hardware als virtualisierbar gelten, müssen alle privilegierten und sensitiven Befehle im Benutzermodus trappen. Das ist bei x86 nicht der Fall, es gibt privilegierte Anweisungen im Benutzermodus, die keinen Trap auslösen. Das Virtutalisierung sehr wichtig geworden ist, und auch immer wichtiger werden wird, haben mittlerweile auch die großen Firmen wie AMD und Intel erkannt. Sie haben in den neusten Chipgenerationen die x86 Architektur so erweitert, das sie das Popek und Goldberg Theorem erfüllen. Bei AMD heißt diese Technologie Pacifica, bei Intel heißt sie Vanderpool. Im Grunde sind aber bei beiden Technologien die gleichen Lösungsstrategien zu finden. Teilweiße sind nur die Namen von Befehlen und Datenstrukturen unterschiedlich. [4] Hier soll anhand von Vanderpool dargestellt werden wie diese neuen Technologien grundsätzlich funktionieren. 4.2 Erweiterungen an der x86 Technologie Sicherlich die wichtigste Frage ist, wie man mit der Ringe Struktur des x86 umgehen soll. Bei den neuen Virtualisierungstechnologien, hier kurz VT genannt, umgeht man das Problem dabei, das man zwei Modi einführt. Den VMX-Root-Modus und den VMX-Non-Root-Modus. Im VMX-Non-Root-Modus läuft das gerade aktive Gast Betriebssystem, im VMX-Root-Modus der Hypervisor oder das Betriebssystem das die uneingeschränkte Kontrolle über das System besitzt. In beiden Modi hat man jeweils vier Ringe zur Verfügung. Somit kann das Gastsystem volle vier Ringe benutzen und muss nicht modifiziert werden. Es kann auch nicht herausfinden das es virtualisiert wird. Ist man nun im VMX-Non-Root-Modus führt eine Privilegierte Operation immer zu einem umschalten in den VMX-Root-Modus, wo der Hypervisor überprüfen kann ob die Operation legitim ist. Um die Virtualisierung aktivieren zu können, und die Wechsel zwischen den Modis verwalten zu können, wurden zahlreiche neue Befehle und Strukturen eingeführt. Hier ein kurzer Abriss, wie die Virtualisierung funktionieren kann: 17

21 4.3 Registerübersicht Anwendungen Anwendungen Ring 1-3 Gast OS 1 Gast OS 2 Ring 0 VMENTRY VMEXIT VMENTRY VMEXIT VMON VMM Monitor VMOFF Ring -1 VMCS 1 VMCS 2 Abbildung 4.1: Virtualisierung zeitlich Mit dem Befehl VMON schaltet man die CPU in den Virtualisierungsmodus. Der Hypervisor oder das privilegierte Betriebssystem (VMM) erhält die Kontrolle. Der VMM ist nun im VMX-Root-Modus und hat vier Ringe zur Verfügung, hier zusammengefasst als Ring -1. Jetzt kann der VMM mit dem Befehl VMENTRY einem Gastbetriebssystem die Kontrolle übergeben. Privilegierte Operationen würden zwangsweiße zu einem Rücksprung führen. Das Gast System kann die Kontrolle aber auch freiwillig mit den Befehl VMEXIT wieder abgeben. Mit dem Befehl VMOFF kann man den Virtualisierungsmodus wieder verlassen. Dann sind, wie es beim x86 üblich ist, nur noch 4 Ringe aktiv. 4.3 Registerübersicht VMCS Struktur Der Status eines Gastsystems, ebendso der Status des Hypervisors muss schnell gesichert und wieder abgerufen werden können. Ebendso muss irgendwo festgelegt werden, was das Gastsystem für Befehle ausführen darf, wann es unterbrochen werden muss, etc. Diese Informationen werden in der VMCS Struktur (Virtual Machine Control Structure) gehalten. Für jedes Gastsystem existiert eine solche Struktur. Auf sie kann mit VMREAD und VMWRITE zugegriffen werden. Definiert wird die aktuelle VMCS mit den Befehlen, VMPTRST, VMPTRLD, die den 64-Bit Zeiger auf die VMCS Struktur laden oder speichern. 18

22 4 Hardware Virtualisierungslösungen Versionsnummer VMCS Abbruch Wert Gast Status Host Status Data VM-Execution Kontroll Felder VM-Exit Kontroll Felder VM-Entry Kontroll Felder VM-Exit Information Felder Abbildung 4.2: VMCS Gast Satus Prozessorstatus des Gastsystems vor und nach der Aktivierung. Host Satus Prozessorstatus des Hypervisors oder privilegiertem Betriebssystems vor und nach der Aktivierung. Kontroll Felder VM-Exit, VM-Entry Legen das Verhalten des Gastes im VMX-Non-Root-Modus fest, beispielsweiße bei welchen Befehlen der Non-Root Modus verlassen wird, oder auf welche Teile des Systems der Gast Zugriff hat. Informations-Feld VM-Exit In dem Feld kann das Gastsystem dem Hypervisor Informationen bei Verlassen des VMX-Non-Root Modues übergeben Kontroll Feld Genauer Blick auf ein Kontrollfeld: VM-Execution Kontroll Felder Pin-Based Controls Exception Bitmap Guest/Host Masks Processor-Based Controls... Abbildung 4.3: VMCS Kontrollfeld Pin-Based Controls Legt fest welche Interrupts zu einem VM-Exit führen. Processor-Based Controls Legt fest welche Befehle zu einem VM-Exit führen. Exception-Based Controls Legt fest welche Ausnahmen zu einem VM-Exit führen. 19

23 4.5 Schluss Guest/Hosts Masks Regeln Schreibzugriff auf die Register cr0 bis cr Befehlsübersicht [1] Hier ein kurzer überblick über die neu eingeführten Befehle: VMPTRLD - Load Pointer to Virtual-Machine Control Structure Lädt den Zeiger auf eine VMCS Struktur. VMPTRST - Store Pointer to Virtual-Machine Control Structure Schreibt Zeiger auf eine VMCS Struktur. VMPTRCLEAR Deaktiviert die aktuelle VMCS Struktur. VMWRITE Schreibt Teile der VMCS Struktur. VMREAD Lädt Teile der VMCS Struktur. VMCALL Hypercall vom Gastsystem zum Hypervisor. VMLAUNCH Starten eine virtuellen Maschine. VMRESUME Lädt den Status des Prozessors eines Gastsystems. VMON Prozessor wird in den VMX-Root-Modus gesetzt. Virtualisierung wird gestartet. VMOFF Virtualisierung wird beendet. 4.5 Schluss Durch diese neuen Technologien ist es auch ohne Paravirtualisierung möglich sehr perfomant und sicher Virtualisierung durchzuführen. Somit ist es XEN auch möglich Betriebssysteme wie z.b. Windows zu virtualisieren. Dies bringt einige Vorteile mit sich. Der nächste Schritt wäre dann wohl die Integration eines Hypervisors in die Hardware, so das die Hardware selbst im Stande ist, mehrere Betriebssysteme ohne die Notwendigkeit von Software Parallel auszuführen. 20

24 Literaturverzeichnis [1] Artikel in Tecchannel zu Vanderpool. index7.html. [2] Popek und Goldberg Theorem. slides1.pdf. [3] BECK, MICHAEL: Linux-Kernel-Programmierung. Addison-Wesley, 4. Auflage, [4] Seminar Intel Vanderpool. Seminar_Aktuelle_Technologien/library/04F_-_Kersten_-_ Hardware-Virtualisierung.pdf. [5] Seminar UML. WS0405/hauptsem/Ausarbeitung05.pdf. [6] Seminar UML 2. [7] Seminar UML 3. [8] XEN I/O. xen-haifux.pdf. [9] Efficient Memory Sharing in the Xen Virtual Machine Monitor. pdf. [10] Seminar Virtualisierung - Xen. Aktuelle_Technologien/library/03F_-_Ebert_Ramanauskas_-_ Software-Virtualisierung.pdf. [11] MESSMER, HANS-PETER: PC Hardware Buch. Addison-Wesley, 6. Auflage, [12] SMITH, JAMES E. und RAVI NAIR: Virtual Machines - Versatile Platforms for Systems and Processes. Morgan Kaufmann Publishers,