Xen-Installation-Seite-2

Aufteilung

Aufgrund der Länge habe ich die Anleitung nun aufgeteilt. Am Ende der jeweiligen Seite findet sich ein Link zur nachfolgenden Seite.

• Startseite
• Seite 2
• Seite 3
• Seite 4
• Seite 5

Hinweise zur Terminologie dieser Anleitung

Da ich kein großer Freund von Wiederholungen bin, verwende ich unterschiedliche Wörter für eine privilegierte Domain, und eine unprivilegierte Domain. Wann immer die Rede von einem Wirt, Dom0 oder ähnliches geht, handelt es immer von der Domain-0. Selbes gilt für den Gast, VM, DomU und weitere Synonyme, es geht in diesem Fall immer um die unprivilegierte Domain.

Bei Zeilen wie diesen:

dom0:# foo

Handelt es sich immer um einen Befehl, der vom Wirt ausgeführt wird, während:

vm<nr>:# foo

Immer in einer virtuellen Instanz ausgeführt wird.

Werden Konfigurationsdateien bearbeitet oder eingesehen, so stellt sich dies so da:

• /pfad/datei

foo bla Wert x

Des weiteren gibt es noch Hinweise wie diese:

Hier gilt es aufzupassen

Hier sind Hinweise und Tipps zu lesen

Benötigte Hilfsmittel

Bevor wir uns an Xen selber wagen, gilt es vorher noch ein paar substantielle Programme kennen zu lernen. Ich werde die einzelnen Programme auflisten und soweit möglich erläutern, sodass die neu gewonnenen Fähigkeiten an Xen angewandt werden können.

Brücken bauen

• Überblick

Wird Xen in seiner Standard Auslieferung genutzt, so wird als Ethernet- Technik das Bridging verwendet. Eine Bridge arbeitet auf Ebene Zwei des ISO/OSI Schichtenmodels und verbindet eigentlich unterschiedliche Netzwerksegmente. Früher wurde diese Technik häufig eingesetzt um verschiedene, physische Ethernet Netzwerk Topologien zusammenzuführen bzw. zu verbinden, wie zum Beispiel BNC mit Twisted Pair. Dabei gab es ein Gerät, welches zwischen den unterschiedlichen Medien vermittelte.

Das eingesetzte Protokoll, TCP/IP, IPX, AppleTalk etc., war dabei nicht von Interesse, denn wie bereits erwähnt, setzt die Bridge auf der Layerschicht Zwei auf, also auf der Ebene von MAC Adressen. Die Bridge war somit für die Protokolle, und damit Anwendungen, transparent.

Eine Bridge lässt sich auch dazu nutzen, über das so genannte SpanningTree Protokoll (STP), ein Netzwerk zu konstruieren, bei dem es theoretisch möglich wäre, dass ein Paket über mehrere Pfade sein Ziel erreichen kann. Da wir nach wie vor auf Ebene Zwei arbeiten, sorgt niemand dafür, das versehentlich duplizierte Pakete aussortiert werden, bzw. gar nicht erst entstehen. Dies könnte dazu führen, dass das Netzwerk mit z.B. Kollisionen überhäuft wird und letztlich zusammenbricht.

Nun kommt das STP (Spanning Tree Protocol) zum Einsatz und sorgt dafür, dass jeweils nur ein einziger Pfad aktuell gültig ist. Die anderen Pfade (Ethernet Ports) werden abgeschaltet. Erst bei dem Ausfall des einen Pfades, wird ein neuer Pfad errechnet und aktiviert.

Um dies zu koordinieren wird eine Root Bridge anhand der niedrigsten Bridge-ID, die jede Bridge besitzt, per Multicast gewählt, steht somit an der obersten Stelle und bestimmt daher den Pfad, den ein Paket nehmen kann um sein Ziel zu erreichen.

Nun könnte sich jemand fragen, warum denn kein Routing verwendet wird: Da die Pakete nicht komplett ausgepackt werden müssen, um zu erfahren, wohin sie denn gern möchten, ist die Datendurchflussmenge sehr viel höher, als dies z.B. beim Routing der Fall wäre, welches erst bei Layer Drei zum Einsatz käme.

Seit dem Kernel 2.2 wurde ein Teil der Technik in einer Softwarelösung implementiert und befindet sich ab der Version 2.4 im Kernel. Dieser ist im ANSI/IEEE 802.1d Standard definiert.

• Mehr Funktionen

Nun hat die Softwarelösung, gegenüber der Hardware-Bridge enorme Vorteile: Mit Hilfe von etables wird der Administrator in die Lage versetzt, bereits auf Layer Zwei eine Firewall aufzubauen und entsprechend zu filtern, ohne die vorhandene Infrastruktur verändern zu müssen.

Des weiteren bietet sich eine Software Bridge an, eine virtuelle DMZ (demilitarisierte Zone) aufzubauen. Dies bedeutet: Verfügt ein Rechner über mehrere Schnittstellen (z.B Netzwerkkarten), die ihrerseits mit Rechnern verbunden sind, (z.B. ein E-Mail oder ein Webserver), so kann darüber verfügt werden, wer mit wem Daten austauschen darf.

Folgendes Beispiel sei aufgezeigt:

Wir haben eine öffentliche Adresse, 65.23.8.7. Die öffentliche IP Adresse bekommt ein Webserver, damit dieser von Außen erreichbar ist. Da der Rechner an der selben physikalischen Leitung hängt,eth1, wie das interne Netz, bedient man sich einer Bridge. Dabei werden beide Netzwerkkarten in einer Bridge mit dem Namen br0 zusammengefasst. Die Firewall Regeln sorgen dann anhand der MAC Adresse dafür, dass auch wirklich nur die Pakete mit der passenden IP Adresse an den Webserver gehen. Der Webserver sieht dagegen nichts von dem Verkehr, der sich im internen Netzwerk abspielt. Dies lässt sich leicht mit einem Netzwerksniffer, wie tcpdump oder IPtraf, auf dem Webserver nachprüfen.

