Virtualisierungstechnologien. Funktionen und Vorgehensweisen

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Wahl der Thematik
1.2 Ziel der Bachelorarbeit

2 Grundlagen der Virtualisierung
2.1 Historische Betrachtung der Virtualisierung
2.2 Charakteristik einer virtuellen Maschine
2.3 Prinzip der Virtualisierung
2.4 Arten von Virtualisierungen
2.4.1 Emulation
2.4.2 Para-Virtualisierung
2.4.3 Vollständige Virtualisierung
2.4.4 Pre-Virtualisierung
2.4.5 Rekursive Virtualisierung
2.5 Virtualisierung auf Hardwareebene
2.5.1 Virtualisierung der x86-Architektur
2.5.1.1 Virtualisierung auf Prozessorebene
2.5.1.2 Intel Vanderpool
2.5.1.3 AMD Pacifica
2.5.2 Speichervirtualisierung
2.6 Problematik der Softwarevirtualisierung
2.7 Architektur einer virtuellen Maschine
2.7.1 Typ I: Native Architektur
2.7.2 Typ II: Host Architektur
2.7.3 Typ III: Hybride Architektur
2.8 Funktionsweise der Virtualisierung
2.8.1 Funktionsweise des Hypervisors
2.8.2 Virtualisierung am Beispiel VMware
2.9 Vor- und Nachteile der Virtualisierung
2.9.1 Vorteile der Virtualisierung
2.9.2 Nachteile der Virtualisierung
2.10 Stand der Entwicklung
2.11 Validität der Virtualisierung

3 Anwendungsbereiche der Virtualisierung
3.1 Einsatzmöglichkeiten und Einsatzgebiete
3.2 Praktische Anwendungen in der Industrie

4 Komplexversuch zur Virtualisierung
4.1 Ziel des Versuches
4.2 Voraussetzungen
4.3 Versuchsvorbereitung
4.4 Beschreibung der Aufgaben
4.5 Ausblick

5 Zusammenfassung

6 Bedarf und Ausblick

Literaturverzeichnis

Glossar

Anhang A Komplexversuch zur Virtualisierung A

Anhang B Versuchsauswertung B

Anhang C Virtualisierungslösungen im Überblick C

Anhang D Programmierung der Automatismen D

Abbildungsverzeichnis

Abbildung 2-1: Darstellung einer API-Emulation. URL: <http://www.lrr.in.tum.de/~stod

den/teaching/sem/virt/ss06/doc/virt06-07-20060531-kern-sld%20-%20Para

virtualisierung.pdf>, verfügbar am 28.10.06

Abbildung 2-2: Darstellung der Emulation einer kompletten Rechnermaschine

URL: <http://www.lrr.in.tum.de/~stodden/teaching /sem/virt/ss06/

doc/virt06-07-20060531-kern-sld%20-%20Paravirtualisierung.pdf>,

verfügbar am 28.10.06

Abbildung 2-3: Para-Virtualisierung mit „Hypervisor“ und modifizierten Betriebssystem-

kernel. URL: <http://www.lrr.in.tum.de/~stodden/teaching/ sem/virt/ss06/

doc/virt06-07-20060531-kern-sld%20-%20 Paravirtualisierung.pdf>,

verfügbar am 28.10.06

Abbildung 2-4: Vollständige Virtualisierung mittels „Hypervisor“. URL: <http://www.lrr

in.tum.de/~stodden/teaching/sem/virt/ss06/doc/virt06-07-20060531-kern-

sld%20-%20Paravirtualisierung.pdf>, verfügbar am 28.10.06

Abbildung 2-5: Exponentieller Slowdown durch die Emulation privilegierter Befehle in einer

konventionellen virtuellen Maschine. URL: <http://www4.informatik.uni-

erlangen.de/DE/Lehre/WS97/HS_OSRES/ flux/Ausarbeitung.ps>,

verfügbar am 20.10.06

Abbildung 2-6: Vergleich des konventionellen Prozessmodells mit dem rekursiven Prozess-

modell. Quelle: eigene Darstellung, verfasst am am 29.12.06

Abbildung 2-7: Privilegierungsstufen der x86-Architektur. URL: <http://www.lrr.in.tum.de/

~stodden/teaching/sem/virt/ss06/doc/virt06-07-20060531-kern- sld%20-%20

Paravirtualisierung.pdf>, verfügbar am 28.10.06

Abbildung 2-8: Zeitliche Betrachtung eines „Exception Handlings“. Bearbeitet aus:

<http://i30www.ira.uka.de/teaching/coursedocuments/130/mkc-09-except

interupt.pdf>, verfügbar am 03.01.07

Abbildung 2-9: Gegenüberstellung des „Goldberg-Popek Theorems“ und einer nicht-

virtualiserbaren x86-Architektur. URL: <http://www.lrr.in.tum.de/~stodden

/teaching/sem/virt/ss06/doc/virt06-07-20060531-kern-sld%20-%20Para

virtualisierung.pdf>, verfügbar am 28.10.06

Abbildung 2-10: Darstellung der „Virtual Machine Control Structur“. Bearbeitet aus:

<http://www.lrr.in.tum.de/~stodden/teaching/sem/virt/ ss06/doc/virt06-07-

20060531-kern-sld%20-20Paravirtualisierung.pdf>,

verfügbar am 28.10.06

Abbildung 2-11: Kontextwechsel auf Prozessorebene unter zeitlichem Gesichtspunkt

Bearbeitet aus: <http://www.lrr.in.tum.de/~stodden/teaching/sem/virt/ ss06

/doc/virt06-07-20060531-kern-sld%20-20Paravirtualisierung.pdf>,

verfügbar am 28.10.06

Abbildung 2-12: Schematische Darstellung des Konzepts zur Virtualisierung des Speichers

URL: <http://www13.in.tum.de/lehre/seminare/WS0203/hauptsem/

Vortrag9_VM_Ausarbeitung_Verbessert.pdf>,

verfügbar am 28.10.06

Abbildung 2-13: Privilegierungsstufen nach der Virtualisierung. URL: <http://www.lrr

in.tum.de/~stodden/teaching/sem/virt/ss06/doc/virt06-07-20060531-kern-

sld%20-%20Paravirtualisierung.pdf>, verfügbar am 28.10.06

Abbildung 2-14: „Typ I Architektur“ einer Virtualisierungsumgebung mit „Hypervisor“

URL: <http://www.lrr.in.tum.de/~stodden/teaching/sem/virt/ss06/doc/

virt06-07-20060531-kern-sld%20-%20Paravirtualisierung.pdf>,

verfügbar am 28.10.06

Abbildung 2-15: „Typ II Architektur“ einer Virtualisierungsumgebung mit Host-System

und „Hypervisor“. URL: <http://www.lrr.in.tum.de/~stodden/teaching/

sem/virt/ss06/doc/virt06-07-20060531-kern-sld%20-%20Para

virtualisierung.pdf>,verfügbar am 28.10.06

Abbildung 2-16: „Typ III Architektur“ mit Host-System und „Hypervisor“

URL: <http://www.lrr.in.tum.de/~stodden/teaching/sem/virt/ss06/doc/

virt06-07-20060531-kern-sld%20-%20Paravirtualisierung.pdf>,

verfügbar am 28.10.06

Abbildung 2-17: Bestandteile des „Hypervisors“. URL: <http://www.lrr.in.tum.de/

~stodden/teaching/sem/virt/ss06/doc/virt06-06-20060524-klitzing-doc

%20-%20System%20VMs.pdf>, verfügbar am 17.10.06

Abbildung 2-18: Temperaturregulierung infolge der Verteilung von Instruktionen auf die

Prozessoren. URL:<http://i30www.ira.uka.de/research/ documents/pm/2006

/eapm_poster.abstract.pdf>, verfügbar am 13.10.06

Abbildung 2-19: Energiemanagement mittels VM Scheduler. URL:<http://i30www.ira

uka.de/research/documents/pm/2006/eapm_poster.abstract.pdf>,

verfügbar am 13.10.06

Abbildung 2-20: Methodik der Pre-Virtualisierungstechnik. URL:<http://l4ka.org/projects

/virtualization/afterburn/previrtualization.pdf>,

verfügbar am 13.10.06

Abbildung A-1: Darstellung des Bildschirmaufbaus der „VMware Workstation“

Quelle: <eigene Darstellung>, verfasst am 26.12.06 A

Abbildung A-2: Gesamtübersicht der „VMware Workstation“ einschließlich der integrierten

virtuellen Maschinen von „Windows“ und Linux

Quelle: <eigene Darstellung>, verfasst am 28.09.06 A

Abbildung A-3: Verzeichnisstruktur des Shared Folder im Explorer

Quelle: <eigene Darstellung>, verfasst am 28.09.06 A

Abbildung A-4: Anzeige der Informationen über das erstellte Laufwerk

Quelle: <eigene Darstellung>, verfasst am 28.09.06 A

Abbildung A-5: Momentaufnahmen in einem linearen Prozess. Quelle: <eigene Darstellung>,

verfasst am 03.10.06 A

Abbildung A-6: Momentaufnahmen in einem Prozessbaum. Quelle: <eigene Darstellung>,

verfasst am 03.10.06 A

Abbildung A-7: Anzeige des abgeschlossenen Vorgangs des Klonens virtueller Systeme

Quelle: <eigene Darstellung>, verfasst am 06.10.06 A

Abbildung A-8: Darstellung eines Bridged-Netzwerks. URL:<http://www.vmware.com/

de/pdf/ws55_manual_de.pdf>, verfügbar am 09.10.06 A

Abbildung A-9: Einfache Darstellung einer NAT. URL:<http://www.vmware.com/de

/pdf/ws55_manual_de.pdf>, verfügbar am 09.10.06 A

Abbildung A-10: Illustration eines Host-Only-Netzwerks. URL:<http://www.vmware.com

/de/pdf/ws55_manual_de.pdf>, verfügbar am 11.10.06 A

