Xen-Meister

Inhaltsverzeichnis

Mit der dritten Version des c't-Debian-Server legen wir noch mal nach: Er findet sich in einer 32- und 64-Bit-Version auf der Heft-DVD, bringt einen moderneren Xen-Kernel mit und erlaubt dadurch den Betrieb beinahe beliebiger Gastsysteme. Die Grundausstattung, die eine Fertig-Firewall (Endian) für den direkten abgesicherten Internet-Zugang und einen Small Business Server (SBS) mit Mail- und Dateidiensten (ClarkConnect) enthält, bildet die Basis für einen kleinen Büro- oder Heimserver.

Der Server lässt sich mit ein bisschen Geschick und Spaß am Tüfteln mit und unter Linux weiter ausbauen: Er zeichnet zum Beispiel als digitaler Video-Recorder TV-Sendungen auf und streamt Medien-Dateien ins Netz, kann aber auch ein Linux-Desktop-System zur täglichen Arbeit allzeit bereithalten. Mit einem geeigneten Prozessor, der Virtualisierung unterstützt, läuft auf dem Server nebenbei der Windows Home Server, der die Clients aus Redmond regelmäßig sichert, oder ein Windows-Desktop für Testzwecke.

Dieser Artikel hilft bei der Inbetriebnahme, beschreibt darüber hinaus aber auch die aktuelle Xen-Welt und verrät Konfigurationskniffe. Das Folgende ist deshalb auch für Nutzer anderer Xen-basierter Lösungen nützlich.

Um den c't-Debian-Server (oder Xen generell) zu installieren, brauchen Sie kein hochmodernes System: Ein Prozessor, der die PAE-Erweiterungen beherrscht, genügt. Das sind alle gängigen Intel-CPUs ab Pentium II mit Ausnahme einiger Mobil-Prozessoren, AMD ab Athlon und aktuellere Via C7. Die PAE-Erweiterungen wären nicht einmal technisch notwendig, sind aber allgemeiner Konsens für fertige Xen-Binärpakete.

Die Anforderungen im Speziellen: 256 MByte RAM sind mindestens nötig, damit die mitgelieferten Komponenten des c't-Debian-Server starten können. Wer beispielsweise längerfristig mit dem SBS arbeiten will, muss ihm allein so viel Speicher zur Verfügung stellen. Entsprechendes gilt natürlich für jede weitere virtuelle Maschine. Mit 8 GByte freiem Plattenplatz können Sie Gehversuche unternehmen; dauerhafter Betrieb braucht eher mehr. Eine Parallelinstallation mit anderen Betriebssystemen ist möglich, aber ohne Gewähr!

Grundbegriffe

Xen verwendet auch aufgrund seiner etwas andersartigen Technik abweichende Begriffe: virtuelle Maschinen heißen „Domains“. Eine Domain spielt für den Hypervisor eine besondere Rolle, da sie die Schnittstelle zur Hardware darstellt, abgekürzt Dom0 oder auch privilegierte Domain. Die zweite Sorte Domains heißen „DomU“, was für unprivilegiert steht. DomU-Instanzen greifen normalerweise nur über spezielle Treiber auf die Ressourcen zurück, die ihnen der Hypervisor bereitstellt; speziellen Treiber-DomUs kann man gezielt den Zugriff auf einzelne PCI-Geräte gestatten.

Ein dritter Typ, die HVM-Domains, kommen ins Spiel, wenn ein Prozessor mit Virtualisierungsfunktionen vorhanden ist. Erst dann ist Xen in der Lage, beliebige Betriebssysteme auszuführen. Die in einer Dom0 oder DomU ausgeführten Betriebssysteme müssen ansonsten für den Einsatz unter Xen modifiziert werden. Der Eingriff heißt Paravirtualisierung. Er ersetzt kritische, nicht virtualisierbare Funktionen durch Hypervisor-Aufrufe.

Die Grundinstallation des c't-Debian-Server richtet eine Dom0 auf Basis von Debian GNU/Linux 4.0r4a (Etch) ein und bestückt das System mit einer DomU mit der Endian-Firewall. In der Dom0 laufen nur wenige Dienste: ssh für den Fernzugriff, der DHCP-Server zum Verteilen der IP-Adressen und ein Name-Server fürs lokale Netz (bind9). Weitere Dienste sollte man innerhalb der Dom0 nur mit Bedacht hinzufügen, denn mit jedem wird die zur Verwaltung des ganzen Systems benutzte Dom0 verwundbarer – das spielt nicht allein auf Sicherheit an, sondern auch auf Betriebssicherheit.

Mit dem Installations- und Konfigurations-Frontend ctsrvcfg können Sie weitere DomUs hinzufügen: Außer dem SBS ClarkConnect bietet es mit dem Paket ctdomubuilder ein generisches Werkzeug an, das fast beliebige Debian-DomUs erzeugt. Eine Spezialität des c't-Debian-Servers ist es dabei, dass er DomUs in Form von Debian-Paketen einrichtet. Das heißt, alle Dateien (beziehungsweise logische Volumes – dazu gleich mehr) gehören zu einem Paket, sind mit einem Schlag entsorgbar und teilen Konfigurationsskripte, die bei der Anpassung an die jeweilige Server-Installation helfen.