Das Interne Netzwerk geht mittels NAT (Network Address Translation) in das öffentliche Netz.

Bei einem Routen basierten Setup, würde jeder den Verkehr belauschen können, sofern die Netzwerkkarte im so genannten Promiscuous Mode arbeitet. Dabei nimmt die Netzwerkkarte jedes Datenpaket an, auch wenn es gar nicht für sie bestimmt ist. Dies ist zwar für z.B. Analysezwecke sehr von Vorteil, kann jedoch auch für die Dunkle Seite der Macht missbraucht werden. Und wir alle wissen, wo dies hinführt ;-)

• In Aktion

Um eine virtuelle Bridge aufzubauen, bedarf es zweier Komponenten: Zum Einen die Module im Kernel, welche eigentlich bei jeder Distribution vorhanden sein sollten; zum Anderen die Bridge Utils, mit dem Kommando brctl.

Um bei dem oben genannten Beispiel zu bleiben, erstellen wir zu Testzwecken eine temporäre Bridge:

Der Name der Bridge soll br0 sein:

dom0:# /usr/sbin/brctl addbr br0

Die beiden Netzwerkkarten eth0 und eth1 zur Brücke hinzufügen

dom0:# /usr/sbin/brctl addif br0 eth0 dom0:# /usr/sbin/brctl addif br0 eth1

Die beiden Netzwerkkarten werden zwar gestartet, dürfen aber keine IP besitzen

dom0:# /sbin/ip addr add 0.0.0.0/0 dev eth0 dom0:# /sbin/ip addr add 0.0.0.0/0 dev eth1 dom0:# /sbin/ip link set up dev eth0 dom0:# /sbin/ip link set up dev eth1

Die Bridge br0 erhält die IP 65.23.8.7, sowie zusätzlich die Adresse 192.168.1.1 für das interne Netz , gefolgt von der Standard Route.

dom0:# /sbin/ip addr 65.23.8.7/5 brd + dev br0 dom0:# /sbin/ip addr add 192.168.1.1/24 brd + dev br0 dom0:# /sbin/ip route add default via 65.23.8.254

Mit dem Kommando: brctl show, lässt sich die Bridge betrachten:

dom0:# brctl show bridge name bridge id STP enabled interfaces br0 8000.feffffffffff no eth0 eth1

Damit haben wir eine Bridge erstellt und mittels IPTables können wir den Datenverkehr von außen gezielt an den Webserver weiterleiten, ohne dass das interne Netzwerk etwas mitschneiden könnte.

Sehr häufig werden Brücken gebaut, um zum Beispiel eine Funknetzwerkkarte und ein kabelgebundenes Netzwerk mit einander zu verbinden. Hier finden wir wieder den klassischen Anwendungszweck, zwei unterschiedliche Ethernet Topologien mit einander zu verbinden.

---

Xen Netzwerk Topologie

Xen bietet von Hause aus, mehrere Möglichkeiten an, um die Gäste (DomU) in ein Netzwerk zu integrieren. Drei von ihnen werden hier erläutert.

Via Bridge

Wie bereits mehrfach erwähnt, verwendet Xen in seiner Standardinstallation eine Bridge um die virtuellen Hosts mit einander zu vernetzen.

Die Vorgehensweise mag auf den ersten Blick ein wenig seltsam, wenn nicht sogar verwirrend erscheinen, doch auf den zweiten Blick hellt sich der Himmel auf:

• Vorgehensweise

1. Es wird eine Bridge mit dem Namen xenbr0 erzeugt
2. Die "echte" Netzwerkkarte eth0 wird heruntergefahren
3. Die IP und MAC Adresse von eth0 wird auf die virtuelle Netzwerkkarte veth0 kopiert
4. Aus der "echten" eth0 wird nun peth0
5. veth0 wird nun in eth0 umbenannt
6. peth0 und die virtuelle vif0.0 wandern nun in die Bridge xenbr0
7. Die Bridge, peth0, eth0 und vif0.0 werden hochgefahren.

Em Ende zeigt sich folgendes Bild:

Warum nun dieses komplizierte kopieren? Die Bridge arbeitet nun auf OSI Schicht Ebene Zwei und leitet daher die Ethernet Pakete einfach an alle virtuellen sowie physischen Netzwerkkarten die in die Bridge eingebunden worden sind weiter.

Dies entspricht auch der Vorgehensweise der physikalischen Welt.

Bei dieser Art und Weise wird die Netzwerkkarte innerhalb eines Gastes mittels (z.B. eth0) eines virtuellen Crossoverkabels mit der virtuellen Netzwerkkarte verbunden, die ihrerseits an der Bridge xenbr0 hängt.

Die physische Netzwerkkarte (die zu peth0 wird) wird dann nur noch zu einem Zugang nach draußen degradiert und agiert damit wie ein physischer Switch Port. Daher wird auch das ARP (Address Resolution Protocoll) für diese Karte deaktiviert und stellt sich somit aus der Sicht des Netzwerkes als nicht vorhanden dar. Die Netzwerkkarte des Wirts eth0, wird ebenfalls per virtuellem Crossoverkabel mit der virtuellen Netzwerkkarte vif0.0 verbunden, welche ihrerseits in der Bridge hängt. Damit können alle mit einander kommunizieren und dennoch verwenden wir nur reine Ethernet Geräte. In älteren Setups von Xen (<3.0.0) wurde die physische Netzwerkkarte und die virtuelle Netzwerkkarte in eine Bridge gebunden, wobei die Bridge dann eine IP Adresse erhielt. Die Xen Entwickler nahmen jedoch Abstand von dieser unsauberen Ethernet Konfiguration und erdachten das neue Verfahren.

Wem das obere Bild noch nicht viel sagt, dem hilft eventuell dieses hier, um sich eine Vorstellung davon zu machen, was die Xen Leute sich dabei gedacht haben:

