Virtualisierung von Betriebssystemen (z.B. VMWare) unter Windows 10


Hausarbeit, 2017

16 Seiten, Note: 1,5


Leseprobe

Inhaltsverzeichnis

I Abbildungsverzeichnis

II Abkürzungsverzeichnis

1 Virtualisierung Allgemein
1.1 Typ-1 und Typ-2-Hypervisioren
1.2 Virtualisierung der x86-Architektur
1.3 Virtualisierung auf Prozessorebene
1.4 Speichervirtualisierung
1.5 Ein- / Ausgabevirtualisierung

2 Virtualisierung mit VMware
2.1 Allgemein
2.2 Verschachtelte Virtualisierung - Windows 10

3 Literaturverzeichnis

I Abbildungsverzeichnis

Abbildung 1: Platzierung der Typ-1- und Typ-2-Hypervisoren

Abbildung 2: Schutzringe und ihre Rechte

Abbildung 3: Umsetzung einer virtuellen in eine physikalische Adresse

Abbildung 4: Anbindung der MMU

Abbildung 5: Obere Komponente des VMM von VMware (ohne HW-Unterstützung)

Abbildung 6: Die VMware Hosted Architecture und ihre drei Komponenten

Abbildung 7: Unterschiede zwischen normalen Kontextwechsel und World Switch

Abbildung 8: Schematischer Aufbau verschachtelter Virtualisierung

II Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Virtualisierung Allgemein

1.1 Typ-1 und Typ-2-Hypervisioren

Generell wird zwischen zwei verschiedenen Möglichkeiten der Virtualisierung unterschieden, wie es erstmals Popek und Goldberg[1] 1974 aufgezeigt haben. Die erste Möglichkeit der Virtualisierung ist der Hypervisor 1 (siehe Abbildung 1, links). Der Typ-1-Hypervisor ist das einzige Programm, welches mit den höchsten Privilegien läuft, und entspricht damit nach technischen Aspekten dem Betriebssystem. Ähnlich den Prozessen, die auf einen normalen Betriebssystem laufen, unterstützt dieser mehrere Kopien der realen Hardware, sogenannte virtuelle Maschinen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Platzierung der Typ-1- und Typ-2-Hypervisoren[2]

Der Typ-2-Hypervisor, manchmal auch gehostetet Hypervisor genannt, arbeitet gegenüber dem Typ-1-Hypervisor auf eine andere Art und Weise. Ähnlich einem gewöhnlichen Prozess belegt und ordnet dieser Ressourcen zeitlich zu, wie ein Benutzerprogramm das beispielsweise auf Windows oder Linux basiert. Weiterhin simuliert der Typ-2-Hypervisor, ein vollständiger Rechner mit einer CPU und diversen Geräten zu sein. Dennoch müssen sowohl der eine als auch der andere Hypervisortyp den Befehlssatz der Maschine auf sichere Art ausführen. So ist es beispielweise möglich, dass das Betriebssystem, welches oberhalb des Hypverisors läuft, seine eigenen Seitentabellen verändern oder sogar durcheinanderbringen kann, allerdings nicht die Tabellen von anderen. Bei beiden Hypervisoren wird das Betriebssystem, das oberhalb von diesen läuft, Gast-Betriebssystem genannt (siehe Abbildung 1). Beim Typ-2-Hypervisor ist zwischen ihm und der Hardware das Gastgeber-Betriebssystem. Die VMware Workstation war der erste Typ-2-Hypvervisor auf dem x86-Markt.[3]

1.2 Virtualisierung der x86-Architektur