Die weitgehend automatisierte Standardinstallation des c't-Debian-Server verwendet für die Aufteilung der Festplatte zwischen den virtuellen Maschinen das in Linux eingebaute Logical Volume Management (LVM2). Eine DomU erhält dann nicht eine Partition oder eine Datei als virtuelle Platte, sondern ein oder mehrere logische Volumes. Die Volume-Group heißt normalerweise „server“. Während der Installation wird ein Dummy-Volume namens „srv“ erstellt, das ctsrvcfg vor dem Einrichten der ersten DomU wieder freigibt.

Der Einsatz von LVM hat diverse Vorzüge: Ein Volume lässt sich, solange noch nicht zugeordneter Speicherplatz da ist, beliebig vergrößern (wenn niemand auf das Volume zugreift); gegebenenfalls stellt man LVM eine weitere Platte zur Verfügung. Der Platz muss nicht zusammenhängend vorhanden sein, wie das etwa bei Partitionen der Fall wäre. Außerdem fertigt LVM auf Zuruf Schnappschüsse von Volumes an, sodass man einen Zustand einfrieren und bei Bedarf wieder herstellen kann.

Bleibt noch ein wichtiges Detail der Dom0-Installation: ctsrvcfg richtet Software-Bridges ein, über die der Netzwerkverkehr nach draußen und ins interne Netz geleitet wird. Diese Bridges (extern und intern genannt) funktionieren wie Switches. Je nachdem, mit wem eine DomU kommunizieren soll, verbindet man ihre Netzwerkschnittstellen mit der entsprechenden Bridge, bei der Endian-DomU etwa mit extern für den Zugriff auf das DSL-Modem (oder eine andere Internet-Verbindung) und intern, um ihre Dienste ins lokale Netz zu reichen.

Nach dem Reboot in der Grundinstallation zeigt ctsrvcfg an, welche Netzwerkkarte es welcher Bridge zuordnet. Diese Zuweisung sollten Sie überprüfen, damit nicht womöglich internes und externes Netz vertauscht sind. Wenn Sie weitere Netzwerkschnittstellen ins Spiel bringen wollen, etwa eine fürs WLAN oder eine DMZ, so können Sie die Datei /etc/network/interfaces entsprechend erweitern. Die von anderen Distributionen genutzte Bridge, die Xen selbst anlegen kann, lassen wir übrigens links liegen, weil sie nur für eine einzige Instanz gut funktioniert.

Server-Starthilfe

Die Installation des c't-Debian-Server verläuft unspektakulär im Text-Modus. Nach dem Booten des PCs von der Heft-DVD können Sie zwischen einer nahezu vollständig automatisierten und einer manuellen Installation wählen. Die automatische Installation löscht auf einer Festplatte ohne freien Platz nach Rückfrage bestehende Partitionen – also Vorsicht!

Beim Start von der Heft-DVD steht eine 32- und eine 64-Bit-Variante zur Auswahl. Wenn das Zielsystem kein DVD-Laufwerk hat, können Sie die auf der Heft-DVD enthaltenen ISO-Dateien auf einen CD-Rohling brennen (i386 für die 32-Bit-Version, amd64 für die 64-Bit-Version, egal ob Intel oder AMD). Welches System installiert wird, hängt von der Eingabe am Boot-Prompt ab; für die 64-Bit-Fassung hängen Sie „64“ an „manual“ beziehungsweise „auto“ an.

Wenn Sie DNS-Domain- und Rechnernamen oder IP-Adressen selbst eingeben wollen, wählen Sie die manuelle Installation. Die dabei erfragten Daten zu Gateway, DNS-Server und DNS-Domain nutzen die Installationsroutinen zur Vorkonfiguration der Dienste (DHCP und Nameserver) und für die der virtuellen Maschinen, etwa der Firewall.

Eine manuelle Installation empfiehlt sich auch dann, wenn weitere Betriebssysteminstallationen auf der Festplatte erhalten bleiben sollen oder wenn Sie die Aufteilung der Festplatte beeinflussen wollen. Das Logical Volume Management (LVM) sollten Sie nutzen. Wer partout darauf verzichten will, kann das tun. ctsrvcfg kann virtuelle Maschinen auch in Image-Dateien anlegen, benötigt dafür dann aber reichlich Platz in /var/lib/xen.

Da der verwendete 2.6.18er-Kernel schon etwas in die Jahre gekommen ist, findet die Installation unter Umständen keine Netzwerkkarte oder keine Festplatten. In solchen Fällen können wir wenig tun. Aufgrund minimaler Unterschiede zwischen dem Kernel der Installationsroutine und der installierten Xen-Variante kann es des Weiteren zu kleineren Unstimmigkeiten kommen, die sich mit ein wenig Improvisation überwinden lassen.

