Advanced Operating Systems

Transkript

1 Advanced Operating Systems Hans-Albrecht Schindler Wintersemester 2016/17 Teil C: Betriebssystem-Architekturkonzepte Abschnitt 10: Virtualisierungs-Architekturen CSI Technische Universität Ilmenau -

2 10.1 Architekturprinzip Die Philosophie prinzipiell:auf gleicher Hardware mehrere unterschiedliche Betriebssysteme ausführbar machen: Anwendungen für BS 1 Anwendungen für BS n (Gast-) Betriebssystem 1 (Gast-) Betriebssystem 2 (Gast-) Betriebssystem 3 & (Gast-) Betriebssystem n (System-Software-Schicht) Hardware damit:anwendungen die sonst nicht gemeinsam auf gleicher Maschine lauffähig auf einer Maschine ausführbar (u.a. ökonomische Vorteile) 10 Virtualisierungs-Architekturen /10.1 Architekturprinzip ws 2016/17 H.-A. Schindler Folie: 10-2

3 Realisierungsprinzipien 3 unterschiedliche Prinzipien 1. Type-1-Hypervisor (früher: VMM Virtual Machine Monitor ) 2. Type-2-Hypervisor 3. Paravirtualisierung 10 Virtualisierungs-Architekturen /10.1 Architekturprinzip ws 2016/17 H.-A. Schindler Folie: 10-3

4 10.2 Typ-1-Hypervisor (auch: Virtual Machine Monitor) Anwendungen für BS 1 Anwendungen für BS n (Gast-) Betriebssystem 1 (Gast-) Betriebssystem 2 (Gast-) Betriebssystem 3 & (Gast-) Betriebssystem n Typ-1-Hypervisor Hardware System-Software-Schicht & Gast-Betriebssystem(e) 10 Virtualisierungs-Architekturen /10.2 Typ-1-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-4

5 Typ-1-Hypervisor Funktionsweise Normalerweise bewirkt ein Betriebssystem über der Hardware: 1. Multiplexing der Hardware (ermöglicht Multiprozess-Betrieb) 2. erweiterte ( verbesserte ) Maschine mit angenehmerer Schnittstelle als die reine Hardware (mit z.b. Dateien usw.) Typ-1-Hypervisor trennt beide Funktionen: läuft wie ein Betriebssystem unmittelbar über der Hardware bewirkt Multiplexing der Hardware, liefert aber keine erweiterte Maschine nach oben Damit bietet er mehrmals die unmittelbare Hardware-Schnittstelle nach oben an, von denen also jede eine virtuelle Maschine jeweils mit den unveränderten Hardware-Eigenschaften darstellt (Kern- u. Nutzer- Modus, Ein-/Ausgaben usw.). 10 Virtualisierungs-Architekturen /10.2 Typ-1-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-5

6 Typ-1-Hypervisor Entwicklung auf IBM-Großrechnern (ursprünglich IBM /360) Original-Betriebssystem OS /360: war reines Stapelverarbeitungs-Betriebssystem (1960iger Jahre) Viele Nutzer: strebten interaktive Arbeitsweise an eigenem Terminal an. verschiedene Arbeitsgruppen innerhalb u. außerhalb der IBM entwickelten Time-Sharing-Systeme IBM-Originalsystem: TSS /360 gewaltige Entwicklungskosten sehr schlechte Performanz Endsieger : Entwicklung des IBM Scientific Center in Cambridge, Mass.: CP/CMS, später VM /370 z/vm 10 Virtualisierungs-Architekturen /10.2 Typ-1-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-6

7 Typ-1-Hypervisor Entwicklung Herzstück des Hypervisors: Virtual Machine Monitor lief auf blanker Hardware lieferte: Menge virtueller Maschinen an nächste Schicht auf jeder virtuellen Maschine: unterschiedliches Betriebssystem lauffähig (da jede virtuelle Maschine exakte Kopie der Hardware) & teilweise benutzt: Original-Betriebssystem OS /360 beliebt bei Programmierern aber: CMS (Conversational Monitor System), ein interaktives Single- User-Betriebssystem 10 Virtualisierungs-Architekturen /10.2 Typ-1-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-7