Für dieses Unterfangen ist das Script network-bridge im Verzeichnis /etc/xen/scripts verantwortlich.

Syntax für die virtuellen Interface lautet vif<domid>.<vifid> - die Namen der angeschlossenen Interfaces lauten somit korrekterweise "vif1.0, vif2.0, vif3.0"

• Vorteile

Wird bei Xen das Bridgesetup genutzt, wird das Ziel -- Vernetzung der Gäste -- am schnellsten erreicht, da es in der Regel Out-Of-The-Box funktioniert. Außerdem erlaubt es interessante Konstruktionen, wie den Aufbau einer DMZ (siehe oben). Hier sei noch einmal ein Beispiel aufgezeigt:

Das Szenario sei ein Webserver, der über das Internet erreichbar ist. Dieser Webserver bezieht seine Daten aus einer Datenbank. Um die Datenbank zu schützen, wird sie vom regulären Netz entkoppelt. Somit ist kein direkter Weg zum Datenbank Server aus dem öffentlichen Netz möglich. Der Zugriff erfolgt nur über die zweite Bridge.

Mit einem erweiterten Setup wäre es auch möglich auf die zweite Bridge zu verzichten und Webserver und Datenbank über eine interne, virtuelle Netzwerkkarte zu verbinden.

Ein weiterer Vorteil ergibt sich aus dem performanteren Datendurchsatz. Der Kernel muss lediglich den Teil des IP Paketes lesen der die MAC Adresse enthält, welcher sich bekanntlich am Anfang findet. Den Rest des Paketes muss er nicht beachten.

Routen

Eine weitere Möglichkeit Rechner und Netze miteinander zu verbinden, besteht im Routing. Routing an sich sollte für die meisten keine Hürde darstellen. Xen unternimmt dafür folgende Arbeiten:

1. Das Script /etc/xen/scripts/network-route wird ausgeführt, welches die IP Weiterleitung (ip forwarding) in der Dom0 aktiviert.
2. Als nächstes wird das Script vif-route gestartet, welches die IP Adresse von eth0 auf die virtuelle Karte vif<Nummer>.0 kopiert und dabei auch noch eine Route für diese Netzwerkkarte hinzufügt, damit der virtuelle Host erreichbar ist. Allerdings gilt dies nur für die Dom0 sowie die ebenfalls laufenden Gäste. Rechner die außerhalb dieses Konstrukts liegen, sind dabei nicht ohne weiteres erreichbar. Der Grund liegt in der Auflösung der MAC Adressen. Die externen Rechner wissen nicht wie sie den virtuellen Gast erreichen können, da dessen MAC ihnen nicht bekannt ist. Um dies zu ändern, bedarf es eines Stellvertreters der die Anfrage entgegen nimmt und weiterleitet. Dies ist der Auftritt des Arp (Address Resolution Protocol - es ordnet in einer Tabelle die MAC Adressen einer IP Adresse zu, welche mit dem Programm arp -a ausgelesen werden kann) Proxy.

Für die Netzwerkkarte vif<Nummer>.0 hat dies bereits das Xen Script vif-route getan. Um dies auch für die realle Netzwerkkarte eth0 zu aktivieren, bedarf es eines einfachen Befehls:

dom0:# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

Unter Umständen kann sich dies von Kernel zu Kernel unterscheiden. Ein find Befehl hilft da weiter:

dom0:# find /proc/sys/net -name "*arp"

Im späteren Verlauf werde ich ein solches Szenario aufzeigen.

NAT

Eine eher selten genutzte Methode bietet Xen ebenfalls. NAT- welches für Network Address Translation steht. Diese Art der Netzwerkverbindung ermöglicht es, mit lediglich einer öffentlichen IP Adresse, mehrere Gäste in Betrieb zu nehmen. Dabei werden die IP Adressen der Gäste auf die öffentliche IP Adresse des Wirts umgesetzt. Dieses Verfahren wird in der heutigen Zeit millionenfach angewandt, nämlich wenn das heimische Netzwerk mit dem Internet kommunizieren möchte. Dabei kommen entsprechende Hardware Router oder auch Software zum Einsatz, die diese Umsetzung erledigen.

Die DomUs sind auf diese Weise jedoch nicht ohne weiteres von außen zu erreichen, daher bedarf es entsprechender Firewall Regeln, die z.B. den Verkehr bestimmter Ports auf die jeweiligen Maschinen um- bzw. weiterleiten.

Im unteren Teil der Anleitung, finden sich entsprechende Beispiele.

Ein Schema sähe so aus:

                         +---- domU
                         |
eth0 --- NAT --- bridge0 |---- domU
                         |
                         |     ... 

Xen in der Praxis

Für die nachfolgenden Erklärungen und Beispiele, ist es sinnvoll ein- oder zwei virtuelle Maschinen zur Verfügung zu haben. Von daher beschäftigen wir uns nun mit der Installation von Xen selbst und die Einrichtung etwaiger Gäste.

Hardware

Für die ersten Gehversuche reicht ein Standardrechner mit etwa 512 bis einem Gigabyte Ram. Als Taktrate sollten mindestens 1Ghz zur Verfügung stehen, weniger gehen zwar auch, wenngleich mit leichten Einschränkungen der Performance ;-).

Wenn Xen produktiv eingesetzt wird, kann man nur sehr schlecht pauschal sagen: Mindestens n Gigabyte Ram und n Gigaherz. Es kommt sehr stark darauf an, wie vielen Gästen der Wirt eine Unterkunft bieten soll, und welche Aufgaben die Gäste übernehmen.

Der Verfasser dieser Anleitung betreibt seit Monaten erfolgreich ein mittelmäßig ausgelastetes System mit 2Ghz und einem Gigabyte Ram. Darauf laufen ein Web-, ein Mail- sowie ein Jabberserver.

Installation

