Alte-Xen-Installation
Inhaltsverzeichnis
Einleitung
Wer wünscht sich das nicht: Eine Möglichkeit, auf einem physikalischen i386'er Rechner mehrere Betriebssystem-Instanzen laufen zu lassen, wie es bei den Großen Gang und Gäbe ist. Wer bisher dies erreichen wollte, benötigte einen Rechner mit viel Power und ein größeres Portemonaie. Emulatoren wie VMware emulieren vollständige Rechner und ermöglichen es, jedes Betriebsystem darin laufen zu lassen. Der Nachteil liegt jedoch im Detail. Diese Art von Emulation benötigt, im Verhältnis, sehr viel Rechenleistung und ist nicht so performant wie ihr Gastgeber. Der Vorteil ist jedoch, daß sich jedes Betriebsystem darin installieren läßt, ohne spezielle Anpassungen vornehmen zu müssen (von Treibern abgesehen).
Doch speziell Vmware und Konsorten sind auf einen i386-kompatiblen Rechner ausgelegt, daß sie die CPU Befehle weiterreichen. Eine Installation auf einem (z.B) PPC basierten System ist damit nicht möglich. Der Emulator Bochs dagegen, emuliert selbst eine CPU und ist damit plattformunabhängig.
Xen geht einen gänzlich anderen Weg als VMware, erreicht aber (fast) das selbe Ziel. Xen selbst ist ein unter GPL stehender Virtueller Maschinen Monitor (VMM). Dieser läuft direkt auf einer i386'er Hardware und unterstützt eine Reihe von Betriebsystemen (Linux, FreeBSD, Plan-9). Durch die Paravirtualisierung wird jedem virtuellem System vorgespielt, es besitze die alleinigen Rechte über die Ressourcen. Tatsächlich fängt Xen die Befehle ab und leitet sie an die echte Hardware weiter. Der Vorteil liegt darin, das keine Hardware emuliert werden muß und damit die paravirtualisierten Systeme mit der nahezu gleichen Performance arbeiten, wie das echte System.
Auszug, aus Wikipedia:
Xen ist eine Linux-Kernelerweiterung. Der Kernel wird um eine Virtuelle Architektur (xen) erweitert. Diese ist der x86 (i386) sehr ähnlich. Das Prinzip ähnelt dem User Mode Linux (UML). Die Erweiterung wird als xen0 für Xen selbst und als xenU für die Linux-Gastsysteme verwendet. Unter einer "normalen" Linux-Distribution wird Xen installiert und eingerichtet. Das sind im wesentlichen Kernelimages (2.4 bzw. 2.6) und ein paar Userspace-Utilitys. Danach wird der Computer neugestartet und der Xen-Kernel (vmlinuz-2.6-xen0) geladen. Anschließend wird Domain-0, für die Steuerung der anderen Domains, gestartet. Mit den Xen-Tools werden andere Domains gestartet, die mit einem Xen-Kernel (z.B. vmlinuz-2.6-xenU) laufen. So können viele verschiedene Linux-Distributionen mit unveränderter Software parallel laufen. Die Anzahl der laufenden Gastsysteme ist eigentlich nur durch die Ressourcen (CPU, Speicher usw.) beschränkt. Die einzelnen Gastsysteme werden voneinander sehr stark isoliert und laufen annähernd so schnell als ob sie direkt auf der Hardware liefen. Diese Eigenschaft unterscheidet Xen von den anderen Verfahren wie UML, VMware usw. Es ist geplant, dass Xen in den offiziellen Linuxkernel 2.6 integriert wird.
Es wurde begonnen, den ReactOS-Kernel dahingehend zu ergänzen, dass er ebenfalls als Gastsystem verwendet werden kann.
In SuSE Linux 9.3 ist Xen bereits integriert, Fedora Core Linux 4 will demnächst folgen.
Wer die Unterschiede zwischen UML und Xen genauer wissen möchte, dem sei dieser Blog-Eintrag empfohlen.
Xen Installation auf einem Debian Sarge System
Debian Grundinstallation
Da mir das unter Gentoo zu lange dauert und Sarge gerade herauskam (Juni.2005) verwenden wir also Debian. Die Installation gestaltet sich recht simpel. Xen kann sowohl auf einem bereits bestehendem System installiert werden, als auch auf einem neuen. Ich ziehe einen neuen Rechner vor.
Als erstes installieren wir ein Debian Grundsystem. Bei der Partitionierung ist zu beachten, dass die Partition für /boot mindestens 50MB groß ist. Wer über das Netzwerk ins Internet kann, verwendet am Besten eine Netinst ISO, hier zu finden. Es wird nur ein Grundsystem ohne extra Pakete installiert, um dieses System möglichst schlank und unempfindlicher zu machen. Bei der Paket Auswahl, bitte Custom auswählen und dann Quit. Da wir die vorkompilierten von Xen verwenden, benötigen wir nur folgende, zusätzliche Pakete, die wir mit Apt nachinstallieren:
# apt-get install screen ssh debootstrap python python2.3-twisted iproute bridge-utils libcurl-dev
Da das Xen Installations Script Python nicht finden würde, müssen wir noch einen Link setzen: (Hinweis, bei Sarge hat sich das mittlerweile erübrigt)
# ln -s /usr/bin/python2.3 /usr/bin/python
Xen Installieren
Nun können wir Xen herunterladen, ...:
# cd /usr/src/ # wget http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-2.0.7-install-x86_32.tgz
... gleich entpacken und installieren:
# tar xvzf xen-2.0.7-install-x86_32.tgz # cd xen-2.0-install # ./install.sh
Wird ein 2.6'er Kernel verwendet, sollte das tls Verzeichnis entschärft werden:
mv /lib/tls /lib/tls.disabled
Ansonsten gibt es beim Booten einen entsprechenden Hinweis. Durch TLS soll die Performance sehr stark leiden.
Wenn alles glatt durchgelaufen ist, sollten sich unter /boot jede Menge neue Dateien befinden. Da Xen einen angepaßten Kernel mitbringt, müssen wir Grub einen neuen Eintrag hinzufügen:
# nano /boot/grub/menu.lst
und fügen das als ersten Eintrag ein:
title Xen 2.0 / XenLinux 2.6.11.12 kernel /xen.gz dom0_mem=64000 module /vmlinuz-2.6-xen0 root=/dev/hda1 ro console=tty0
Die Daten sind natürlich an die Umgebung (z.B. /dev/hda1) anzupassen. Falls /boot auf keiner eigenen Partition liegt muß bei beiden Einträgen das Verzeichnis /boot hinzugefügt werden. Damit der Xen Monitor und die Domains automatisch beim booten hochfahren, sind entsprechende Runlevel Einträge zu erstellen. Ich mache das so:
# update-rc.d xend defaults 20 21 # update-rc.d xendomains defaults 21 20
Netzwerk vorbereiten
Der Xen Kernel bringt die meist verwandten Netzwerktreiber mit, also 3com, Realtek, Intel, Via etc. Da jegliche Kommunikation über ein virtuelles Gerät (Bridge) xen-br0 vonstatten geht, wird eth0 entsprechend umkonfiguriert:
- cat /etc/network/interfaces
auto lo eth0 iface lo inet loopback iface eth0 inet static address 0.0.0.0 netmask 255.255.255.255
Reboot
Nachdem dies alles bewerkstelligt worden ist, kann das System rebootet werden. Es sollte nun der Xen Kernel gebootet werden, was sich leicht an den Meldungen verfolgen läßt.
Debian Linux Gast System einrichten
Die virtuellen Systeme können sowohl auf echten Partitionen laufen, als auch in Image Dateien. Laut den Benchmarks der Zeitschrift c't, ist die Performance mit Image Dateien besser, als mit echten Partitionen. Außerdem sind sie einfacher in der Handhabung, weshalb ich die Image Variante erläutere. Damit ich den ßberblick nicht verliere, erstelle ich mir eine Verzeichnisstruktur und mounte mir eine große Partition dorthin:
# mkdir -p /mnt/vserver # mount /dev/hda8 /mnt/vserver # mkdir /mnt/vserver/images web mail plain
Grundsystem erstellen
Für unseren virtuellen Mail Server, erstellen wir eine ein Gigabyte große Datei für das System und eine 500MB Datei für die Swap:
# dd if=/dev/zero of=/mnt/vserver/images/mail.img bs=1024k count=1000 # dd if=/dev/zero of=/mnt/vserver/images/mail-swap.img bs=1024k count=500
Dann werden die Dateisysteme erzeugt:
# mkfs.ext3 /mnt/vserver/images/mail.img # eventuelle Frage mit Ja beantworten # mkswap /mnt/vserver/images/mail-swap.img
Dann läßt sich das Image bereits mounten:
# mount -o loop /mnt/vserver/images/mail.img /mnt/vserver/mail
Debian Bootstrap
Mit Hilfe von Debian's Bootstrap, läßt sich sehr einfach ein Debian basiertes System installieren. Doch bevor wir auf das Netzwerk zugreifen können, müssen wir das Netzwerk hochfahren. Wer einen DHCP Server sein eigen nennt, kann die IP einfach per dhcp Client beziehen:
# dhclient xen-br0
Achtung: Mit Einführung der Version XEN3.0.x hat sich die Standard Bridge im Namen geändert. Sie heisst jetzt nur noch xenbr0 solltet ihr vielleicht beachten, wenn ihr bei Eurer Fehlermeldung irgendwas mit No such Device oder Error: Device 0 (vif) could not be connected. Backend device not found. o.ä bekommt (Quelle [ http://wiki.xensource.com/xenwiki/DebianDomU xensource.com ])
--Schroedi 15:28, 28. Mai 2006 (CEST)
Wer keinen DHCP hat, muß die Einstellungen manuell vornehmen:
# ifconfig xen-br0 192.168.1.5 up # route add default gw 192.168.1.1
Zu beachten ist, das nicht eth0 verwendet wird. Eth0 wird nicht mehr auf direktem Wege verwandt.
Nun können wir den debootstrap anwerfen:
# debootstrap --arch i386 sarge /mnt/vserver/mail/ http://ftp.de.debian.org/debian
Wer das ganze mit der Netinst ISO machen will, weil er z. B. kein dauerhaften Internet-Zugang hat, muss nach dem Mounten des ISO-Images als Loop-Back-Device folgendes machen:
# debootstrap --arch i386 sarge /mnt/vserver/mail/ file:/mnt/to/debian/netinstall/cd
Nun kann man erstmal ein wenig Tee trinken, denn das dauert ein paar Minuten, je nach Bandbreite. Ist dies abgeschlossen, läßt sich sogleich in das frische System chrooten:
Debian Linux Gast konfigurieren
# chroot /mnt/vserver/mail
Dann sollte man die Basis Konfiguration durchlaufen:
# base-config
Auch hier wieder bis auf SSH, $EDITOR, MC etc. keine weiteren Pakete installiert. Ist das dann ausgeführt, werden ein paar andere Dinge erledigt:
Hier werden die Partitionen für die "neue" DomU angelegt. Das heisst, hier werden die Partitionen angelegt, die dann in der DomU zur Verfügung stehen sollen. Diese können auch jederzeit von der bisherigen Partition der Dom0 abweichen --Schroedi 00:13, 31. Mai 2006 (CEST)
# rm /etc/hostname # wird später per Kernel Config übermittelt # nano /vi /etc/fstab /dev/sda1 / ext3 defaults 1 2 /dev/sda2 none swap sw 0 0 /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0
Das Netzwerk selbst, wird out-of-the-box funktionieren, allerdings wird es da noch kein lo Netzwerk geben. Da viele Dienste über diese Schnittstelle kommunizieren, sollte das nachgetragen werden. Dazu muss die Datei /etc/network/interfaces geöffnet werden, und folgendes enthalten:
auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0
Bei nächsten Start werden dann sowohl ethx also auch lo verfügbar sein.
Um nun eine Console im Xen-Gast-System zu bekommen, ändert man in /etc/inittab die Zeile:
1:2345:respawn:/sbin/getty 38400 tty1 in 1:2345:respawn:/sbin/getty 38400 console
Die restlichen Einträge ( 2-6 ) können auskommentiert werden, da sie in Xen nicht berücksichtigt werden.
Dieser Fehler tritt auf falls man die Einstellungen nicht gemacht hat:
INIT: Entering runlevel: 5 INIT: Id "1" respawning too fast: disabled for 5 minutes ... INIT: Id "6" respawning too fast: disabled for 5 minutes INIT: no more processes left in this runlevel
>>> COMMENT-BEGIN from ricci007 <<<
Das hat allerdings den negativen Nebeneffekt, dass man _kein_ Controlling-TTY bekommt und so beispielsweise keine Fordergrund-Prozesse mittels [CTRL]+[C] abbrechen kann, da der Process-Leader nicht weis, wohin er das Signal schicken soll (es gibt noch mehr Eigenarten). Es macht durchaus Sinn, zuerst mit der obigen /etc/inittab zu starten und dann erstmal ein tty1 anzulegen bzw. auch mehrere (-:. Es macht nämlich den Anschein, als würde devpts dies leider nicht machen )-;
# mknod tty1 c 4 1 # mknod tty2 c 4 2 # mknod tty3 c 4 3 # mknod tty4 c 4 4 # mknod tty5 c 4 5 # mknod tty6 c 4 6
Wer zu faul zum Tippen ist (wie beispielsweise ich):
# for ((i=1;i<=6;i+=1)); do mknod /dev/tty$i c 4 $i; done
>>> COMMENT-END <<<
Ist auch das erledigt, verlassen wir wieder die chroot mit exit. Da mit Sicherheit weitere Vserver dazukommen, kopieren wir uns das System so wie es ist:
# umount /mnt/vserver/mail # cp /mnt/vserver/images/mail.img /mnt/vserver/images/plain.img
Nun hat man einen Startpunkt, mit dem sich neue Server schnell erstellen lassen.
Gast Konfiguration
Ich habe hier mal eine simple Xen DomU Konfiguration:
cat /etc/xen/mail-config.sxp # standard config name ="debian-mail" kernel ="/boot/vmlinuz-2.6.11-xenU" root ="/dev/sda1" memory =128 disk = ['file:/mnt/vserver/images/mail.img,sda1,w','file:/mnt/vserver/images/mail-swap.img,sda2,w'] # network nics=1 vif = ['mac=aa:00:00:00:00:02, bridge=xen-br0'] dhcp ="off" ip="192.168.1.10" netmask="255.255.255.0" gateway="192.168.1.1" hostname="mx02" extra="3"
Wie sich leicht erkennen läßt, bekommt diese Maschine 128MB Ram und hat zwei SCSI Platten, unsere Images. Als Hostname bekommt er den Namen mx02 zugeteilt und Xen kennt das System unter debian-mail. Wird der Eintrag vif weggelassen, wird automatisch eine MAC Adresse generiert. Sollten sie XEN ab der Version 3.0.x einsetzen, dann beachten sie, dass die Bridge xenbr0 heisst.
Gast starten
Hat man es bis hier her geschafft, läßt sich der Virtuelle Server starten:
# xm create -c /etc/xen/mail-config.sxp
Es sollten nun Kernel Meldungen über den Schirm flimmern und am Ende ein Prompt warten. Sollte man bei der Base-config noch kein Kennwort festgelegt haben, kann man sich entsprechend als Root od. Benutzer einloggen.
Das erste was man tun sollte, ist auch hier das /lib/tls Verzeichnis zu deaktivieren.
# mv /lib/tls /lib/tls.disabled
Nach dem nächsten Reboot der DomU, erscheint die TLS Warnung nicht mehr.
Automatisches Starten der Gast Rechner
Wer mit seiner Konfiguration der Gastrechner zufrieden ist, kann dafür sorgen, das beim starten des Rechners selber, auch die entsprechenden DomUs gebootet werden. Um dies zu erreichen, muss lediglich ein Symlink der Xen DomU Konfiguration, in das Verzeichnis /etc/xen/auto abgelegt werden. Wer hier mehrere eingetragen hat, sollte bedenken das der Start ein wenig länger dauert als gewöhnlich
xm Kommandos
Hat man den SSH Dienst gestartet, loggt man sich am Besten wieder aus, mit STRG + ] (für Benutzer die Putty benutzen: Strg + 5), verläßt die xm console, und loggt sich per SSH wieder ein. xm ist das Haupttool, um virtuelle Maschinen zu kontrollieren.
die wichtigsten sind:
# xm create -c /path/to/config # VSystem starten # xm shutdown <name> # VSystem stoppen # xm list # Alle laufenden Systeme auflisten # xm console <name> # Login auf dem entsprechendem System, ähnlich dem Login per serieller Konsole # xm help # Auflistung aller Befehle
Routen oder Bridge
Wann welches Netzwerk
Normalerweise, funktioniert das Xen Netzwerk Out-of-the-box, wie es so schön heißt. Dabei bindet jede DomU an den virtuellen Switch xen-br0 . Dieses ist wiederum an ethx gebunden. Man kann dies sehr schön sehen, wenn ein IP Logger wie iptraf, od. tcpdump an eth0 lauscht. Dies hat allerdings den Nachteil, dass alles an eth0 mitgeschnitten werden kann. Externe Geräte wie Switches, an denen das Kabel von ethx angeschlossen ist, bekommen so den Verkehr mit, der zwischen den DomUs abläuft.
Nun gibt es aber Gebiete, wo dies unerwünscht ist. Als Beispiel nehme ich einen Rootserver, der über nur eine IPAdresse verfügt. Man möchte aber gerne verschiedene Dienste auf verschiedene DomUs ablegen. Weiterhin gibt es Provider, die sofort den Port schließen, sobald sie eine IP entdecken, welche nicht zum Provider Netz gehört. Dies wäre jedoch unvermeidlich, würden wir die DomUs an eth0 über xen-br0 hängen.
Um das zu umgehen, nutzen wir eine weitere Netzwerk Variante von Xen. ßber Routing. Das Ganze sähe etwa so aus:
+---- domU
|
eth0 --- NAT --- bridge0 |---- domU
|
| ...
Dabei wird ein virtueller Switch aufgestellt, der jedoch nicht an ethx gebunden wird, sondern ausschließlich dazu dient, die DomUs untereinander, und mit der Dom0 zu verbinden. Damit die Pakete auch ihren Weg finden, werden entsprechende Routen bzw. NAT Regeln gesetzt. So bekommt der Provider nichts von den DomUs mit.
Von Beginn an
Da ich das auf einem Gentoo Testsystem ausgeführt habe, beschreibe ich es so, wie es von Hand gemacht wird. Die Umsetzung in den einzelnen Distributionen muß dann individuell umgesetzt werden. Desweiteren ist dies größtenteils nicht auf meinem Mist gewachsen. Die Quellen stehen am Ende, dieses Artikels.
in diesem Abschnitt gehe ich davon aus, das alles Grundsätzliche funktioniert. Xen ist in seiner standard Installation und es existieren noch keine xen-br0 Bridges. Sozusagen, frisch nach dem installieren von Xen. Die Namen der Geräte habe ich von meiner Quelle übernommen.
Per Hand einrichten
Zuerst legen wir unseren virtuellen, internen Switch an und geben ihm seine Konfiguration:
# brctl addbr xenintbr # brctl stp xenintbr off # brctl sethello xenintbr 0 # brctl setfd xenintbr 0
Dann die IP Adresse
# ifconfig xenintbr 192.168.1.1 netmask 255.255.255.0 up
Unsere DomU config, ist die selbe, wie oben. Lediglich das Netzwerk ist angepasst:
nics=1 vif = ['bridge=xenintbr'] dhcp ="off" ip="192.168.1.2" netmask="255.255.255.0" gateway="192.168.1.1"
Unser vif ist unser virtueller Switch, xenintbr. Damit nun auch xen selber weiß, dass er nun nichtmehr automatisch eine Bridge erstellen soll, um die DomUs mit einander zu verbinden, braucht es eine angepasst xend-config.sxp:
# Xend configuration file. # Port xend should use for the HTTP interface. (xend-port 8000) # Port xend should use for the event interface. (xend-event-port 8001) # Address xend should listen on for HTTP connections. # Specifying 'localhost' prevents remote connections. # Specifying the empty string '' allows all connections. (xend-address 'localhost') # The port xend should start from when allocating a port # for a domain console. (console-port-base 9600) # Address xend should listen on for console connections. # Specifying 'localhost' prevents remote connections. # Specifying the empty string '' allows all connections. (console-address 'localhost') ## Use the following if VIF traffic is routed. # The script used to start/stop networking for xend. (network-script network-route) # The default script used to control virtual interfaces. #(vif-script vif-route) ## Use the following if VIF traffic is bridged. # The script used to start/stop networking for xend. #(network-script network) # The default bridge that virtual interfaces should be connected to. (vif-bridge xenintbr) # The default script used to control virtual interfaces. (vif-script vif-bridge) # Whether iptables should be set up to prevent IP spoofing for # virtual interfaces. Specify 'yes' or 'no'. (vif-antispoof no) # Setup script for file-backed block devices (block-file block-file) # Setup script for enbd-backed block devices (block-enbd block-enbd)
Nun können wir die DomU hochfahren und es sollte ein Ping an unsere xenintbr (192.168.1.1) möglich sein. Wenn dies klappt, kann es einen Schritt weitergehen. Damit auch die Kommunikation ins Internet funktioniert, muß zum einen das Forwarding aktiviert sein:
# echo "1" > /proc/sys/net/ipv4/ip_forward
und zum anderen, unser NAT aktiviert werden. Dazu wird folgende Regel verwendet:
# iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/24 -j SNAT --to <bekomme-ip-vom-provider>
oder um alle ausgehenden Pakete umzusetzen:
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to <bekomme-ip-vom-provider>
Hat man alles durch, ist nun auch ein Ping ins Internet möglich. Mit einem Sniffer kann das Ergebnis überprüft werden. Es dringt nach außen kein 192.168.1.x'er Netz. :-)
unter Debian
Unter Debian ist es sehr einfach, diese Bridges erstellen zu lassen. Es genügt in die Datei /etc/network/interfaces folgendes einzutragen:
# Internal Bridged Network. auto xenintbr iface xenintbr inet static pre-up brctl addbr xenintbr post-down brctl delbr xenintbr address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 bridge_fd 0 bridge_hello 0 bridge_stp off
Beimn nächsten reboot, steht diese Brücke zur Verfügung.
unter Gentoo
Unter Gentoo ist es nicht ganz so simpel. In der /etc/conf.d/net.example ist ein Beispiel für Bridges, aufgeführt. Das Problem besteht darin, das diese Brücke automatisch an ein reales Netzwerkgerät gehangen wird. Im Beispiel an eth0. Da dies hier jedoch nicht sein darf, müssen wir uns mit der depend() Funktion aushelfen.
/etc/conf.d/network:
bridge_xentbr="xenintbr"
config_xentbr=( "192.168.1.1/24" )
depend_xentbr() {
need bridge
}
brctl_xentbr=( "setfd 0" "sethello 0" "stp off" )
Dann habe ich ein einfaches Script in /etc/init.d/bridge, welches aufgerufen wird, bevor die Bridge ihre IP Adresse bekommt:
depend() {
before xend
}
start() {
ebegin "Starting bridge-config"
brctl addbr xenintbr
brctl stp xenintbr off
brctl sethello xenintbr 0
brctl setfd xenintbr 0
eend $? "Failed to brige-config"
}
stop() {
ebegin "Stopping bridge-config"
brctl delbr xenintbr
eend $? "Failed to stop bridge-config"
}
Damit die Bridge auch gestartet werden kann, bedarf es eines Links:
# ln -s /etc/init.d/net.lo /etc/init.d/net.xenintbr
Entweder net.xentintbr wird per "rc-update" hinzugefügt, oder überlassen es einfach /etc/init.d/xend, indem wir es dort in die use Angabe schreiben.
Hinweise
Ubuntu debootstrap und Shadow
Wird eine neue DomU aufgesetzt und Ubuntu mit Hilfe von debootstrap installiert, so muss nachdem base-config am Besten, ein
sudo shadowconfig on
ausgeführt werden. Ansonsten wird keine /etc/shadow angelegt und auch verwendet.
Xen 3.x
Xen3 wird nach dem selben Schema aufgebaut, wie Xen 2.x. Es gibt nur minimale ßnderungen.
- In der Xen DomU Config, ist der Eintrag Nics=<Wert> überflüssig. Dieser Wert wird nun von vif =<Wert> übernommen.
- Neue tools wie xentop ermöglichen einen besseren ßberblick, über die Instanzen.
Für ein Routen basierendes Setup, wie es häufig auf Rootserver zum Einsatz kommt, genügt dieses /etc/xen/xend-config.sxp Skript:
# -*- sh -*- (vif-script vif-bridge) (network-script network-route) (dom0-min-mem 48) (dom0-cpus 0)
- Die Handhabe von PCI Geräten habe ich bereits hier erwähnt.
- Der Name der Xen-bridge lautet nun xenintbr, wichtig für Firewall Regeln.
- Bei der Konfiguration über Routen, behält eth0 seine IP-Adresse und wird nicht auf xentinbr gemappt.
Ein Beispiel, wobei eth0 seine Adresse per DHCP erhält.
# localnet auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp # Internal Bridged Network. auto xenintbr iface xenintbr inet static pre-up brctl addbr xenintbr post-down brctl delbr xenintbr address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 bridge_fd 0 bridge_hello 0 bridge_stp off
Upgrade auf Xen 3.3
Wer den von Xen Standardkernel verwendet, muss unbedingt vorher ein Initimage erstellen, da sämtliche Treiber als Module vorliegen. Das bezieht auch die IDE Treiber mit ein.
depmod 2.6.16.29-xen apt-get install libhtml-template-perl libparse-recdescent-perl wget http://backports.org/debian/pool/main/y/yaird/yaird_0.0.12-8bpo1_i386.deb dpkg -i yaird_0.0.12-8bpo1_i386.deb mkinitrd.yaird -o /boot/initrd.img-2.6.16.29-xen 2.6.16.29-xen -- vi /boot/grub/menu.lst title Xen 3.0.3 / XenLinux 2.6 root (hd0,0) kernel /xen.gz dom0_mem=64000 module /vmlinuz-2.6-xen root=/dev/hda6 ro max_loop=255 module /initrd.img-2.6.16.29-xen
Des weiteren sollte man vorher die Scripte in /etc/xen gesichert haben, besonders dann, wenn die Firewall darauf getrimmt wurde. Denn diese Scripte wurden erneut geändert, sodass möglicherweise die Firewall Scripte nicht mehr funktionieren. Ein zurücksichern der Scripte kann diese Probleme temporär beseitigen, bis die Regeln an die neue Umgebung angepasst wurden. Eine englische Anleitung zu Xen 3.0.3 findet sich hier.
IpTables
Um einen Virtuellen Server mit IPTables zu bestücken, muß der domU Kernel mit IPTables, respektive Netfilter, ausgestattet werden. Der Kernel und die Module sollten dann nach /boot kopiert werden. Hier erweist es sich als Vorteil, einen eigenen Namen zu verwenden, damit die DomU Instanzen unhabhängige Kernel Varianten verwenden können. Kein Muß, aber hilfreich wenn, abgespeckte od. gehärtete Varianten zum Einsatz kommen.
Auszug aus einer Mail:
You must implement it in your dom0 and not in domU. It is the same thing as your domU nic will show up in dom0. So you only have to setup 1 firewall for all of your domU and you do this via dom0 > i search in google but don't find the answer. If i want iptables support > in a virtuel machine, do i need iptables support in Dom0? > > I build my own modules in a Dom1 machine with iptables support, but i > can't load anything: > > modprobe ip_tableshttp://wiki.xensource.com/xenwiki/XenFaq > modprobe: Can't open dependencies > file /lib/modules/2.6.11.10-xenU/modules.dep (No such file or directory) > build:/usr/src/linux# depmod -a > depmod: QM_MODULES: Function not implemented > > Should i recompile my dom0 kernel? >
und
If you want QM_MODULES to go away install module-init-tools that will take care of it, as far as this... file /lib/modules/2.6.11.10-xenU/modules.dep (No such file or directory) well, its not there, so shut down the domU and .. mount -o loop image.img /mount/point cp -dpR /lib/modules/2.6.11.10-xenU /mount/point/lib/modules/ umount /mount/point rev up the domU and have fun
xm save
xm save erlaubt das Dumpen des Speichers einer laufenden DomU. Leider funktioniert das unter Debian Sarge nicht, weil der dazu notwendige xfrd nicht startet, weil ihm ein paar Libs fehlen.
Ich habe ziemlich lange danach gesucht, weil der Fehler (connection refused) und die vorhandene Doku erstmal nicht in Richtung eines weiteren Daemons gezeigt hat, hier als Ergänzung zur Doku:
potemkin:~# /usr/sbin/xfrd
/usr/sbin/xfrd: error while loading shared libraries: libcurl.so.2: cannot open shared object file: No such file or directory
potemkin:~# ldd /usr/sbin/xfrd
libxc.so.2.0 => /usr/lib/libxc.so.2.0 (0xb7fd6000)
libxutil.so.2.0 => /usr/lib/libxutil.so.2.0 (0xb7fc5000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7fb3000)
libcurl.so.2 => not found
libssl.so.4 => not found
libcrypto.so.4 => not found
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7f9d000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7f35000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7f32000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7f0f000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb7efd000)
libdl.so.2 => /lib/libdl.so.2 (0xb7efa000)
libc.so.6 => /lib/libc.so.6 (0xb7dc7000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)
Wenn man die fehlenden, geforderten Libs gegen die passenden, auf dem System vorhandenen Libs linkt, tut das wunderbar:
potemkin:~# ln -s /usr/lib/libcurl.so.3.0.0 /usr/lib/libcurl.so.2 potemkin:~# ln -s /usr/lib/libssl.so.0.9.7 /usr/lib/libssl.so.4 potemkin:~# ln -s /usr/lib/libcrypto.so.0.9.7 /usr/lib/libcrypto.so.4 potemkin:~# /usr/sbin/xfrd [1]+ Stopped /usr/sbin/xfrd potemkin:~# bg [1]+ /usr/sbin/xfrd &
Hinterher habe ich gefunden, das es im Xen-Wiki doch einen Hinweis gibt: Why can't I save VM instances or migrate with Fedora Core 3 or Debian Sarge? I get a connection refused error from twisted referring to port 111. (keine Ahnung, ob diese URL stabil ist, sieht ja mehr nach einer Session-ID aus...)
--Aleks 12:26, 6. Apr 2006 (CEST)
Eigener Kernel
Es empfiehlt sich dringend, eine eigene Vserver Umgebung einzurichten, für das kompilieren von Programmen, sowie dem Kernel. Die Paketierung erfolgt dann in einer Buildumgebung während die Produktiv System keine überflüssigen Programme wie make, gcc und diverse dev-libs beherbergen müssen.
Um einen eigenen Kernel für DomU od. Dom0 zu erstellen, habe ich die Quellen von Xen heruntergeladen, die sich hier finden. Derzeit ist die Version xen-3.0.3-src.tgz aktuell. Nach dem download und dem entpacken im Build System, müssen die Quellen übersetzt werden. Dazu reicht ein "make world" im Quellen Verzeichnis. Es wird dann der Kernel herunterladen, entpackt und mit den Xen Kernel Patches, gepatcht. Im Anschluß daran, finden sich zwei Verzeichnisse Namens linux-2.6.18-xen0 und linux-2.6.18-xenU darin.
Um einen eigenen DomU od. Dom0 Kernel zu erstellen, wird in das jeweilige Verzeichnis gegangen. Mit folgendem Aufruf lässt sich der jeweilige Xen Kernel anpassen, übersetzen und installieren:
# make menuconfig ARCH="xen" # make ARCH="xen" # make install modules_install ARCH="xen"
Hinweis für Debian: make-kpkg kernel_image ... funktionierte an dieser Stelle nicht, er hat was gegen die Großschreibung in DomU, welches gegen die Policy verstößt.
Wenn der Kernel nach /boot und die Module nach /lib/modules installiert wurden, können diese auf Dom0 an ihren jeweiligen Platz übertragen werden. Ich packe das Ganze und kopiere es per scp zur Dom0 Maschine.
Beispiel. DomU Kernel:
# cd / # tar cvzf kernel-xenu_2.0.7-1.tar.gz /boot /lib/modules # scp kernel-xenu_2.0.7-1.tar.gz root@dum0_ip:/usr/src
Das geht natürlich nur, wenn sshd läuft. Wird er aus sicherheitsgründen kein SSH angeboten, muß das per externe Datenträger und (einfacher) das build-image per loop (zb. mount -o loop /mnt/vserver/image/build.img /mnt/vserver/build) gemountet werden. Dann lassen sich auf die Daten normal zugreifen.
Hardware in Dom0
Die gute Nachricht, es ist möglich, die schlechte, leider nicht mit einem DomU Kernel. Es ist bisher keinem gelungen, einen DomU Kernel mit der aktuellen Version von Xen (2.0.7) zu erstellen, welcher auch Zugriff auf Hardware bekommen kann. Werden die entsprechenden Kernel Optionen aktiviert, bootet der Kernel nicht mehr, od. init wird nicht ausgeführt. Um z.B. eine Netzwerkkarte in einem Vserver zu verwenden, muß derzeit ein Dom0 Kernel verwendet werden. Das kann ruhig der selbe sein, wie von Xen selber, der in der Grub-Config angegeben wurde, od. es wird ein eigener erstellt. Es ist auch hier ratsam, eine bestehende Kernel Config (und damit funktionierende) aus /boot zu verwenden. Diese kann dann einfach angepasst werden. Es sollten nur Optionen entfernt werden, bei denen man sich ganz sicher ist, sie nicht zu brauchen. Ansonsten ist die Wahrscheinlichkeit hoch, das auch dieser Kernel nicht funktioniert.
Damit die xen Dom0 Maschine die Hardware nicht für sich selber verwendet, muß diese vor Dom0 versteckt werden. Dies geschieht mit einer Grub Zeile. Ein Bespiel aus meiner grub.conf (od. menu.lst):
title Xen 2.0 / XenLinux 2.6.11 kernel /boot/xen.gz dom0_mem=64000 physdev_dom0_hide='(00:0c.0)' max_loop=32 module /boot/xen-linux-2.6.11.12-xen0.xen.kernel root=/dev/hda2 ro
Es ist der Eintrag physdev_dom0_hide='(00:0c.0)' der dieses Wunder vollbringt. Die Adresse 00:0c.0 ist die Busadresse vom PCI Steckplatz, die per lspci od. cat /proc/pci ausgelesen werden kann. Nach einem reboot, sollte diese Hardware nicht mer auftauchen. Um dann diese Hardware der DomU zuzuordnen, muss in der jeweiligen DomU Config eine weitere Zeile hinzugefügt werden.
Merke: Bei mehr als einem Gerät, gilt: physdev_dom0_hide='(00:0c.0)(00:0b.0)(00:0a.0)' etc.
Beispiel meiner Config:
nics=1 vif = ['mac=aa:00:00:00:00:02, bridge=xen-br0'] dhcp ="off" ip="192.168.100.3" netmask="255.255.255.0" gateway="192.168.100.253" hostname="mx02" pci=['00,0c,0'] extra="3"
Man achte auf die Schreibweise. Komma, statt Doppelpunkt. Ist dies geschehen, kann diese Hardware per /cat/proc/pci in der DomU Maschine bestaunt und genutzt werden.
Xen 3.0.2
Ab Xen 3.0.2 ist die Möglichkeit zurückgekehrt, PCI Geräte wieder in einer DomU zu nutzen. Die entsprechenden Parameter haben sich ein wenig geändert. Die Grub Kernel Parameter (also in der Zeile mit dem lauten nun:
title Xen 3.0 XenLinux 2.6.16
root (hd0,0) kernel /xen.gz dom0_mem=64000 module /vmlinuz-2.6-xen root=/dev/hda5 ro console=tty0 max_loop=64 pciback.hide=(0000:00:0c.0)(0000:00:09.0)
In der Xen3 DomU Config steht:
- pci = ['00:0c.00','00:09.00']
Eine weitere Besonderheit besteht darin, dass die Geräte weiterhin in der Dom0 zu sehen sind, und nicht wie unter Xen2.x, ausgeblendet werden.
Der Sinn hinter dieser Xen3 ßnderung bestehen darin, dass die Option pciback.hide lediglich verhindert, das ein Treiber geladen, aber die Hardware dennoch mit lspci aufgelistet wird.
Nachträglich PCI Karten in eine DomU hinzufügen
Es besteht auch die Möglichkeit, PCI Karten nachträglich hinzuzufügen, ohne Grub verändern und damit neu starten zu müssen. Dafür reicht es, folgendes auszuführen:
echo -n 0000:00:0c.0 > /sys/bus/pci/drivers/pciback/new_slot echo -n 0000:00:09.0 > /sys/bus/pci/drivers/pciback/bind
Wurde alles korrekt ausgeführt, sind die Karten nun nach dem Start der Xen DomU zu sehen:
asterisk:~# lspci 0000:00:09.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02) 0000:00:0c.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
Das Ganze lässt sich natürlich auch wieder rückgängig machen, nachdem die entsprechende DomU runtergefahren wurde:
echo -n 0000:00:0c.0 > /sys/bus/pci/drivers/<treibername>/unbind echo -n 0000:00:09.0 > /sys/bus/pci/drivers/<treibername>/unbind
echo -n 0000:00:0c.0 > /sys/bus/pci/drivers/pciback/new_slot echo -n 0000:00:09.0 > /sys/bus/pci/drivers/pciback/bind
Damit lässt sich die Karte wieder in Dom0 verwenden. Das Ganze funktioniert natürlich nur, wenn keine Treiber in Dom0 geladen wurden.
Modem ISDN und Co.
Wer wie ich, Hylafax in einer DomU (aber mit Dom0 Kernel) nutzen möchte, kann leider derzeit nicht die Onboard Com1 od. Com2 Ports nutzen. Gleiches gilt auch für den Parallel Port. Denn diese basieren immer noch auf der ISA-Bustechnologie. Diese lassen sich nicht, zwischen Dom0 und DomU (derzeit) teilen. Ein Ausweg besteht darin, einen USB zu Seriell Wandler zu verwenden (und dann den USB Controller, der bei lspci auftaucht in die Grub Zeile eintragen), od. eine PCI Schnittstellenkarte.
Für ISDN sollte das gleiche gelten, allerdings habe ich es bisher noch nicht getestet, aber es gibt diverse User, die ISDN in DomU (mit Dom0 Kernel) verwenden.
Nicht genügend Loop Geräte
Unter einem standard Linux ohne devfs/udevfs, wird es nach spätestens 8 gemounteten Loop Laufwerken eng. Um diese mögliche Anzahl zu erhöhen, müssen zwei Dinge getan werden. Erstens max_loop=64 in die Kernel Zeile der Grub Config schreiben, zweitens, weitere Geräte Dateien anlegen:
# mknod -m 660 /dev/loop8 b 7 8 # mknod -m 660 /dev/loop9 b 7 9 # mknod -m 660 /dev/loop10 b 7 10 # ...
Das ließe sich selbstverständlich mit einem Bash Einzeiler schneller bewerkstelligen:
# for ((i=8;i<=$ANZAHL;i+=1)); do mknod -m 660 /dev/loop$i b 7 $i; done
Meine Umsetzung
Zweck dieser Einarbeitung war es, zu lernen wie Xen funktioniert und wo es seinen Einsatz findet. Da unser hauseigener Router eine schnellere Plattform bekommen konnte, war dies eine passende Möglichkeit, Xen im Einsatz zu erleben. Bis vor kurzem lief alles (Mail, SQL, DSL/Firewall, Web, FAX) auf einem Gentoo PC.
Mit Xen konnte ich die Aufgaben besser verteilen. Der Rechner bekam drei DomUs, mit Dom0 also vier Instanzen:
DomU1 MX02 Gentoo
Die DomU1 bekam alle Aufgaben zugeteilt, was mit Mail zu tun hat. Das betraf den SMTP Server (Postfix), Pop/imap (Cyrus), Hylafax. Da die Konten in MySQL Datenbanken liegen, wurde auch der MySQL Server auf diesem installiert. Aus performance Gründen hätten man auch da noch eine eigene Instanz einrichten können, doch war das für meine Zwecke overkill. Dem DomU wurde eine serielle Schnittstellenkarte zugeteilt, damit Hylafax weiterhin Faxe über ein Modem empfangen und senden kann.
Da ich bei den Mailgeschichten auf möglichst akuelle Software setze, kommt Gentoo zum Einsatz, denn selbst Debian Sarge ist schon zu alt (insb. bei Cyrus).
DomU2 Web Debian
Auf dieser Instanz läuft lediglich ein Apache2 mit PHP4 unter Debian Sarge. Auf diesem sind die Konfigurationsverwaltung für das Mailsystem (web-cyradm), als auch das Horde/IMP Webmail installiert. Auch können hier die Filter mit Hilfe von smartsieve eingerichtet werden. Der Datenbankzugriff geschieht per TCP auf MX02.
Um Interne Seiten von Außen fernzuhalten, wurden zwei virtuelle Webserver eingerichtet. Einer der nur vom lokalen Netz aus erreicht werden kann, und einen zweiten für externe Zugriffe (wie Webmail (auch über SSL)).
DomU3 Build Debian
Dieser Rechner dient lediglich dazu, um Pakete zu kompilieren, Kernel zu erstellen etc. Er wird nur bei Bedarf gestartet. Dort sind alle nötigen Tools und Libs vorhanden, die auf den anderen überflüssig wären.
Dom0 Hauptinstanz
Hier sind zwei Netzwerkkarten installiert. Eine für das DSL-Modem, die andere für das Netzwerk. Der Kernel wurde mit Iptables Funktionen sowie pppoe ausgestattet. Ursprünglich war dies für eine Domu4 vorgesehen, doch da ich keine DSL Verbindung herstellen konnte, musste ich umdisponieren. Die Firewall ist so konfiguriert, das sie Anfragen für Mail und Web, an die entsprechenden Rechner intern weiterleitet. Der Dom0 Rechner besitzt außer SSH, keine weiteren Dienste und ist somit praktisch kaum anfällig für Angriffe. Ein Ideales Design würde den Web und MX02 Rechner in eine DMZ stellen, doch wäre das für mich auch ein Overkill.
Die Firewall habe ich mit Hilfe von fwbuilder zusammengestellt, welches garnicht so einfach war, da die Logik dieses Programms sich mir nicht anfangs erschloss.
Mein Fazit
Mittlerweile läuft diese Kombination schon seit vier Wochen anstandslos durch und ich musste noch nicht nachkonfigurieren. Die Performance ist ausgeglichen. Selbst von der MX02 auf 100% CPU steigt, merkt man davon auf dem Web Server nichts.
Die nächste größere ßnderung wird sein, Xen auf ein LVM + Raid1 zu legen, um damit für einen Plattenausfall vorzusorgen.
Have Fun
Läuft das erste System, läßt sich in weniger als 5 Minuten das zweite System einrichten. Es müssen nur die Images kopiert und die Xen Config Datei angepasst werden. Wer die MAC nicht generieren läßt, darf nicht vergessen sie auch zu ändern, sonst läuft das Netzwerk nicht.
Quellen
- Xen host with Debian
- Creating File Backed VBD
- Xen User Documentation
- Xen Install Log
- Xen Install Log, ausführliche PDF Version
- Wikipedia Eintrag
- Ideal(istic) Xen firewall design
- Xen Netzwerk über Routing für z.B. Provider Server (Abschnitt: Routen oder Bridge)
- Xen3.0.2 PCI Hardware
- Xen3 User Anleitung
Dank
Mein besonderer Dank geht an Johannes Formann für seine Hilfe beim Routing von Xen und an Ernst Bachmann, der mir alles nochmal genau erklärt hat und von dem diese hübsche ASCII Grafik stammt :-)
Sonstiges
Was sonst noch so anfällt.
IPCOP
Per Mail erhalten, IPCop PDF-Anleitung in einer DomU Maschine.
fwbuilder Firewall für Xen
Firewall Beispiel für Xen mit virtuellen Hosts, erstellt mit fwbuilder (2.0.9). Diese ist so eingerichtet, das verschiedene Dienste an die virtuellen Kollegen weitergereicht werden (port forwarding), sowie die ausgehenden Quellpakete verändert werden. Für den Provider erscheint ausschließlich die externe IP Adresse. Zur Benutzung sollte die Adresse von der Netzwerkkarte: xen-eth0, angepasst werden. In fwbuilder ist sie zwar als dynamisch markiert, doch konnte ich bestimmte Regeln nicht definieren, ohne das dort eine IP stand.
Sollte jemand Verbesserungen beitragen können, bitte an mich weitergeben.
TODO
IPTables einrichten und Firewall erstellen
--Denny 00:14, 11. Jun 2005 (CEST)