Abbildung A-11: Mögliche Szenarien einer Migration. URL:<http//www.vmware.com/

products/beta/converter/converter.gif>, verfügbar am 16.10.06 A

Abbildung C-1: Übersicht zu den mannigfaltigen Virtualisierungsarten unter dem Aspekt der

Virtualisierungsarchitektur. Bearbeitet aus: <http://l4ka.org/publications

/2005/previrtualization-techreport.pdf>, verfügbar am 09.11.2006 C

Tabellenverzeichnis

Tabelle B-1: Gegenüberstellung der Systemkomponenten des Host- und Gast-Systems B

Tabelle B-2: Vergleich des virtuellen Systems vor und nach der Installation

der „VMware-Tools“ B

Tabelle B-3: Gegenüberstellung der Leistung des realen und des virtuellen Systems B

Tabelle B-4: Speicherbedarf der konzipierten virtuellen Festplatten B

Tabelle C-1: Virtualisierungslösung im Überblick C

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Zitat:

„If it's there and you can see it - it's REAL

If it's there and you can't see it - it's TRANSPARENT

If it's not there and you can see it - it's VIRTUAL

If it's not there and you can't see it - it's GONE!“

Roy Wilks, 1983

Die Entwicklung der Menschheit wird signifikant von der Entwicklung des technologischen Fortschritts beeinflusst. Betrachtet man dabei den Menschen unter dem Aspekt der tech-nologischen Entwicklung, so kann man feststellen, dass diese immer schneller voranschreitet. Folglich tangiert der Bereich der realisierbaren Lösungen immer öfters mit dem Grenzgebiet des verfahrenstechnisch Möglichen.

Besonders im Bereich der Informationstechnologie, wo der technologische Fortschritt außerordentlich schnell voranschreitet, erfährt man immer öfters die Grenzen von Physik und

Informatik. Infolge dessen wurden Überlegungen getätigt, um diese Probleme auf alternativen Wegen zu lösen. Einer dieser Wege führt über die Virtualisierung. Diese eigentlich recht alte Disziplin der Informationstechnologie entwickelt sich seit kürzester Zeit zum An-ziehungspunkt für Problemerkennung, Problemlösung und Optimierung.

Die Probleme der Informationstechnologie sind durch die ständig schnellere Entwicklung des technologischen Fortschritts mannigfaltig. Sie reichen von Fragen über das optimale Sizing, Migration bis hin zur optimalen Ausnutzung der Rechnerkapazität. Dabei birgt die Virtualisierung Vorteile wie Desaster-Recovery-Backups, Migrationsautomatisierungen, Speicher-virtualisierung im Storage Area Network (SAN), Applikationsvirtualisierung, Plattformunabhängigkeit, Kosten- und Platzersparnis, um nur einige Vorteile zu nennen. Dieses Potential der Virtualisierung wurde erkannt und aus diesem Grund entwickelten sich rasant Ansätze, die durch verschiedenste Hersteller realisiert werden.

Die Virtualisierung ist sicherlich ein Konzept, welches die Entwicklung in vielen Bereichen der Informationstechnologie beschleunigen wird. Man spricht sogar davon, dass die Virtualisierung die Informationstechnologie revolutionieren könnte. Sie wird aber sicherlich die nächsten Jahre das bestimmende Thema sein. Das Konzept der Virtualisierung macht sich dabei das Know-how von Gebieten der Informatik, Informationstechnologie und Kommunikationstechnik zunutze, wobei mehrere Bereiche der genannten Gebiete ineinander über-gehen.

1.1 Wahl der Thematik

Der Abschluss des Bachelorstudiums im Bereich Informationstechnologie und Elektrotechnik erfordert die Anfertigung einer Bachelorarbeit. Schon im Vorfeld wurden Gedanken und Forderungen hinsichtlich Realisierung der Systemstabilität, Automatisierung und Optimierung geäußert. Gründe für die Wahl dieser Thematik waren zum einen die Beeinflussung durch die aktuellen Entwicklungen und Trends in der Informationstechnologie. Zum anderen aber auch längerfristige Überlegungen in welche Richtung sich die Informationstechnologie in Zukunft verändern wird. Ein weiterer Beweggrund war, dass im Praktikumssemester verschiedenste Aufgaben zur Realisierung der Sicherheit, Automatisierung und Vermeidung von Suboptimierung in Netzwerken verwirklicht wurden. Dabei wurden hinreichende Kenntnisse im Umgang mit der Optimierung und Datensicherheit erlangt. Folglich kam man mit der Virtualisierung und ihren Auswirkungen in Kontakt. Mit dem Konzept der Virtualisierung ließ sich die Anforderung im Praktikum wesentlich effizienter und kostengünstiger realisieren. Aus den oben genannten Aspekten wird offensichtlich, dass die Wahl der Thematik im Vorfeld geprägt und durch aktuelle Ereignisse angeregt wurde. In Anbetracht dessen, wurde die Thematik „Virtualisierung“ für die Bachelorarbeit gewählt und verfasst, um die Realisierung der genannten Forderungen zu erfüllen.

1.2 Ziel der Bachelorarbeit

Zunächst soll die Virtualisierungstechnologie, ihre mannigfaltigen Konzepte sowie die damit verbundenen Auswirkungen untersucht werden. Daraus resultierend ist ein Überblick zu den Grundlagen und der Funktionsweise der Virtualisierung zu erstellen. Die dazugehörigen

Aspekte werden klar definiert und in einem gemeinsamen Kontext verglichen. Nach einer Übersicht zu den mannigfaltigen Arten einer solchen Konzeption werden die Vor- und Nachteile der Virtualisierung fokussiert. Es erfolgt eine Diskussion über die rechtlichen Grundlagen sowie die resultierenden Lizenzierungsbestimmungen. Im Anschluss daran werden einige Einsatzmöglichkeiten und Einsatzgebiete sowie praktische Anwendungen in der Industrie erläutert. Dabei ist dieses Konzept vor allem in der Industrie bedeutend, wo

wichtige Einflussfaktoren wie System-Sizing, Capacity-Management und System-Services-Limiting-Performance eine tragende Rolle spielen. Diese Aspekte sollen verdeutlichen, in wie weit die Entwicklungen und Einsatzmöglichkeiten in einer praxisnahen Umgebung

bisher forciert wurden.

Eine signifikante Relevanz dieser Bachelorarbeit bildet der Entwurf eines Komplexversuches für Studenten der Hochschule Mittweida. Dazu ist es erforderlich eine Anforderungsanalyse über die Durchführung und Realisierung zu erstellen. Der entworfene Komplexversuch für Studenten soll einen entsprechenden praktischen Bezug zur Thematik herstellen und dient gleichzeitig dazu, die Axiome der Virtualisierung zu veranschaulichen. Des Weiteren ist die Gestaltung der Aufgaben so zu entwerfen, dass die Praxistauglichkeit anhand einiger Problemstellungen im Komplexversuch gezeigt werden kann. Darauf folgt eine Auseinandersetzung zwischen einem realen und einem virtualisierten System. Später soll den Studenten das Konzept und dessen Auswirkung dadurch demonstriert und Rückschlüsse auf verschiedene Konzeptionen ermöglicht werden.

Abschließend erfolgt eine Zusammenfassung, in der nochmalig alle dazugehörigen Aspekte konkretisiert werden. Es soll mit dieser Bachelorarbeit belegt werden, wie weit der aktuelle Stand der Virtualisierung ist und welches Potential noch zu erwarten sein dürfte. Dies sollte vor allem für die Firmen der Informationstechnologie, den Rechenzentren der Hochschulen aber auch für den konventionellen Computer-Nutzer von Interesse sein.

2 Grundlagen der Virtualisierung

2.1 Historische Betrachtung der Virtualisierung

Im Folgenden werden die verschiedenen Stufen der Entstehungsgeschichte der Virtualisierung bis hin zur heutigen technologischen Entwicklung vorgestellt und dabei die Konzepte und Besonderheiten der Virtualisierung angesprochen.

Die Idee von der Virtualisierung begann am 20. Juni 1959 mit der Abhandlung „Time

Sharing in Large Fast Computers" von Christopher Strachey, einem englischen Pionier auf dem Gebiet der Computerwissenschaft [1]. In der Publikation wird ein System beschrieben, welches aus einem Prozessor besteht und Programme linear folgend bearbeitet. Greift ein Programm auf die Peripherie des Computers zu, so wird ein Kontextwechsel durchgeführt und das nächste Programm wird bis zu einem erneuten Zugriff auf die Peripherie abge-arbeitet. Strachey schildert in der Abhandlung einen logischen Prozessor, auf dem Pro-gramme wie auf einem realen Prozessor gestartet werden können. Ein Scheduler ordnet dann den logischen dem physikalischen Prozessor zu.

Drei Jahre später, am 7. Dezember 1962 wurde in Manchester der ATLAS Computer als

rechenstärkster Computer der Welt eingeweiht. Dieser beinhaltete einen einstufigen virtu-ellen Speicher mit „Demand Paging“. Bei Letzterem handelt es sich um eine Technologie, bei der ein Zugriff auf eine Speicherseite erfolgt, die nicht im Hauptspeicher, sondern im Auslagerungsspeicher abliegt. Zudem werden die Seiten nur dann in den Speicher geladen, insofern diese benötigt werden. Wenn sich auf einer virtuellen Maschine ein Betriebssystem befindet, welches selber „Paged“, entsteht eine zweite Stufe des „Paging“, was Verzöge-rungen mit sich führt. Durch das einfache „Demand Paging“ konnte der Hauptspeicher virtualisiert werden, was bei dem ATLAS Computer zu einer Kosteneinsparung führte.