Wer Xen einsetzen möchte, dem bieten sich zwei Möglichkeiten: Zum einen die Distributions- Pakete einspielen, zum zweiten aus den Quellen installieren. Ersteres hat den Vorteil das sämtliche Abhängigkeiten gleich mit installiert werden und ein Update einfacher ausfällt sowie die Basisinstallation auf ein abolutes Minimum reduziert werden kann.

Wenn jedoch der eingesetzte Kernel, den die Distribution zum Xen mitliefert, nicht den Ansprüchen genügen sollte, oder das Xen Paket selbst zu alt ist, hilft nur eine Installation aus den Quellen. Es empfiehlt sich sehr stark die Quellen auf einem Entwicklerrechner zu übersetzen und erst das fertig geschnürte Paket auf den Zielrechner zu kopieren. So wird unnötiger Ballast, bspw. Software wie gcc und Entwickler Dateien, vom Wirt ferngehalten.

Datenspeicher

Es gibt drei Möglichkeiten den Gästen ein Zuhause zu bieten:

• Per loop eingebundene Dateien, die wir wie Blockgeräte behandeln, welche ein Dateisystem zuzüglich Betriebssystem beinhalten
• Physikalischen Datenträgern, zu denen in der Xen-Analogie auch Logical Volumes zählen (iSCSI und Co. sind selbstverständlich mit dabei)
• Ein Root Dateisystem, welches per NFS eingebunden wird.

Die erste Variante ist am einfachsten umzusetzen und bedarf nur entsprechenden Plattenplatz, während die Zweite am flexibelsten und bevorzugte Variante ist. Im nachfolgendem Bild wurde der Durchsatz auf einem Ext3 Dateisystem mittels eines einfachen bonni++ Benchmarks ( bonnie++ -uroot -s256 -m vm01-diskimage -x1 -b ) getestet. Die Option -n1024 musste ich leider weglassen, mangels Plattenplatz.

Gut zu erkennen ist, dass LVM wesentlich weniger Zeit benötigt um die Dateien anzulegen, zu löschen etc. Des weiteren fällt der geringere CPU Bedarf auf, somit ist klar, dass LVM weit aus weniger Overhead verursacht.

Xen unter Debian Etch

Debian in der Version 4.0 mit dem Namen Etch, bietet in seinem Softwarebestand Xen in der Version 3.0.3 an. Die aktuelle Fassung liegt derzeit (01.06.07) bei Xen 3.1.0. Doch die Debian Variante wird in den meisten Fällen sicher genügen.

Da wir ein absolutes minimal System wünschen, wird bei der Grundinstallation nichts installiert. Etch bietet während der Installation an, eine Kollektion auszuwählen, für Web, Mail, Desktop etc. Dort einfach alle Haken entfernen.

Ist das Basissystem soweit installiert worden, sollten zunächst, sofern noch nicht während der Installation geschehen, die Software-Quellen Liste angepasst werden. Ein einfaches Beispiel könnte so aussehen:

• /etc/apt/sources.list

deb http://security.debian.org/ etch/updates main contrib deb http://ftp.de.debian.org/debian/ etch main contrib non-free

Darauf folgt ein Update der Datenbank und falls nötig, ein Update der bereits installierten Software:

dom0:# apt-get update && apt-get upgrade

Ist auch das geschehen, so kann die Xen Software an sich installiert werden. Dabei unterscheidet Debian zwischen folgenden Varianten:

1. Xen Hypervisor - Für CPU Typen ohne spezielle Fähigkeiten
2. Xen Hypervisor PAE - Für die Unterstützung von mehr Arbeitsspeicher jenseits der vier Gigabyte auf 32Bit Architekturen
3. Xen ioemu - Für die Unterstützung von Virtualisierungs CPUs, wie sie Intel Vanderpool und AMDs Pacifica bieten (Hardware Virtualisierung)

Xen Pakete installieren

In diesem Beispiel installiere ich folgende Pakete:

# apt-get install grub iproute linux-image-2.6-xen-686 xen-hypervisor-3.0.3-1-i386-pae libc6-xen bridge-utils

PAE-Version Unbedingt die -pae-Version des Hypervisors installieren. linux-image-2.6-xen-686 ist scheinbar mit PAE-Unterstützung compiliert und läuft nicht mit der nicht-PAE Version. Die Fehlermeldung ist: Panic on CPU0 Could not set up DOM0 guest OS

Apt wird dafür sorgen, dass alle notwendigen Pakete installiert werden. Besonders wichtig sind vor allem Grub, welches mittlerweile unter Etch Standard ist, und libc6-xen. Einzig Grub ist in der Lage den Kernel von Xen zu starten, weshalb kein Lilo verwendet werden kann. Des weiteren kommt noch eine speziell angepasste glibc6 hinzu.

Glibc Hinweise: Diese Problematik betrifft ausschließlich 32Bit systeme. Die 64Bit Systeme bedürfen keiner angepasster Glibc und laufen so. Ab Xen 3.0.3 darf nicht mehr der Trick die /lib/tls zu löschen, bzw. umzubennen, angewandt werden. Hier muss nach einer kompatiblen glibc geschaut werden. Um zu überprüfen, ob die vorliegende Glibc dafür bereits vorbereitet wurde, kann dies mit folgendem tun: cat /proc/self/maps Es sollte ein /lib/i686/nosegneg/libc-2.x.so erscheinen, wobei "x" die entsprechende Version ist.

Für eine einfache und schnelle Installation von Gästen, die ebenfalls auf Debian basieren, kommt noch ein zusätzliches Paket dazu:

dom0:# apt-get install xen-tools

Die xen-tools eignen sich prinzipiell auch für RPM basierende Systeme, mittels rpmstrap. Die Scripte dazu liegen in /usr/lib/xen-tools/scripts Allerdings wurden sie schon lang nicht mehr aktualisiert, sodass sie dringend einer Überarbeitung bedürfen.