8 10.3 Voraussetzungen zur Virtualisierung (oder: warum spielte Virtualisierung im PC-Bereich lange keine Rolle 9?) Systematische Untersuchungen erstmals: 1974 durch Popek& Goldberg Ergebnis: zur Realisierung virtueller Maschinen: Prozessor muss virtualisierbar sein Entscheidend: ein Gast-Betriebssystem (welches auf virtueller Maschine im Nutzer- Modus läuft): muss erreichen, dass seine privilegierten Instruktionen irgendwie ausgeführt werden. Prozessor: muss bei jeder im Nutzermodus versuchten Ausführung einer privilegierten Instruktion Trap zum Virtuellen Maschinen Monitor ausführen, damit Instruktion gegebenenfalls dort emuliert werden kann 10 Virtualisierungs-Architekturen / 10.3 Voraussetzungen zur Virtualisierung ws 2016/17 H.-A. Schindler Folie: 10-8

9 Voraussetzungen zur Virtualisierung Systematische Untersuchungen IBM-Hardware: besaß diese Eigenschaft u. war virtualisierbar 9 Intel-Prozessoren: besaßen diese Eigenschaft lange nicht waren also nicht virtualisierbar! 10 Virtualisierungs-Architekturen / 10.3 Voraussetzungen zur Virtualisierung ws 2016/17 H.-A. Schindler Folie: 10-9

10 Voraussetzungen zur Virtualisierung: GENAUER... Untersuchungen von Popek & Goldberg bei jedem Prozessor mit Kernel- u. Nutzer-Modus: existiert: Menge an Maschinen-Befehlen, die nur im Kernel-Modus ausgeführt werden dürfen (z.b. Befehle zur Realisierung von E/A, solche zur Änderung der MMU u.a.) nach [Popek&Goldberg]: sensitive Instruktionen es existiert auch: Menge an Maschinenbefehlen, die Trap auslösen, wenn sie im Nutzer-Modus ausgeführt werden nach [Popek&Goldberg]: privilegierte Instruktionen Ein Prozessor nur dann virtualisierbar: wenn Menge der sensitiven Instruktionen Untermenge der privilegierten Instruktionen einfacher: Damit Prozessor virtualisierbar, muss bei jedem Befehl der im Nutzer- Modus nicht erlaubt, Trap generiert werden. 10 Virtualisierungs-Architekturen / 10.3 Voraussetzungen zur Virtualisierung ws 2016/17 H.-A. Schindler Folie: 10-10

11 Voraussetzungen für Virtualisierung: GENAUER... privilegierte Instruktionen bei virtualisierbaren Prozessoren auf virtualisierbaren Prozessoren: bei Ausführung einer privilegierten Instruktion in virtueller Maschine: immer Trap in im Kernel-Modus laufende Systemsoftware hier (Typ1-)Hypervisor (siehe umseitig) Hypervisor: kann (durch Inspektion) feststellen: ob privilegierte Anweisung in virtueller Maschine durch Gastbetriebssystem oder durch Nutzerprogramm auf virtueller Maschine (Systemaufruf!) ausgelöst Instruktionen des Gast-Betriebssystems: werden ausgeführt 10 Virtualisierungs-Architekturen / 10.3 Voraussetzungen zur Virtualisierung ws 2016/17 H.-A. Schindler Folie: 10-11

12 Voraussetzungen für Virtualisierung: GENAUER... privilegierte Instruktionen bei virtualisierbaren Prozessoren Systemaufrufe von Nutzerprogrammen auf virtueller Maschine (Trap- Befehl!): wird emuliert, was reale Hardware getan hätte: normalerweise: Einsprung in Betriebssystem, hier also Einsprung in Gast-Betriebssystem bei nicht virtualisierbaren Prozessoren: solche Instruktionen typischerweise ignoriert! 10 Virtualisierungs-Architekturen / 10.3 Voraussetzungen zur Virtualisierung ws 2016/17 H.-A. Schindler Folie: 10-12

13 Wirkung von privilegierten Instruktionen bei Typ-1-Hypervisor virtuelle Maschine Anwendungen des Gast-BS ein Gast-Betriebssystem virtueller Nutzer- Modus Typ-1-Hypervisor virtueller Kern- Modus Trap bei jeder privilegierten Instruktion Nutzer- Modus Kern- Modus Hardware 10 Virtualisierungs-Architekturen / 10.3 Voraussetzungen zur Virtualisierung Darstellung nach [Tanenbaum2008] Bild 8-26 S. 572 ws 2016/17 H.-A. Schindler Folie: 10-13