Später in den 60er Jahren folgte der Entwurf des M44/44X-Projektes, welches im IBM Watson Research Center (Cambridge, USA) durchgeführt wurde. Dabei dient eine IBM 7044 als Hauptrechner, auf dem mehrere virtuelle Maschinen (VM) des Typs IBM 7044 ausgeführt wurden. Weitere Entwicklungen zu virtualisierten Maschinen wurden auf der Mainframe-Ebene mit dem CP/CMS-40 und dem VM/370 (offiziell: Virtual Machine Facility/370) von IBM (Armonk, USA) verfolgt, wobei „CP“ für „Control Program“ und „CMS“ für „Console Monitor System“ steht [11]. Dieses am Massachusetts Institute of Technology (MIT) realisierte Projekt stellt, geschichtlich betrachtet, die erste virtuelle Maschine dar. Dabei lehnte sich das Prinzip an ein Multi-User-System an, welches mehrere Kopien von Single-User-Systemen in virtuellen Maschinen ausführt. Die darunter liegende Hardware wurde damit in den virtuellen Maschinen abstrahiert. Der Befehlssatz, ein weiteres essentielles Axiom der Virtualisierungsarchitektur, konnte in privilegierte und unprivilegierte Instruktionen differenziert werden. Ein weiterer Bestandteil dieser Architektur war das Aufteilen der Hardwareressourcen. Hierzu musste eine Instanz die Kontrolle übernehmen, welche dem heutigen „Virtuellen Maschinen Monitor“ (VMM), auch „Hypervisor“ genannt, gleichsteht.

Die Abstrahierung von physischen auf virtuelle Speicheradressen wurde durch die Implementierung einer virtuellen Speicherverwaltung realisiert. Die beschriebene Vorgehensweise

findet auch heute noch in modernen Betriebssystemen Anwendung.

Eine der ersten theoretischen Arbeiten zur Virtualisierung stellte Robert P. Goldberg mit seiner Doktorarbeit „Architectural Principles of Virtual Machines“ im Februar 1972 vor [2]. Darin wurden die grundsätzlichen Elemente einer virtuellen Maschine definiert und als effizientes Duplikat einer realen Maschine beschrieben. Die Verteilung der Ressourcen wird durch den „VMM“ reguliert. Darüber hinaus wurde zum Beispiel die Trennung der Befehls-sätze in sensitive und nicht-sensitive Instruktionen differenziert. Diese werden als solche vom „Virtuellen Maschinen Monitor“ behandelt oder direkt von der Hardware ausgeführt. Einen wichtigen Punkt bildet dabei die Isolation zwischen den virtuellen Maschinen. Es ist ungewiss, ob sich die Entwicklung der Virtualisierung ohne den formalen Beweis von Robert P. Goldberg ebenso vollzogen hätte. Ansätze zu dieser Konzeption finden sich auch in Aus-zügen der Arbeit „The evolution of virtual machine architecture“ von Ugo O. Gagliardi und J. P. Buzen, welche im Jahr 1972 verfasst wurde [3]. Weitere theoretische wissenschaftliche Arbeiten zur Thematik Virtualisierung folgten im Juli 1974 von Gerald J. Popek und Robert P. Goldberg mit der Ausarbeitung „Formal Requirements for Virtualizable Third Generation Architectures” [4].

Bis zum Jahr 1977 war eine virtuelle Maschine üblicherweise eine Kopie einer realen Maschine. Die von Kenneth Bowles entwickelte Pseudo-Maschine (P-Maschine) änderte diesen Zustand. Allerdings ist anzuführen, dass diese Maschine nie konzipiert wurde, jedoch theoretisch existieren kann. Das Prinzip der P-Maschine gründet sich auf die Entwicklung eines Emulators, der die Funktionalität anderer Rechenmaschinen nachbildet. Dabei konnten die Programme auf der Emulation ausgeführt werden. Zudem kann durch dieses Konzept Portabilität erreicht werden, womit solche Emulatoren für verschiedene Plattformen zur Verfügung stehen.

Die 1991 von Sun Microsystems Inc. (Santa Clara, USA) entwickelte und sehr verbreitete „Java Virtual Machine“ (JVM) agiert ähnlich der P-Maschine. Die JVM wird auf einem

realen Rechner emuliert, arbeitet aber direkt mit dem Java-Bytecode. Mit „Java Virtual Machine“ konnten erstmals die Vorteile des Maschinencodes mit dem Aspekt der interpretierten Sprachen verbunden werden. Dieses Konzept stellt heutzutage eine sehr effiziente und schnelle Emulation sowie eine sehr gute Portabilität dar. Konträr zur JVM konnte das 1997 entwickelte Konzept des JEM1-Mikroprozessors den Java-Bytecode ohne Emulation direkt verarbeiten. Dabei stellt die von Rockwell Collins Inc. (Cedar Rapid, USA) konzipierte

Methode eine so genannte „Java Real Machine“ dar. In Zukunft könnte es möglich sein, gänzlich auf Java Interpreter und Compiler zu verzichten, wodurch die Geschwindigkeit

erheblich verbessert wird [50].

Den nächsten entscheidenden Punkt in der Entwicklung der Virtualisierung stellt die im Jahr 1993 von Sun Microsystems Inc. vorgestellte Software „Wabi“ dar. Durch das „Windows Application Binary Interface“ konnte erstmalig Software ohne Veränderungen auf einem nicht proprietären Betriebssystem verwendet werden. Weiterhin war es möglich, Programme auf einer anderen Architektur als der ursprünglich geplanten einzusetzen. Dieser völlig neu-artige Virtualisierungsansatz konnte dabei Windows-Programme direkt unter dem Betriebssystem Solaris sowohl auf der x86- als auch auf der SPARC-Plattform (Scalable Processor ARChitecture) ausführen. Dazu war eine Zwischenschicht erforderlich, die Windows-Systemaufrufe interpretieren konnte. Auch wenn auf einem SPARC-Prozessor ein x86-Emulator verwendet wurde, konnte in einer x86-Architektur der restliche Code direkt ausgeführt werden. Es war folglich keine Emulation in der x86-Architektur erforderlich.

Einen ähnlichen Schritt in diese Richtung setze das im Jahr 1993 formierte Wine-Projekt (WINE Is Not an Emulator), welches ursprünglich unter der MIT-Lizenz veröffentlicht

wurde. Dabei war der Ansatz, Windows 3.1 Programme unter Linux auszuführen. Ein signifi-kanter Unterschied zu dem Konzept der Software Wabi ist die hier als Prämisse benötigte x86-Architektur. Diese ist ein Erfordernis, da keine Emulatorschicht verwendet wird. In-zwischen hat sich die Software so weit entwickelt, dass selbst Aufrufe in speziellen Bibliotheken unter Linux ohne Performanceverlust ausgeführt werden können. Zudem besteht in diesem Konzept die Möglichkeit, auf freigegebene Verzeichnisse oder Geräte zuzugreifen. Dabei ist eine Speichervirtualisierung notwendig, um Konflikte im gleichen Speicherraum zu verhindern sowie das unerlaubte Zugreifen in diesem zu unterbinden.

Der Programmierer Jeff Dike machte im Jahr 1999 mit seinem Linux Patch einen weiteren bedeutenden Schritt. Mit einem modifizierten Kernel des Linux-Betriebssystems war es nun möglich, diesen als unprivilegierten Prozess zu gestalten. Seine Entwicklung nannte er anschließend „User Mode Linux“ (UML). Mit UML konnten folglich mehrere Instanzen eines Linux-Betriebssystems gleichzeitig auf derselben Architektur ausgeführt werden. Dabei bietet diese Methode mehrere Vorteile. Zum einen entfällt eine umständliche Migration auf

einen dedizierten Testrechner und die Fehlersuche bei der Kompilierung von Programmen ist nun wesentlich einfacher zu gestalten. Zum anderen ist ein weiterer positiver Aspekt der

Kostenfaktor, da UML lizenzkostenfrei verwendet werden kann.

Im Jahr 1999 präsentierte „VMware“ (Palo Alto, USA) die „VMware Workstation“. Dies stellt einen weiteren Abschnitt in der Entwicklung der Virtualisierung dar. Dabei sorgte die von „VMware“ vorgestellte Virtualisierungslösung für große Aufregung in der Öffentlichkeit, da bis zum damaligen Zeitpunkt die Virtualisierung einer x86-Architektur als undenkbar galt. Dem sollte hinzugefügt werden, dass erstmalig unter dem Aspekt einer performanten Umgebung ein vollständiger x86-Computer auf einem anderen x86-System virtualisiert werden konnte. Neben einem BIOS (Basic Input Output System) kann die Virtualisierungslösung eigene virtuelle Hardware bereitstellen, die unter dem Einfluss bestimmter Restriktionen Verwendung findet. Es handelt sich bei diesem Programm um eine kommerzielle ge-schlossene Virtualisierungslösung.

2.2 Charakteristik einer virtuellen Maschine

In diesem Abschnitt werden die signifikanten Eigenschaften einer virtuellen Maschine zum besseren Verständnis gegliedert. Die Charakteristiken basieren auf den Entwicklungen der VM/370, der ersten virtuellen Maschine der Welt. Zudem werden einige der hier vorge-stellten theoretischen Ansätze in der Arbeit „ Architectural Principles of Virtual Machines“von Robert P. Goldberg beschrieben [3].

- Eine virtuelle Maschine ist das Abbild eines realen Systems. Der „Hypervisor“ generiert dabei die Umgebung der virtuellen Systeme. Das in einer virtuellen Maschine befindliche Programm soll sich ebenso verhalten wie in einem äquivalenten realen System [23].
- Der auf dem realen System eingesetzte „Hypervisor“ besitzt die Kontrolle über die virtuelle Maschine.
- Zwei Systeme sind identisch, wenn von diesen eine bijektive isomorphe Abbildung besteht. Von einer Kongruenz der Systeme (Duplikat) spricht man, wenn diese strukturgleich und umkehrbar eindeutig sind.
- Es können auf einer virtuellen Maschine mannigfache Betriebssysteme parallel respektive gleichzeitig auf einer isolierten Maschine verwendet werden.
- Mehrere Benutzer eines Systems können auf eine Maschine zugreifen. Dabei soll der Eindruck entstehen, dass die Nutzer einen exklusiven Zugriff auf das virtuelle System besitzen [22].
- Der Speicherbereich einer virtuellen Maschine bleibt dem jeweiligen System vorbehalten. Das heißt, keine Maschine kann auf den Speicherbereich der anderen zugreifen.