Boot Manager Grub

Ist soweit alles installiert, sollte Apt einen Eintrag in die Bootmanager Konfiguration eingepflegt haben:

• /boot/grub/menu.lst

title Xen 3.0.3-1-i386-pae / Debian GNU/Linux, kernel 2.6.18-4-xen-686 root (hd0,1) kernel /boot/etch/xen-3.0.3-1-i386-pae.gz module /boot/etch/vmlinuz-2.6.18-4-xen-686 root=/dev/mapper/daten-etch ro console=tty0 module /boot/etch/initrd.img-2.6.18-4-xen-686

Über den Grub haben wir Möglichkeiten, auf das spätere Verhalten unseres Wirts - Dom0 - Einfluss zunehmen. In diesem Fall wird der Hypervisor als Kernel gestartet, welcher dann den eigentlichen Linux Kernel ausführt. Diese Reihenfolge ist unbedingt zu beachten, da sonst das System nicht startet.

Wer dem Kernel weitere Parameter mitgeben möchte, muss diese in der module Zeile des Linux Kernels eintragen und nicht in der Kernel Zeile.

Xen aus den Quellen

Wer mit dem Gedanken spielt Xen aus den Quellen zu übersetzen, muss mit bedenken, dass einige Pakete eingespielt werden müssen, die eigentlich nichts auf einem Server verloren haben. Daher sei dringend angeraten dies auf einer eigenen Entwicklermaschine (od. gar in einem Gast) vorzunehmen.

Xen nutzt als Versionsverwaltung Mercurial und stellt die Quellen dem entsprechend so zur Verfügung, dass wir diese mit dem selben Tool herunterladen und auch aktualisieren können. Desweiteren benötigt es noch entsprechende Pakete wie den gcc oder auch Entwickler-Pakete.

Bevor eine Installation aus den Quellen erwogen wird, ist darauf zu achten, dass sich keine Xen Reste mehr auf dem System finden, da es sonst zu Problemen kommen kann

Xen aus den Quellen - Debian Etch

Als ersten besorgen wir die notwendigen Programme:

• Programm und Entwicklerpakete installieren

dom0:# apt-get install build-essential mercurial libssl-dev graphviz gettext python-dev zlib1g-dev libncurses5-dev xorg-dev bridge-utils iproute bcc gawk

Xen stellt für jede Testversion einen entsprechenden Zweig zur Verfügung. Diese wären:

• xen-3.3-testing.hg : pre-release of the next 3.2 version of Xen
• xen-3.2-testing.hg : pre-release of the next 3.2 version of Xen
• xen-3.1-testing.hg : pre-release of the next 3.1 version of Xen
• xen-3.0.4-testing.hg : pre-release of the next 3.0.4 version of Xen
• xen-3.0.3-testing.hg : pre-release of the next 3.0.3 version of Xen
• xen-3.0-testing.hg : pre-release of the next 3.0.2 version of Xen

[...]

Xen 3.1

Je nachdem, für welchen Zweig man sich nun entscheidet, kann man die Quellen beziehen. Als Beispiel wird hier nun ein 3.1-testing verwendet.

Hier erstellen wir nun das passende Verzeichnis

dom0:# mkdir /usr/src/xen-3.1 dom0:# cd /usr/src/

Als nächsten müssen wir mit dem Kommando hg von Mercurial, die Versionsverwaltung initialisieren und können dann die Quellen beziehen:

dom0:/usr/src/# hg init xen-3.1 dom0:/usr/src/# cd xen-3.1 dom0:/usr/src/xen-3.1# hg pull http://xenbits.xensource.com/xen-3.1-testing.hg dom0:/usr/src/xen-3.1# hg update

Danach findet sich in diesem Verzeichnis auch eine lesenswerte README Datei, welcher wir folgendes entnehmen können:

dom0:/usr/src/xen-3.1# make world dom0:/usr/src/xen-3.1# make install

Sollten Fehler auftreten, hilft es zumeist ein wenig nach oben zu scrollen und vor allem nach Meldungen wie No such file Ausschau zu halten. Des weiteren empfiehlt es sich dringend die Kernel- Konfiguration zu überarbeiten, da viele überflüssige Module übersetzt werden. Dies kann mit folgendem Befehl bewerkstelligt werden:

dom0:/usr/src/xen-3.1# make linux-2.6-xen-config CONFIGMODE=menuconfig od. dom0:/usr/src/xen-3.1# make linux-2.6-xen-config CONFIGMODE=xconfig

Da für den Gast in der Regel keine Hardware Treiber benötigt werden, können wir auch zwei Unterschiedliche Kernel Varianten übersetzen lassen. Der Gast Kernel ist dann von dem gesamten Treiber Ballast befreit:

dom0:/usr/src/xen-3.1# KERNELS="linux-2.6-xen0 linux-2.6-xenU" make world

Wer mehr als 4GB Ram in seinem Rechner stecken hat, sollte PAE aktivieren:

dom0:/usr/src/xen-3.1# KERNELS="linux-2.6-xen0 linux-2.6-xenU" XEN_TARGET_X86_PAE=y make world

Möchte man die Quellen erneut übersetzen lassen, ohne die Konfigurations- Datei bearbeitet zu haben (Makefile), reicht folgendes, wobei die Installation dann im Verzeichnis dist zu finden ist:

dom0:/usr/src/xen-3.1# make dist

Wurde Xen und der jeweilige Kernel übersetzt, ist es wichtig darauf zu achten, auch die passende Initrd Ramdisk zu erstellen. Unter Debian reicht folgender Befehl:

dom0:/usr/src/xen-3.1# mkinitramfs -o /boot/initrd.img-2.6-xen 2.6.18-xen

Dieser Befehl erstellt die RAMDISK in /boot mit dem Namen initrd.img-2.6-xen und den Kernel Modulen von /lib/modules/2.6.18-xen. Die Versionsnummer ist bei Bedarf anzupassen.

