Es gibt zahlreiche Virtualisierungslösungen, jede mit ihren eigenen Vor- und Nachteilen. Dieses Buch konzentriert sich auf Xen, LXC und KVM, es gibt jedoch weitere bemerkenswerte Umsetzungen einschließlich der folgenden:
Xen
ist eine Lösung zur „Paravirtualisierung“. Es führt zwischen der Hardware und den darüber liegenden Systemen eine dünne Abstraktionsschicht ein, die „Hypervisor“ genannt wird. Diese agiert als Schiedsrichter, der den Zugang der virtuellen Rechner zur Hardware kontrolliert. Er wickelt jedoch nur einige der Instruktionen ab, der Rest wird direkt von der Hardware im Auftrag des Systems ausgeführt. Der Hauptvorteil liegt darin, dass die Leistung nicht abnimmt und die Systeme so fast dieselbe Geschwindigkeit wie bei direkter Ausführung erreichen. Die Kehrseite besteht darin, dass die Kernel der Betriebssysteme, die man mit einem Xen-Hypervisor verwenden möchte, angepasst werden müssen, um mit Xen zu funktionieren.
Lassen Sie uns einige Zeit bei den Ausdrücken bleiben. Der Hypervisor ist die unterste Schicht, die direkt auf der Hardware läuft, sogar unterhalb des Kernels. Dieser Hypervisor kann die übrige Software auf verschiedene Domains aufteilen, die man als ebenso viele virtuelle Rechner ansehen kann. Eine dieser Domains (die erste, die gestartet wird) wird als dom0 bezeichnet und spielt eine besondere Rolle, da nur diese Domain den Hypervisor und die Ausführung der übrigen Domains kontrollieren kann. Diese übrigen Domains werden domU genannt. Mit anderen Worten und aus der Sicht des Benutzers entspricht dom0 dem „Host“ bei anderen Virtualisierungssystemen, während eine domU als „Gast“ angesehen werden kann.
Zur Verwendung von Xen unter Debian sind drei Komponenten erforderlich:
Der Hypervisor an sich. Je nach verfügbarer Hardware ist das entsprechende Paket entweder xen-hypervisor-4.0-i386 oder xen-hypervisor-4.0-amd64.
Ein Kernel mit passenden Patches, die es ihm ermöglichen, mit diesem Hypervisor zu laufen. Im Falle von 2.6.32, der für Squeeze gilt, bestimmt die verfügbare Hardware die Auswahl unter den verschiedenen verfügbaren Paketen namens xen-linux-system-2.6.32-5-xen-*.
Die i386-Architektur erfordert zudem eine Standardbibliothek mit passenden Patches, um Xen nutzen zu können; diese befindet sich im Paket libc6-xen.
Um den Aufwand der manuellen Auswahl dieser Komponenten zu vermeiden, stehen einige Pakete zur Erhöhung der Benutzerfreundlichkeit bereit (wie zum Beispiel xen-linux-system-2.6.32-5-xen-686 und seine Varianten); sie alle installieren eine als gut bekannte Kombination aus passendem Hypervisor und Kernelpaketen. Der Hypervisor bringt zudem das Paket xen-utils-4.0 mit sich, das Hilfsprogramme zur Steuerung des Hypervisors von dom0 aus enthält. Dieses wiederum bringt die passende Standardbibliothek mit sich. Während der Installation all dieser Komponenten erstellen Konfigurationsskripten außerdem einen neuen Eintrag im Menü des Grub Boot-Loaders, mit dem der ausgewählte Kernel in einer Xen dom0 gestartet wird. Man beachte jedoch, dass dieser Eintrag gewöhnlich nicht zuoberst in der Liste steht und deshalb nicht standardmäßig ausgewählt wird. Falls dies nicht das erwünschte Verhalten ist, kann es mit folgenden Befehlen verändert werden:
# mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen
# update-grub
Nachdem diese Voraussetzungen installiert sind, besteht der nächste Schritt darin, das Verhalten von dom0 selbst zu testen; hierzu gehört ein Neustart des Hypervisors und des Xen-Kernels. Das System sollte auf normale Art hochfahren mit einigen zusätzlichen Meldungen auf dem Terminal während der frühen Initialisierungsschritte.
Jetzt ist es an der Zeit, unter Verwendung der Hilfsprogramme aus xen-tools tatsächlich brauchbare Systeme auf dem domU-System zu installieren. Dieses Paket stellt den Befehl xen-create-image bereit, der die Aufgabe weitgehend automatisiert. Der einzig zwingend notwendige Parameter ist --hostname, der domU einen Namen gibt. Andere Optionen sind zwar ebenfalls wichtig, können aber in der Konfigurationsdatei /etc/xen-tools/xen-tools.conf gespeichert werden, und ihr Fehlen in der Befehlszeile führt nicht zu einer Fehlermeldung. Es ist daher wichtig, entweder vor der Erstellung von Abbildern den Inhalt dieser Datei zu überprüfen oder beim Aufruf des Befehls xen-create-image zusätzliche Parameter zu verwenden. Zu den wichtigen und beachtenswerten Parametern gehören folgende:
--memory, um den Umfang an RAM festzulegen, den das neu erstellte System nutzen kann;
--size und --swap, um die Größe der „virtuellen Platten“ zu definieren, die der domU zur Verfügung stehen;
--debootstrap, um zu veranlassen, dass das neue System mit debootstrap installiert wird; in diesem Fall wird meistens auch die Option --dist verwendet (mit dem Namen einer Distribution wie zum Beispiel squeeze).
--dhcp legt fest, dass die Netzwerkkonfiguration der domU durch DHCP besorgt wird, während --ip die Benennung einer statischen IP-Adresse ermöglicht.
Schließlich muss noch eine Speichermethode für die zu erstellenden Abbilder (diejenigen, die von der domU aus als Festplatten gesehen werden) gewählt werden. Die einfachste Methode besteht darin, mit der Option --dir auf der dom0 eine Datei für jedes Gerät zu erstellen, das der domU zur Verfügung stehen soll. Für Systeme, die LVM verwenden, besteht die Alternative darin, die Option --lvm zu nutzen, gefolgt von dem Namen einer Volume-Gruppe; xen-create-image erstellt dann ein neues logisches Volume innerhalb dieser Gruppe, und dieses logische Volume wird der domU als Festplatte zur Verfügung gestellt.
Nachdem diese Entscheidungen getroffen sind, können wir das Abbild der zukünftigen Xen-domU erstellen:
# xen-create-image --hostname=testxen
General Information
--------------------
Hostname : testxen
Distribution : squeeze
Mirror : http://ftp.us.debian.org/debian/
Partitions : swap 128Mb (swap)
/ 4Gb (ext3)
Image type : sparse
Memory size : 128Mb
Kernel path : /boot/vmlinuz-2.6.32-5-xen-686
Initrd path : /boot/initrd.img-2.6.32-5-xen-686
[...]
Logfile produced at:
/var/log/xen-tools/testxen.log
Installation Summary
---------------------
Hostname : testxen
Distribution : squeeze
IP-Address(es) : dynamic
RSA Fingerprint : 25:6b:6b:c7:84:03:9e:8b:82:da:84:c0:08:cd:29:94
Root Password : 52emxRmM
Wir haben jetzt einen virtuellen Rechner, er läuft zur Zeit jedoch nicht (und belegt daher lediglich Platz auf der Festplatte der dom0). Wir können selbstverständlich weitere Abbilder erstellen, möglicherweise mit anderen Parametern.
Bevor wir diese virtuellen Rechner starten, müssen wir festlegen, wie wir auf sie zugreifen werden. Sie können natürlich als eigenständige Rechner angesehen werden, auf die nur über ihre jeweilige Systemkonsole zugegriffen wird, dies entspricht jedoch nur selten dem Nutzungsmuster. Meistens wird eine domU als entfernter Server angesehen, auf den nur über ein Netzwerk zugegriffen wird. Es wäre jedoch ziemlich umständlich, für jede domU eine Netzwerkkarte hinzuzufügen. Deshalb ist es möglich, mit Xen virtuelle Schnittstellen zu erstellen, die von jeder Domain gesehen und auf übliche Weise benutzt werden können. Man beachte, dass diese Karten, obwohl sie virtuell sind, nur von Nutzen sind, wenn sie mit einem Netzwerk verbunden sind, selbst wenn dieses virtuell ist. Xen bietet zu diesem Zweck mehrere Netzwerkmodelle:
Das einfachste Modell ist das bridge-Modell; alle eth0-Netzwerkkarten (sowohl in der dom0 als auch in den domU-Systemen) verhalten sich so, als wären sie direkt an einen Ethernet-Switch angeschlossen.
Dann kommt das routing-Modell, bei dem dom0 als Router agiert, der zwischen den domU-Systemen und dem (physischen) externen Netzwerk steht.
Schließlich befindet sich im NAT-Modell die dom0 ebenfalls zwischen den domU-Systemen und dem übrigen Netzwerk, jedoch sind die domU-Systeme von außen nicht direkt zugänglich, sondern der Datenverkehr wird auf der dom0 einer „Network Address Translation“ unterworfen.
Zu diesen drei Netzknoten gehören eine Reihe von Schnittstellen mit ungewöhnlichen Bezeichnungen, wie zum Beispiel vif*, veth*, peth* und xenbr0. Der Xen-Hypervisor ordnet sie gemäß dem an, was auch immer als Layout festgelegt worden ist, unter der Kontrolle der Hilfsprogramme auf der Anwenderebene. Da die NAT- und Routing-Modelle besonderen Fällen vorbehalten sind, beschäftigen wir uns hier nur mit dem Bridging-Modell.
Die Standardkonfiguration der Xen-Pakete verändert die systemweite Netzwerk-Konfiguration nicht. Jedoch ist der xend-Daemon so konfiguriert, dass er virtuelle Netzwerkschnittstellen in eine bereits bestehende Netzwerkbrücke integriert (wobei xenbr0 Vorrang erhält, falls es mehrere solcher Brücken gibt). Wir müssen daher eine Brücke in /etc/network/interfaces einrichten (wozu das Paket bridge-utils installiert werden muss, weshalb es vom Paket xen-utils-4.0 empfohlen wird), um den bestehenden eth0-Eintrag zu ersetzen:
auto xenbr0
iface xenbr0 inet dhcp
bridge_ports eth0
bridge_maxwait 0
Nach einem Neustart, um sicherzustellen, dass die Brücke automatisch erstellt wird, können wir jetzt die domU mit den Xen-Steuerprogrammen starten, insbesondere mit dem Befehl xm. Mit diesem Befehl ist es möglich, Verschiedenes mit den Domains zu machen, unter anderem sie aufzulisten und sie zu starten oder zu beenden.
# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 940 1 r----- 3896.9
# xm create testxen.cfg
Using config file "/etc/xen/testxen.cfg".
Started domain testxen (id=1)
# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 873 1 r----- 3917.1
testxen 1 128 1 -b---- 3.7
Man beachte, dass die domU testxen wirklichen Speicher des RAM verwendet, der ansonsten für die dom0 verfügbar wäre, und keinen simulierten Speicher. Man sollte daher darauf achten, das physische RAM entsprechend zuzuteilen, wenn man einen Server einrichtet, auf dem Xen-Instanzen laufen sollen.
Voilà! Unser virtueller Rechner startet. Wir können auf ihn auf zweifache Art zugreifen. Der normale Weg besteht darin, sich mit ihm „aus der Ferne“ über das Netzwerk zu verbinden, wie wir es auch bei einem wirklichen Rechner tun würden; hierzu ist es normalerweise erforderlich, entweder einen DHCP-Server oder eine DNS-Konfiguration einzurichten. Der andere Weg, der der einzige sein könnte, falsch die Netzwerk-Konfiguration nicht korrekt war, besteht darin, über den Befehl xm console die Konsole hvc0 zu benutzen:
# xm console testxen
[...]
Starting enhanced syslogd: rsyslogd.
Starting periodic command scheduler: cron.
Starting OpenBSD Secure Shell server: sshd.
Debian GNU/Linux 6.0 testxen hvc0
testxen login:
Man kann dann eine Sitzung öffnen, als säße man an der Tastatur des virtuellen Rechners. Zur Trennung von dieser Konsole dient die Tastenkombination Strg+].
Sobald eine domU läuft, kann sie so wie jeder andere Server verwendet werden (da sie schließlich ein GNU/Linux-System ist). Ihr Status als virtueller Rechner ermöglicht jedoch einige zusätzliche Funktionen. So kann eine domU zum Beispiel mit den Befehlen xm pause und xm unpause vorübergehend angehalten und dann wieder fortgesetzt werden. Man beachte, dass bei einer angehaltenen domU, obwohl sie keine Prozessorleistung in Anspruch nimmt, der ihr zugeordnete Speicherplatz weiterhin belegt ist. Es könnte interessant sein, hier die Befehle xm save und xm restore in Erwägung zu ziehen: das Speichern einer domU gibt die Ressourcen frei, die vorher von dieser domU verwendet wurden, einschließlich des RAM. Wenn sie fortgesetzt wird (oder eigentlich ihr Pausieren beendet wird), bemerkt eine domU außer dem Fortschreiten der Zeit nichts. Falls eine domU läuft, wenn die dom0 heruntergefahren wird, speichern die gebündelten Skripten automatisch die domU, und stellen sie beim nächsten Hochfahren wieder her. Dies schließt natürlich die gleichen Unannehmlichkeiten ein, die entstehen, wenn man zum Beispiel einen Laptop in den Ruhezustand versetzt; insbesondere, dass Netzwerkverbindungen verfallen, falls die domU zu lange ausgesetzt ist. Man beachte auch, dass Xen insofern mit einem Großteil der ACPI-Energieverwaltung inkompatibel ist, als es nicht möglich ist, das Host-System (die dom0) in den Bereitschaftsbetrieb zu versetzen.
Das Anhalten oder Neustarten einer domU kann entweder aus dieser domU heraus geschehen (mit dem Befehl shutdown) oder von der dom0 aus mit xm shutdown oder xm reboot.