2.3 Prinzip der Virtualisierung

Das Axiom der Virtualisierung ist das Emulieren von identischen Ausführungsumgebungen. Mittels der Simulation werden alle internen Zustände eines Systems abgebildet. Emulation und Simulation beschreiben dabei völlig konträre Methoden [58]. Ein Simulator imitiert möglichst genau den internen Zustand des Systems, wie beispielsweise einen Algorithmus zur Abarbeitung von Instruktionen oder ein taktzyklengenaues Verhalten. Ein Emulator hingegen beachtet den internen Vorgang eines Systems nur soweit wie erforderlich [4]. Das heißt, für einige Funktionen sind Abkürzungen möglich, da dieser ergebnisorientiert arbeitet. Die Ausführungsumgebung kann aus mannigfachen Systemkomponenten wie Prozessoren, Festplatten oder Netzwerkkarten bestehen [48]. Die virtuell erzeugten Systeme existieren isoliert voneinander. Das Ziel einer Disjunktion ist das Ausführen von mannigfaltigen Betriebssystemen auf einer realen Rechnerarchitektur. Die virtualisierten Systeme existieren ohne die Erkenntnis virtualisiert zu werden.

2.4 Arten von Virtualisierungen

In der Virtualisierung existieren mannigfaltige Verfahren auf Softwareebene. In dem folgenden Kapitel wird in einem ersten Punkt auf die artverwandten Technologien eingegangen. Dies soll zum besseren Verständnis beitragen. Danach werden die essentiellen Ausprägungen der Virtualisierungstechnologie definiert. Eine in den Konzeptionen der Virtualisierung in-härente Unterteilung ist die Unterscheidung in Para-Virtualisierung, vollständige

Virtualisierung, Pre-Virtualisierung und Rekursive Virtualisierung. Aus dem Spektrum der Virtualisierung auf Softwareebene finden derzeit zwei Arten vermehrt Anwendung in den Virtualisierungslösungen und in der Industrie. Hier kann die Para-Virtualisierung und die vollständige Virtualisierung genannt werden.

2.4.1 Emulation

Grundsätzlich kann man die Emulation in zwei Teilbereiche differenzieren. Ein erstes Gebiet stellt dabei die Emulation einer „ Application Programming Interface“(API) dar, wobei der Sektor der Anwendungsprogramme fokussiert wird [6]. Gleichzeitig hat das Betriebssystem eine eher untergeordnete Existenz bei dieser Methode. Besteht also die Notwendigkeit, keine weiteren Betriebssysteme einzusetzen, ist nur die Emulation der API des zu verwendenden Betriebssystems erforderlich. Hierbei können die Anwendungsprogramme unter artfremder Architektur zum Einsatz kommen. Das Verfahren der Emulation einer API ist sehr per-formant, da nur Systemrufe übersetzt werden und eventuell erforderliche Bibliotheken verfügbar sind. Ein weiterer Vorteil ist, dass eine Kopie eines weiteren Betriebssystems entfällt, wodurch der Bedarf an Speicherressourcen minimiert wird. Ebenfalls ist der Erwerb von zusätzlichen Lizenzen weiterer Betriebssysteme nicht erforderlich. Diesen Vorteilen steht der Nachteil gegenüber, dass eine API-Übersetzung für jede Kombination von Host- und Gastsystemen existent sein muss. Weiterhin müssen die spezifischen Voraussetzungen der API Berücksichtigung finden. Das heißt, eventuelle Fehler in der API werden mit imitiert. Ein Vertreter für die Emulation einer API stellt das Programm „WINE“ dar. Dieses kann eine Win32 API unter Unix-Derivaten, wie beispielsweise Solaris, Linux und Irix implementieren. Dabei können unveränderte Win32 Codes mittels eines Program Loader, welcher sich in den Programmbibliotheken von „WINE“ befindet, ausgeführt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1: Darstellung einer API-Emulation

Einen zweiten Punkt bildet die Emulation einer kompletten Rechnermaschine. Dieses Konzept der Emulation korreliert dabei nahezu analog mit den Ansätzen zur Virtualisierung. Dabei wird mittels dieser Technik ein vollständiger Rechner in einer Datenstruktur imitiert und von der Emulationssoftware geeignet modifiziert. Einzig die Ein- und Ausgaben greifen auf die Ressourcen des Host Rechners zurück. Die emulierte Architektur kann dabei eine völlig andere sein als die, auf der die Emulation läuft, was einen weiteren Vorteil dieses Verfahren offenbart. Dazu werden alle Instruktionen der virtuellen Maschine durch einen eigenen Simulationscode in einer Emulationsumgebung ersetzt. Daraus folgt, dass die Hardwarekomponenten in Datenstrukturen abgebildet und mit Wirkung auf diese ausgeführt werden. Ziel einer solchen Emulation ist die Ausführung mannigfaltiger Betriebssysteme, sowie deren inhärente Anwendungsprogramme auf den unterschiedlichsten „Instruction Set Architecture“ (ISA) Schnittstellen [34]. Bei dem Vorgang der Emulation sind jedoch hohe Leistungs-verluste zu erwarten, da das Verfahren sehr langsam und aufwendig ist und jeder Befehl emuliert wird. Im Gegensatz dazu stellt dieses Verfahren höchstmögliche Flexibilität her. Als Beispiel hierzu ist die Software Java zu erwähnen, welche über die Laufzeitumgebungen mittels kompilierten Binärcodes ähnliche Flexibilität erzielt. Ein weiteres Beispiel dieser Art ist die portable x86-PC-Emulationssoftware Bochs [12]. Dieses in „C++“ geschriebene „Open-Source-Programm“ emuliert eine komplette Rechnerarchitektur, um beispielsweise Windows oder andere Betriebssysteme ausführen zu können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2: Darstellung der Emulation einer kompletten Rechnermaschine

2.4.2 Para-Virtualisierung

Bei der Thematik der Para-Virtualisierung wird sich eines Verfahrens bedient, welches Modifikationen am Gast-System vornimmt. Bei dieser Methode wird durch Anpassungen am Gast-Betriebssystemkernel und der Kompensierung von Schwachstellen der Virtualisierung der Leistungsverlust, der bei einer vollständigen Virtualisierung entsteht, gemindert [16]. Dabei werden das Einfügen von Emulations-Code zur Laufzeit, sowie das Erkennen sensitiver Instruktionen konträr zur vollständigen Virtualisierung vermieden. Das Gast-Betriebssystem kann b ei dem Verfahren der Para-Virtualisierung den Emulations-Code benutzen, welcher der „ Hypervisor“, der dabei als Interface dient, zur Verfügung s tellt. Dazu ist es erforderlich den Betriebssystemkernel des Gast-Systems so zu portieren, dass dieses den zugehörigen Emulations-Code des „Hypervisors“ aufrufen kann. Dies erfolgt beispielsweise, wenn in einem Gast-Betriebssystem auf ein Gerät zugegriffen wird. Als einen weiteren Aspekt unter der Optimierung, erlaubt es die Para-Virtualisierung, bestimmte Teile des „ Hypervisors“in den Adressraum des Gast-Betriebssystems zu verlagern. Somit kann der performance beanspruchende Wechsel von Gast zum „ Hypervisor“gemindert werden. Hinsichtlich dieser Methodik ist der Verlust der Leistungsfähigkeit von virtualisierten Systemen gegenüber den

realen Systemen nur als sehr gering zu bezeichnen. Diesen Vorteilen stehen aber auch Nachteile gegenüber, die im Folgenden ersichtlich werden. Obgleich man bei einer voll-ständigen Virtualisierung ein bestehendes System unverändert verwenden und konzipieren kann, ist bei der Para-Virtualisierung eine Portierung des Gast-Betriebssystemkernel auf eine virtuelle Maschine erforderlich. Die Modifizierung des Kernel stellt ein komplexes Verfahren dar, welches sehr zeit- und kostenintensiv ist. Abschließend ist anzuführen, dass die Systeme nur dann portiert werden können, wenn ein erforderlicher Quellcode vorhanden ist. Der bedeutendste Vertreter einer solchen Virtualisierungstechnologie ist „XEN“ [14].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3: Para-Virtualisierung mit „Hypervisor“ und modifizierten Betriebs-

systemkernel

2.4.3 Vollständige Virtualisierung

Die vollständige Virtualisierung, auch unter dem Namen „native Virtualisierung“ bekannt, ist derzeit die essentielle Determinante der Virtualisierung. Diese Konzeption korreliert weitestgehend mit der Definition einer virtuellen Maschine nach Robert P. Goldberg . Weiterhin kann aufgeführt werden, dass Modifikationen an bestehenden Betriebssystemen nicht erforderlich sind. Das Gast-Betriebssystem eines Host-Systems kann unverändert und ohne je-gliche Restriktionen im Hinblick auf die Virtualisierung eingesetzt werden. Einerseits werden bei dem Konzept der vollständigen Virtualisierung die Befehle nur partiell direkt auf der Hardware ausgeführt. Andererseits werden aber die Instruktionen auf der Virtualisierungsebene verarbeitet und tangieren somit nicht direkt mit der Hardware. Grundlegend müssen die „sensitiven Instruktionen“ als Erstes erfasst und ausgewertet werden. Danach erfolgt eine Generierung des Emulationscodes zur Laufzeit, welcher an Stelle der „sensitiven Instruktion“ ausgeführt wird. Durch diese Vorgehensweise können auf dem Host-System Betriebssysteme und deren inhärente Anwendungen ohne adaptive Modifikation in einer virtuellen Umgebung realisiert werden. Konträr dazu gestaltet sich die Thematik in Bezug auf die Integration einer neuen Hardware-Plattform. Um hierbei die Instruktionen sowie die Fähigkeiten einer neuen Hardware-Plattform zu unterstützen, müssen Modifikationen am „ Hypervisor“ durchgeführt werden .

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-4: Vollständige Virtualisierung mittels „Hypervisor“