Diese RAMDISK wird dann dem Grub übergeben.

Xen 3.3

Unter Xen 3.3 ist das Verfahren ein wenig einfacher geworden. Xen stellt keine vorgefertigten Pakete mehr zur Verfügung, sodass man auf die vom Distributor angewiesen ist. Möchte man dennoch Xen 3.3 einsetzen, so lädt man sich einfach das Quellen Paket herunter:

dom0:/usr/src# wget http://bits.xensource.com/oss-xen/release/3.3.1/xen-3.3.1.tar.gz dom0:/usr/src# tar xzf xen-3.3.1.tar.gz

Als nächstes müssen erneut die Entwicklerpakete herunter geladen werden, wie schon in Xen 3.1 angegeben.

ist dies auch geschehen, können wir in das Verzeichnis gehen und Xen übersetzen lassen:

dom0:/usr/src# cd xen-3.3.1 dom0:/usr/src/xen-3.3.1# make world && make dist

Wichtig ist hierbei, dass eine Internetverbindung besteht, da das Makescript die Kernelquellen aus dem Netz zieht, sowie noch einige andere Pakete, unter anderem für die Full-Virtualization - sprich - um z.B. Windows installieren zu können.

In dem oben genannten Befehl make world wird erst einmal Xen übersetzt, sowie ein Kernel und die dazu gehörigen Module. Da Xen hier so ziemlich jedes Modul aktiviert, dauert der Vorgang auf einem AMD Dualcore etwa 30-45 Minuten. Der zweite Befehl make dist im Anschluß erstellt das Verzeichnis dist/ in welchem sich alles befindet und praktischerweise auf einem anderen Computer kopiert werden kann, um auch Xen dort zu installieren.

Der Autor bevorzugt eine separate Entwicklerumgebung um Xen zu übersetzen, um die Dom0 mit möglichst wenig Pakete zu überladen. Diese Umgebung kann auch ohne weiteres innerhalb einer Chroot Umgebung laufen.

Um den Kernel ein wenig abzuspecken, kann natürlich auch dieser angepasst werden, wie bereits in Xen 3.1 aufgezeigt. Die Konfigurationsdatei wird dann in z.B. build-linux-2.6.18-xen_x86_64/.config erwartet. In diesem Fall hat Xen eine 64Bit Umgebung erkannt, sodass er automatisch einen 64Bit Kernel erstellt.

Für die Installation genügt nun ein:

dom0:/usr/src/xen-3.3.1# ./install.sh

Bitte auch hier nicht vergessen, die Ramdisk zu erstellen und die Grub Konfiguration anzupassen. Mittlerweile genügt es unter Debian Etch folgendes aufzurufen:

dom0:# update-grub

Damit wird dann automatisch die Grub Konfiguration erweitert, da das Script hier den Xen Kernel erkennt.

Hinweise

Ab Xen 3.2 hat sich ein wenig die Geräte Verwaltung geändert. Die Festplatten werden nun nicht mehr (zwangsweise) per /dev/sda angesprochen, sondern über z.B. /dev/xvda welche für einen höheren Durchsatz sorgen sollen. Des weiteren wird auch die Xen Console anders angesprochen. Wer dies nicht beachtet, wird beim erzeugen der DomU nur sehen:

[...]
md: md0 stopped.
md: md1 stopped.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
EXT3 FS on xvda1, internal journal
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver

Es wird also keine Konsole angezeigt, für den Login. Je nach Netzwerk ist aber ein Login über SSH möglich. Um auch die Konsole wieder zu erhalten, muss in der DomU Distribution dafür sorgen, dass udev installiert ist und in der /etc/inittab folgender Inhalt zu finden ist:

• /etc/inittab

x0:2345:respawn:/sbin/getty 38400 xvc0

Damit Root sich auf von dieser einloggen darf, bedarf es einer Erweiterung der /etc/securetty:

• /etc/securetty

xvc0

Und als letztes die angepasste Xen DomU Konfiguration:

• /etc/xen/domu.cfg

[...] extra = 'xencons=xvc0 console=xvc0'

Damit sollte nun auch eine Xen Konsole ab Xen 3.2 wieder funktionieren.

Der Start

Ist das erfolgt, wird ein Reboot nötig, um den um Xen erweiterten Kernel zu starten. Während des Starts laufen diverse Meldungen über den Bildschirm. Da wären zum einen die Meldungen vom Linux Kernel selbst, und zum anderen die Meldungen von Xen. Da diese viel zu schnell vorbei fliegen, können wir uns diese nachträglich anschauen. Dazu verwenden wir das Standard Programm dmesg, um auf den Ringpuffer des Kernel zuzugreifen, und wir nutzen das erste Mal das Managmentwerkzeug xm, für die Xen Nachrichten. Wir rufen es folgendermaßen auf:

dom0:# xm dmesg

In den Meldungen können wir ablesen, wie viel Arbeitsspeicher Xen für sich beansprucht und auch wie viele Prozessoren gefunden und aktiviert wurden.

Der Xend Daemon

Nach der Installation und dem Start, können wir uns ein wenig näher mit dem eigentlichen Daemon von Xen beschäftigen, dem xend bzw. dessen Konfiguration. Noch einmal zur Erinnerung: er ist für die Verwaltung der Gäste etc. zuständig und führt die Kommandos aus, die er via xm erhält.

Wie es sich für einen Daemonen gehört, verfügt er über eine Konfigurationsdatei /etc/xen/xend-config.sxp. Diese ist an sich schon recht gut dokumentiert, daher werde ich sie nur in Auszügen erläutern.

Bei einigen Parametern, welche mit einem # beginnen, kann dies zum einen der Standardwert sein, zum Anderen kann aber auch die betreffende Zeile der Abschaltung dienen. Dies muss gegebenenfalls überprüft werden. Als Faustregel gilt, dass sicherheitskritische Parameter einer Aktivierung bedürfen:

