9.2 Virtuelle Maschinen

9.2 Virtuelle Maschinen
Zur Erinnerung (1.3):
Virtuelle Maschine (virtual machine, VM) entsteht durch
vollständige Virtualisierung einer realen Maschine
Linux
Windows
...
Linux
VS
Hardware
bs-9.2
Minix
Mehrere virtuelle Maschinen
 mit potentiell verschiedenen
Gastsystemen (evtl. auch VS!)
 Virtualisierungssystem (VS)
(Virtual Machine Monitor,
VMM, Hypervisor)
1
Was bringt die Virtualisierung?






Z.B. Linux und Windows auf einem Rechner;
allgemein weniger - dafür größere - Maschinen,
damit potentiell bessere Auslastung der Hardware
und weniger Aufwand für Wartung und Administration.
Isolation und damit mehr Sicherheit und Zuverlässigkeit.
BS-Entwicklung: Test neuer oder modifizierter Systeme!
Insgesamt:
Verringerung der sog. total cost of ownership (TCO)
Nachteile: 



bs-9.2
"zurück zum Großrechner"
Hardware ist unverhältnismäßig teuer
geringere Flexibilität bzgl. Erweiterung
Effizienzverluste?
2
Präzisierung des Begriffs Virtuelle Maschine:

Äquivalentes Verhalten: die virtuelle Maschine hat
die gleichen Ressourcen wie die reale Maschine,
wenngleich kleinere (Speicher) und/oder weniger
(Peripherie, Prozessoren). (Abgrenzung: JVM, CIL, ...)

Ressourcen-Aufteilung: der VMM versorgt jede
virtuelle Maschine mit einem bestimmten Anteil an
den Hardware-Ressourcen, und keine VM hat beliebigen
Zugriff auf diese Ressourcen.

Keine Emulation: von wenigen Ausnahmen abgesehen
wird jeder von einer virtuellen Maschine ausgeführte
Befehl direkt von der realen Maschine ausgeführt.
(Abgrenzung: Bochs, ... )
bs-9.2
3
Verwandte Prinzipien:
 Paravirtualisierung
 VS als Prozess
 Server-Virtualisierung
 und andere . . .
 9.2.4 ff.
bs-9.2
4
Die Idee ist mehr als 30 Jahre alt:
CP-67
("control program") für IBM System/360-67 (1969!);
als CP/CMS mit Einplatzsystem CMS für Teilnehmerbetrieb eingesetzt, später VM/370 genannt
( S/390, zSeries) (9.2.3)
z/VM
Nachfolger von VM/370 für die aktuelle
Großrechner-Familie IBM zSeries
VMware
VMware WSX für Intel x86 (1999) (9.2.4)
Xen
realisiert Paravirtualisierung für x86 (2003) (9.2.5)
und zahlreiche weitere . . .
bs-9.2
5
Terminologie:
Gastsystem (guest system)
ist ein Betriebssystem, das in einer virtuellen
Maschine läuft.
Virtualisierungssystem (Virtual Machine Monitor, VMM)
ist die virtualisierende Software, die zwischen
der Hardware und den Gastsystemen liegt.
Hypervisor
ist ein Synonym für VMM und drückt aus, dass
damit die Gastsysteme überwacht werden, so wie
der Supervisor (Systemkern) eines Gastsystems
die dortigen Benutzerprozesse überwacht.
bs-9.2
6
Information:
J. E. Smith, R. Nair: Virtual Machines. Morgan Kaufmann 2005
IEEE Computer May 2005 (Themenheft)
Wikipedia (englisch!): http://en.wikipedia.org/wiki/Virtualization
u.v.a.
bs-9.2
7
9.2.1 Funktionsweise
 VS läuft im Systemmodus, VM läuft im Benutzermodus!
VM speichert für jedes VS:  Prozessorzustand (mit MMU)
und  Abbildung virtuelle Peripherie  reale Peripherie
 virtueller Alarm = realer Alarm  Alarmbehandlung im VS:
Rückkehr zur VM, und zwar zur Behandlungsroutine des BS
bs-9.2
VS
BS
Hardware
Hardware
analog zu:
Alarmbehandlung durch
Benutzerprogramm
8
 virtueller privilegierter Befehl
im virtuellen Benutzermodus (= realer Benutzermodus)
 realer Alarm  Alarmbehandlung im VS (wie oben)
 virtueller privilegierter Befehl
im virtuellen Systemmodus (= realer Benutzermodus!)
 realer Alarm  Alarmbehandlung im VS emuliert den Befehl!