Ein signifikanter Nachteil der vollständigen Virtualisierung ist die zu erwartende Per-formanceeinbuße, die sich durch die Erkennung, Auswertung von Instruktionen sowie dem Generieren und Einfügen von Emulationscode zur Laufzeit ergibt. Da das Erstellen und Integrieren vom Emulationscode durch den „Hypervisor“ realisiert wird, b ewirkt dies einen permanenten Wechsel im Hinblick auf dem „VMM“ und dem Gast-System. Die Konzeption der vollständigen Virtualisierung hält Einzug in der wohl bekanntesten Virtualisierungssoftware welche von „VMware“ [15] distributiert wird.

2.4.4 Pre-Virtualisierung

In diesem Abschnitt wird die Pre-Virtualisierung nur kurz angesprochen. Eine ausführliche Beschreibung findet sich im Kapitel „2.10 Stand der Entwicklung“. Die Pre-Virtualisierung stellt derzeit eine Verbreiterung der am Markt bestehenden Konzeptionen dar. Dieser neu-artige Ansatz der Virtualisierung verspricht Erfolge hinsichtlich der Verbesserung der Performance und einem weniger komplexen Aufwand zur Portierung von Systemen. Die

Forschungen für diese Art der Virtualisierung konzentrieren sich unter der Projektbezeichnung „L4Ka-Projekt“ der Universität Karlsruhe, welches gegenwärtig den Entwicklungsstand der Pre-Virtualisierung in der Welt definiert. Bei der Pre-Virtualisierung werden in einem halbautomatisierten Prozess die privilegierten Befehle vorab markiert und mit zusätzlichen Instruktionen versehen. Hierzu ist der Einsatz eines neu entwickelten Compilers notwendig.

2.4.5 Rekursive Virtualisierung

Die rekursive Virtualisierung beschreibt das Abbilden einer virtuellen Maschine auf sich selbst. Eine solche Konzeption ist nur dann möglich, wenn ein virtualisiertes System vollständig emuliert wird. Das Verfahren ist bei „QEMU“ (Paris, Frankreich), einem CPU-Emulator, durchaus denkbar, während es bei „VMware“ hinsichtlich der rekursiven Virtualisierung zu Problemen kommen kann. Die Rekursion einer Maschine kann auch als Virtualisierung einer virtuellen Maschine aufgefasst werden. Man spricht hier von einer „n-fachen“ Virtualisierung nach den rekursiven „f-Abbildungen“ von Robert P. Goldberg [24].

Die „f-Abbildungen“ beschreiben die Darstellung einer virtuellen Maschine mit ihren in-härenten Systemkomponenten auf der ihr unterliegenden Stufe. Die Abbildung der Systemressourcen sollte so trivial wie möglich konzipiert sein, um eine effiziente Ausführung bei

n-facher Abbildung von virtuellen Maschinen zu gewährleisten. Diese Prämisse ergibt sich durch die rekursive Darstellung der Systemkomponenten und des Prozessablaufs, welcher unikal je Durchführung angewendet wird. Im Gegensatz zur Betriebsmittelabbildung kann die Prozessabbildung aufgrund der Einmaligkeit dynamisch komplexer anwachsen. Die Betriebsmittelabbildung beschreibt die Darstellung von Systemkomponenten wie Prozessor, Speicher, Ein- und Ausgabegeräten durch Emulation. Die Prozessabbildung hingegen wird als Prozess für die Durchführung der Virtualisierung definiert. Zwischen den virtuellen Maschinen werden bei der Abbildung der Systemkomponenten einzelne Stufen der Betriebsmittelverteilung zur Verfügung gestellt. Im Gegensatz dazu werden bei dem Prozessablauf Privilegierungsstufen innerhalb einer einzelnen virtuellen Maschine verfügbar. Dieses Verfahren der rekursiven Virtualisierung unterscheidet signifikant zwischen der Abbildung der Systemkomponenten und dem Prozessablauf. Die größte Leistungsausbeute auf jeder Stufe der virtuellen Maschine ist das definierte Ziel einer solchen rekursiven Maschine. Als die wesentlichsten Charakteristiken bei der Entwicklung der rekursiven virtuellen Maschine werden die Flexibilität, Modularität und die Erweiterbarkeit der virtuellen Systeme fokussiert. Um die Problematik besser verstehen zu können und um die Bedeutung einer rekursiven Virtuali-sierung zu veranschaulichen, werden in den nachfolgenden Punkten einige Nachteile der konventionellen virtuellen Maschinen dargestellt.

- In den konventionellen virtuellen Maschinen gibt es nur Vater- und Sohnprozesse, die miteinander kommunizieren können. Im Unterschied dazu ist bei der rekursiven Virtualisierung die Möglichkeit der Kommunikation zwischen Großvater- und Enkelprozessen gegeben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-5: Exponentieller Slowdown durch die Emulation privilegierter

Befehle in einer konventionellen virtuellen Maschine

- Die Verringerung der Performance stellt sich in jeder Stufe der Rekursion ein, da sämtliche privilegierten Befehle aus der höheren Schicht empfangen und gleichzeitig emuliert werden. Dieser Slowdown steigt exponentiell zur Anzahl der verwendeten Stufen an. So muss zum Beispiel auf der n-ten Stufe der Virtualisierung, wie in Abbildung 2-5 zu sehen ist, der Befehl 2n-1 mal iteriert werden.
- Nicht alle Befehle eines Prozessors in der virtuellen Maschine können mit akzeptablem Einsatz zur Verfügung gestellt werden.

Die Architektur der rekursiven Virtualisierung ist angesichts der genannten Nachteile der konventionellen Virtualisierung bestimmten Änderungen unterworfen. Die exponentiell verlaufenden Leistungseinbrüche werden vermieden, indem in jeder Stufe der rekursiven Virtu-alisierung die vollständige Umgebung einer übergeordneten Stufe simuliert wird. Die Um-gebung umfasst alle Instruktionen, den Zugriff auf den Speicher sowie die Ein- und Ausgabegeräte. Dabei haben die Funktionen der rekursiven Virtualisierung „Border Control“ und „State Encapsulation“ einen exorbitant großen Einfluss [60]. Diese Eigenschaften sind

wichtig, um die Kontrolle über die Aktivitäten aller Sohnprozesse und deren Nachfolger zu bekommen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-6: Vergleich des konventionellen Prozessmodells mit dem rekursiven

Prozessmodell

Einen weiteren wichtigen Bestandteil des Konzeptes bilden die rekursiv virtualisierbaren Prozesse. Diese können im Vergleich zu den konventionellen Prozessen, wie in Abbildung

2-6 dargestellt, als logisch inhärent geschachtelte Objekte angesehen werden. So ist es zu verstehen, das man hier ebenfalls von einem Vater- und Sohnprozess spricht. Es ergibt sich eine rekursive Vorgänger-Nachfolger-Beziehung. Es sei zu erwähnen, dass ein Sohnprozess nicht mehr Zugriffsrechte als sein Erzeuger haben kann, sondern der Vaterprozess kann die Privilegien seiner Nachkommen weiter begrenzen. Ein Beispiel, bei dem die rekursive Virtualisierung zur Anwendung kommt, ist das von der Universität Utah entwickelte Betriebs-system „Flux“ (Salt Lake City, USA). Das System verwendet als Basis einen Mikrokernel und bedient sich der vertikalen und horizontalen Schichtung von virtuellen Maschinen [37].

2.5 Virtualisierung auf Hardwareebene

In diesem Kapitel erfolgt die Differenzierung der mannigfachen Konzepte der Hardwarevirtualisierung. In dem ersten Unterpunkt wird die Virtualisierung auf Prozessorebene besprochen und es wird auf die dafür notwendige Ringproblematik eingegangen. Danach werden die Konzeptionen des „Vanderpools“ von Intel und des „Pacificas“ von AMD besprochen. Die Speichervirtualisierung bildet den letzen Punkt dieses Kapitels.

2.5.1 Virtualisierung der x86-Architektur

In der x86-Architektur existieren verschiedene Modi, in denen der Zugriff auf spezifische Speicherbereiche erfolgt und spezielle Instruktionen ausgeführt werden. Der Modus mit den meisten Privilegien des Prozessors besitzt eine Vielzahl von Bezeichnungen. So ist dieser als „Supervisormodus“, „Current Privilege Level 0“ (CPL 0), „Kernel Mode“ oder auch

„Ring 0“ bekannt. In dieser höchsten Privilegierungsstufe befinden sich die konventionellen Betriebssysteme und die Gerätetreiber, wobei diese Zugriff auf alle Speicherbereiche erhalten [8]. Im „Supervisormodus“ dürfen die „privilegierten Befehle“ ausgeführt werden. Die Privilegierungsstufen „Ring 1“ und „Ring 2“ finden in den Betriebssystemen nur wenig Verwendung und werden daher nicht weiter besprochen. Im wichtig zu betrachtenden „Nutzermodus“ respektive „User Mode“ befinden sich die immanenten Applikationen der Betriebssysteme. In diesem „nicht privilegierten Modus“, der auch als „Ring 3“ bezeichnet wird, verfügen die Anwendungsprogramme über sehr wenige Rechte, was in Abbildung 2-7 dargestellt wird. So ist es zu erklären, dass ein „privilegierter Befehl“, der von einem Programm ausgeführt werden soll, an das Betriebssystem im „Ring 0“ weitergereicht wird. Würden mehrere Betriebssysteme parallel zueinander ausgeführt, käme es zu erheblichen Problemen. Aus den genannten Gründen ist die Virtualisierung in der x86-Architektur nur sehr schwer möglich.

