DokuWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Xen ist das geilste was geht in Sachen Virtualisierung. Vielen Dank an XenSource! <br>
Nachfolgend ein weiteres der vielen Howtos, dieses allerdings mit etwas aktuellerer Software.

====== Rohstoffe ======
===== Hardware =====
  * Pentium III 450MHz
  * 192MB SDRAM
  * 80GB SATA-Platte am PCI-Controller für die Domains
  * Einige weitere Platten für den Fileserver
===== Software =====
  * Gentoo Linux 2006.0
  * xen-3.0.1_p9029
  * xen-sources-2.6.16_rc5
===== Hirnschmalz =====
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. 

====== Basissetup (Domain0-Setup) ======
===== Partitionen =====
Folgendes Layout empfielt sich:
  - Boot-Device (/boot, 64MB oder so)
  - Swap Space (für dom0)
  - dom0 Root-Device (kann recht klein sein)
  - Shared-Device (/mnt/share, wird per nfs von dom0 an alle domU freigegeben)
  - N Root-Devices (für N DomainU's)
  - eine Partition für die Swap Spaces der DomU's, am besten als file-backend
===== System =====
  - Stage3 auf dom0-Root aufspielen
  - /mnt/share erstellen, Shared-Device reinmounten
  - Portage nicht nach /usr, sondern nach /mnt/share entpacken
  - /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:
  - mit ''rsync'' (in Stage3 vorhanden) /usr/src nach /mnt/share/ syncen
  - /usr/src rekursiv löschen
  - von /mnt/share/src nach /usr/src verlinken

===== Domain0-Kernel =====
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.)
===== Grub-Konfiguration für Xen =====
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.
===== Grundkonfiguration =====
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".
==== Software ====
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)
==== Configs ====
Zum editieren:
  * domainname (/etc/conf.d/domainname)
  * sshd (/etc/ssh/sshd_config + Runlevel)
  * syslogd, crond (mind. Runlevel)
  * etc...
===== Imaging =====
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.
===== Spezifische Konfiguration =====
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)

====== DomainU-Setup ======
===== DomainU-Kernel =====
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.
===== DomainU-Root =====
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.'''
==Xen-Domain-Konfiguration==
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.

====== Und Action! ======
===== Start =====
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
===== Konsole =====
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.
===== Shutdown =====
Domain0 hat die Macht:
  * Herunterfahren:
  xm shutdown <domainconfig>
  * Neustart:
  xm reboot <domainconfig>
  * "Windows-Reboot":
  xm destroy <domainconfig>

====== Krönender Abschluss ======
Der Spass hat erst richtig begonnen.
===== Auto-DomainU-Boot =====
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
===== Netzwerk =====
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.
==== Xen NIC-Layout ====
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:
==== Physikalische Devices ====
Die hängen etwa so zusammen, wobei N für die DomainU-ID steht:
  Domain0 -> ethX -> vif0.X -|
                             |-> xenbrX -> pethX
  DomainU -> ethX -> vifN.X -|

==== Virtuelle Devices ====
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 -|

==== Konfiguration ====
==== Physikalische Devices ====
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.
==== Virtuelle Devices ====
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'':
  - ifconfig vif0.X up
  - brctl addif xenbrX vif0.X
  * Verhalten bei ''stop'':
  - brctl delif xenbrX vif0.X
  - ifconfig vif0.X down
Nach dessen Start kann dann das Device ''vethX'' auf herkömmliche Weise 
konfiguriert werden.
===== Tuning =====
==== Extreme Dateisystem-Sharing ====
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.
==== /usr sharing ====
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.

====== Links ======
[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>