14 IBM/370-Prozessor Virtualisierung wurde unterstützt Voraussetzungen für Virtualisierung: GENAUER... Intel-Architektur (ab 386) keine Unterstützung für Virtualisierung 9 bei versuchter Ausführung einiger sensitiver Instruktionen im Nutzer- Modus: diese einfach ignoriert 9 außerdem schlimm : z.b. auf Pentium-Prozessor kann Programm feststellen, ob es im Kerneloder Nutzer-Modus läuft 9 Betriebssystem, das entdeckt, dass es im Nutzer-Modus läuft: trifft möglicherweise absolut fehlerhafte Entscheidungen 9 Diese Mängel der Intel-Architektur 20 Jahre lang (!!) im Sinne von Rückwärtskompatibilität auch auf Nachfolgeprozessoren übertragen 9 (!!) 10 Virtualisierungs-Architekturen / 10.3 Voraussetzungen zur Virtualisierung ws 2016/17 H.-A. Schindler Folie: 10-14

15 Forderungen nach Virtualisierbarkeit Bedarf an Virtualisierungslösungen Reihe von Gründen: führten im Laufe der Zeit zu hohem Bedarf an Virtualisierungslösungen: 1. Mehrere unterschiedliche Server, die in Unternehmen bisher auf mehreren unterschiedlichen Rechnern mit unterschiedlichen Betriebssystemen liefen, jetzt ökonomischer auf einem Rechner lauffähig 9 2. Checkpointingu. Migration virtueller Maschinen wesentlich einfacher als als auf Prozess-Ebene 9 3. Benutzung von Legacy -Software kostengünstig möglich 9 4. Software-Entwicklung für unterschiedliche Systeme: ökonomischer u. angenehmer möglich 9 10 Virtualisierungs-Architekturen / 10.3 Voraussetzungen zur Virtualisierung ws 2016/17 H.-A. Schindler Folie: 10-15

16 Forschungsarbeiten 1990iger Jahre verschiedene akademische Projekte zur Virtualisierungbisher nicht virtualisierbarer Prozessoren: erstes und vermutlich bekanntestes: DISCO-Projekt der University of Stanford Resultat: letztlich VMware (heute kommerziell) u. Typ-2-Hypervisoren 9 10 Virtualisierungs-Architekturen / 10.3 Voraussetzungen zur Virtualisierung ws 2016/17 H.-A. Schindler Folie: 10-16

17 10.4 Typ-2-Hypervisor Anwendungen für BS 1 Anwendungen für BS n (Gast-) Betriebssystem 1 (Gast-) Betriebssystem 2 & (Gast-) Betriebssystem n Anwendungen des Host-Betriebssystems Typ-2-Hypervisor Host-Betriebssystem Hardware System-Software-Schicht & Gast-Betriebssystem(e) 10 Virtualisierungs-Architekturen /10.4 Typ-2-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-17

18 Wie funktioniert Typ-2-Hypervisor? am Beispiel VMware VMware läuft: als gewöhnlicher Nutzer-Prozess auf Gast-Betriebssystem (z.b. Windows oder Linux) beim ersten Start: VMwarereagiertwie neuer Rechner u. erwartet Betriebssystem-DVD im entsprechenden Laufwerk 9 VMware: installiert Betriebssystemauf virtuellem Speichermedium (in Realität: eine Datei des Host-Betriebssystems) kann danach wie ganz normales Betriebssystem gestartet werden 9 10 Virtualisierungs-Architekturen /10.4 Typ-2-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-18

19 Typ-2-Hypervisor Interne Arbeitsweise Bei Ausführung z.b. von Pentium-Binärprogramm (egal ob von Installations-CD oder virtueller Disk): wird zunächst nach Basis-Blöcken gesucht & (Das sind Befehlsfolgen, die mit jump-, call- oder Trap-Befehl bzw. anderen Befehlen abgeschlossen sind, die den Kontrollfluss ändern [sichtbar an Änderung des Programm-Zählers].) Basisblöcke: werden nach sensitiven Instruktionen abgesucht 9 Diese: jeweils durchaufruf einer Vmware-Prozedur ersetzt, die jeweilige Instruktion behandelt gleiche Verfahrensweise: mit letzter Instruktion eines Basis-Blocks Virtualisierungs-Architekturen /10.4 Typ-2-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-19

20 Typ-2-Hypervisor Interne Arbeitsweise... so modifizierter Basis-Block: wird innerhalb von VMware in Cache gespeichert u. ausgeführt Basis-Block ohne sensitive Instruktionen: läuft unter VMwareabsolut genauso schnell wie unmittelbar auf Hardware (weil er auch tatsächlich unmittelbar auf der Hardware läuft) sensitive Instruktionen: nach dargestellter Methode abgefangen u. emuliert diese Technik: bekannt als Binary Translation (Binär-Übersetzung) 10 Virtualisierungs-Architekturen /10.4 Typ-2-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-20