Abbildung in dieser Leseprobe nicht enthaltenAbbildung 2-7: Privilegierungsstufen der x86-Architektur

2.5.1.1 Virtualisierung auf Prozessorebene

Die Virtualisierung der Prozessoren bildet den wichtigsten Bestandteil der Hardwarevirtualisierung. Gründe für die Entwicklung waren die negativen Aspekte der Virtualisierung auf Softwareebene, die nachfolgend aufgeführt werden. Aus den ständigen Kontextwechseln bei Systemaufrufen zwischen dem „Hypervisor“ und den virtuellen Maschinen resultieren

Performanceverluste. Ein weiterer signifikanter Nachteil ist, dass sich die Gast-Systeme und deren Anwendungen auf derselben Ebene der Priorität befinden. Außerdem sind die Betriebssysteme auf den „Supervisormodus“ programmiert worden, welche sich jedoch nach der Softwarevirtualisierung im „Ring 1“ oder „Ring 3“ der Privilegierung befinden.

Aus den genannten Nachteilen wurde die Virtualisierung auf Basis des Prozessors fokussiert. Als einen wichtigen Grund dafür kann die immense Effizienzsteigerung der Virtualisierung auf Prozessorebene gegenüber der Softwarevirtualisierung genannt werden. Einen weiteren Vorteil bilden die Betriebssysteme, welche sich nun im „Supervisormodus“ befinden. Zudem können die virtuellen Maschinen ohne Retardation ausgeführt werden. Isoliert voneinander ist es möglich, virtuelle Systeme auszuführen. Bei einem Schaden oder bei einem Virenbefall der Systeme können diese einfach entfernt werden ohne andere Betriebssysteme zu beeinflussen. Um auf den Aspekt der CPU eingehen zu können, müssen zuvor formale Grundlagen beschrieben werden. Exorbitant wichtig ist die Gruppe der Instruktionen, die ein Prozessor erhält. Die Befehle können in einem ersten Unterscheidungskriterium in „privilegierte Be-fehle“ und „unprivilegierte Befehle“ differenziert werden. Erst genannte Befehle lösen einen so genannten „Trap“ aus. Das heißt, Instruktionen, die auf Basis der Hardware abgefangen werden können, bezeichnet man als „privilegierte Befehle“, alle verbleibenden Befehle sind als „unprivilegierte Befehle“ zu kennzeichnen. Die „privilegierten Befehle“ müssen in der CPU im „Nutzermodus“ abgefangen und im „Supervisormodus“ bearbeitet werden. Dadurch dürfen virtuelle Maschinen sich nie im „Ring 0“ befinden. Der „Hypervisor“ kontrolliert, ob ein Befehl direkt auf der CPU ausgeübt werden darf. Zudem ist es notwendig, nach einem „Trap“ einen „Exception Handler“ befehligen zu können, um weitere Schritte zur Behandlung der Ausnahme durchzuführen [49]. Der besprochene „Handler“ muss einen „Dispatch“ (siehe Kapitel „2.8.1 Funktionsweise des Hypervisors“) ausführen, um den „privilegierten Befehl“ zu emulieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-8: Zeitliche Betrachtung eines „Exception Handlings“

Tritt eine Ausnahme ein, wird der „Exception Handler“ aktiviert. Dieser speichert als erste Maßnahme den aktuellen Zustand. Dann erfolgt ein Wechsel (auch als Sprung bekannt) in den „Supervisormodus“. Im Anschluss daran wird der „Exception Handler“ ausgeführt, wobei dieser die Ausnahme behandelt. Danach wird der besprochene „Handler“ beendet und der Zustand wiederhergestellt [49]. Damit ein „privilegierter Befehl“ abgefangen werden kann, sind des Weiteren mindestens zwei Modi von einem Prozessor zu unterstützen. Zum einen der schon bekannte „Nutzermodus“ und zum anderen der „Supervisormodus“. Im letzteren befinden sich entweder das Host-System oder der „Hypervisor“ je nach der Art der Virtualisierung. Im „Nutzermodus“ agieren die virtuellen Maschinen und deren immanente Applikationen.

Die Differenzierung von „sensitiven Befehle“ und „nicht-sensitive Befehle“ bildet ein zweites Unterscheidungskriterium der Instruktionen [9]. Unter „sensitiven Befehlen“ versteht man Instruktionen, die den Zustand eines Betriebssystems oder einer virtuellen Maschine ver-ändern können. In der Virtualisierung dürfen solche Befehle niemals direkt auf dem Prozessor verarbeitet werden, da ansonsten die virtuellen Maschinen den Status ihrer Isolation verletzen würden. Dies führt dazu, dass sich die virtuellen Systeme gegenseitig beeinflussen und sich zum Absturz bringen könnten. Ein solches Szenario würde zudem das Goldberg-Popek-Theorem verletzen, welches die Axiome der Virtualisierung manifestiert. Es ist es notwendig, jeden „sensitiven Befehl“ mittels eines „Trap“ zu erfassen und auszuwerten. Jeder „sensitive Befehl“ der mittels Hardware „Trap“ abgefangen werden kann, ist zugleich auch ein „privilegierter Befehl“. Danach werden die genannten Instruktionen im „Hypervisor“ emuliert. Dies wird durch Generierung des Emulationscodes zur Laufzeit realisiert, welcher an Stelle der „sensitiven Befehle“ ausgeführt wird. Anzumerken sei noch, dass alle „nicht-sensitiven Befehle“ direkt an die CPU weitergeleitet und ausgeführt werden können. Zudem ist anhand der Privilegierungsstufen eine perfekte Virtualisierung nicht möglich.

Nach den Axiomen des Goldberg-Popek-Theorems stellt sich der Idealfall ein, wenn die „sensitiven Befehle“ eine Untermenge der „privilegierten Befehle“ bilden (wie in Abbildung 2-9 dargestellt).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-9: Gegenüberstellung des „Goldberg-Popek-Theorems“ und einer nicht-

virtualiserbaren x86-Architektur

Des Weiteren besteht in der konventionellen x86-Architektur die Möglichkeit, dass bei der Ausführung von „sensitiven Befehlen“ kein „Trap“ ausgelöst wird. Wie in Abbildung 2-9 rechts deutlich zu sehen ist, kann dies bei „unprivilegierten Befehlen“ auftreten, die einige „sensitive Instruktionen“ enthalten. Bei den Befehlssätzen des Intel Pentium Prozessors tritt dieser Fall ein. Da kein „Trap“ ausgelöst wird, ist der „Hypervisor“ nicht in der Lage, die „privilegierten Befehle“ zu emulieren [35]. Einzig mit dem „Prescan Verfahren“ ist es möglich, die Instruktionen zu erkennen. Das auch als „Scan Before Execution” (SBE) bezeichnete Verfahren ist die Ursache, weshalb die Virtualisierung auf Prozessorebene als aufwendig gilt. Der „Hypervisor“ hat bei dem „Prescan Verfahren“ bedeutend Mehrarbeit zu leisten. Die „sensitiven“ und zudem „unprivilegierten Befehlen“ müssen vor ihrer Ausführung abge-fangen werden. Dazu ist die Überprüfung der Instruktionen notwendig. Aus dem Grund, dass virtuelle Maschinen nicht deterministisch sind, wird dies zur Laufzeit realisiert. Der „Hypervisor“ sucht während des „Prescans“ nach „sensitiven Befehlen“, die nicht vom Prozessor abgefangen werden können. Hierzu wird vom „VMM“ eine Befehlspfadverfolgung durchgeführt. Identifiziert der „Hypervisor“ die „sensitiven Instruktionen“, substituiert er diesen Befehl durch eine „Interrupt 3 Instruktion“ (INT 3) [6]. Bei diesem „privilegierten Befehl“ wird ein „Interrupt“ ausgelöst. Bei dem Erreichen einer solchen Stelle während der Laufzeit, übergibt der Prozessor anschließend die Kontrolle an den „Hypervisor“, der die „INT 3 Instruk-tion“ behandelt.

Weiterhin kann es bei ringabhängigen Instruktionen zu Problemen kommen. Diese verändern ihr Verhalten abhängig von der Privilegierungsstufe. Die ringabhängigen Befehle können vom Prozessor mittels „Trap“ nicht erfasst und abgefangen werden. Die einzige Möglichkeit diese Art der Befehle zu identifizieren, ist über das „Prescan Verfahren“. Eine weitere

Kategorie von Befehlen, die zu Komplikationen führen, sind die konfigurierbaren Instruk-tionen. Ihr Verhalten wird von bestimmenden Zuständen verändert. Die konfigurierbaren Instruktionen werden einerseits privilegiert ausgeführt und können somit abgefangen werden. Andererseits ist es erforderlich, diese durch das „Prescan Verfahren“ zu lokalisieren [11].

Aus den vorangegangenen Punkten ergeben sich für die Virtualisierung folgende Prämissen:

- Eine Erfassung von „sensitiven Befehlen“ sowie die Emulierbarkeit dieser muss gewährleistet sein.
- Mindestens zwei Modi müssen von der CPU unterstützt werden. Einerseits der „Nutzermodus“, in dem die privilegierten Instruktionen erfasst werden können. Andererseits der „Supervisormodus“, in dem Befehle bearbeitet werden.