Findet der zweite Installationsteil nach dem Reboot die CD/DVD nicht, so könnte die zugeordnete Gerätedatei „verrutscht“ sein. Um dennoch fortzufahren, melden Sie sich auf der zweiten Console an (Alt-F2), durchsuchen die Startmeldungen des Kernels nach dem DVD-Laufwerk mit dmesg | grep DVD und merken sich die dabei ausgegebene Gerätebezeichnung, etwa /dev/hda und tragen dieses Gerät in der Datei /etc/fstab statt des dort für /media/cdrom0 hinterlegten ein. Nach dem Zurückwechseln auf die erste Console (Alt-F1) können Sie dann mit der Installation fortfahren.

Bei SATA-Platten, die im ersten oder zweiten Installationsteil nicht erkannt werden, kann es sinnvoll sein, die BIOS-Einstellungen zu variieren. Je nach BIOS-Setup heißen die entsprechenden Optionen „AHCI“, „Compatible Mode“ oder auch „Legacy Mode“. Wenn eine auf diese Weise erfolgreiche Grundinstallation nicht freiwillig bootet, kann es nötig sein, die Datei /etc/fstab und /boot/grub/menu.lst umzuarbeiten, alle Einträge von /dev/hda auf /dev/sda umzuschreiben oder vice versa.

Die Grundinstallation bietet nach einem Reboot zu Beginn an, die auf der DVD/CD enthaltenen Pakete auf die Festplatte zu kopieren; letztlich landet das Debian-Repository auf der lokalen Platte und wird von dem standardmäßig eingerichteten Minimal-Web-Server (dhttpd) ausgeliefert. Den Vorschlag sollten Sie annehmen, weil er die weitere Konfiguration und besonders das Erzeugen weiterer virtueller Maschinen erleichtert und beschleunigt. Das Repository von der Heft-DVD mit i386- und amd64-Paketen belegt rund ein GByte.

Nach abgeschlossener Installation erreichen Sie Ihren Server von einem Client-System aus dem gleichen lokalen Netz unter der URL server.zuhause.xx:82 oder unter der IP-Adresse, wenn der Client noch nicht mit dem Nameserver auf dem Server spricht. Die Minimal-Webseite verweist auf die mit dem Browser erreichbaren Konfigurations-Frontends, etwa für die Firewall oder den SBS, sofern Sie Letzteren mit installiert haben.

Firewall-Starthilfe

Um den Server und das lokale Netz über die virtualisierte Endian-Firewall ans Internet zu bringen, müssen Sie diese konfigurieren. Das geht über das Web-Interface, das auf der IP-Adresse 192.168.1.1 bei einer Standardinstallation erreichbar ist (andernfalls unter der Adresse, die Sie als Gateway eingegeben haben). Die Meldungen zu den nicht mit offiziellen Signaturen versehenen Zertifikaten sollten Sie zumindest inspizieren und erst dann abnicken. Anschließend fragt ein Einrichtungsassistenten Sprache und Zeitzone ab, fordert die GPLv2 zu akzeptieren und bietet an, eine Datensicherung wiederherzustellen. Das ist im Fall eines Updates auf die neue Version der Firewall oder bei einer Neuinstallation sehr praktisch.

Anschließend werden die Passwörter für den Zugang zur Firewall festgelegt: Als admin meldet man sich an das Web-Frontend an, als root kann man die Firewall bei zusätzlich aktiviertem ssh-Zugang durch die Hintertür per ssh erreichen. Ein Anmelden über die Console, die man per xm console endian in der Dom0 erreicht, ist erst möglich, wenn Sie in der Datei /etc/securetty die Xen-eigene Console xvc0 nachtragen.

Die Firewall startet nach Eingabe der Passwörter direkt mit der Abfrage der Netzwerkkonfiguration. Hier lassen sich in der virtualisierten Form ADSL per USB/PCI-Gerät, ISDN und Analog/UMTS-Modem nicht nutzen (wir haben das jedenfalls nicht getestet). Nach Wahl der Technik müssen Sie lokalen Netzwerkkarten Rollen zuordnen. Endian nutzt dazu Farben: Das grüne Netz ist das interne Bein der Firewall, das rote verbindet sie mit der Außenwelt. Diese sind in der Grundkonfiguration des c't-Debian-Servers mit den entsprechenden Bridges verbunden, sodass die Firewall die jeweiligen Netze über die Netzwerkkarten des Servers erreicht.

Achten Sie darauf, dass Sie bei der Auswahl der Netzwerkschnittstelle für externe Verbindungen die DNS-Einstellungen nicht übersehen. Meist genügt es, diese automatisch zu beziehen – anders als voreingestellt. Die MAC-Adressen sollten Sie sich merken: Es ist sinnvoll, sie fest in der Xen-Konfigurationsdatei für die virtuelle Maschine einzutragen, damit nicht bei jedem frischen Start neue generiert werden – in der Testphase, wenn Sie die Firewall oder den Server womöglich häufiger neustarten, sorgen wechselnde Mac-Adressen gern für bockende Clients (die sich die Mac-Adressen für eine IP-Adresse für eine Weile merken).