Die Konfigurationsdatei

• /etc/xen/xend-config.sxp

#(logfile /var/log/xen/xend.log)
#(loglevel DEBUG)

Hier bestimmen wir, wohin die Logdatei geschrieben wird und wie ausführlich diese ausfällt.

#(xend-http-server no)
#(xend-port            8000)

Hiermit können wir eine sehr rudimentäre Webschnittstelle aktivieren, die uns ein paar wenige Basiskommandos ermöglichen.

Der Zugriff erfolgt über dieses Schema:

http://<IPAdresse>:8000/xend/domain/<name-der-domain>

Der Schnappschuss zeigt das Ergebnis

#(xend-relocation-port 8002)

Wird eine Maschine migriert, läuft das über diesen Port

#(xend-address )
#(xend-address localhost)

Wird der HTTP Server aktiviert, so können wir hier bestimmen, wer darauf zugreifen darf. Bei einem leeren Eintrag ' ', kann dies von überall aus getan werden.

Doch Vorsicht, es findet keine Authentifizierung statt

#(xend-relocation-address )

Besitzt der Rechner mehrere Netzwerkkarten bzw. IP-Adressen, so kann hier definiert werden, über welche die Migration stattfinden soll, bzw. kann. Auch hier gilt ein leerer Eintrag als: "von überall aus"

#  (xend-relocation-hosts-allow '^localhost$ ^.*\.example\.org$')
#(xend-relocation-hosts-allow )

Über diesen Einträge kann bestimmt werden, welche Rechner die Erlaubnis (IP/DNS) haben, Gäste auf diesen Wirt zu übertragen. Dabei können auch reguläre Ausdrücken helfen. Auch hier findet keine sonstige Authentifizierung statt.

(network-script network-bridge)

Dies ist der passende Eintrag, wenn Xen die Bridge verwenden soll. Xen wird die eth0 verwenden und die Brücke darauf aufbauen.

Unter Debian Etch wird dieser Eintrag auskommentiert und dafür (network-script network-dummy) aktiviert. Damit wird keine Bridge erstellt

#(network-script 'network-bridge netdev=eth1')

Soll statt der eth0 eine andere Karte verwendet werden, kann dies über netdev=ethx angegeben werden.

# (network-script 'network-bridge bridge=<name>')

Auch der Name der Bridge lässt sich anpassen. Ansonsten heißt sie xenbr0

#(network-script network-dummy)

Dieses Script ist unter Etch aktiviert. Es macht schlicht nichts. Doch wem die vorhandenen Scripte nicht reichen, derjenige kann sich sein eigenes Netzwerkscript erstellen und entsprechend einsetzen.

#(network-script 'network-bridge bridge=<name>')
(vif-script vif-bridge)

Die vif Scripte bestimmen, wie die virtuellen Netzwerkkarten der Gäste konfiguriert werden. Bei einem Bridge Setup sollten auch die virtuellen Netzwerkkarten entsprechend konfiguriert werden. Wurde der Name der Bridge geändert, muss davon auch das vif-Script in Kenntnis gesetzt werden.

#(network-script network-route)
#(vif-script     vif-route)

Wird statt der Bridge ein Routen- basiertes Setup verwendet, so gilt es diese beiden zu aktivieren. In der Konfiguration des Gastes muss entsprechend das vif = [ 'ip= 192.168.4.1' ] gesetzt werden. Nur dann kann das vif-script eine Route in der Dom0 zu diesem Client erstellen.

#(network-script network-nat)
#(vif-script     vif-nat)

Für NAT sind diese beiden Einträge zuständig.

(dom0-min-mem 196)

Dieser Parameter bestimmt, wie viel MB Arbeitsspeicher dem Wirt für die Domain-0 mindestens zur Verfügung stehen. Wird ein Gast gestartet welches dazu führen würde, dass der Arbeitsspeicher unter diesen Wert sinkt, bricht xend den Vorgang ab und meldet den Arbeitsspeichermangel.

(dom0-cpus 0)

Hier können wir angeben, über wie viele CPU Kerne Dom0 verfügen darf. Per Default ist kein Limit gesetzt und es werden alle verwendet.

#(enable-dump no)

Sollte es häufiger zu Fehlern kommen, können Speicherabbilder erstellt werden, die den Xen Entwicklern helfen können.

#(vnc-listen '127.0.0.1')

Um ein grafisches Bild von einem Gast zu erhalten, kann dazu VNC verwendet. Hier können wir bestimmen, an welcher Adresse der VNC server lauscht. Soll er an allen Adressen lauschen, so ist als Adresse 0.0.0.0 einzutragen.

xm - das Werkzug

Weiter oben wurde bereits erwähnt, das xm das Programm ist, um dem xend Daemon mitzuteilen, was wir gerne von ihm möchten. Dazu bietet es uns mehrere Möglichkeiten, die wir mit folgenden Befehl angezeigt bekommen:

dom0:# xm help

Dabei werde ich die wichtigsten herausgreifen

console             Verbindet uns mit einer Console der gewünschten DomU
create               Erzeugt einen neuen Gast mittels seiner Konfigurationsdatei            
destroy             Versucht die angegebene DomU zu eliminieren
list                     Listet alle gestarteten Domains auf
mem-max          Legt die maximale Reservierung des Arbeitsspeichers für die DomainU fest
mem-set            Hiermit bestimmen wir den neuen verfügbaren Arbeitsspeicher, den der Gast nutzen kann
migrate              Wird verwendet, um einen Gast auf einen neuen physischen Rechner zu übertragen
pause                Pausiert die angegebene DomainU
reboot               Veranlasst einen Reboot des Gastes
rename             Benennt die virtuelle Maschine um
restore              Stellt einen Gast wieder her, der vorher gespeichert wurde
save                  Speichert den aktuellen Zustand der DomainU für eine Wiederherstellung
shutdown          Fährt den Gast herunter
top                     Liefert eine Übersicht über die Domains - Das Programm xentop wird aufgerufen
unpause            Führt eine DomainU fort, welche vorher pausiert wurde
uptime               Zeigt, wie lang ein Gast bereits arbeitet
vcpu-list            Listet die virtuellen CPUs auf, die verwendet werden      
vcpu-pin            Steuert, welche virtuelle CPU, welchen CPU-Kern verwenden kann
vcpu-set            Setzt die Anzahl der aktiven VCPUs fest, für eine DomainU
dmesg               Gibt die Ring-Puffer Meldungen aus, die sich auf Xen selbst beziehen.
info                   Gibt zahlreiche Informationen aus,                 
log                    Zeigt Logmeldungen an