Um die nachfolgenden Thematiken des „Vanderpools“ und des „Pacificas“ besser zu verstehen, werden die Modi des konventionellen x86-Prozessors erläutert. In der x86-Architektur existieren drei Betriebsarten. Der erste Modus ist der „Real Mode“ (RM), welcher auch unter dem Begriff „Real Address Mode“ bekannt ist. In diesem Modus besteht kein Zugriffsschutz, wodurch Applikationen den gesamten Hauptspeicher nutzen und auf die Hardware zugreifen können. Dieser Nachteil ist für heutige „Multitask-Systeme“ nicht erstrebenswert. Daher befinden sich fast alle herkömmlichen Betriebssysteme im „Protected Mode“ (PM). In diesem zweiten Modus können mehrere Programme gewissermaßen parallel zueinander ausgeführt werden. Des Weiteren wird zur Realisierung des Speicherschutzes das „Paging“ angewendet. Isoliert von anderen kann jeder Prozess in einem eigenen virtuellen Adressraum existieren. Zugleich ist es möglich, zwischen den Operationen eine gemeinsame Speichernutzung zu realisieren. Zudem erfolgt im „Protected Mode“ die Differenzierung zwischen „Supervisor-“ und „Nutzermodus“. Als dritter und letzter Modus der konventionellen x86-Prozessoren ist der „Virtual Mode 8086“ (VM86) zu nennen. Da im „Real Mode“ immer noch viele Programme verwendet werden, ist diese spezielle Erweiterung in den Prozessoren implementiert. Bei dem VM86 besteht die Möglichkeit, RM-Programme in PM-Betriebssystemen auszu-führen, ohne diesen Modus verlassen zu müssen. Die Modi „Real Mode“ und „Virtual Mode 8086“ werden heutzutage nur noch aus Gründen der Kompatibilität angeboten.

2.5.1.2 Intel Vanderpool

Der folgende Vergleich wird die Prozessorvirtualisierung zwischen den Virtualisierungslösungen „Intel Vanderpool“ und der „AMD Pacifica“ betrachten. Die Prozessoren wurden um zusätzliche Befehlssätze erweitert, um die Konventionen des Goldberg-Popek-Theorems zu erfüllen.

Bei dem Konzept des „Vanderpools“ (auch „Intel Virtualization Technology“ genannt),

welches von Intel (Santa Clara, USA) entwickelt wurde, verfolgt man die Virtualisierung auf Prozessorebene durch die Erweiterung auf zehn neue Befehlssätze [41]. Diese Art neuer Instruktionen bezeichnet Intel als „Virtual Machine Extensions“ (VMX). Weiterhin wurde die neue Datenstruktur „Virtual Machine Control Structur" (VMCS) eingeführt, welche für die Wechsel in und aus dem „VMX Non-Root Modus“ verantwortlich ist.

In dieser Struktur wird zum einen festgelegt, welche Befehle im Gast-System ausgeführt werden, wenn dieses unterbrochen wird. Zum anderen wird in der VMCS der Status des „Hypervisors“ und des Gast-Systems gesichert und wieder aufgerufen. Der Zugriff erfolgt mittels der beiden Befehle „VMREAD“ und „VMWRITE“ [9].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-10: Darstellung der „Virtual Machine Control Structur“

Der „Gast-Status“ beschreibt den Zustand des Prozessors vom Gast-System vor und nach der Aktivierung. Hingegen wird im „Host-Status“ der Status der vom „Hypervisor“ verwendeten CPU beschrieben. Die Sicherung des Zustandes erfolgt wie im „Gast-Status“ vor und nach der Aktivierung [61]. Zudem besitzt die Funktion „VM Execution“ die Kontrolle zur Aus-führung des Gast-Systems. Bei einem Wechsel zum „VMX Root-Modus“ werden im Feld „VM Exit Information“ der Grund des Rücksetzens sowie zusätzliche Informationen vom Gast-System an den „Hypervisor“ übermittelt. In den Feldern „VM Exit“ und „VM Entry Kontroll“ wird das Verhalten des Gast-Systems festgelegt [47].

Durch den „Hypervisor“ kann der „VMX Modus“ mittels dem Setzen des Bit 13 im „Control Register 4“ (CR4) des Prozessors aktiviert werden. Die Frage, ob die „Virtualization Technology“ im vorhandenen Intel Prozessor existiert, kann durch Auslesen der „Central Processing Unit Identification“ (CPUID) beantwortet werden. Ist das Bit 5 des „Extended Count

Registers“ (ECX Register) auf 1 gestellt, wird der „VMX Modus“ unterstützt [5]. Benutzen lässt sich dieser Modus durch den Befehl „VMXON“, welcher vom „VMM“ initialisiert wird.

Durch das Kommando „VMXOFF“ kann der „VMX Modus“ wieder abgeschaltet werden. Die „Virtual Machine Extensions“ Befehle lassen sich in zwei Arten unterteilen, den „VMX Root-Modus“ und den „VMX Non-Root Modus“ [40]. Im erst genannten Modus agiert der „Hypervisor“, welcher die vollständige Kontrolle über die Hardware besitzt. Im „VMX Non-Root Modus“ hingegen befinden sich die virtuellen Maschinen. Die Befehle im „VMX Root-Modus“ bezeichnen die Zugriffe vom „Hypervisor“ ausgehend, während bei dem „VMX Non-Root Modus“ die Instruktionen aus den virtuellen Maschinen erfolgen [61]. Die Gast-Systeme befinden sich dabei im „Ring 0“ der Privilegierungsstufe. Die virtuellen Maschinen registrieren folglich nicht ihre eigene Virtualisierung. Zugleich agiert der „Hypervisor“ im „Ring -1“, eine neuen Privilegierungsstufe [42]. Der „VMM“ befindet sich also in einem höheren Level der Privilegierung. Vorteilig ist diese Eigenschaft vor allem für Softwareentwickler, da sich die Gast-Systeme nun im „Supervisormodus" befinden. In diesem Modus existieren gewöhnlich die konventionellen Betriebssysteme. Dem „Hypervisor“ ist es möglich, mit „VM Entries Befehlen“ den Prozessor in dem „VMX Non-Root Modus“ arbeiten zu lassen. Dadurch bekommt das Gast-System die Kontrolle. Die Ausführung von „privile-gierten Befehlen“ bedeutet zugleich einen Wechsel in den „VMX Root Modus“. Der

„Hypervisor“ kann verifizieren, ob die „privilegierten Befehle“ legitim sind. Die Rückführung in den „VMX Root-Modus“ lässt sich durch die „VM Exit Befehle“ erzwingen. Der „Hypervisor“ erhält wieder die vollständige Kontrolle über die Hardware [61].

Derzeit gibt es zwei Ausprägungen der „Vanderpool Technologie“. Zum einen ist die „Virtualization Technology for IA-32 x86-Architecture“ (VT-x) und zum anderen die „Virtuali-zation Technology for Itanium-Architecture“ (VT-i) zu nennen. Der erst genannte Aufbau wurde für die konventionelle x86-Architektur gestaltet. Die VT-i Architektur findet bei den Itanium Prozessoren Anwendung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-11: Kontextwechsel auf Prozessorebene unter zeitlichem Gesichtspunkt

Ein trivial dargestellter Kontextwechsel wird in Abbildung 2-11 gezeigt. Im ersten Schritt wird durch den Befehl „VMXON“ der „VMX Modus“ aktiviert. Danach wird die „ Virtual Machine Control Structur 1" (VMCS 1) a ngewählt. Im nächsten Vorgang wird durch den „VM Entry Befehl“ die Kontrolle an das Gast-System übergeben. Der „Hypervisor“ erhält die Befehlskontrolle durch die Operation „VM Exit“ im letzten Schritt zurück. Das Gast-System übergibt die Kontrolle freiwillig mittels des Befehls „VM Call“ an den „VMM“. Durch das Kommando „VMXOFF“ kann der „VMX Modus“ deaktiviert werden.

2.5.1.3 AMD Pacifica

Einen weiteren Ansatz zur Virtualisierung auf Prozessorebene bietet AMD mit dem

„Pacifica“. Bei diesem Konzept, welches auch unter dem Namen „Secure Virtual Machine Architecture“ bekannt ist, wurden neun weitere Befehlssätze in den Prozessor implementiert. Diese von AMD als „Secure Virtual Machine“ (SVM) bezeichneten neuen Instruktionen

agieren nach den gleichen Axiomen wie die „Virtualization Technology“ von Intel. Außerdem wurde eine neue Datenstruktur mit der Bezeichnung „Virtual Machine Control Block“ (VMCB) implementiert, welche den Kontextwechsel in und aus dem „Gast-Modus“ reguliert [46]. Durch Setzen des Bit 12 im EFER-MSR-Register kann der „Hypervisor“ den „SVM Modus“ aktivieren. Wie schon bei der „Vanderpool Technologie“ besitzt der „Hypervisor“ die vollständige Kontrolle über die ihm unterliegende Hardware. Über die CPUID-Funktion kann im „Extended Accumulator Register“ (EAX Register) die SVM-Unterstützung des AMD Prozessors ausgelesen werden.

Die SVM-Befehlssätze lassen sich durch das Kommando „VMRUN“ verwenden, wobei die CPU in den „Gast-Modus“ wechselt. Dieser ist vergleichbar mit dem von Intel propagierten „VMX Non-Root Modus“. Die Rückführung aus dem „Gast-Modus“ wird mittels des Kommandos „#VMEXIT“ durchgeführt. Im „Gast-Modus“ agieren die Gast-Betriebssysteme mit der Privilegierungsstufe „Ring 0“. Wie schon bei der „Vanderpool Technologie“ wird die Virtualisierung der Systeme vom Betriebssystem nicht erkannt und der „Hypervisor“ befindet sich im „Ring -1“. Eine sichere und einfachere Verwaltung der Prozessorressourcen wird durch dem „Pacifica“ ermöglicht. Die SVM-Befehlssätze erleichtern des Weiteren das

„Exception Handling“ der CPU. Zudem kann der „Hypervisor“ mit Unterstützung des

„Pacificas“ einfacher konzipiert werden. Da der „VMM“ aufgrund der SVM-Befehle kleiner zu dimensionieren ist und weniger Ressourcen in Anspruch nimmt, können zusätzliche

Leistungsverluste vermieden werden.