21 Typ-2-Hypervisor Interne Arbeitsweise Nachdem Basis-Block vollständig ausgeführt: erhält VMwareKontrolle zurück 9 und lokalisiert nachfolgenden Basis-Block falls dieser schon transformiert: kann er sofort ausgeführt werden. (Falls nicht, wird wie eben verfahren.) irgendwann:großteil des Programms im Cache, 9 läuft dann: mit nahezu Original-Geschwindigkeit, die Hardware ermöglicht 10 Virtualisierungs-Architekturen /10.4 Typ-2-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-21

22 Typ-2-Hypervisor Optimierungstechniken zusätzlich: verschiedene Optimierungstechniken angewendet Beispiel: Wenn Basisblock durch Sprung zu oder Aufruf eines anderen Basisblocks endet, kann diese letzte Anweisung durch Sprung zu bzw. Aufruf des übersetzten Basis-Blocks ersetzt werden. Hierdurch jeglicher Overhead bezüglich Auffindens des nächsten Basis-Blocks eliminiert. 10 Virtualisierungs-Architekturen /10.4 Typ-2-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-22

23 Typ-2-Hypervisor Performanz Messungen: zeigen gemischtes Bild Typ2-Hypervisoren: keinesfalls so schlecht, wie vielleicht zu erwarten 9 Vergleich mit virtualisierbarer Hardware (u. Typ1-Hypervisor): durch dort verwendete trap-and-emulate -Technik: wird Vielzahl von Traps erzeugt diese:bei moderner Hardware sehr teuer (weil sie CPU-Caches, TLBs u. Branch-Prediction-Tabellen des Prozessors korrumpiert) wenn andererseits sensitive Instruktionen durch Aufruf von VMware- Prozeduren innerhalb des ausführenden Programms ersetzt: keine dieser Kontext-Umschaltungs-Overheads 10 Virtualisierungs-Architekturen /10.4 Typ-2-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-23

24 Typ-2-Hypervisor Performanz Messungen (von Adams u. Agesen) zeigen: manchmal:übertrifft Softwarelösung sogar Hardwarelösung (abhängig von Art der Last). deshalb heute: sogar einige Typ1-Hypervisoren benutzen aus Performanzgründen binarytranslation (auch wenn alles auch ohne diese korrekt funktionieren würde) 10 Virtualisierungs-Architekturen /10.4 Typ-2-Hypervisor ws 2016/17 H.-A. Schindler Folie: 10-24

25 Funktionsprinzip 9 unterscheidet sich von dem der diskutierten Hypervisor Hierbei: Quellcode des Gast-Betriebssystems modifiziert sensitive Instruktionen: durch Hypervisor-Calls ersetzt 10.5 Paravirtualisierung Effekt: Gast-Betriebssystem arbeitet jetzt wie Nutzerprogramm, welches Systemaufrufe ( system calls ) zum Betriebssystem (hier dem Hypervisor) ausführt dazu: Hypervisor: muss spezielles Interface definieren dieses umfasst: Menge von Prozedur-Aufrufen zur Benutzung durch Gast-Betriebssystem Prozedur-Aufrufe: bilden Art API als Schnittstelle für Gast- Betriebssysteme (nicht für Nutzerprogramme!) 10 Virtualisierungs-Architekturen / 10.5 Paravirtualisierung ws 2016/17 H.-A. Schindler Folie: 10-25

26 Paravirtualisierung Verwandtschaft mit Mikrokernel-Prinzip Geht man noch einen Schritt weiter I und entfernt alle sensitiven Instruktionen aus Gast-Betriebssystem und ersetzt diese durch Hypervisor-Aufrufe, um Systemdienste wie E/A zu benutzen, 9 hat man praktisch den Hypervisor in Mikrokern transformiert. 10 Virtualisierungs-Architekturen / 10.5 Paravirtualisierung ws 2016/17 H.-A. Schindler Folie: 10-26

27 10.6 Security als unterstützte nichtfunktionale Eigenschaft Was macht Virtualisierungsarchitekturensicher(er)? Vergleiche bisher gemachte Ausführungen: es existieren: viele getrennte Adressräume (wie z.b. bei Mikrokern-Architekturen) dadurch möglich: 1. bedeutende Einschränkung der Fehlerausbreitung 2. Überwachung der Kommunikation zwischen Teilsystemen möglich sogar: Sandboxing (Verhinderung jeglicher Beeinflussung der Umgebung durch Abfangen entsprechender Versuche) 10 Virtualisierungs-Architekturen /10.6 Security als unterstötztenfe ws 2016/17 H.-A. Schindler Folie: 10-27