(dies kann Spooling implizieren!)
VS
Hardware
bs-9.2
9
 realer Eingriff  Eingriffsbehandlung im VS
simuliert virtuellen Eingriff bei zugehöriger* VM:
gespeicherten Maschinenstatus entsprechend ändern
unter Berücksichtigung des Inhalts der virtuellen
Unterbrechungsadresse (interrupt location) des BS ;
sobald die VM wieder zum Zug kommt, beginnt sie
mit der Behandlung des virtuellen Eingriffs .

VS
Hardware
bs-9.2

*
"zugehörige VM":
VS hatte sich gemerkt,
für welche VM das Gerät
gestartet worden war
10
 Rückkehr einer VM
vom virtuellen Systemmodus (= realer Benutzermodus!)
zum virtuellen Benutzermodus (= realer Benutzermodus!)
mit virtuellem privilegiertem Befehl
 Emulation dieses Befehls durch VS (wie auf S. 9)
Aber: Was tun bei einer Maschine, bei der dieser Befehl
nicht privilegiert ist?
Oder bei einer Maschine, bei der es andere
nicht privilegierte Befehle gibt, die sensible
Systemregister (zwar nicht ändern, aber:)
lesen können?
bs-9.2
11
9.2.2 Virtualisierbare Hardware
Def.: Eine Rechnerarchitektur heißt virtualisierbar,
wenn sie die Konstruktion eines VMM zulässt.
Achtung:
Nicht jede Hardware ist virtualisierbar,
und manche Hardware ist "schwerer"
virtualisierbar als andere!
Fundamentale Erkenntnisse:
G.J. Popek, R.P.Goldberg: Formal requirements for virtualizable
third-generation architectures. Proc. 4. ACM Symp. on Operating
System Principles. Ferner in: Comm. ACM, July 1974
bs-9.2
12
9.2.2.1 Virtualisierbarkeit nach Popek/Goldberg
Hardware-Modellierung:





Arbeitsspeicher
Prozessor
Prozessor-Modus (user oder supervisor)
einfache MMU (base und length)
Alarme: Speicherschutz, privilegierter Befehl
Def.: Ein Maschinenbefehl heißt privilegiert,
wenn er im Benutzermodus einen Alarm auslöst,
im Systemmodus aber nicht.
Beispiel:
bs-9.2
LPSW
auf IBM System/360
13
Def.: Ein Maschinenbefehl heißt steuerungssensitiv,
(control sensitive), wenn er Modus oder MMU
verändern kann (ohne dass ein SpeicherschutzAlarm die Ursache wäre).
Beispiele: LPSW
POPF
auf IBM System/360 (privilegiert)
auf IA-32 (nicht privilegiert):
lädt das EFLAGS-Register bei CPL 0;
bei CPL 3 aber werden etliche Flags
stillschweigend ignoriert (z.B. IF) !
Wenn POPF also von einem Gast-BS
in einer VM ausgeführt wird (mit CPL 3 !),
verhält es sich anders als wenn es von
diesem BS auf der realen Maschine
ausgeführt wird.
bs-9.2
14
Def.: Ein Maschinenbefehl heißt verhaltenssensitiv,
(behaviour sensitive), wenn sein Verhalten von der
MMU (d.h. seiner Lage im Speicher) oder vom Modus
abhängt (auch lagesensitiv bzw. modussensitiv).
Beispiele: MOV AX,CS auf IA-32 (nicht privilegiert):
liest vom Code Segment Register
ins Register AX - und kann damit
den CPL erfragen.
BS-Code in der VM erhält hierbei den
CPL 3, in der realen Maschine aber 0
(oder 1 oder 2).
bs-9.2
15
Satz: (Popek/Goldberg)
Eine Rechnerarchitektur ist virtualisierbar,
wenn alle sensitiven Operationen privilegiert sind.
Achtung: dies ist hinreichende, nicht notwendige Bedingung!
Beispiele:
IBM System/360
Motorola 68020
Gegenbeispiel: Intel x86, IA-32/64: Virtualisierung möglich,
aber schwierig  HW-Modifikationen?
J.S. Robin, C.E. Irvine: Analysis of the Intel Pentium’s Ability to Support a
Secure Virtual Machine Monitor. Proc. Usenix 2000.
bs-9.2
16
9.2.2.2 Intel VT
Geänderte x86-Hardware:
VT (virtualization technology, auch "Vanderpool", 2005)
als VT-x für IA-32 und VT-i für IA-64 (Itanium)
Virtual Machine Extension (VMX) unterscheidet zwischen
root operation mode
non-root operation mode
≈ x86, für VS
= virtuelle x86, für VMs
(Folgerung: keine rekursive Virtualisierung möglich)
http://en.wikipedia.org/wiki/X86_virtualization
http://developer.intel.com/technology/itj/2006/v10i3/1-hardware/1-abstract.htm
bs-9.2
17
Hardware-Erweiterungen:
VMCS - Virtual Machine Control Structure für eine VM
auf bestimmter (realer!) Adresse besteht aus 2 Teilen:
guest-state area
host-state area
(für BS)
(für VS)
für die Aufnahme der Zustände der entsprechenden
Systemregister.
Übergang rootnon-root rettet Zustand nach host-state area
und lädt Zustand aus guest-state area.
Übergang non-rootroot rettet umgekehrt.
Außerdem erweiterter Befehlssatz für root operation.
bs-9.2
18
9.2.3 Klassische Virtualisierung
Die IBM-360-Architektur ist virtualisierbar!
CP-67 ("control program") ist ein VS für die 360-67,
zusammen mit dem Einbenutzersystem CMS
(Cambridge Monitor System) eingesetzt als
Teilnehmersystem CP/CMS (typisch: 30 Benutzer)
Einschränkung: MMU des Modells 360-67 wird
benutzt, aber nicht virtualisiert. (Viele 360Modelle haben gar keine MMU!)
bs-9.2
R.A. Meyer, L.H. Seawright: A virtual machine time-sharing system.
IBM Systems Journal, Sept. 1970.
http://www.research.ibm.com/journal/sj/093/ibmsj0903D.pdf
19
9.2.3.1 IBM CP-67
bs-9.2
20
360-Architektur:
bs-9.2