Konträr zur Konzeption des „Vanderpools“ gestaltet sich die Virtualisierung des Speicher Controllers. Die „Virtualization Technology“ von Intel bietet nur eine Lösung auf Softwareebene an, woraus entsprechende Performanceeinbrüche resultieren. Jede konventionelle virtuelle Maschine befindet sich in einem eigenen Adressbereich, der durch den „Hypervisor“ kontrolliert wird. Die Adressanfragen eines Gast-Systems werden vom „VMM“ behandelt und entsprechend auf den realen Adressraum zugewiesen. Eine erneute Umleitung über den „Hypervisor“ erfolgt dann bei dem Auslesen von Instruktionen im realen Speicher. Die genannten Vorgänge werden im „Pacifica“ durch den neuen Speicher-Modus „Nested Paging“ mit den „Nested Page Tables“ (NPT) realisiert. Dieser Modus agiert auf Grundlage einer neuen Übersetzungsschicht, allerdings erfolgen die Vorgänge auf Basis realer Hardware. Dadurch ist der Speicher-Modus „Nested Paging“ leistungsfähiger als die Virtualisierungs-lösung des „Vanderpools“. Die Kontrolle über den Hauptspeicherbedarf besitzt der "Memory Management Unit" (MMU), welcher den Programmen den gewünschten Hauptspeicher zuteilt.

Eine zusätzliche Erweiterung wurde mit dem „Device Exclusion Vector“ (DEV) in dem

„Pacifica“ implementiert. In der „Secure Virtual Machine Architecture“ reguliert der DEV die „Direct Memory Access“ (DMA) Zugriffe in den virtuellen Maschinen. Des Weiteren kann ein Schutzmechanismus vor Zugriffen in den physikalischen Speicher in Bezug auf DMA-fähige Geräte in Anspruch genommen werden.

Außerdem anzuführen gilt der neue „Paged Real Mode“ des „Pacificas“. Mit Hilfe des Modus kann der „Real Mode“ des Prozessors virtualisiert werden. Bei der Variante des

„Vanderpools“ sind virtuelle Maschinen im „Real Mode“ nicht ausführbar. Eine Emulation des genannten Modus durch den „Hypervisor“ ist notwendig, um die virtuellen Maschinen dennoch zu unterstützen. Im Gegensatz dazu können Programme im „Real Mode“ auf dem „Pacifica“ verwendet werden. Durch „Paging“ des „Real Modes“ ist eine Emulation des Modus nicht mehr erforderlich, was sich entsprechend positiv auf die Performance auswirkt.

2.5.2 Virtualisierung des Speichers

Kaum ein Thema ist so hoch zu bewerten, wie die Virtualisierung des Speichers unter dem Aspekt der Hardwarevirtualisierung. Bedeutungsvoll ist dies vor allem für die virtuellen Systeme, welche einen eigenen virtuellen Speicherbereich erhalten müssen. Die Virtualisierung des Speichers wird in diesem Abschnitt kurz umrissen.

Der Arbeitsspeicher ist die einzige Systemkomponente, welche für die Virtualisierung ent-wickelt wurde [54]. Die Idee der Speichervirtualisierung wurde 1961 von John Fotheringham (New York, USA) erstmalig publiziert [56]. In seiner Abhandlung über den Arbeitsspeicher des ATLAS Computers wird eine Applikation beschrieben, welche mehr Speicher benötigt, wie der zur Verfügung stehende Hauptspeicher beinhaltet. Um Konflikte zu vermeiden, sind die aktuell erforderlichen Bestandteile eines Programms im physischen Speicher zu halten, die verbleibenden werden nach Bedarf eingefügt. Außerdem besteht die Möglichkeit, dass ein Zugriff auf eine Speicherseite erfolgen kann, welche sich im Auslagerungsspeicher und nicht im Hauptspeicher befindet. Um diese Methodik zu realisieren ist es erforderlich, ein zweistufiges Adressensystem zu konzipieren, welches aus den Segment- und Seitentabellen definiert wird. Zudem wurde die Notwendigkeit der Einführung eines zusätzlichen Adressraumes erkannt. Bei der doppelten Adressübersetzung werden so genannte „Shadow Tables“ verwendet. Diese Tabellen bilden die virtuellen Adressen der virtuellen Systeme auf den realen physischen Adressraum ab. Die virtuellen Adressen werden von der „Memory Management Unit“ (MMU) in physische Adressen konvertiert [51]. Essentiell wichtig bei der Virtualisierung des Speichers ist die Kontrolle über die „Speicher Deskriptor Tabellen“. Den virtuellen Systemen darf diese Tabelle nicht bekannt sein, da die inhärenten Informationen die Zuordnung der virtuellen auf die physischen Adressen enthalten. Würde ein Zugriff von einem Gast- und einem Host-System auf die „Speicher Deskriptor Tabellen“ zur selben Zeit erfolgen, käme es unweigerlich zu einem Konflikt. Ebenfalls müssen die „Globale Deskriptor Tabelle“ (GDT) und die „Lokale Deskriptor Tabelle“ (LDT) virtualisiert werden. Die letztgenannte Tabelle ist wichtig für den Speicherschutz, da die „LDT“ als Grundlage zur

Isolation von Tasks verwendet wird. Außerdem ist es notwendig, dass jedem virtuellen System eine eigene „Interrupt Deskriptor Tabelle“ (IDT) zugeteilt wird. Die „IDT“ kann vom

„Hypervisor“ gelesen und beschrieben werden.

Wie das Prinzip der Adressübersetzung detailliert funktioniert, wird in der Abbildung 2-12 dargestellt. Nicht abgebildet ist der Speicherschutz, welcher von der „Memory Management Unit“ bereitgestellt wird. Einzelne Speicherbereiche können durch die von der „MMU“ ausgehenden Restriktionen die Ausführung von Prozessen implizieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-12: Schematische Darstellung des Konzepts zur Virtualisierung des Speichers

Der in Abbildung 2-12 links dargestellte virtuelle Adressraum des Gast-Systems wird mittels der Segmentierung in den linearen Adressraum konvertiert [57]. Die Segmentierung ist ein eindimensional funktionierender Mechanismus, wodurch eine weitere Stufe eines Adressraums notwendig wird. Durch den „Paging Mechanismus“ können die Adressen im linearen Adressraum in virtuelle physische Adressen überführt werden. Dieser Adressraum stellt für die virtuellen Systeme den physischen Adressraum dar. Die Gast-Systeme sind nicht in der Lage, den virtuellen physischen Adressraum als virtualisiert zu identifizieren. Eine virtuelle physische Adresse impliziert eine virtuelle physische Seitenrahmennummer und zusätzlich den Offset einer Seite [52]. Dieser kann von der realen Seite (Page) entnommen werden und beginnt wie bei dem realen physischen Adressraum bei Null [53]. Die Seitenrahmennummer wird verwendet, um Einträge in die „Page Table“ (Seitentabelle) zu referenzieren. Das heißt, in der besagten Tabelle sind die Zuordnungen zwischen den linearen und den korrespondierenden virtuellen physischen Adressen definiert. Zudem erhält jedes virtuelle System seine eigene „Deskriptor Tabelle“, um somit nur auf den eigenen Speicherbereich Zugriff zu erhalten. Damit die Adressen aus den virtuellen physischen Adressraum in den realen physischen Adressraum übersetzt werden, ist eine weitere Stufe der Konvertierung notwendig. Diese muss vom „Hypervisor“ bereitgestellt werden, da in der konventionellen x86-Architektur nur zwei Stufen der Adressübersetzung unterstützt werden. In dieser letzten Stufe wird die „Page Table“ eingesetzt, um die virtuellen physischen Adressen den korrespondierenden realen physischen Adressen zuzuordnen. Die realen physischen Adressen werden in Offset und

Seitenrahmennummer unterteilt [51].

Ein wesentlicher Nachteil bei der Verwendung von virtuellem Speicher ist die Konvertierung von virtuellen auf die physischen Adressen. Eine Beschleunigung der Adressübersetzung kann durch den Einsatz eines „Translation Lookaside Buffer“ (TLB) erzielt werden. Dieser Übersetzungspuffer, welcher eine vergleichbare Funktionsweise eines Caches aufweist, ist als eine Einheit der „MMU“ des Prozessors anzusehen. Der „TLB“ beschleunigt die Aus-führung von Speicherzugriffen außerordentlich, da bei jedem Zugriff von einem Gast-System auf den virtuellen Speicher verifiziert wird, ob der „Translation Lookaside Buffer“ diese

Adresse in einer Tabelle gespeichert hat. Die Granulität der Speicherung kann dabei ganze Speicherseiten umfassen. Liegt die Speicherung vor, kann die virtuelle der physischen

Adresse anschließend sofort zugeordnet und zur Verfügung gestellt werden.

2.6 Problematik der Softwarevirtualisierung

Wie im Kapitel „2.5.1 Virtualisierung der x86-Architektur“ erwähnt, stehen dem Prozessor vier Privilegierungsstufen zur Verfügung. Die Betriebssysteme befinden sich im „Super-visormodus“ und deren inhärente Programme im „Nutzermodus“. Um eine Softwarevirtualisierung in der x86-Architektur auszuführen, ist ein geschicktes Vorgehen erforderlich.

Als ersten Schritt ist es notwendig, einen „Hypervisor“ in das System zu implementieren. Der „VMM“ befindet sich im „Ring 0“ und besitzt jederzeit die vollständige Kontrolle über das System [9]. Im nächsten Schritt wird das Betriebssystem deprivilegiert. Es befindet sich folglich in einer geringeren Privilegierungsstufe als zuvor. Wird ein Befehl vom Betriebssystem ausgeführt, der beispielsweise die Priorität „Ring 0“ besitzt, so löst dieser im Prozessor einen „Trap“ aus. Nachfolgend wird der Befehl vom „Hypervisor“ behandelt und zur Laufzeit emuliert. Gegenüber der konventionellen x86-Architektur lässt sich der Verlust der Performance aufgrund der Generierung von Emulationscode in einem virtualisierten System auf etwa 40 % beziffern [47].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-13: Privilegierungsstufen nach der Virtualisierung

[...]