28 10.7 Robustheit als unterstützte nichtfunktionale Eigenschaft Was macht Virtualisierungsarchitekturenrobust(er)? Vergleiche ebenfalls bisher gemachte Ausführungen: es existieren: viele getrennte Adressräume möglich dadurch: 1. Einschränkung der Fehlerausbreitung 2. Überwachung der Kommunikation & 10 Virtualisierungs-Architekturen /10.7 Robustheit als unterstötztenfe ws 2016/17 H.-A. Schindler Folie: 10-28

29 10.8 Adaptivität als unterstützte nichtfunktionale Eigenschaft Was macht Virtualisierungsarchitekturenadaptiv? Ähnlich wie bei Exokernen: können viele unterschiedliche Betriebssysteme mit jeweils unterschiedlichen Eigenschaften ausgeführt werden damit können: Gruppen von Anwendungen auf ähnliche Weise jeweils unterschiedliche Abstraktionen etc. zur Verfügung gestellt werden 10 Virtualisierungs-Architekturen /10.8 Adaptivitätals unterstötztenfe ws 2016/17 H.-A. Schindler Folie: 10-29

30 10.9 Fallbeispiele VM /370 Vmware VirtualBox Xen VMI Paravirt ops virtuelle Maschine für Linux auf Linux (User-Mode-Linux) 9 10 Virtualisierungs-Architekturen /10.9 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 10-30

31 Vmware (Aktuelles Logo)... ist Unternehmen in Palo Alto, Kalifornien (USA) gegründet 1998 von 5 Informatikern stellt verschiedene Virtualisierungs-Software-Produkte her: 1. Vmware Workstation war erstes Produkt von Vmware (1999) mehrere unabhängige Instanzen von x86- bzw. x Betriebssystemen auf einer Hardware betreibbar 2. Vmware Fusion ähnliches Produkt für Intel Mac-Plattformen 3. Vmware Player (war) Freeware für nichtkommerziellen Gebrauch 10 Virtualisierungs-Architekturen /10.9 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 10-31

32 Vmware 4. Vmware Server (früher GSX Server) 5. Vmware vsphere(esxi) Produkte : für Desktop-Systeme Produkte : für Server-Systeme Produkte : benutzen Host-Guest-Architektur (Typ2-Hypervisor) (Bild umseitig) bei Vmware-Installation: spezielle vm-treiber in Wirts-Betriebssystem eingefügt diese ermöglichen: direkten Hardware-Zugriff durch Laden der Treiber: entsteht sog. Virtualisierungsschicht 10 Virtualisierungs-Architekturen /10.9 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 10-32

33 Vmware: Host-Guest-Architektur 10 Virtualisierungs-Architekturen /10.9 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 10-33

34 Typ1-Hypervisor-Architektur Anwendung nur bei Vmware ESX-Server Vmware: bare-metal -Architektur 10 Virtualisierungs-Architekturen /10.9 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 10-34

35 Vmware: Paravirtualisierung Entsprechende Produkte in Vorbereitung 10 Virtualisierungs-Architekturen /10.9 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 10-35

36 VirtualBox Virtualisierungs-Software für x86- bzw. x86-64-betriebssysteme für Industrie und Hausgebrauch (ursprünglich: Innotek, dann Sun, jetzt Oracle) (Aktuelles Logo) (angeblich) einzigefreiverfügbareprofessionellelösung, alsopen Source Software untergnu General Public License(GPL) version 2. 9 (gegenwärtig) lauffähigaufwindows, Linux, Macintoshu.SolarisHosts unterstütztgroßeanzahlvon Gast-Betriebssystemen: Windows(NT 4.0, 2000, XP, Server 2003, Vista, Windows 7), DOS/Windows 3.x, Linux(2.4 and 2.6), Solaris and OpenSolaris, OS/2, and OpenBSD u.a. Typ2-Hypervisor-Lösung 10 Virtualisierungs-Architekturen /10.9 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 10-36

