Xen: Unterschied zwischen den Versionen
Michi (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Michi (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 19: | Zeile 19: | ||
===Paravirtualisierung=== | ===Paravirtualisierung=== | ||
Die <b>Paravirtualisierung</b> emuliert die vollständige PC-Hardware emuliert und erlaubt das Ausführen von Gastbetriebssystemen auf klassischen x86-Rechnern mit beinahe nativer Geschwindigkeit. Diese Variante beschränkt sich vor allem darauf, Rechnerressourcen wie [[Prozessor]]-Zeit, [[Arbeitsspeicher]] oder | Die <b>Paravirtualisierung</b> emuliert die vollständige PC-Hardware emuliert und erlaubt das Ausführen von Gastbetriebssystemen auf klassischen x86-Rechnern mit beinahe nativer Geschwindigkeit. Diese Variante beschränkt sich vor allem darauf, Rechnerressourcen wie [[Prozessor]]-Zeit, [[Arbeitsspeicher]] oder Rechnernetz-Bandbreite zu verwalten und den verschiedenen virtuellen Maschinen zuzuweisen. Der eigentliche Hypervisor Xen läuft dabei im Kernel-Mode auf dem sogenannten privilegierten Kernel-Ring 0. | ||
Moderne [[Prozessor]]en kennen vier solcher Ringe. Diese lassen sich auch als Sicherheitsstufen ansehen. | Moderne [[Prozessor]]en kennen vier solcher Ringe. Diese lassen sich auch als Sicherheitsstufen ansehen. | ||
Zeile 57: | Zeile 57: | ||
Diese Konfiguration lädt den 300 KB grossen Hypervisor Xen und kümmert sich anschliessend um die Verteilung der Rechnerressourcen. | Diese Konfiguration lädt den 300 KB grossen Hypervisor Xen und kümmert sich anschliessend um die Verteilung der Rechnerressourcen. | ||
Die erste virtuelle Maschine, die unter dem Namen "Domain 0" läuft, stellt dann das auf dem physikalischen Rechner installierte Wirtssystem dar. Diese virtuelle Maschine dient lediglich als Managementsystem für zusätzliche virtuelle Maschinen und sollte möglichst schlank ausfallen: Gelingt es einem Angreifer, diese Domäne zu kompromoittieren, so sind alle weiteren Domänen ebenfalls betroffen. Daher läuft an Netzwerkdiensten hier höchstens ein [[SSH]]-Server, sodass sich die Maschine auch übers | Die erste virtuelle Maschine, die unter dem Namen "Domain 0" läuft, stellt dann das auf dem physikalischen Rechner installierte Wirtssystem dar. Diese virtuelle Maschine dient lediglich als Managementsystem für zusätzliche virtuelle Maschinen und sollte möglichst schlank ausfallen: Gelingt es einem Angreifer, diese Domäne zu kompromoittieren, so sind alle weiteren Domänen ebenfalls betroffen. Daher läuft an Netzwerkdiensten hier höchstens ein [[SSH]]-Server, sodass sich die Maschine auch übers Rechnernetz verwalten lässt. Die Xen-Terminologie unterscheidet zwischen privilegierten und unprivilegierten Domänen, in denen Betriebssysteme ablaufen. Während Domäne 0 die privilegierte Domäne darstellt, laufen alle zusätzlich installierten virtuellen Maschinen in einer unprivilegierten Domäne. | ||
=== Befehlszentrale xm === | === Befehlszentrale xm === | ||
Zeile 140: | Zeile 140: | ||
Mit [[xm]] wird das soeben erzeugte System aus der Domäne 0 heraus verwaltet. So erhöht etwa der Aufruf "xm mem-set 512 rhel5" den zur Verfügung stehenden Arbeitsspeicher auf 512 MB. Mit "xm save rhel5" wird die Maschine gestoppt. Der Aufruf "xm restore rhel5.xm migrate --live rhel5 <Rechner>" bewirkt die Live-Migration der virtuellen Maschine auf einen anderen Rechner. Wie gesagt funktioniert das jedoch nur bei paravirtualisierten virtuellen Maschinen. Mit "xm shutdown rhel5" wird die virtuelle Maschine heruntergefahren. Anstelle des Domänennamens (im Beispiel "rhel5") kann stellvertretend bei allen xm-Befehlen auch die Domänen-ID stehen, die mit "xm --list" angezeigt wird. | Mit [[xm]] wird das soeben erzeugte System aus der Domäne 0 heraus verwaltet. So erhöht etwa der Aufruf "xm mem-set 512 rhel5" den zur Verfügung stehenden Arbeitsspeicher auf 512 MB. Mit "xm save rhel5" wird die Maschine gestoppt. Der Aufruf "xm restore rhel5.xm migrate --live rhel5 <Rechner>" bewirkt die Live-Migration der virtuellen Maschine auf einen anderen Rechner. Wie gesagt funktioniert das jedoch nur bei paravirtualisierten virtuellen Maschinen. Mit "xm shutdown rhel5" wird die virtuelle Maschine heruntergefahren. Anstelle des Domänennamens (im Beispiel "rhel5") kann stellvertretend bei allen xm-Befehlen auch die Domänen-ID stehen, die mit "xm --list" angezeigt wird. | ||
Die eben gezeigte | Die eben gezeigte Installation verwendet die Standardeinstellungen: So ist das installierte Gastsystem etwa über eine Bridge mit der Netzwerkschnittstelle "eth0" verbunden und hat so direkten Zugang zum selben Rechnernetz, in dem sich auch der Wirtsrechner befindet. Über die Konfigurationsdatei "/etc/xen/xend-config.sxp" kann diese Einstellung geändert werden. Diese Datei kann zum Beispiel wie folgt aussehen: | ||
<pre> | <pre> | ||
name = "rhel5" | name = "rhel5" | ||
Zeile 163: | Zeile 163: | ||
== Weblinks == | == Weblinks == | ||
{{ | {{Weblinks}} | ||
{{url_dewikipedia|Xen|Xen}} | |||
{{Fuss}} | |||
{{cat|Virtualisierung}} | {{cat|Virtualisierung}} | ||
{{cat|Xen}} | {{cat|Xen}} |
Aktuelle Version vom 10. Februar 2010, 20:18 Uhr
Xen (auch: Hypervisor, Virtual Machine Monitor / VMM) ist eine freie Virtualisierungs-Umgebung, die den Betrieb mehrerer Betriebssysteme auf einem physikalischen Rechner erlaubt. Xen ist Bestandteil der meisten grossen Linux-Distributionen.
Merkmale
- Beinahe native Performance im Paravirtualisierungsbetrieb.
- Dynamisches Verändern von Ressourcen wie dem Arbeitsspeicher im laufenden Betrieb der virtuellen Maschine.
- Unterbrechungsfreie Migration eines physikalischen Rechner auf einen anderen, sofern beide Rechner auf das "shared storage" zugreifen können, das die virtuelle Maschine enthält. Ob es sich bei diesem Massenspeicher um ein teures Fiber-Channel-SAN oder um eine günstige ISCSI-Lösung handelt, spielt dabei keine Rolle. Fehlt eine solche Hardware auf dem Rechner, so können die virtuellen Maschinen im Ruhezustand migriert werden.
- Konsolidierung von Servern, die als virtuelle Maschinen auf einem einzigen Rechner betrieben werden. Um eine Einrichtung hochverfügbar zu machen, lassen sich virtuelle Maschinen bei einem Ausfall der Hardware einfach auf einen zweiten Rechner verschieben, der gewissermassen als Standby-Maschine arbeitet.
- Ausfallzeiten wegen Wartungsarbeiten entfallen: Man migriert die virtuelle Maschine für den Zeitraum der Arbeiten auf eine andere physikalische Maschine und startet nach Beendigung der notwendigen Arbeiten wieder auf dem ursprünglichen Rechner.
- Einfaches Testen eines neuen Betriebssystems. Anstatt den vollständigen Rechner zu installieren, wir einfach eine neue virtuelle Maschine mit dem zu testenden Betriebssystem eingerichtet.
- Sicherer Betrieb mehrerer Netzwerkdienste wie Web- oder Dateiserver auf einer physikalischen Maschine, da die virtuellen Maschinen und damit die Dienste abgeschottet voneinander in eigenen VMs (?) laufen.
Konzept
Xen wurde ursprünglich an der Universität Cambridge zum Virtualisieren von x86-Architekturen entwickelt. Die Software verfolgt dabei zwei verschiedene Konzepte:
- Mit der Paravirtualisierung laufen Gastbetriebssysteme mit fast nativer Geschwindigkeit auf klassischen x86-Rechnern.
- Die native Virtualisierung emuliert die vollständige PC-Hardware und erlaubt Xen auch den Betrieb von Closed Source-Betriebssystemen wie Microsoft Windows, wobei die Performance allerdings weniger gut ist.
Paravirtualisierung
Die Paravirtualisierung emuliert die vollständige PC-Hardware emuliert und erlaubt das Ausführen von Gastbetriebssystemen auf klassischen x86-Rechnern mit beinahe nativer Geschwindigkeit. Diese Variante beschränkt sich vor allem darauf, Rechnerressourcen wie Prozessor-Zeit, Arbeitsspeicher oder Rechnernetz-Bandbreite zu verwalten und den verschiedenen virtuellen Maschinen zuzuweisen. Der eigentliche Hypervisor Xen läuft dabei im Kernel-Mode auf dem sogenannten privilegierten Kernel-Ring 0.
Moderne Prozessoren kennen vier solcher Ringe. Diese lassen sich auch als Sicherheitsstufen ansehen.
- Ring 0: Nur aus diesem innersten Ring ist ein direkter Zugriff auf die Hardware und bestimmte Arbeitsspeicherbereiche möglich ist. Hier operiert üblicherweise auch der eigentliche Betriebssystem-Kernel im Kernel-Mode.
- Ring 1: Wird auf x86-Architekturen nicht benutzt.
- Ring 2: Wird auf x86-Architekturen nicht benutzt.
- Ring 3: Hier laufen Benutzeranwendungen im User-Mode.
Auf einem Xen-System operiert nun der Hypervisor anstelle des eigentlichen Betriebssystems im Ring 0. Die Gastmaschinen befinden sich im Ring 1 und müssen jeden privilegierten Zugriff (Systemaufrufe) über den Hypervisor im Ring 0 anfordern. Dies erfordert eine Veränderung des Kernels des Gastsystems, weswegen nur Systeme mit einem offenen Quellcode einen paravirtualisierten Betrieb erlauben. Dazu zählen neben Linux auch verschiedene BSD-Varianten und Opensolaris. Da Anwendungen unverändert im Ring 3 laufen, sind hier keine Eingriffe notwendig und sie lassen sich ohne Änderung auf einem Xen-System betreiben.
Die hier besprochene und von Xen angebotene Paravirtualisierung ähnelt beim Arbeitsprinzip dem VMware ESX Server.
Native Virtualisierung
Bei der nativen Virtualisierung emuliert Xen die vollständige PC-Hardware. Das entspricht ungefähr dem Ansatz von Vmware Workstation oder Microsoft Virtualpc. Dieser Modus erfordert keine Veränderung am Gastbetriebssystem, sodass sich etwa auch Microsoft Windows über Xen ausführen lässt - allerdings nur auf Systemen mit Prozessoren, welche diese Virtualisierungstechnologie unterstützen. Intel hat diese unter dem Namen "Vanderpool" (IVT) herausgebracht; AMD bezeichnet die entsprechende Prozessorfamilie als "Pacifica" (AMD-V).
Ob der eigene Prozessor die notwendige Unterstützung mitbringt, wird mit folgendem Befehl festgestellt:
- unter AMD mit "grep svm /proc/cpuinfo"
- unter Intel mit "grep vmx /proc/cpuinfo"
Bleibt die Ausgabe leer, so unterstützt der Prozessor die Technologie nicht.
Im Gegensatz zur Paravirtualisierung, die Ressourcen nur verteilt, arbeitet ein nativ virtualisiertes System wesentlich langsamer, da Xen dann sämtliche Hardwareressourcen emulieren muss.
Installation und Konfiguration
Aktuelle Versionen der gängigen Linux-Distributionen bringen die notwendigen Pakete zum Betrieb von Xen von sich aus mit, womit sich die folgenden auf Fedora basierenden Beispiele auch auf alle anderen Systeme mit Xen-Unterstützung übertragen lassen.
Bei Fedora Core 6 kommt das RPM-Paket "kernel-xen" zum Einsatz. Es enthält unter anderem den eigentlichen Hypervisor Xen, der direkt beim Systemstart aufgerufen und gestartet wird. Der notwendige Boot-Eintrag in der Datei "/boot/grub/menu.lst" sieht wie folgt aus.
title Fedora Core (2.6.20-1.2933.fc6xen) root (hd0,0) kernel /xen.gz-2.6.20-1.2933.fc6 module /vmlinuz-2.6.20-1.2933.fc6xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet module /initrd-2.6.20-1.2933.fc6xen.img
Diese Konfiguration lädt den 300 KB grossen Hypervisor Xen und kümmert sich anschliessend um die Verteilung der Rechnerressourcen.
Die erste virtuelle Maschine, die unter dem Namen "Domain 0" läuft, stellt dann das auf dem physikalischen Rechner installierte Wirtssystem dar. Diese virtuelle Maschine dient lediglich als Managementsystem für zusätzliche virtuelle Maschinen und sollte möglichst schlank ausfallen: Gelingt es einem Angreifer, diese Domäne zu kompromoittieren, so sind alle weiteren Domänen ebenfalls betroffen. Daher läuft an Netzwerkdiensten hier höchstens ein SSH-Server, sodass sich die Maschine auch übers Rechnernetz verwalten lässt. Die Xen-Terminologie unterscheidet zwischen privilegierten und unprivilegierten Domänen, in denen Betriebssysteme ablaufen. Während Domäne 0 die privilegierte Domäne darstellt, laufen alle zusätzlich installierten virtuellen Maschinen in einer unprivilegierten Domäne.
Befehlszentrale xm
Nach dem Start des Managementsystems der Domäne 0 sowie einem Login als Benutzer "root" ermöglicht das Werkzeug "xm" aus dem Xen-RPM-Paket das Verwalten bereits bestehender Systeme: diese können gestartet, gestoppt oder verändert werden. Auch dynamische Verändern der Ressourcen (z. B. der Arbeitsspeicher) wird damit erledigt.
Die wichtigsten xm-Argumente sind die folgenden.
Argument | Bedeutung |
---|---|
console <Domänen-ID> | Erlaubt den direkten Zugriff auf die Textkonsole der genannten Domäne. |
create [-c] <Domänenname> | Startet anhand der gleichnamigen Konfigurationsdatei die virtuelle Maschine. Die Option "-c" stellt eine direkte Verbindung zur Textkonsole der virtuellen Maschine her. |
shutdown <Domänen-ID / Name> | Fährt die virtuelle Maschine sauber herunter. Mit der Option "-a" können alle laufenden virtuellen Maschinen gestoppt werden. |
list | Auflistung aller gestarteten Domänen. Die einzelnen Spalten geben Auskunft über Domänennamen und -ID, den zugewiesenen Arbeitsspeicher, die Anzahl der virtuellen Prozessoren, den Status und die Laufzeit der Maschine. |
mem-max <Domänen-ID> <RAM> | Festlegung des maximalen Arbeitsspeichers, welcher der virtuellen Maschine zugewiesen wird. |
mem-set <Domänen-ID> <RAM> | Setzt den zur Verfügung stehenden Arbeitsspeicher für die genannte Domäne. |
migrate <Domänen-ID / Name> <Host> [-l] | Migriert die genannte virtuelle Maschine auf einen anderen physikalischen Host. Dazu stoppt Xen die virtuelle Maschine zuerst und startet sie dann auf dem Zielrechner wieder. Durch den Schalter "-l" wird die virtuelle Maschine ohne Unterbrechung migriert. Dafür sind allerdings bestimmte Voraussetzungen notwendig (siehe Xen-Benutzerhandbuch). |
pause <Domänen-ID / Name> | Anhalten der virtuellen Maschine. Die Ressourcen der virtuellen Maschine werden dabei allerdings nicht wieder freigegeben. |
unpause <Domänen-ID / Name> | Aktivierung der virtuellen Maschine nach Pausieren. |
save <Domänen-ID / Name> <Statusdatei> | Speichert den Zustand der virtuellen Maschine in der genannten Statusdatei und hält die virtuelle Maschine danach an. |
* restore <Statusdatei> | Startet die virtuelle Maschine erneut anhand der Statusdatei. |
vcpu-set <Domänen-ID / Name> <VCPUs> | Weist der genannten virtuellen Maschine eine bestimmte Anzahl von virtuellen Prozessoren zu. |
Der Aufruf "xm list" zeigt zu diesem Zeitpunkt nur die Domäne 0 an.
Name ID Mem VCPUs State Time(s) Domain-0 0 747 1 r----- 84.6
Installation virtueller Maschinen
Die Installation neuer virtueller Maschinen gelingt am einfachsten mit dem Werkzeug "virt-install", das über das RPM-Paket "python-virtinst" auf dem Rechner eingerichtet wird. Dieses Programm erzeugt eine Konfigurationsdatei mit dem Namen der Domäne im Verzeichnis "/etc/xen", die xm im Ansachluss zum Verwalten der Domäne verwendet. Zum Anlegen einer neuen Domänen-Konfigurationsdatei mit virt-install müssen einige Informationen mit den entsprechenden Argumenten beim Aufruf angegeben werden. Die wichtigsten davoin sind die folgenden.
Argument | Bedeutung |
---|---|
-n <Name> | Zuweisung eines neuen Namens an die Domäne. |
-r <RAM> | Bestimmt die Grösse des Arbeitsspeichers. |
--vcpus <Anzahl> | Bestimmt die Anzahl der virtuellen Prozessoren der neuen virtuellen Maschine. |
-f <Abbilddatei> | Bestimmt den Namen der Abbilddatei für die virtuelle Maschine. Die Datei sollte sich im Verzeichnis "/var/lib/xen/images" befinden, da es sonst Probleme mit aktiviertem SELinux geben kann. Die Datei benötigt den SELinux-Kontext "xen_image_t". Im Zweifelsfall lässt sich dieser mit dem Befehl "chcon -t xen_image_t <Abbilddatei>" neu setzen. |
-s <GB> | Bestimmt die Grösse der Abbilddatei in GigaByte. |
-p | Installiert die virtuelle Maschine als paravirtualisiertes Gastsystem. |
-l <Ort> | Bestimmt den Installationsrechner und den Pfad. Gültige Angaben sind "nfs://Rechner/Pfad", "ftp://Host/Pfad" und "http://Rechner/Pfad". |
--vnc | Startet einen VNC-Server und erlaubt damit die Installation auch im Grafikmodus. |
--nographics | Führt die Installation im Textmodus durch. |
Das folgende Beispiel zeigt die Installation eines neuen RHEL5-Systems (Red Hat Linux Enterprise Linux 5) in einer virtuellen Maschine. Das funktioniert auf dieselbe Weise mit anderen Betriebssystemen, sofern diese die notwendigen Xen-Unterstützung mitbringen.
Die benötigten Installationsdateien für die RHEL5-Installation liegen im Beispiel auf einem FTP-Server mit der IP-Adresse "192.168.0.1" im Verzeichnis "/pub". Anstelle des FTP-Servers kann auch ein HTTP- oder NFS-Server als Installationsquelle dienen. Der Name der Domäne heisst "rhel5" - die virtuelle Maschine wird in einer 5 GB umfassenden Abbilddatei in der Domäne 0 abgelegt und bekommt 256 MB Arbeitsspeicher zugewiesen. Der enstprechende Aufruf von virt-install sieht folgendermassen aus:
virt-install -p -n rhel5 -r 256 -f /var/lib/xen/images/rhel5.img -s 5 -l ftp://192.168.0.1/pub/
Danach startet das Setup des Betriebssystems wie gewohnt. Nach dem Abschluss der Installation wird das Betriebssystem mit dem Aufruf "xm create rhel5" gestartet. Ein erneuter Aufruf von "xm list" zeigt nun das neue System.
Name ID Mem VCPUs State Time(s) Domain-0 0 747 1 r----- 88.0 rhel5 1 256 1 -b---- 0.5
Mit dem Aufruf "xm console rhel5" wird auf die Konsole der neuen Domäne zugegriffen und man kann sich mit den bei der Installation festgelegten Benutzerdaten anmelden. Das Werkzeug "virt-manager" aus dem gleichnamigen RPM-Paket ermöglicht einen grafischen Überbrlick über alle bereits gestarteten Domänen. Über diese grafische Oberfläche kann zudem für jedes System eine grafische Konsole gestartet werden, mit der ein Login in die grafische Oberfläche der virtuellen Maschine möglich ist. Dieses Programm ermöglicht auch die Installation eines neuen virtuellen Betriebssystems über die grafische Oberfläche. Die notwendigen Informationen dafür sind dieselben wie die bei "virt-install" auf der Befehlszeile.
Mit xm wird das soeben erzeugte System aus der Domäne 0 heraus verwaltet. So erhöht etwa der Aufruf "xm mem-set 512 rhel5" den zur Verfügung stehenden Arbeitsspeicher auf 512 MB. Mit "xm save rhel5" wird die Maschine gestoppt. Der Aufruf "xm restore rhel5.xm migrate --live rhel5 <Rechner>" bewirkt die Live-Migration der virtuellen Maschine auf einen anderen Rechner. Wie gesagt funktioniert das jedoch nur bei paravirtualisierten virtuellen Maschinen. Mit "xm shutdown rhel5" wird die virtuelle Maschine heruntergefahren. Anstelle des Domänennamens (im Beispiel "rhel5") kann stellvertretend bei allen xm-Befehlen auch die Domänen-ID stehen, die mit "xm --list" angezeigt wird.
Die eben gezeigte Installation verwendet die Standardeinstellungen: So ist das installierte Gastsystem etwa über eine Bridge mit der Netzwerkschnittstelle "eth0" verbunden und hat so direkten Zugang zum selben Rechnernetz, in dem sich auch der Wirtsrechner befindet. Über die Konfigurationsdatei "/etc/xen/xend-config.sxp" kann diese Einstellung geändert werden. Diese Datei kann zum Beispiel wie folgt aussehen:
name = "rhel5" memory = "256" disk = [ 'tap:aio:/var/lib/xen/images/rhel5.img,xvda,w', ] vif = [ 'mac=00:16:3e:71:a5:8d, bridge=xenbr0', ] vnc=0 vncunused=1 #uuid = "154cde6d-42b0-c2b7-7f52-bfaa2f44c1a9" bootloader="/usr/bin/pygrub" vcpus=1 on_reboot = 'restart' on_crash = 'restart'
Xen erlaubt auch das Erstellen komplexer Routing-Varianten. Alernativ zur Abbilddatei des Beispiels, in der die virtuelle Maschine in der Domäne 0 erzeugt wird, kann auch eine reale Partition oder ein Logical Volume aus der Domäne 0 verwendet werden. Nähere Informationen dazu und zu allen anderen Konfigurationsmöglichkeiten finden sich im Xen-Handbuch im Verzeichnis "/usr/share/doc/xen-version".
Um sich die Installationsarbeit für eine virtuelle Maschine zu sparen, kann auch aus dem Internet ein fertiges Xen-Abbild verschiedener Distributionen wie SUSE Linux, Ubuntu oder Debian heruntergeladen werden:
Weblinks
Herausgeber | Sprache | Webseitentitel | Anmerkungen |
---|---|---|---|
Wikipedia | ger | Xenwbm | Enzyklopädischer Artikel |