Benutzermodus und Systemmodus

MMU für virtuellen Speicher (Option, modellabhängig)

Ein/Ausgabe über programmierbare Kanäle,
angestoßen durch privilegierten E/A-Befehl SIO

typische Peripherie der 60er/70er Jahre,
einschließlich zeichenorientierter Datenstationen
21
 Jedem Benutzer des CP gehört eine eigene virtuelle Maschine.
Typisch für die Benutzung mit CMS: Prozessor, 256 KB
Arbeitsspeicher, 2 Plattenlaufwerke, 1 Operateur-Konsole,
1 Drucker, 1 Lochkartenleser.
 Benutzerverwaltung des CP führt
Name, Passwort, Konfiguration der virtuellen Maschine.
 Erfolgreiches Einloggen bei CP erzeugt virtuelle Maschine.
Der Benutzer ist der Operateur dieser Maschine!
 Anschalten der virtuellen Maschine mit Laden/Starten eines BS:
Befehl initial program load, z.B. IPL CMS
(CP hält einige BSe vor, mnemonisch benennbar).
Danach Operateur/Benutzer-Befehle des jeweiligen BS.
bs-9.2
22
Beachte:
Über die Konsole werden zwei Arten von Interaktionen
abgewickelt:
 Interaktionen mit dem BS
 Interaktionen mit der virtualisierten Hardware:
"virtuelle Tasten" (z.B. IPL), "virtuelle Anzeigen"
In den Zustand  gelangt man u.a. durch IPL,
in den Zustand  durch eine spezielle Taste an der Datenstation.
Ausgewählte weitere "virtuelle Tasten" im Zustand :
BEGIN
LOGOUT
DISPLAY
...
bs-9.2
Übergang nach 
Abschalten der VM
Registerinhalte der VM anzeigen
23
Verwaltung des CP
 durch "realen" Operateur (der realen Maschine)
 mit eigener Befehlssprache
 in privilegierter Verwaltungs-VM
bs-9.2
24
Hardware
Virtualisierung
Jahr
360-67
CP/CMS
370
VM/370
1972 ("Virtual Machine Facility")
Weiterentwicklung des CP/CMS,
rekursive Virtualisierung
370/XA
VM/XA
bs-9.2
1969
≈ 1985 ("Extended Architecture")
(32-Bit-Architektur)
25
390
VM/ESA
1990 ("Enterprise Systems A.")
neuer Maschinenbefehl SIE - start interpretive execution beschleunigt die Emulation im CP;
ferner leistungsfähigeres CMS (Multitasking, ...)
zSeries
z/VM
angepasst
z9
z/VM
2005
auch Paravirtualisierung (9.2.4) für Linux
bs-9.2
2000
(64-Bit-Architektur)
26
9.2.4 Paravirtualisierung
bedeutet: Gast-Systeme sehen eine verbesserte Hardware
Beispiel:
Flag für enable/disable interrupt nicht in
Systemregister, sondern in spezieller Speicherzelle!
 sogar ohne Intervention des Hypervisor umsetzbar!