37 Xen entstanden als Forschungsprojekt der University of Cambridge (UK), dann XenSourceInc., danachcitrix, jetzt: Linux Foundation ( self-governing ) (Logo) freiverfügbaralsopen Source Software untergnu General Public License(GPL) version 2. 9 lauffähig auf Prozessoren der Typen x86, x86-64, PowerPC, ARM, MIPS unterstütztgroßeanzahlvon Gast-Betriebssystemen: FreeBSD, GNU/Hurd/Mach, Linux, MINIX, NetBSD, Netware, OpenSolaris, OZONE, Plane9 bekannt für Paravirtualisierung unterstützt heute auch andere Virtualisierungs-Prinzipien 10 Virtualisierungs-Architekturen /10.9 Fallbeispiele ws 2016/17 H.-A. Schindler Folie: 10-37

38 10.10 Virtualisierungsarchitekturen: Zusammenfassung Unterstützte nichtfunktionale Eigenschaften A. Laufzeiteigenschaften 1. Zuverlässigkeit nichtfunktionierendes Gastbetriebssystem: kann keinen Absturz des Host-Betriebssystems verursachen einfacher: 1. Test der Gastsysteme (sind unabhängige Teilsysteme) 2. Wartung/Modifikation der Gastsysteme 2. Robustheit stark eingeschränkte Fehlerausbreitung, bis hin zu Sandboxing 3. Security (IT-Sicherheit) (vergleiche Bemerkungen zur Robustheit) 10 Virtualisierungs-Architekturen /10.10 Virtualisierungsarchitekt.: Zusammenfassung ws 2016/17 H.-A. Schindler Folie: 10-38

39 Zusammenfassung Unterstützte nichtfunktionale Eigenschaften A. Laufzeiteigenschaften 4. Sparsamkeit Hardware-Ressourcen:für mehrere bis viele unterschiedliche Aufgaben genutzt (die sonst jeweils eigene Hardware benötigen würden) 5. Effizienz durch Mehrfachnutzung der Hardware: diese auch effizienter genutzt 6. Migrierbarkeit vollständige Gastsysteme: leichter migrierbar als einzelne Prozesse ws 2016/17 H.-A. Schindler Folie: 10-39

40 Zusammenfassung Unterstützte nichtfunktionale Eigenschaften B. Evolutionseigenschaften 1. Wartbarkeit Veränderungen (Beheben von Fehlern, Anpassungen) der Gastsysteme leicht möglich 2. Portierbarkeit Gastsysteme leicht umsetzbar 3. Offenheit u. Erweiterbarkeit neue Gastsysteme einfach hinzufügbar ws 2016/17 H.-A. Schindler Folie: 10-40

41 Zusammenfassung Weitere Vorteile von Virtualisierungsarchitekturen 1. höhere Modularität 2. Nutzbarkeit von Legacy-Software ws 2016/17 H.-A. Schindler Folie: 10-41

42 Nachteile von Virtualisierungsarchitekturen Zusammenfassung gewisser Overhead (je nach Virtualisierungsprinzip u. Hardware) ws 2016/17 H.-A. Schindler Folie: 10-42

43 Literatur 1. [Tanenbaum2008] Tanenbaum, Andrew S.: Modern Operating Systems, 3te Auflage Pearson Prentice Hall 2008 ISBN 13 : S und S [Adams2006] Adams, Keith / Agesen, Ole: A Comparison of Software and Hardware Techniques for x86 Virtualization Artikel (aus dem www) 2006 oder später 10 Virtualisierungs-Architekturen /Literatur ws 2016/17 H.-A. Schindler Folie: 10-43

44 Literatur IEEE-Zeitschrift Computer (Mai 2005) mit einer Reihe von Beiträgen zur Thematik: S : Figueiredo, R. u.a.: Resource Virtualization Renaissance S.32 38: Smith, James A. / Nair, Ravi: The Architecture of Virtual Machines S Rosenblum, Mendel / Garfinkel, Tal: Virtual Machine Monitors: Current Technology and Future Trends S Uhlig, Rich u.a.: Intel Virtualization Technology 10 Virtualisierungs-Architekturen /Literatur ws 2016/17 H.-A. Schindler Folie: 10-44

45 Literatur Computer Mai Fortsetzung: S : Whitaker, Andrew / Cox, Richard S. / Shaw, Marianne / Gribble, Steven D.: Rethinking the Design of Virtual Machine Monitors S.63 69: Ruth, Paul / Jiang, Xuxian / Xu, Dongyan / Goasguen, Sebastian: Virtual Distributed Environments in a Shared Infrastructure 10 Virtualisierungs-Architekturen /Literatur ENDE Abschnitt 10 ws 2016/17 H.-A. Schindler Folie: 10-45