Gesetzt den Fall, Sie haben fürs grüne Netz die Adresse 11:11:11:11:11:11 und für das rote 22:22:22:22:22:22 angezeigt bekommen, so sollten Sie auf dem Server die folgende Zeile in der Datei /etc/xen/endian:

vif = [ 'bridge=intern','bridge=extern' ]

durch diese beiden ersetzen:

vif = [ 'mac=11:11:11:11:11:11,bridge=intern',
'mac=22:22:22:22:22:22,bridge=extern' ]

Fortan nutzt Xen diese Mac-Adressen für die virtuellen Netzwerkkarten. Nach Reboots bei den Tests müssen Sie nicht laufend dem Client per arp-Befehl alte Mac-Adressen für die Gateway-IP-Adresse austreiben.
Wenn sich die Endian-Firewall mit den eingegebenen Optionen neu gesammelt hat, zeigt sie eine Anmeldebox, an der Sie sich als Benutzer „admin“ mit dem zuvor vergebenen Passwort anmelden können. Bei korrekt eingegebenen Zugangsdaten hat die Firewall automatisch eine Verbindung ins Internet hergestellt.

Auf der Startseite finden Sie eine Warnung, dass nicht die aktuellste Kernelversion auf der Firewall läuft, die dadurch zustande kommt, dass der Kernel nicht in der RPM-Datenbank eingetragen ist. Das hat im Fall der virtualisierten Software seine Richtigkeit: Sie läuft nicht mit dem Original-Kernel, sondern einem speziell für Endian präparierten Kernel, den Jens Friedrich, der im ctserver.org-Forum als neobiker aktiv ist, gebaut und freundlicherweise zur Verfügung gestellt hat.

Apropos Versionen: Statt Kernel 2.6.22 läuft Kernel 2.6.21 – die Patches entsprechen den wesentlichen Ergänzungen der Endian-Entwickler. Und: Die Endian-Fassung die wir auf die Heft-DVD bringen können, ist ein Release Candidate, also keine von den Entwicklern für fertig erklärte Version. Sie ist aber sehr weit gediehen und so haben wir sie der inzwischen über ein Jahr alten Version 2.1 vorgezogen.

Wir haben mit den Endian-Entwicklern abgesprochen, dass wir kritische Updates via smart-Repository auf heise online bereitstellen. Hinweise, wie das geht, liefern wir auf den Projektseiten [1], sobald Updates verfügbar sind (ein entsprechender Eintrag im smart-Paketmanager der Installation ist bereits vorhanden). Bei Interesse wäre es möglich, dort auch ein Repository für Pakete aus der Community aufzubauen. Mit Erscheinen der finalen 2.2 können wir gegebenenfalls auch das ganze Paket als Update anbieten.

Gewöhnungsbedürftig ist die Art, wie man bei der neuen Endian-Version Port-Forwardings einrichtet: Zunächst definiert man die Regel, über welches Interface und auf welchem Port etwas hereinkommt und wohin es weiterzuleiten ist. Dann fügt man konkrete Adressen hinzu (über das Pluszeichen in den Knöpfen der definierten Regel), die die Firewall auch tatsächlich durchlässt. Das scheint auf den ersten Blick etwas verwirrend, hat aber für weitere Ports in den älteren Versionen schon ähnlich funktioniert.

SBS-Starthilfe