Nachteil:
Gast-Systeme müssen portiert werden
Vorteile:
 anwendbar für die nichtvirtualisierbare x86-Architektur,
 effizienter als dynamische Code-Umwandlung (9.2.5)
 Ressourcen-Garantien für die beteiligten Systeme (QoS)
bs-9.2
27
Prominente Vertreter:
Denali (Univ. of Washington, 2002)
Xen (Univ. of Cambridge, 2003)
Xen
leistet Paravirtualisierung für x86, IA-64, Power 5 für
(bisher) portierte Betriebssysteme Linux und Windows XP



bs-9.2
P. Barham et al.: Xen and the Art of Virtualization.
Proc. 19. ACM Symp. on Operating System Principles, 2003
http://www.cl.cam.ac.uk/research/srg/netos/xen
http://www.xensource.com/
28
Architektur:
CPL
Benutzer
Benutzer
Benutzer
Control
Software
3
XenoLinux
XenoXP
(XenoBSD)
XenoLinux
1
Xen Hypervisor
0
x86-Maschinen
bs-9.2
29
Interaktion zwischen Supervisor und Hypervisor :
Hypercall
 Aufruf des Hypervisor
 durch Systemaufruf-Instruktion ( Alarm),
 ersetzt sensitiven Befehl (in portiertem BS-Code!)
Event
 Benachrichtigung eines Supervisor
 von Geräte-Unterbrechung,
 ersetzt HW-Unterbrechung,
 ist realisiert wie SW-Unterbrechung in Einzelsystem
bs-9.2
30
Interaktion zwischen Benutzer und Supervisor :
Alarme (Systemaufruf, Fehler – außer Seitenfehler)
 werden direkt vom Supervisor behandelt,
 weil Xen die Unterbrechungsvektoren so einrichtet,
 wie ihm vom Supervisor beim Start mitgeteilt wurde
Seitenfehler: Die verursachende Adresse befindet sich im
Register CR2 – and dieses ist nur über eine
privilegierte Instruktion erreichbar! Daher:
 Xen übernimmt, speichert CR2 im Keller des BS
 und überlässt danach dem BS die Behandlung
bs-9.2
31
Zur Virtualisierung der Prozessoren:
 Parameter der Zuteilung von Prozessorzeit an die
Gastsysteme einstellbar über die Control Software
 Ablaufsteuerung bevorzugt System, das gerade
aufgeweckt wurde (damit zeitkritische Aktionen
nicht verzögert werden *)
* z.B. TCP basiert seine Einschätzung der Netzgeschwindigkeit
auf den Antwortzeiten der Quittungen!
bs-9.2
32
Zur Virtualisierung der Uhren:
 Jedes Gastsystem hat eigene virtuelle Geräte für
Realzeit (!), eigene virtuelle Zeit (bleibt stehen bei
Inaktivität) und Uhrzeit, ferner 2 Wecker – für
Realzeit und virtuelle Zeit
bs-9.2
33
Zur Virtualisierung von Seitentabellen und MMU:
 Es gibt keine Unterscheidung zwischen „virtuellen Seitentabellen“
eines Gastsystems und „realen Seitentabellen“ des Hypervisor
 Gastsystem liest die realen, vom Hypervisor verwalteten
Seitentabellen – kann sie aber nicht direkt verändern.
 Seitentabellen können nur über Hypercall modifiziert werden.
bs-9.2
34
 Unterscheidung zwischen hardware memory und physical memory:
letzteres ist der aus Sicht des Gastsystems reale, physisch
zusammenhängende Speicher, in Wirklichkeit aber der von Xen
angebotene virtuelle Speicher, dessen Seiten gestreut liegen.
 Beim Start eines Gastsystems wird ihm von Xen ein bestimmter
Anteil am realen Speicher (nicht notwendig zusammenhängend)
zugesichert.
 Dieser Anteil kann auf Wunsch des Systems (in Grenzen)
vergrößert bzw. verkleinert werden.
bs-9.2
35
Zur Virtualisierung der Ein/Ausgabe:
 Einfache Hypervisor-Schnittstelle für E/A
(geräteunabhängige Block-E/A, USB-E/A etc.).
 Daher keine komplizierten Treiber bei den Gastsystemen.
 Xen-Treiber laufen mit CPL 1 - was Xen vor fehlerhaften
Treibern schützt.
bs-9.2
36
9.2.5 Dynamische Code-Umwandlung
(dynamic recompilation)
 Die "sensitiven Stellen" im Code des Gastsystems
werden direkt vor ihrer Ausführung geeignet modifiziert.
 Das dafür zuständige VS wird nicht auf der nackten
