• Pentium III 450MHz
• 192MB SDRAM
• 80GB SATA-Platte am PCI-Controller für die Domains
• Einige weitere Platten für den Fileserver

• Gentoo Linux 2006.0
• xen-3.0.1_p9029
• xen-sources-2.6.16_rc5

Da als Basissystem Gentoo zum Einsatz kommt wäre es ziemlich dämlich, eine andere Distribution für die Gastsysteme zu verwenden. Denn jeder weiss:

• zumindest CFLAGS sind auf allen Systemen gleich
• mit gleichen USE-Flags kann man auch auskommen
• mit Gentoo kann man ganz simpel Binary-Packages aus den Installierten Paketen bauen
• es kann ein gemeinsames Package-Repository verwendet werden (Portage)

Das hier gezeigte Setup nutzt die oben genannten Eigenschaften. Portage wird zentral angelegt, muss ein Paket auf N Domains installiert werden, wird es einmal übersetzt, und N-1 mal als Binary installiert.

Folgendes Layout empfielt sich:

1. Boot-Device (/boot, 64MB oder so)
2. Swap Space (für dom0)
3. dom0 Root-Device (kann recht klein sein)
4. Shared-Device (/mnt/share, wird per nfs von dom0 an alle domU freigegeben)
5. N Root-Devices (für N DomainU's)
6. eine Partition für die Swap Spaces der DomU's, am besten als file-backend

1. Stage3 auf dom0-Root aufspielen
2. /mnt/share erstellen, Shared-Device reinmounten
3. Portage nicht nach /usr, sondern nach /mnt/share entpacken
4. /mnt/share/portage nach /usr/portage verlinken

Danach ganz normal mit der Gentoo-Installation fortfahren, also chroot, emerge –sync, etc. Um das TLS-Problem elegant zu umgehen, ist folgendes zu beachten:

• Zu den 'CFLAGS' muss -mno-tls-direct-seg-refs hinzugefügt werden
• Zu den 'USE'-Flags nptlonly hinzufügen (zumindest für glibc)
• glibc muss neu übersetzt werden

Dann sollten direkt Xen, Xen-Kernel und Grub installiert werden, wobei die Kernel-Quellen auch wieder ausgelagert werden:

1. mit rsync (in Stage3 vorhanden) /usr/src nach /mnt/share/ syncen
2. /usr/src rekursiv löschen
3. von /mnt/share/src nach /usr/src verlinken

Der dom0-Kernel sollte folgende Dinge unterstützen:

• Support für alle Hardware des Systems. (Nur die Domain0 hat darauf Zugriff, und muss diesen für alle anderen tätigen.)
• Support für Ethernet Bridging, ausser es soll geNATet werden.
• Support für den NFS-Server. Die beste Möglichkeit, gemeinsamen Speicherplatz für alle Domains zu realisieren.
• In Processor type and features muss Subarchitecture Type auf Xen-compatible gesetzt werden, da auch die Domain0 auf den Xen Hypervisor aufsetzt.
• Privileged Guest unter XEN aktiv.
• Die nötigen Xen Backend Treiber.

Danach kann dieser mit

make && make install

installiert werden. Falls der Kernel manuell installiert werden soll, ist es ratsam, die Konfiguration mitzusichern. Später soll ein weiterer Kernel mit verschiedener Konfiguration erstellt werden, wenn danach noch Änderungen am Domain0-Kernel gemacht werden sollen, ist es recht praktisch, wenn die originale Konfiguration vorhanden ist. (Alternativ/zusätzlich kann auch der Kernel .config Support aktiviert werden.)

Um den Hypervisor an der richtigen Stelle ins Spiel zu bringen, muss eine spezielle Grub-Konfiguration verwendet werden:

title=Gentoo XEN 2.6.16
        root (hd0,0)
        kernel /xen.gz dom0_mem=64M
        module /vmlinuz-2.6.16-xen root=/dev/sda3 gentoo=nodevfs

Hierbei ist zu beachten:

• Xen legt seinen Kernel in /boot ab, und erstellt einige Links drauf. Die eigentliche Datei heisst bei meiner Version xen-3.0.0.gz, wobei xen.gz, xen-3.gz und xen-3.0.gz darauf verlinkt sind.
• dom0_mem legt den maximal zugesicherten Arbeitsspeicher für Domain0 fest. Weitere Optionen stehen im [http://tx.downloads.xensource.com/downloads/docs/user/ Xen User Manual].
• Die Zeile mit module hat den gleichen Aufbau wie die mit kernel bei herkömmlichen Setups. Hier werden die eigentlichen Kernelparameter mitgegeben.

Soweit keine Probleme beim Boot des Xen-Systems aufgetreten sind, kann eine möglichst generische Basiskonfiguration vorgenommen werden. “Möglichst generisch” heisst in diesem Fall “für alle späteren Domains gültig”.

Zum installieren:

• cracklib (crackt die lib)
• distcc (mein pc ist schneller als mein server
• eix, vim, screen (obligatorisch)
• logrotate, cron, syslogd
• nmap, tcpdump (und viele weitere)

Zum editieren:

• domainname (/etc/conf.d/domainname)
• sshd (/etc/ssh/sshd_config + Runlevel)
• syslogd, crond (mind. Runlevel)
• etc…

Um möglichst einfach ein Image des gerade aufgesetzten Systems zu erhalten, nimmt man sich am besten die Gentoo-CD zur Hand und bootet sie erneut. So kann dann das dom0 Root-Device gemountet, und mit tar gesichert werden. Damit stellt man sicher, dass die nötigen Devices in /dev vorhanden sind, sowie dass keine externen Dateisysteme mitgesichert werden, wie /proc oder /sys. /usr/src und /usr/portage wurden ohnehin schon ausgelagert, und da sowohl der Mount Point, wie auch die Links hinein im Image existieren, genügt später ein Mount des NFS-Shares an die richtige Stelle.

Nachdem ein Image für die anderen Domains erstellt wurde, kann die Konfiguration von Domain0 spezifisch gemacht werden. Anzufassen sind:

• Xen Konfiguration (/etc/xen/xend-config.sxp + Runlevel)
• Netzwerkkonfiguration (abhängig von Xend-Konfiguration)

Generell baut man nur einen Kernel für alle DomainU's, da sich diese nur minimal unterscheiden sollten (wenn überhaupt). Zu beachten wäre:

• PCI access mode muss das Xen-Frontend sein
• Privileged Guest in XEN inaktiv
• keine Xen-Backends werden benötigt,
• dafür die Xen-Frontends
• Dateisystemtreiber sind in jedem Fall erforderlich
• es werden keine Treiber für Festplatten benötigt, die freigegebenen Devices werden von Xen direkt in /dev erstellt
• Der restliche Hardware-Support kann in den meisten Fällen auch weggelassen werden

Diesen Kernel darf man nur übersetzen, beim Aufruf von make install würde man den Domain0-Kernel überschreiben. Übersetzen und “installieren” also mit:

cd /usr/src/linux
make
mkdir -p /xenboot
for i in vmlinuz-domU config-domU; do
  [ -e /xenboot/$i ] && cp /xenboot/$i /xenboot/${i}.old
done 
cp vmlinuz /xenboot/vmlinuz-domU
cp .config /xenboot/config-domU

Soweit /boot automatisch gemountet wird, kann natürlich auch /boot anstelle von /xenboot verwendet werden. Auch hier kann auf das Sichern der .config-Datei verzichtet werden, wenn Kernel .config Support aktiviert wurde.

Das RootFS einer DomainU ist schnell angelegt, da ja ein Image dafür vorbereitet wurde. Die zu verwendende Partition also mounten, das Image darin entpacken und zur Sicherheit mit chroot hineinwechseln. Zu Überprüfen:

• Dienste und deren Runlevel
• /etc/fstab (wobei die Namen der Devices von der Konfiguration der Xen-Domain abhängen, siehe nächstes Kapitel)
• /etc/inittab - Hier sollten alle tty-Einträge bis auf den für tty1 auskommentiert werden.
• evtl. weitere Konfigurationsdateien

'An dieser Stelle kann das Skeleton-Root für die DomainU neu angelegt werden, um das Setup weiterer Domains zu vereinfachen.'

Um eine DomainU zu betreiben, wird neben domU-Kernel und Root-Device eine Konfigurationsdatei für Xen benötigt. Hierzu sind die Beispiele in /etc/xen hilfreich, normalerweise xmexample1 und xmexample2. Normalerweise sollte es genügen, xmexample1 zu kopieren und den Namen der Domain, sowie die freigegebene Partition anzupassen. Die Konfiguration wird später sowieso nochmal angefasst.

Die neue Domain sollte jetzt bereit sein zum booten: xm create <domainconfig> -c

• domainconfig ist eigentlich ein Pfad, relativ zu /etc/xen, der zur Xen-Konfiguration der Domain verweist
• -c lässt xm direkt eine Konsole zur Domain öffnen

Die Konsole kann auch nachträglich zu einer Domain aufgemacht werden:

xm console <domainconfig>

Zum Verlassen der Konsole dient <CTRL>+], wobei in den meisten Fällen auch <CTRL>+5 funktioniert.

Domain0 hat die Macht:

• Herunterfahren:

xm shutdown <domainconfig>

• Neustart:

xm reboot <domainconfig>

• “Windows-Reboot”:

xm destroy <domainconfig>

Der Spass hat erst richtig begonnen.

Eine selektive Liste DomainU's automatisch booten zu lassen, ist ohne Probleme möglich:

• die Xen-Konfiguration der Domain in /etc/xen nach /etc/xen/auto verlinken, 'allerdings muss die Pfadangabe relativ gemacht werden!' (oder einfach dahin verschieben)
• das init-Script xendomains dem Default-Runlevel hinzufügen

Kommt Bridging zum Einsatz, ist die Kommunikation der Domains untereinander nicht ganz unkritisch. Hängt die Maschine an einem Hub (was auch mal ein Switch gewesen sein kann , so empfängt ein laufender Sniffer auch alle Pakete, die nur zwischen den Domains wandern sollen. Daher empfielt sich die Einrichtung eines internen Lan, über welches dann auch NFS sicher betrieben werden kann.

Vielen anderen Howtos zuwider bin ich der Ansicht, dass den von Xen erstellten Bridges keine IP zugeteilt werden sollte. Die werden nur benötigt, um die verschiedenen virtuellen NIC's zusammenzukleistern, für die Adressvergabe stehen andere Devices zur Verfügung:

Die hängen etwa so zusammen, wobei N für die DomainU-ID steht:

Domain0 -> ethX -> vif0.X -|
                           |-> xenbrX -> pethX
DomainU -> ethX -> vifN.X -|

Hierzu muss wohl Xen-Loopback Support im Kernel aktiv sein. Der Aufbau ist sehr ähnlich zum obigen:

Domain0 -> vethX -> vif0.X -|
                            |-> xenbrX -> '''NIRVANA'''
DomainU ->  ethX -> vifN.X -|

Soweit die Xend-Konfiguration korrekt ist, erscheint jedes physikalische Device mit seinem originalen Namen, sowohl bei der Domain0 als auch bei allen DomainU's. Dieses kann dann ganz normal über die init-Scripte konfiguriert werden.

Gut möglich, dass Gentoo hier etwas buggy ist, zumindest die Einrichtung in der Domain0 war etwas komplizierter:

• Nach dem Eintragen in der Xend-Konfiguration erscheint auf allen DomainU's das Device als ethX, das dann herkömmlich konfiguriert werden kann.
• Auf Domain0 fehlt es, in der zusätzlichen Bridge ist nur vifN.X eingetragen.

'BUGFIX': Ich habe ein kleines init-Script geschrieben, welches before net.vethX xendomains und needs xend beinhaltet.

• Verhalten bei start:

1. ifconfig vif0.X up
2. brctl addif xenbrX vif0.X

• Verhalten bei stop:

1. brctl delif xenbrX vif0.X
2. ifconfig vif0.X down

Nach dessen Start kann dann das Device vethX auf herkömmliche Weise konfiguriert werden.

Durch die gemeinsame Nutzung von Teilbäumen des Verzeichnisbaums kann nicht nur Speicherplatz gespart, sondern teils auch einiges erleichtert werden. Bestes Beispiel: /usr/portage. Es genügt, wenn eine der Maschinen emerge –sync ausführt, um Portage für alle Maschinen zu aktualisieren.

Hier wirds sehr Distributionsspezifisch. Es kommt darauf an, welche Systemtools in /bin bzw. /sbin, und welche in /usr/bin bzw. /usr/sbin installiert sind. Zudem hängt der Spass davon ab, welche dieser Systemtools beim Booten des Systems bis nach dem Mounten des NFS-Shares benötigt werden. Es folgt also eine Analyse des Problems auf Basis von Gentoo: <br> Erstmal das /usr aufs Share syncen:

rsync -avP /usr /mnt/share/

Dann eine DomainU zum Testen anpassen:

mount /dev/sda6 /mnt/tmp
mount /dev/sda5 /mnt/tmp/mnt/share
chroot /mnt/tmp
mv /usr /usr.old
ln -s /mnt/share/usr /usr
exit
umount /mnt/tmp/mnt/share /mnt/tmp

Ein erster Boot zeigt, dass find, sowie xargs von den Init-Scripts benötigt werden und nicht vorhanden sind. Also müssen sie manuell bereitgestellt werden:

mount /dev/sda6 /mnt/tmp
cp /usr/bin/{find,xargs} /mnt/tmp/bin
umount /mnt/tmp

Ein weiterer Boot zeigt, dass syslog-ng 'vor' netmount starten will, zumindest solange kein Loghost in syslog-ng.conf angegeben wurde. Um dies zu fixen einfach das Init-Script anpassen:

@@ -12,7 +12,7 @@
                        need net ;;
        esac
 
-       need clock hostname
+       need clock hostname netmount
        provide logger
 }

Dies muss wohl bei allen Diensten gemacht werden, die in /usr installiert sind und vor netmount gestartet werden wollen. Soweit es nicht möglich ist, sie später zu starten, müssen sie (wie xargs und find) nach /bin kopiert werden.

Ganz haarig wird die Sache, wenn ein NFS-Server auf einer DomainU laufen soll. dieser benötigt dann zum Start ebenso netmount, allerdings benutzt netmount selbst nfs beim start. Um die lästige Fehlermeldung zu beseitigen, muss nfs manuell im Init-Script aus der use-Deklaration entfernt werden.

[http://tx.downloads.xensource.com/downloads/docs/user/ Xen User Manual] <br> [http://wiki.xensource.com/xenwiki/ Xen Wiki von XenSource] - die kann aber mal garnix…<br> [http://wiki.xensource.com/xenwiki/XenFaq FAQ's der XenWiki] <br>