Aufgrund des Designs der x86-CPUs von Intel und AMD, muss die Virtualisierungsschicht einige Befehle abfangen, die vom Gastsystem an die CPU gesendet werden. Privilegierte CPU-Instruktionen dürfen ausschließlich vom zuerst gestarteten Betriebssystem verwendet werden, damit dieses über später gestartete Anwendungen die Kontrolle behält. Es existieren verschiedene Modi in der x86-Architektur, die sich beim Zugriff auf besondere Speicherbereiche und spezifische Instruktionen unterscheiden. Der Aufbau bzw. die Einteilung der verschiedenen Berechtigungsstufen innerhalb eines Prozessors ist in Abbildung 2 dargestellt. Die meisten Privilegien besitzt der Ring 0, Supervisormodus, Current Privilege Level 0 (CPL0) oder aber auch Kernel Mode genannt. In dieser höchsten Privilegierungsstufe erfolgt über die konventionellen Betriebssysteme und Gerätetreiber der Zugriff auf alle Speicherbereiche und Interrupts (Clear Interrupts und Set Interrupts), d.h. hier erfolgt die Ausführung der privilegierten Befehle. Im Ring 1 und Ring 2 arbeiten beispielsweise Betriebssystemtreiber. Im Ring 3 oder auch Nutzermodus respektive User Mode, befinden sich die immanenten Applikationen der Betriebssysteme. Anwendungen verfügen in dieser Ebene über sehr wenige Rechte. Dieser Modus wird daher auch als nicht privilegierter Modus bezeichnet. Ein privilegierter Befehl eines Programms wird an den Ring 0 eines Betriebssystems weitergeleitet. Es gibt bei den meisten x86 Kernels, drei Hauptfunktionen die es im Ring 0 zu schützen gilt. Den Speicher, Input/Outputs und die Möglichkeit bestimmte Befehle in der Maschinensprache, auch Assembler genannt, auszuführen. Es kommt zu schwerwiegenden Problemen, wenn mehrere Betriebssysteme parallel zueinander ausgeführt werden. Aus diesen Gründen ist die Virtualisierung in der x86-Architektur besonders schwer möglich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Schutzringe und ihre Rechte4

1.3 Virtualisierung auf Prozessorebene

Ein besonders wichtiges Differenzierungskriterium der Instruktionen eines Prozessors sind die privilegierten und unprivilegierten Befehle. Erstere sind solche, bei denen Instruktionen auf Hardwareebene abgefangen werden können. Alle weiteren werden als unprivilegierte Befehle bezeichnet. Privilegierte Befehle haben die Möglichkeit Traps auszulösen, eine Art Interrupt die durch die Software initiiert wird. Sie dienen dazu, relevante aber seltene Bedingungen innerhalb der Software zu bearbeiten, wie zum Beispiel die Division durch Null.

Die privilegierten Befehle werden in der CPU im Nutzermodus selektiert und im Supervisormodus modifiziert. Die Selektion findet mit den privilegierten Befehlen in der CPU im Nutzermodus statt und die Modifikation im Supervisormodus, d.h. die virtuellen Maschinen laufen ausschließlich außerhalb vom Ring 0. Die Aufgabe des Hypervisors ist die Überprüfung der Befehlsausführung auf der CPU. Der Exception-Handler dagegen bekommt nach einem Trap den Befehl, bei Ausnahmen weitere Schritte durchzuführen. Der aktuelle Zustand wird als allererstes gesichert und anschließend in den Supervisormodus gewechselt, auch Sprung genannt. Die Ausführung eines Dispatch erfolgt durch den Handler, ebenso die Emulierung von privilegierten Befehlen. Zur Beendigung des Handlers wird der ursprüngliche Zustand wiederhergestellt. Die Emulierung des privilegierten Befehls muss durch ein Dispatch vom Handler erfolgen. Für die Unterstützung werden mindestens zwei Modi von einem Prozessor benötigt, diese sind der Nutzermodus und der Supervisormodus. Im ersteren sind die virtuellen Maschinen und ihre immanenten Applikationen aktiv. Abhängig von der Art der Virtualisierung befindet sich im Supervisormodus das Host-System oder der Hypervisor. Die Instruktionen unterscheiden sich auch von sensitiven und nicht sensitiven Befehlen. Sensitive Befehle sind Instruktionen, die eine Veränderung des Betriebssystemzustands oder der virtuellen Maschinen verursachen. Dabei ist zu beachten, dass die Befehle der virtuellen Maschine nicht direkt auf dem Prozessor ausgeführt werden, ansonsten würde der Status der Isolation der virtuellen Maschinen verloren gehen. Es kann unter Umständen zu einem Systemabsturz kommen, wenn sich diese gegenseitig stark beeinflussen. Mit Hilfe der Traps wird jeder sensitive Befehl erfasst und ausgewertet. Jeder sensitive Befehl, der von einem Trap abgefangen wird, ist ebenfalls ein privilegierter Befehl. Die Emulierung der genannten Instruktionen erfolgt im Anschluss durch den Hypervisor, durch die Erzeugung des Emulationscodes zur Laufzeit, der anstatt der sensitiven Befehle ausgeführt wird. Zudem werden alle nicht-sensitiven Befehle direkt an die CPU weitergereicht und bearbeitet.