Gäste erstellen

Um xm in Aktion zu sehen, hilft es, wenn mindestens zwei Gäste laufen. Um diese am schnellsten zu erzeugen, nutzen wir das Debian Xen Tool, welches wir vorher schon installiert haben. Dieses Tool unterstützt verschiedene Distributionen wie, Debian (Sarge, Etch) Ubuntu (Dapper ..), CentOS etc.

Xen Tool

Nach der Installation des Debian Xen Tools, besitzen wir ein paar neue Programme:

/usr/bin/xen-create-image

Erzeugt virtuelle Gäste auf unterschiedlichen Wegen

/usr/bin/xen-delete-image

Löscht einen Gast wieder

/usr/bin/xen-list-images

Listet die Gäste auf z.B. mit IP Adresse, Namen und Arbeitsspeicher

/usr/bin/xen-update-image

Hängt einen nicht laufenden Gast in Dom0 ein und führt eine apt-get update && apt-get upgrade aus. Funktioniert daher nur auf Debian basierten Gästen.

Mittels dieser Helferlein, können wir innerhalb weniger Minuten unsere Gäste automatisiert erzeugen.

Wir können dem Programm xen-create-image jede Menge Parameter mit auf den Weg geben, oder einen großen Teil davon in seiner Konfigurationsdatei vorgeben.

Eine gekürzte Fassung kann so aussehen:

• /etc/xen-tools/xen-tools.conf

dir = /home/xen # Wird kein LVM verwendet, werden die Images der Gäste in diesem Verzeichnis abgelegt, in der Struktur: # /home/xen/domains/<domainname>/<disk.img> und <swap.img> # Das Verzeichnis muss vorher angelegt werden! # lvm = daten # Wird LVM verwendet, so können wir hier bestimmen, aus welchem Pool das Tool sich bedienen soll # Hier bestimmen wir die Methode, wie der Gast installiert wird. Dabei stehen uns verschiedene Varianten zur Verfügung # - Installation via des debootstrap Kommandos # - Installation via des rpmstrap Kommandos # - Installation durch kopieren aus Verzeichnissen einer bestehenden Installation # Hinweis: Wird die copy Funktion genutzt, muss angegeben werden, um welche Distribution es sich handelt, # da noch automatisch Änderungen vorgenommen werden, im Zielsystem, # - Installation durch entpacken einer gesicherten Tar Datei # copy = /pfad/zur/bestehenden/installation debootstrap = 1 # rpmstrap = 1 # tar = /pfad/zur/img.tar # Ab diesem Teil widmet sich das Tool der Große, der Behälter für die Gäste size = 1Gb # Größe des Datenträgers memory = 128Mb # Zugewiesene Arbeitsspeicher swap = 128Mb # Größe der Swap # noswap = 1 # Wenn wir keine Swap möchten fs = ext3 # Das verwendete Dateisystem dist = etch # Die Default Distribution image = sparse # Sparse legt die Datei nur so groß an, wie nötig, "full" alloziert die volle Größe der Datei. # LVM ignoriert diesen Wert. Die Option '''sparse''' muss vom Dateisystem unterstützt werden. # Die unterstützten Distributionen sind: # # sid - Debian # sarge - Debian # etch - Debian # dapper - Ubuntu # centos4 - CentOS 4 (nicht getestet) # fedora-core4 - Fedora Core 4 (codname stentz) (nicht getestet) ## # Netzwerk Parameter ## # Möchten wir eine Statische IP vergeben, so können wir sie hier vorgeben # gateway = 192.168.1.1 # netmask = 255.255.255.0 # Andernfalls aktivieren wir Netzwerk per DHCP # dhcp = 1 ## # Diverse Optionen ## # # Bereits heruntergeladene Dateien behalten, # wenn debootstrap verwendet wurde # cache = yes # # # Hier können wir interaktiv nach einem Root Kennwort gefragt werden, für den neuen Gast # # passwd = 1 # # # Gibt es auf dem Dom0 User Konten, die es auf dem Gast nicht gibt, so können diese # dort ebenfalls erstellt werden. # accounts = 1 # # # Hier wird der zu verwendende Kernel und dessen Ramdisk anzugeben. # Es empfiehlt sich mit Links zu arbeiten und erspart Tippfehler. # kernel = /boot/vmlinuz-2.6.18-4-xen-686 initrd = /boot/initrd.img-2.6.18-4-xen-686 # # Bei debootstrap und rpmstrap wird die Architektur angeben. # # arch=i386 # # # # Der zu verwendende Spiegelserver, für Debian basierte Gäste. # mirror = http://ftp2.de.debian.org/debian/ # # Das selbe für Ubuntu # # mirror = http://gb.archive.ubuntu.com/ubuntu/ # Hier geben wir an, ob der neue Gast nach dem erzeugen, gleich gestartet wird. # # boot = 1

Wer Gäste für bestimmte Anwendungszwecke erstellen möchte, kann dies mit Hilfe des Parameters --role bestimmen. Dabei finden sich im Verzeichnis /etc/xen-tools/role.d/ einige Beispiele für Debian, wie solche Dateien aussehen können.

---

Zurück zur Seite 1 Weiter zur Seite 3