Nach dem Hinzufügen von ClarkConnect als virtuelle Maschine sollten Sie mit einigen Handgriffen zunächst dessen Konfiguration überprüfen. ctsrvcfg nimmt dort nur eine minimale Voreinrichtung von IP-Adresse und Passwort vor. Insbesondere bei einer manuellen Installation sollten Sie nach der Anmeldung als Benutzer root an die Administrationsoberfläche, die unter der IP-Adresse des SBS per HTTPS auf Port 81 erreichbar ist (standardmäßig https://192.168.1.3:81), die IP-Konfiguration überprüfen. Sie finden diese unter Netzwerk und dort unter IP-Einstellungen.

Wenn dort Nameserver-Einträge rot dargestellt sind, entfernen Sie diese und ersetzen Sie sie durch den nicht rotgefärbten Eintrag der Zeile darunter. Nach einem Klick auf den Ausführen-Knopf sollten rotgefärbte Felder verschwunden sein. Kontrollieren Sie bei einer manuellen Installation auch, ob das Gateway in den Einstellungen für die Netzwerkkarte passt – ctsrvcfg trägt diese Daten nicht ein. Damit haben Sie sichergestellt, dass die nötige Registrierung Ihres Systems bei Point Clark Networks auch klappt – erst dadurch können Sie den vollständigen Leistungsumfang des SBS benutzen, können weitere Module nachinstallieren und profitieren von Updates.

Für die Registrierung der SBS-Installation müssen Sie sich ein kostenloses Konto auf der Website von Point Clark Networks (www.clarkconnect.com) einrichten. Mit diesen Zugangsdaten füttern Sie dann die Funktion „System registrieren“, die Sie unter „Dienste“ finden. Wählen Sie anschließend „Ein neues System zu meinem Account hinzufügen“ und betätigen Sie den „Weiter“-Knopf.

Daraufhin erfragt das Web-Interface einen Namen für den Rechner, unter dem dieser nicht nur bei Point Clark Networks registriert wird, sondern Ihre externe IP-Adresse auch im dortigen DNS-Dienst eingetragen wird; im Web-Angebot bei Point Clark Networks können Sie den Namen ändern und die Funktion auch ganz abschalten. Zum Abschluss der Registrierung müssen Sie die Service-Bedingungen akzeptieren, die auf den kommerziellen Einsatz des SBS zugeschnitten sind. Die Community-Ausgabe, die der c't-Debian-Server mitbringt, ist auf zehn Mailboxen beschränkt.

Nach der Registrierung können Sie in ihrem SBS-Server nach Belieben schalten und walten. Standardmäßig ist der automatische Bezug von kritischen Updates aktiv. Das schließt auch solche ein, die aus einem (apt-)Repository von heise online kommen. In der Vergangenheit gab es für ClarkConnect Updates der C-Bibliothek, die den Betrieb unter Xen unnötig erschwerten. Gegebenenfalls können wir hier eingreifen, ohne dass Sie dazu an Ihrer Installation überhaupt Hand anlegen müssen. Entsprechende Updates werden wir auf den Webseiten des Projekts dokumentieren.

Bevor Sie Benutzerkonten für den Zugriff auf die Dienste von ClarkConnect einrichten können, müssen Sie in der „Account Verwaltung“ unter „Organization“ die Basisdaten für den LDAP-Server festlegen. Der enthält bei ClarkConnect die Account-Daten und lässt sich auch von anderen virtuellen Maschinen aus anzapfen [2]. Aus den eingegebenen Daten leitet ClarkConnect die für jeden neuen Benutzer ab. Außerdem erstellt es die für den Zugriff auf die Administration via HTTPS und andere Dienste verwendeten Zertifikate neu. Beim Anlegen eines Kontos müssen Sie auswählen, auf welche Dienste ein neuer Benutzer zugreifen darf – diese Liste erweitert sich mit der Installation weiterer Komponenten („Software Modules“ unter „Dienste“).

Im c't-Debian-Server 3 haben wir alle für den Betrieb eines Mailservers nötigen Module vorinstalliert inklusive dem auf Port 83 erreichbaren Web-Frontend für die E-Mail (Horde) und dem Maildrop-Modul, um Mail auf POP3- oder IMAP-Servern automatisch einzusammeln. Die Detail-Konfiguration müssen Sie allerdings selbst besorgen – Hinweise dazu finden Sie in älteren c't-Artikeln [3] und eine knappe Zusammenfassung im Wiki auf den Projektseiten im Web [1].

Mehr virtuelle Maschinen

Neben Firewall und SBS bringt der c't-Debian-Server ein Programm mit, das weitere virtuelle Maschinen generiert: ctdomubuilder. Es arbeitet Hand in Hand mit ctsrvcfg. Dort können Sie unter „domus“ ein Häkchen vor ctdomubuilder setzen. Das Konfigurations-Frontend fragt daraufhin die Eckdaten für die neue virtuelle Maschine ab. Beim ersten Aufruf legt ctdomubuilder ein Template für das jeweilige System an, das es bei weiteren Aufrufen als Vorlage hernimmt – das Erstellen einer neuen DomU dauert deshalb beim ersten Mal deutlich länger.

Derzeit befüllt ctdomubuilder die DomUs ausschließlich mit Debian. Wenn advanced=“false“ in der Datei /etc/default/ctdomubuilder auf „true“ geändert ist, dann können Sie außer dem zur Zeit stabilen Zweig von Debian (Etch) auch den Testzweig (Lenny) und den als „unstable“ markierten (Sid) in einer DomU einrichten lassen. Auf einem 64-Bit-System bietet ctdomubuilder dann auch die Wahl zwischen 32- und 64-Bit-Umgebungen in der DomU an; ein 32-Bit-Xen-System kann nur 32-Bit-Gäste ausführen, dort fehlt die entsprechende Wahlmöglichkeit.

ctdomubuilder verhält sich für ein Debian-Paket etwas merkwürdig, weil es von sich aus solche generiert, selbst dafür jedoch nur kurzfristig von ctsrvcfg installiert und sofort wieder deinstalliert wird. Dabei bleibt es als entfernt, aber nicht gesäubert im System hängen. Dadurch halten sich die erzeugten Dateien, etwa die Vorlagen, aber auch die Konfigurationsdatei in /etc/default für den nächsten Aufruf im System. Falls das Erzeugen einer neuen DomU schief geht, könnte es nötig sein, eine dabei unvollständig angelegte Vorlage zu entfernen – mit einem Handgriff geht das per dpkg –purge ctdomubuilder, betrifft dann aber alle Dateien. Weniger rabiat geht es auch, mehr dazu in [1].

Die per ctdomubuilder erzeugten virtuellen Maschinen bekommen in der Debian-Paketverwaltung als Namen ein „domu-“ vorangestellt. Der Befehl dpkg -l | grep "domu-" liefert eine Liste der auf diese Weise erzeugten DomUs. Mit dpkg --purge ctdomu-video würde eine DomU namens „video“ aus dem System verschwinden. Die Deinstallation räumt all ihre Hinterlassenschaften ab, darunter auch logische Volumes. Die von ctdomubuilder genierten Pakete sind nicht dafür gedacht, auf andere Systeme überspielt zu werden – Abhängigkeiten sind nicht hinreichend deklariert und nur im Fall von LVM-loser DomUs enthalten sie überhaupt die Dateisystemdaten.

Eine Schwäche der per Konfigurationsdatei beschriebenen Xen-DomUs lässt sich mit einem kleinen Trick ausgleichen: Normalerweise denkt sich Xen bei jedem frischen Start einer DomU eine neue Mac-Adresse aus. Das hat bei Debian-Etch und -Lenny im Zusammenspiel mit udev den Effekt, dass die Netzwerkkarte wandert: Beim ersten Boot ist es eth0, beim zweiten eth1 und so weiter. Bei statischen IP-Adressen ist die DomU beim zweiten Start netzlos. Lösen lässt sich das, indem man die Mac-Adresse in die Konfigurationsdatei aufnimmt – wie zuvor schon für die Endian-Firewall gezeigt. Eleganter wäre es, wenn das automatisch geschehen könnte.

Da es sich bei den Konfigurationsdateien um Python-Skripte handelt, liegt es nahe, diese entsprechend zu erweitern. Die von ctdomubuilder angelegten Konfigurationsdateien binden von sich aus schon eine Datei ein, um eine gemeinsame Variable für den Pfad zu den Xen-Binaries „xenpath“ zu besetzen (/etc/xen/ctsrvcommon). Diese Datei lässt sich durch Python-Code erweitern, der automatisch unbekannten Domains neue Mac-Adressen zuordnet; der Prototyp sah so aus:

import random
import shelve
import sys
import os.path
xenpath=os.path.dirname(sys.argv[0])+'/../'
if not name:
print 'Missing domu name, abort'
sys.exit(1)
macs=shelve.open('/etc/xen/macaddrs')
if not macs.has_key(name):
mac=[0x00, 0x16, 0x3e,
random.randint(0x00, 0x7f),
random.randint(0x00, 0xff),
random.randint(0x00, 0xff) ]
macs[name]=':'.join(map(lambda x: "%02x" % x, mac))
mymac=macs[name]
macs.close()
print 'Using mac: %s' % mymac


Eine darauf abgestimmte Konfigurationsdatei enthielt folgende Zeilen:

name='etch64'
execfile('/etc/xen/ctsrvcommon')
bootloader=xenpath+'/bin/pygrub'
memory='128'
root='/dev/xvda1 ro'
disk = [ 'phy:/dev/server/etch64_lv_root,xvda1,w',
'phy:/dev/server/etch64_lv_swap,xvda2,w' ]
vif = [ 'mac='+mymac+',bridge=intern' ]


Das ctsrvcommon-Skript funktioniert analog einem gesourceten Shell-Skript. Es erbt die Variablen des Hauptskripts (das die Datei umgebende Skript ist das in Python geschriebene Xen-xm-Kommando) und gibt die von ihm gesetzten Variablen in das Hauptskript zurück. Damit ctsrvcommon für jede DomU eine eigene Mac-Adresse generieren kann, muss die Variable name beim Aufruf gesetzt sein. Es gibt dann in mymac die individuelle und beim ersten Aufruf generierte Adresse zurück.

Eine länger ausfallende Variante des Skripts, die eine im Klartext lesbare und einem Texteditor änderbare Datei für die Zuordnungen benutzt, finden Sie auf den Projektseiten zum Download. Wir werden diese Fassung in eine spätere Version von ctdombuilder einbauen. An seine Grenzen stößt das Skript, wenn eine Domain mehr als nur eine Netzwerkschnittstelle hat, denen feste Mac-Adressen zugeordnet werden sollen.

Mehr Beispiele

Für andere Betriebssysteme, die unter Obhut des c't-Debian-Server laufen sollen, muss man von Hand eine Konfigurationsdatei stricken. Die sind nicht allzu verzwickt, sodass der Einsatz grafischer Werkzeuge für diesen Zweck eher Overkill darstellt. Zumal man damit die möglichst mager ausgerüstete Dom0 belasten müsste. Hinzu kommt, dass viele dieser Programme mit der aktuell stabilen Debian-Version nur mit Gewalt zu verheiraten sind – sie nutzen als GUI-Werkzeuge moderne Bibliotheken, die sich kaum mehr in Etch zum Laufen bringen lassen.

Einen Spezialfall stellen die HVM-Domains dar, die zum Ausführen nicht modifizierter Betriebssysteme wie Windows dienen. Hier legt man zunächst ein logisches Volume für die virtuelle Platte an:

lvcreate -L8G -nwinxp server

Der Befehl erstellt ein 8 GByte großes logisches Volume mit dem Namen „winxp“ in der Volume Group „server“. In der Annahme, dass auf dem Server im Verzeichnis /root die ISO-Datei der XP-Installations-CD mit dem Namen winxp.iso liegt, sieht die minimale Konfigurationsdatei so aus:

path='/usr/lib/xen-3.2-1'
kernel=path+'/boot/hvmloader'
device_model=path+'/bin/qemu-dm'
builder='hvm'
memory='512'
name='winxp'
boot='d'
disk=['phy:/dev/server/winxp,ioemu:hda,w',
'file:/root/winxp.iso,hdc:cdrom,r']
vnc=1
vncpasswd='peter'
vif = [ 'bridge=intern' ]
usbdevice='tablet'


Die Einträge sorgen der Reihe nach dafür, dass Xen die richtigen Programme findet, dass die DomU ein unmodifiziertes Gastsystem ist, dass dafür der HVM-Loader gebraucht wird, dass 512 MByte RAM bereitstehen sollen, dass die Festplatte aus einem logischen Volume besteht und hda heißen soll, dass das CD-Laufwerk als ISO-Datei vorliegt und hdb heißt, dass die Console des virtuellen Systems per VNC zugänglich und durch das Passwort „peter“ geschützt sein soll, dass das Netzwerk-Interface der DomU in der Bridge intern stecken soll und dass die VNC- und Windows-Mauszeiger innerhalb der VNC-Sitzung besser synchronisiert sein sollen.

Damit der Zugriff via VNC auf die Console der HVM-Domain klappt, müssen Sie dem Xen-Daemon erlauben, die VNC-Sessions übers lokale Netz anzubieten. Die entsprechende Option steckt in der Datei /etc/xen/xend-config.sxp und heißt vnc-listen. Statt der vorgeschlagenen Adresse „0.0.0.0“ sollten Sie defensiv die Adresse der internen Netzwerkkarte des Servers/der Dom0 eintragen. Vor dem Starten der HVM-DomU muss der Xen-Daemon mit /etc/init.d/xend restart neu gestartet werden, damit die Änderung wirksam wird.

Die zum Verbinden mit der virtuellen Console nötigen VNC-Clients gibt es eigentlich für jedes Betriebssystem. Sie fragen neben der IP-Adresse und dem Passwort auch die Display-Nummer ab. Die zählt VNC mit jeder aktiven HVM-Domain um eins hoch. Welche aktiv sind, verrät zum Beispiel der Aufruf von netstat -nat | grep ":59" – ab Port 5900 ff. lauschen die VNC-Server auf Verbindungen. Bei einigen Clients kann es nötig sein, Optimierungsoptionen abzuschalten, bis sie sich mit den Xen-VNC-Servern verbinden.

Weitere Beispiele für Xen-DomU-Konfigurationsdateien finden Sie auf den Projektseiten [1]. Dort gibt es unter anderem auch Hilfen, um mit DOS in die PC-Steinzeit abzutauchen, und zur Inbetriebnahme eines digitalen Videorecorders, der die PCI-DVB-Karten innerhalb einer DomU benutzt und dorthinein auch einen seriellen Port für den Betrieb eines LIRC-Empfängers reicht.

Weitermachen

Apropos LIRC: Anders als bisher für den c't-Debian-Server blieben wir zusätzliche Modulpakete für den Kernel, etwa für LIRC, EM8300 und cdfs, schuldig – die Header-Pakete zum verwendeten Xen-Kernel hatten eine Macke, sodass sich die Modulpakete mit dem Module-Assistant nicht bauen ließen. Abhilfe ist aber nicht weit: Im Repository auf heise online liegen für die Debian-Xen-Kernel entsprechende Pakete, um diese Geräte in einer DomU mit dem offiziellen Kernel in Betrieb zu nehmen – weitere Hinweise dazu finden Sie auf den Projektseiten.

Literatur

[1] Webseiten, Wiki, Bug-Tracker zum c't-Debian-Server

[2] Peter Siering, Kontroll-Tux, ClarkConnect mit LDAP, PAM und Samba, c't 20/07, S. 182

[3] Peter Siering, Betreutes Wohnen, Loslegen mit ClarkConnect Community, c't 4/07, S. 102

Soft-Link

---

Die Neuerungen im c't-Debian-Server 3

Seit Version 2 setzt der c't-Debian-Server zur Virtualisierung nicht mehr auf User Mode Linux, sondern auf Xen. Die Version 3 erfährt gleich mehrere Updates: Xen ist in der Version 3.2 enthalten. Die standardmäßig installierten Kernel sind anders als die offiziellen zu Debian Etch (4.0) gelieferten Kernel mit aktualisierten Xen-Patches ausgestattet. Die Version 3 des c't-Projekts kommt erstmals sowohl in einer 32-Bit- als auch einer 64-Bit-Fassung daher. Die mitgelieferten Programme zum Erzeugen von virtuellen Maschinen sind entsprechend angepasst, um wahlweise 32- oder 64-Bit-VMs – DomUs in der Xen-Notation – zu erzeugen. Wie gehabt bringt der Server eine Firewall und einen Small Business Server als vorkonfektionierte virtuelle Maschinen mit, die freien Community-Ausgaben der Endian Firewall 2.2 (als Release Candidate 2) und ClarkConnect 4.3.

---

Xen und der Linux-Kernel

Xen hat es bis heute nicht geschafft, Bestandteil des Linux-Kernels zu werden. Nur einzelne Teile haben bisher Einzug gehalten. Das macht es schwer, den Hypervisor auf x-beliebiger Hardware an den Start zu bringen. Die offiziellen Xen-Patches beziehen sich nach wie vor auf den Linux-Kernel 2.6.18 (der Xen-Hypervisor nutzt den Linux-Kernel zum Ansteuern der Hardware). Zum Vergleich: Die Kernel-Entwickler arbeiten derzeit an Kernel 2.6.27.

Eine Weile haben die Distributoren versucht, Schritt zu halten und die Xen-Patches an neuere Kernel-Versionen angepasst. Sehr rührig waren die Fedora/Red-Hat-Entwickler, deren Patches diverse Distributionen genutzt haben (unter anderem Debian). Die haben aber alle Aktivitäten in dieser Richtung eingestellt und verfolgen seit einiger Zeit einen anderen Ansatz. Noch sind Ubuntu und Suse im Rennen, aber hier ist absehbar, dass sie sich auf Alternativen für die Virtualisierung wie KVM stürzen, das jedoch CPUs mit Virtualisierungsfunktionen voraussetzt.

Die neue Marschrichtung, die Fedora und Red Hat vorgeben, heißt „paravirt ops“ – das ist eine Schnittstelle im Kernel, die die tatsächlich genutzte Virtualisierungstechnik abstrahiert und dabei sogar das Ausführen auf realer Hardware kapselt. Ein so übersetzter Kernel läuft auf „beliebigen“ Hypervisoren oder auch nativ auf echter Hardware. Aktuell arbeiten die Entwickler daran, mehr und mehr Xen-Funktionen auf „paravirt ops“-Beine zu stellen. In 2.6.28 könnte es das erste Mal gelingen, auch den Teil, der zum Ausführen des Hypervisors nötig ist (Dom0), per paravirt ops anzubinden.

Zurzeit gibt es allerdings keine praktikable Möglichkeit, ein Xen- und Debian-Wirtssystem mit einem halbwegs aktuellen Kernel zu nutzen. Zwar liefert Ubuntu den Kernel 2.6.24 in einer Xen-Variante, doch der hat anfangs sehr viele Kinderkrankheiten gehabt und im Testbetrieb nicht überzeugt – diverse Warnungen bei intensivem Nutzen von Block-I/O haben uns Abstand davon nehmen lassen, den Kernel als Basis für den c't-Debian-Server herzunehmen.

Noch dazu haben auch die offiziellen Debian-Kernel ihre Tücken: Das Archiv liefert zwar solche für den Betrieb eines i386- und eines amd64-Systems, also eine 32- und eine 64-Bit-Fassung (amd64 meint 64-Bit-Debian, ist also nicht auf AMD-CPUs beschränkt, sondern läuft auch auf Intel). Wenn man aber 32- und 64-Bit-Umgebungen in virtuellen Maschinen mischen will, scheitert das an veralteten Xen-Patches im Kernel. Dort rächt sich, dass die Debian-Kernel-Entwickler die Xen-Patches im stable-Zweig nicht aktualisieren (können).

Das kommende Lenny (zurzeit Debian-Testing) bringt lediglich einen Xen-fähigen Kernel mit, der aber nur 32-Bit-Betrieb als Gast gestattet – das wird sich voraussichtlich bis zur Fertigstellung auch nicht mehr ändern. Einer der rührigsten Debian-Kernel- und Xen-Maintainer, Bastian Blank, stellt aber in einem „privaten“ Repository Debian-Kernel auf Basis von 2.6.18 bereit, die er mit moderneren Xen-Patches bestückt hat (zur Zeit aus Xen 3.1). Diese Kernel haben keine Probleme mehr, auch 32-Bit-Systeme in einer 64-Bit-Umgebung zu betreiben. Genau diese Kernel nutzt der c't-Debian-Server 3.

Auch die nächste Xen-Version 3.3, die voraussichtlich mit Erscheinen dieser Ausgabe veröffentlich sein wird, ändert an der Kernel-Misere nichts. Sie wird weiterhin Patches für 2.6.18 mitbringen. Eigentlich hatten die Xen-Entwickler die nächste Release 4.0 nennen wollen, doch das Xen Adivisory Board, das als Community-Vertretung der freien Version aktiv ist, hat sie zurückgepfiffen: Eine .0-Release würde der Reife der Version nicht entsprechen. (ps)