Bei der x86-Architektur kann es bei der Abarbeitung von sensitiven Befehlen vorkommen, dass kein Trap ausgelöst wird. Dies kann unter Umständen geschehen, wenn unprivilegierte Befehle einige sensitive Instruktionen enthalten, wie es beispielsweise bei den Befehlsätzen der Intel Pentium Prozessoren zutrifft. Die privilegierten Befehle können aufgrund des fehlenden Traps nicht vom Hypervisor emuliert werden. Nur durch das Prescan oder Scan Before Execution Verfahren ist es möglich, solche Instruktionen zu erkennen. Dies gilt aber auch als Grund für die aufwendige Virtualisierung auf Prozessorebene. Die Ursache dafür liegt in der deutlichen Mehrarbeit, die vom Hypervisor bei dem Prescan Verfahren geleistet werden muss. Bei jeder Ausführung von sensitiven und zugleich privilegierten Befehlen müssen diese vor der Ausführung abgefangen werden und eine Überprüfung der Instruktionen erfolgen.

Probleme können auch bei ringabhängigen Instruktionen auftauchen, da deren Verhalten von der Priviligierungsstufe abhängig ist. Diese können nicht durch Traps erfasst und abgefangen werden, sondern ausschließlich mittels Prescan-Verfahren ermittelt werden. Eine ebenfalls kritische Befehlskategorie die zu Problemen führen kann sind die konfigurierbaren Instruktionen, die abhängig von bestimmten Zuständen ihr Verhalten ändern. Durch deren privilegierte Ausführung können diese zwar abgefangen werden, erfordern jedoch für die Identifizierung im Vorfeld das Prescan-Verfahren. Für die Virtualisierung entstehen damit einige Bedingungen die erfüllt werden müssen. Zum einem muss die Erfassung von sensitiven Befehlen, aber auch deren Emulierung sichergestellt sein. Zum anderem müssen von der CPU sowohl der Nutzermodus für die Erfassung von privilegierten Instruktionen, wie auch der Supervisormodus für die Bearbeitung der Befehle gegeben sein.

1.4 Speichervirtualisierung

Zur Konfliktvermeidung werden momentan notwendige Bestandteile einer Applikation im physischen Speicher gehalten, während die übrigen nur bei Bedarf eingefügt werden. Zudem gibt es die Option, dass der Zugriff auf eine Speicherseite erfolgen kann, die sich nicht im Haupt- sondern im Auslagerungsspeicher befindet. Um diesen Mechanismus umsetzen zu können, ist ein zweistufiges Adressensystem notwendig, welches sich aus Segment- und Seitentabellen zusammensetzt. Zudem ist ein weiterer Adressraum notwendig.

Für die doppelte Adressübersetzung werden Shadow Tables verwendet, welche die virtuellen Adressen der virtuellen Systeme auf den realen physischen Adressraum abbilden. Die Konvertierung der virtuellen in physische Adressen wird durch die Memory Management Unit (MMU) umgesetzt (vgl. Abbildung 4). Die Umsetzung von einer virtuellen in eine physikalische Adresse ist in Abbildung 3 erkennbar. Hier wird die virtuelle Seitenummer für den Index der Seitentabelle getrennt. Die physikalische Adresse setzt sich aus den Einträgen des Offsets der virtuellen Adresse sowie der Indexstelle zusammen. Unabdingbar bei der Virtualisierung des Speichers, ist die Kontrolle über die Speicher Deskriptor Tabellen. Diese Tabellen müssen gegenüber den virtuellen Systemen verborgen bleiben, da diese inhärente Informationen über die Zuordnung der virtuellen auf die physischen Adressen enthalten. Bei zeitgleichem Aufruf auf die Speicher Deskriptor Tabellen von einem Gast- und einem Host-System, würde es unvermeidlich zu einem Konflikt kommen. Zudem müssen die lokale Deskriptor Tabelle (LDT) und die globale Deskriptor Tabelle (GDT) virtualisiert werden. Die LDT ist essentiell für den Speicherschutz, da diese als Fundament zur Isolation von Tasks herangezogen wird. Weiterhin ist es erforderlich, dass jedem virtuellen System eine eigene Interrupt Deskriptor Tabelle (IDT) zugewiesen wird, die vom Hypervisor gelesen und beschrieben werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Umsetzung einer virtuellen in eine physikalische Adresse5