Maschine, sondern samt Gast-BS in einem normalen
Benutzerprozess eines Gastgeber-BS ausgeführt!
("hosted virtual machine architecture")
zur Erinnerung: klassisches VS
VS
BS
bs-9.2
VS
37
...
...
read(file,buf,len);
Gast-BS
Systemaufruf wird emuliert:
Sprung ins Gastsystem: E/A-Befehl
für virtuelle Platte;
VS
E/A-Befehl wird emuliert:
read(disk,...)
Systemaufruf für Gastgeber-BS
Gastgeber-BS
E/A-Befehl für reale Platte
HW
Vorteile:
einfache Installation und Verwaltung
Nachteil:
Effizienzverluste
Beispiele: VMware Workstation für x86 unter Windows, Linux, Mac OS
MS Virtual PC für x86 unter Windows
bs-9.2
38
9.2.5.1 VMware Workstation
 VS überwacht den Ablauf des Gastsystems:
der Code wird fragmentweise so modifiziert, dass er
zwar größtenteils nicht-emuliert abläuft (Effizienz!),
regelmäßig aber immer wieder zum VS zurückkehrt.
 VS kümmert sich nur um denjenigen Code, der tatsächlich
zur Ausführung kommt.
 Die vorgenommenen Modifikationen umfassen die
Emulation sensitiver Maschinenbefehle. Zu diesem Zweck
werden virtuelle Systemregister geführt.
 Die modifizierten Fragmente werden eine Zeit lang in
einem Cache abgespeichert und dort wiederverwendet,
wenn der Programmablauf wieder auf sie stößt.
bs-9.2
(Vergleiche mit just-in-time compilation für JVM!)
39
 Fragment endet mit einem Sprungbefehl oder einem
sensitiven Befehl, spätestens aber nach 12 Befehlen.
Beispiel:
...
JGE
c: ...
x
;
wird übersetzt in
...
JGE
...;
JMP
...;
Fragment-Ende
Adresse im VS für die Behandlung
des bei x beginnenden Codes
Adresse im VS für die Behandlung
des bei c beginnenden Codes
und im Cache abgelegt.
bs-9.2
40
 Schutz des VS vor fehlerhaften Zugriffen seitens des
Gastsystems mittels Segmentierung:
Den Segmenten des Gastsystems werden jeweils
überlappende Segmente zugeordnet, bei denen im
oberen Adressbereich die VS-Teile hinzugefügt sind.
 Übersetzter Befehl kann nur auf die kürzeren
Originalsegmente zugreifen (andernfalls Alarm).
Ein übersetzter Befehl, der auf VS-Daten
zugreifen muss, verwendet dafür das GS-Register.
(Original-Befehle, die ebenfalls GS verwenden,
Wurden zuvor geeignet umgewandelt.)
bs-9.2
41
 Neue VMware-Variante für virtualisierbare Intel VT-x:
Umfangreiche Experimente mit Leistungsmessungen
zeigen eher Verlangsamung!
K. Adams, O. Ageson: A Comparison of Software and Hardware
Techniques for x86 Virtualization. Proc. ASPLOS 2006
bs-9.2
42
(Quelle: Xen)
bs-9.2
43
9.2.5.2 VMware ESX Server
verwendet ebenfalls dynamische Code-Umwandlung,
realisiert aber das VS direkt auf der Hardware
(mit Elementen der Paravirtualisierung).
bs-9.2
Vorteil:
Effizienz, auch durch eigene Treiber
Nachteil:
(geringer) Portierungsaufwand
für die Gastsysteme
Ferner:
Migration virtueller Maschinen möglich.
Voraussetzung: reale Maschinen im
gleichen Storage Area Network!
44
(Quelle: www.vmware.com/...)
bs-9.2
45
Eigenes Exemplar für jede VM!
(Quelle: www.vmware.com/...)
bs-9.2
46
Empfehlenswerte Einführung in Virtualisierung:
M. Rosenblum, T. Garfinkel: Virtual Machine Monitors:
current technology and future trends.
IEEE Computer, May 2005
bs-9.2
47
9.2.6 Virtualisierung auf Betriebssystem-Ebene
Ein Betriebssystem verwaltet verschiedene Bereiche (partitions,
containers, ...) mit jeweils fest zugeordneten Ressourcen.
Effekt:
Schutz zwischen Bereichen, insbesondere gegen
Denial-of-Service-Angriffe
Beispiele: Linux Vserver, Solaris Containers, FreeBSD Jail, ...
bs-9.2
48
(Quelle: Wikipedia ;-)
bs-9.2
49