Durch die Segmentierung in den linearen Adressraum wird der virtuelle Adressraum vom Gast-System konvertiert. Da dies ein eindimensionaler Modus ist, wird ein zusätzlicher Adressraum erforderlich. Der Paging Mechanismus ermöglicht die Überführung von Adressen aus dem linearen Adressraum hinein in die virtuellen physischen Adressen. Gast-Systeme können allerdings den virtuellen physischen Adressraum nicht als virtualisiert identifizieren.

Eine virtuelle physische Adresse erfordert eine virtuelle physische Seitenrahmennummer sowie den Offset einer Seite, der von der realen Seite entnommen werden kann und wie bei dem realen physischen Adressraum bei null beginnt. Die Zuordnung zwischen den linearen und den entsprechenden virtuellen physischen Adressen ist innerhalb der Seitentabelle definiert, die ihre Einträge aus der Seitenrahmennummer erhält. Damit jedes virtuelle System ausschließlich auf seine eigenen Speicherbereiche zugreifen kann, erhält jedes System zusätzlich seine eigene Deskriptor Tabelle. Desweiteren ist eine zusätzliche Stufe der Konvertierung notwendig, um Adressen aus dem virtuellen physischen in den realen physischen Adressraum zu übersetzen. Da es in der x86-Architektur nur zwei Stufen der Adressübersetzung gibt, muss diese vom Hypervisor angeboten werden. Um die virtuellen physischen Adressen zuzuordnen, wird in diesem finalen Schritt die Page Tabelle eingesetzt.

Abbildung 4: Anbindung der MMU[6]

Die Unterteilung von realen physischen Adressen erfolgt in Seitenrahmennummern und Offsets. Ein großer Nachteil, der sich bei der Nutzung von virtuellem Speicher ergibt, ist die Konvertierung von virtuellen auf physische Adressen. Die Effizienz der Adressübersetzung kann durch die Verwendung eines Translation Lookaside Buffer (TLB) gesteigert werden. Dieser Übersetzungspuffer ist als Einheit der MMU vom Prozessor zu sehen und weist die gleiche Arbeitsweise wie die eines Caches auf. Die Speicherzugriffszeiten werden mittels TLB effizient gesteigert, da das Gast-System bei jedem Zugriff auf den virtuellen Speicher verifiziert, ob der TLB diese Adresse in einer Tabelle gespeichert hat. Sobald eine Speicherung vorliegt, kann die virtuelle der physischen Adresse daraufhin umgehend zugeordnet und zur Verfügung gestellt werden.

[...]


[1] Popek, G. J./Goldberg, R. P., Formal requirements for virtualizable third generation architectures, 1974, Vgl. S. 413

[2] Tanenbaum, A. S., Moderne Betriebssysteme, 2016, S. 581

[3] Bugnion, E. u. a., Bringing Virtualization to the x86 Architecture with the Original VMware Workstation, 2012

[4] Fertig, A., Rechnerarchitektur Grundlagen, 2016, Vgl. S.208

[5] Fertig, A., Rechnerarchitektur Grundlagen, 2016, Vgl. S.204

[6] Fertig, A., Rechnerarchitektur Grundlagen, 2016, Vgl. S.209

Ende der Leseprobe aus 16 Seiten

Details

Titel
Virtualisierung von Betriebssystemen (z.B. VMWare) unter Windows 10
Hochschule
Steinbeis-Hochschule Berlin
Note
1,5
Autor
Jahr
2017
Seiten
16
Katalognummer
V373646
ISBN (eBook)
9783668509610
ISBN (Buch)
9783668509627
Dateigröße
512 KB
Sprache
Deutsch
Schlagworte
virtualisierung, betriebssystemen, vmware, windows
Arbeit zitieren
David Dederer (Autor), 2017, Virtualisierung von Betriebssystemen (z.B. VMWare) unter Windows 10, München, GRIN Verlag, https://www.grin.com/document/373646

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Virtualisierung von Betriebssystemen (z.B. VMWare) unter Windows 10



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden