Aufteilung
- Aufgrund der Länge habe ich die Anleitung nun aufgeteilt. Am Ende der jeweiligen Seite findet einen Link zur nachfolgenden Seite.
Netzwerk Setups
Bridge Setup - Etch als Gast mit Imagedatei
- Da wir als erstes ein Bridge basiertes Setup verwenden wollen, müssen wir in der /etc/xen/xend-config.sxp die beiden Einträge aktivieren und ggf. neustarten mit /etc/init.d/xend restart:
|
|
(network-script network-bridge)
(vif-script vif-bridge)
|
- Hier erstellen wir nun unseren Gast mit dem Debian Xen Tool, wobei wir als Hostname vm01 mitgeben:
|
|
dom0:# xen-create-image --hostname=vm01
|
- Eine Ausgabe schaut dann so aus:
|
|
General Infomation
--------------------
Hostname : vm01
Distribution : etch
Fileystem Type : ext1
Size Information
----------------
Image size : 1Gb
Swap size : 128Mb
Image type : full
Memory size : 128Mb
Kernel path : /boot/vmlinuz-2.6.18-4-xen-686
Initrd path : /boot/initrd.img-2.6.18-4-xen-686
Networking Information
----------------------
IP Address : DHCP
|
|
|
In der Konfigurationsdatei sollten LVM und dir nicht gleichzeitig aktiv sein, denn sonst werden zwar Images erzeugt, aber er wird versuchen den Datenträger über LVM einzubinden
|
- Es hilft unter Umständen, wenn die Logdatei parallel angeschaut wird:
|
|
dom0:# tail -f /var/log/xen-tools/<domainname>.log
|
|
|
Wird das debootstrap von Hand aufgerufen, so muss am Schluß unbedingt die libc6-xen installiert werden (Per chroot wechseln und dann ein apt-get install libc6-xen), da es ansonsten zu Fehlermeldungen, wie 4gb seg fixup kommt
|
- Wurde der Gast installiert, haben wir auch eine passende Konfigurationsdatei unter /etc/xen/vm01.cfg
|
|
Ab Debian Etch werden die MAC Adressen unter Udev mit dem Gerätenamen verknüpft. Daher muss in der Konfiguration eine MAC Adresse eingetragen werden. Am einfachsten lässt sich diese nach dem ersten Start mit "ifconfig / ip addr show dev eth0" od. im Wirt mit xm network-list <gastname> erfahren. Diese MAC Adresse muss mit der Gastkonfiguration unter /etc/udev/rules.d/z25_persistent-net.rules übereinstimmen, da beim nächsten Start das Netzwerk nicht mehr funktioniert und die eth + 1 erstellt wird.
|
|
|
kernel = '/boot/vmlinuz-2.6.18-4-xen-686'
ramdisk = '/boot/initrd.img-2.6.18-4-xen-686'
memory = '128'
root = '/dev/sda1 ro'
disk = [ 'file:/home/xen/domains/vm01/disk.img,sda1,w', 'file:/home/xen/domains/vm01/swap.img,sda2,w' ]
name = 'vm01'
dhcp = 'dhcp'
vif = [ 'mac =00:16:3E:27:1F:A6' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
|
|
|
Weitere Werte der Konfigurationsdatei lassen sich über den Befehl: xm create --help_config anzeigen, oder in der Manpage xmdomain.cfg(5).
|
- Bevor wir den Gast nun starten, überprüfen wir, ob die Bridge auch entsprechend vorhanden ist:
|
|
dom0:# brctl show
bridge name bridge id STP enabled interfaces
xenbr0 8000.feffffffffff no vif0.0
peth0
|
- Dann starten wir unseren Gast
|
|
dom0:# xm create vm01.cfg
|
- Wir können uns von dem Start mit xm überzeugen:
|
|
dom0:# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 739 1 r----- 1029.5
vm01 5 128 1 -b---- 5.8
|
- und die Bridge sieht nun folgendermaßen aus:
|
|
dom0:# brctl show
bridge name bridge id STP enabled interfaces
xenbr0 8000.feffffffffff no vif0.0
peth0
vif5.0
|
- Wir können nun erkennen, dass die virtuelle Netzwerkkarte vif5.0 hinzugekommen ist. Auch mit ip od. ifconfig können wir uns davon überzeugen:
|
|
vif5.0: <BROADCAST,NOARP,UP,10000> mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
valid_lft forever preferred_lft forever
|
- Nachdem das geklappt hat, können wir uns mit dem Gast verbinden. Dazu verwenden wir erneut xm mit dem Parameter console vm01
- Nun sollten wir vor einem Login Bildschirm stehen und können uns einloggen, wobei kein Root Kennwort nötig ist.
- Sofern ein DHCP lief, sollte der Gast auch schon eine IP Adresse bekommen haben, sollte kein DHCP laufen, vergeben wir schnell eine temporäre Adresse:
|
|
vm01:# ip addr add 192.168.1.100 brd + dev eth0
vm01:# ip link set up
vm01:# ip route default via 192.168.1.254
|
- Die Adresse kann natürlich im selben Netz liegen, wie unser Wirt. Sollte ip nicht funktionieren, dann geht das auch über ifconfig
|
|
vm01:# ifconfig eth0 192.168.1.100 up
vm01:# route add default gw 192.168.1.254
|
- Ein Ping sollte nun möglich sein. Für eine korrekte DNS Auflösung sollte nur noch die /etc/resolv.conf angepasst werden, sofern dies noch nicht geschehen ist.
- Um die IP dauerhaft einzutragen, bedienen wir uns der passenden Konfigurationsdatei:
|
|
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.254
|
- Nach einem /etc/init.d/networking restart sollte nach wie vor das Netzwerk funktionieren, incl. der obligatorischen lo Netzwerkkarte.
- Haben wir uns von der Funktionsfähigkeit der virtuellen Maschine überzeugt, lösen wir uns wieder von der Konsole. Dazu bedarf es einer Tastenkombination:
- Funktioniert mittels puTTY diese Tastenkombination nicht, hilft evtl. STRG + 5 bei deutscher Tastatur.
- Nun können entsprechend weitere Gäste nach dem selben Schema erstellt werden.
- Mit 'xm können wir nun die virtuelle Maschine auch herunterfahren oder neustarten:
|
|
dom0:# xm reboot vm01
dom0:# xm shutdown vm01
|
Routing Setup - Etch als Gast mit LVM
- In dem oberen Beispiel haben wir eine Image Datei erzeugen lassen und für die Netzwerkkommunikation die Bridge verwendet. Nun stellen wir die Konfigurationsdatei der Debian Xen Tools auf LVM um. In diesem Beispiel heißt der Pool daten und sollte entsprechend den eigenen Bedürfnissen angepasst werden.
- /etc/xen-tools/xen-tools.conf
|
|
# dir = /home/xen
lvm = daten
|
- Die restlichen Werte können wir belassen. Nun konfigurieren wir den Xend um, sodass er nun Routing für die Gäste benutzt:
|
|
# (network-script network-bridge)
# (vif-script vif-bridge)
(network-script network-route)
(vif-script vif-route)
|
- Danach nicht vergessen, den Xen Daemon neuzustarten:
|
|
dom0:# /etc/init.d/xend restart
|
- Danach genügt wieder ein einfacher Aufruf der Xen Tools
|
|
dom0:# xen-create-image --hostname=vm02
|
- Auch die Ausgabe ist mit der von vm01 weitestgehend identisch:
General Infomation
--------------------
Hostname : vm02
Distribution : etch
Fileystem Type : ext3
Size Information
----------------
Image size : 1Gb
Swap size : 128Mb
Image type : full
Memory size : 128Mb
Kernel path : /boot/vmlinuz-2.6.18-4-xen-686
Initrd path : /boot/initrd.img-2.6.18-4-xen-686
Networking Information
----------------------
IP Address : DHCP
Creating ext3 filesystem on /dev/daten/vm02-disk
Done
- Unter anderen sehen wir hier, wo nun unser zweiter Gast ein Zuhause gefunden hat. Auch die Konfigurationsdatei des Gastes vm02 unterscheidet sich nicht weiter von der vm01. Allerdings müssen wir in diesem Fall beide Dateien bearbeiten. Insbesondere interessiert uns die vif = Zeile. So lautet sie bisher:
- /etc/xen/vm01.cfg und /etc/xen/vm02.cfg
- Nun müssen wir dieses Mal eine IP Adresse eintragen, und zwar aus dem selben Netz, in welchem sich auch der Wirt (Dom0) befindet.
|
|
vif = [ 'ip=192.168.1.100' ]
|
|
|
vif = [ 'ip=192.168.1.101' ]
|
- Damit weiß der Xend Daemon nun, welche Routen erzeugt werden müssen. Des weiteren wird das IP Weiterleiten auf der Karte vif<Nummer>.0 aktiviert. Doch starten wir einfach einen Gast, dann können uns davon überzeugen:
|
|
Die Nummern der vif werden sukzessive herauf gezählt und fangen erst nach einem Reboot wieder bei vif1.0 an.
|
|
|
dom0:# ip route show
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.150
default via 192.168.1.254 dev eth0
dom0:# xm create vm01.cfg
Using config file "/etc/xen/vm01.cfg".
Started domain vm01
dom0:# ip route show
192.168.1.100 dev vif6.0 scope link src 192.168.1.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
default via 192.168.1.254 dev eth0
|
- Wir können nun sehen, das vif6.0 erzeugt, eine Route hinzugefügt und der Arp Proxy aktiviert wurde:
|
|
dom0:# cat /proc/sys/net/ipv4/ip_forward
1
dom0:# cat /proc/sys/net/ipv4/conf/vif6.0/proxy_arp
1
|
- Wenn nun auch vm02 gestartet wird, ist die Ausgabe äquivalent zu vm01. Dies reicht schon, damit sich alle Drei unterhalten können, doch für externe Rechner reicht dies noch nicht. Es fehlt noch der Arp Proxy für Netzwerkkarte eth0:
|
|
dom0:# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
|
- Siehe auch den Teil Routen, in dieser Anleitung.
- Damit wir das nicht immer von Hand ausführen müssen, passen wir das Script für die Routen leicht an:
- /etc/xen/scripts/vif-route
|
|
case "$command" in
online)
ifconfig ${vif} ${main_ip} netmask 255.255.255.255 up
echo 1 >/proc/sys/net/ipv4/conf/${vif}/proxy_arp
# hier folgt die Zeile
echo 1 >/proc/sys/net/ipv4/conf/eth0/proxy_arp
ipcmd='add'
cmdprefix=''
;;
offline)
do_without_error ifdown ${vif}
ipcmd='del'
cmdprefix='do_without_error'
# Hier setzen wir den Arp Proxy wieder auf 0
echo 0 >/proc/sys/net/ipv4/conf/eth0/proxy_arp
;;
esac
|
- Eine Alternative Möglichkeit wäre noch, beim starten des Netzwerkes dies automatisch zu aktivieren, unabhängig von den Xen Scripten. Dazu gibt es unter Debian die Möglichkeit, Befehle ausführen zu lassen, vor oder nach dem Initialisieren des Netzwerkes. Proxy Arp betreffend ließe sich folgende Zeilte verwenden:
|
|
auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.254
# Arp für Xen aktivieren
post-up echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
|
- Die Netzwerkkonfiguration von vm01 und vm02 kann so aussehen:
|
|
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.254
|
- Für vm02 ist dann die 192.168.1.101 einzutragen und damit sollte nun die Kommunikation über die Routen laufen und zwar in beide Richtungen. Mit einem Netzwerk Sniffer wie tcpdump od. iptraf, ließe sich das schnell überprüfen.
Kombiniertes Routing und Bridge
- Die dritte und letzte Methode die ich erläutern werde, nutzt eine Kombination aus beidem. Wir erstellen ein Setup, welches häufig auf Rootserver zum Einsatz kommt. Dabei darf unter keinen Umständen die MAC Adresse einer der Gäste an das "Tageslicht" geraten - sprich - dem Switch des Providers. Wir nutzen hier die Möglichkeit des NAT. Siehe auch hierzu NAT.
Möglichkeit 1 mit NAT
- Um dies zu konfigurieren, bedarf es nur einer Anpassung des Xend Daemons:
|
|
(network-script network-nat)
(vif-script vif-nat)
|
- Die Bridge und Routing Scripte sollten dementsprechend deaktiviert werden. Nun können wir den DomUs ein völlig anderes Netz geben:
|
|
vif = [ 'ip=192.168.4.10,mac =00:16:3E:27:1F:A6' ]
|
- vm01: /etc/network/interfaces
|
|
auto eth0
iface eth0 inet static
address 192.168.4.10
netmask 255.255.255.0
gateway 192.168.4.137
|
- Das Gateway entspricht der IP Adresse des vif<nummer>, welches beim hochfahren der DomU in der Dom0 entstanden ist.
- Nun kann überprüft werden, ob das Netzwerk in der DomU funktioniert und auch wirklich extern nur die IP des Gastes (und damit nur seine MAC) zu sehen ist. Die Skripte übernehmen ebenfalls den IPTables Anteil, welcher bei NAT notwendig wird.
Möglichkeit 2 mit NAT
- Eine weitere Möglichkeit besteht darin, eine dedizierte Bridge zu erstellen, welche die Gäste mit einander verbindet. Dazu erstellen wir eine Bridge xen-intern in der Dom0:
|
|
dom0:# brctl addbr xen-intern
dom0:# brctl stp xen-intern off
dom0:# brctl sethello xen-intern 0
dom0:# brctl setfd xen-intern 0
|
- Dann geben wir der Bridge xen-intern eine IP-Adresse, welche nicht nicht nach außen gelangt. Hier bietet sich ein privates Netz an:
|
|
dom0:# ip addr add 192.168.10.1/24 brd + dev xen-intern
dom0:# ip link set up xen-intern
|
- Danach passen wir die Xend Daemon Konfigurationsdatei an:
|
|
(network-script network-route)
# Mit der nachfolgenden Zeile bestimmen wir, an welche Bridge die Gäste gebunden werden sollen
(vif-bridge xen-intern)
(vif-script vif-bridge)
|
- Nun passen wir den Gast an:
|
|
vif = ['bridge=xen-intern,vifname=vm01.1,mac=00:16:3E:55:3D:AC']
|
|
|
Nicht vergessen die MAC Adresse mit einzutragen, da sie sonst erneut generiert wird, womit verschiedene Distributionen die Netzwerkkarte nicht mehr zuordnen können, weil sie dann eine neue MAC sehen, die nicht zur alten Konfiguration passt
|
|
|
Um die vif Zuordnung zu vereinfachen, bietet es sich an, den Namen der Netzwerkkarte des Gastes einen Namen zu geben. In diesem Beispiel: vm01.1
|
- Die Gäste bekommen nun eine IP Adresse aus dem 192.168.10.x'er Pool und als Gateway 192.168.10.1.
- Die Bridge sieht nun im folgenden aus:
|
|
dom0:# brctl show
bridge name bridge id STP enabled interfaces
xen-intern 8000.feffffffffff no vif8.0
vif9.0
|
- Wir können nun sehen, beide virtuellen Gäste sind nun über diese Bridge verbunden und können sich direkt unterhalten.
- Nun kommen wir zum dem NAT Teil, denn so würden immer noch die fremden IP- und MAC-Adressen im Netz auftauchen. Um dies zu verhindern, bedienen wir uns zweier NAT Regeln mit iptables, um das zu verhindern:
|
|
dom0:# iptables -t nat -A POSTROUTING -o eth0 -s 192.168.10.0/24 -j SNAT --to 192.168.1.1
dom0:# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.1.1
|
- Die Adresse 192.168.1.1 ist dabei die IP-Adresse, die der Rechner vom Provider erhalten hat. Findet nun ein Datenverkehr statt, so werden die internen Adressen durch die Externe getauscht. Diese beiden Zeilen würden allein jedoch nicht reichen, daher bedarf es noch eines Konstrukts. Da ich kein Fan von kryptischen IP-Tables Regeln bin, habe ich dafür eine Vorlage für fwbuilder erstellt. Dieses lässt sich hier herunterladen. Einfach umbennen in Xen-dom0-firewall.fwb und laden.
- In diesem Script wurden die beiden, virtuellen Maschinen eingetragen, wobei die HTTP Ports auf den Rechner vm01 geleitet, und die E-Mail Ports auf vm02 weitergeleitet werden. Diese Vorlage sollte einen Einblick geben, wie so etwas ausschauen kann. Doch für Verbesserungen wäre ich sehr dankbar.
- Damit wir die Bridge nicht immer von Hand erstellen müssen, tragen wir sie in der Dom0 Netzwerkkonfiguration fest ein:
|
|
# Interne Brücke für die Xen Gäste
auto xen-intern
iface xen-intern inet static
pre-up brctl addbr xen-intern
post-down brctl delbr xen-intern
address 192.168.10.1
netmask 255.255.255.0
network 192.168.10.0
broadcast 192.168.10.255
bridge_fd 0
bridge_hello 0
bridge_stp off
|
Mehrere physische Netzwerkkarten
- Sofern Xen mit nur einer Netzwerkkarte ausgestattet wurde, läuft zumeist alles wie geschmiert. Doch möchte man bestimmte Gäste über dedizierte Netzwerkkarten laufen lassen, gibt es zwei Möglichkeiten.
- Variante 1 besteht in dem Durchreichen der physischen Netzwerkkarte in einen Gast. Dies wird im Hardware Abschnitt dieser Anleitung erläutert. Der Nachteil jedoch besteht darin, dass diese ausschließlich nur diesem Gast zur Verfügung steht.
- Variante 2 stellt weitere Bridges zur Verfügung, über die wir die ausgewählten Gäste mit dem dedizierten Netz verbinden können.
- Temporär lässt sich dies am einfach testen, in dem das network-bridge Script im Xen Script Verzeichnis mit entsprechenden Parametern gestartet wird:
dom0:# /etc/xen/scripts/network-bridge vifnum=0 netdev=eth0 bridge=xenbr0
dom0:# /etc/xen/scripts/network-bridge vifnum=1 netdev=eth1 bridge=xenbr1
- In diesem Fall haben wir zwei Brücken erstellt, mit jeweils einer physischen Netzwerkkarte. Damit die Gäste diese Verwenden können, reicht in der DomU Konfiguration folgende Anpassung:
|
|
[...]
vif = [ 'bridge=xenbr0' ]
|
|
|
[...]
vif = [ 'bridge=xenbr1' ]
|
- Doch beim nächsten Start vom Xen System wären diese Brücken wieder verschwunden. Um diese dauerhaft, bzw., automatisch einzurichten, bedarf es eines Wrapper Scriptes, welches wir unter dem freien Namen 2nics-network-script ablegen:
- /etc/xen/scripts/2nics-network-script
|
|
#!/bin/sh
dir=$(dirname "$0")
"$dir/network-bridge" "$@" vifnum=0 netdev=eth0 bridge=xenbr0
"$dir/network-bridge" "$@" vifnum=1 netdev=eth1 bridge=xenbr1
|
- Nach einem ...:
|
|
dom0:# chmod +x /etc/xen/scripts/2nics-network-script
|
- ... ist das Script nun ausführbar und kann von Xen genutzt werden, nachdem wir ihm dies mitgeteilt haben:
|
|
[...]
(network-script 2nics-network-script)
(vif-script vif-bridge)
[...]
|
- Nun ist dies dauerhaft eingerichtet und unterscheidet sich vom Internen nicht von dem Setup, mit nur einer Karte.
Andere Gäste
- Natürlich sind die Xen Gäste, und auch der Wirt, nicht nur an Debian gebunden (auch wenn wir wissen, das Debian das Beste Linux ist ;-) ..), sondern lassen sich auf eine Vielzahl anderer Systeme übertragen, welche mit mehr oder weniger Aufwand verbunden sind.
- Nachfolgend finden sie weitere Hinweise, wie sie Gäste anderer Distributionen installieren können.
Debian Etch Wirt - Fedora Core 6 Gast
- Um ein Fedora Core 6 installieren möchte, wird in erster Linie Yum verwendet. rpmstrap funktioniert leider nur mit älteren Systemen, sodass es hier nicht erwähnt wird.
- Die Debian Etch Variante von Yum ist leider ebenfalls zu alt und funktioniert daher mit Fedora Core 6 und Neueren nicht , sodass wir in jedem Fall den Paket Manager aktualisieren müssen. Da Yum auf Python basiert, wird außer make und ein paar weitere Pakete nicht mehr benötigt. Zuerst installieren wir diese entsprechenden Programme:
Vorbereitungen - Yum
|
|
dom0:# apt-get install python-sqlite python-celementtree python-libxml2 python-urlgrabber rpm python-rpm
|
- Dann laden wir die passende Yum Version herunter und installieren sie:
|
|
dom0:# cd /usr/src && wget http://linux.duke.edu/projects/yum/download/3.0/yum-3.0.6.tar.gz
dom0:# tar xvzf yum-3.0.6.tar.gz
dom0:# cd yum-3.0.6
dom0:# make DESTDIR=/ && make install DESTDIR=/
|
|
|
Die neuste Variante von yum 3.2.x, produzierte nur Fehler, daher wird nur die 3.0.6 verwendet
|
Fedora 6 - Installation
- Ist dies geschehen, kann auch schon installiert werden. Ich gehe davon aus, dass ein Datenträger für Fedora (Image, oder Volume) unter /mnt eingehangen wurde, unter dem Wirt.
- Zunächst einmal benötigen wir eine Konfigurationsdatei für Yum, welche folgenden Inhalt hat:
- /etc/yum.repos.d/fc6.conf
|
|
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
exclude=*-debuginfo
gpgcheck=0
obsoletes=1
reposdir=/dev/null
[base]
name=Fedora Core 6 - $basearch - Base
mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-6
enabled=1
[updates-released]
name=Fedora Core 6 - $basearch - Released Updates
mirrorlist=http://fedora.redhat.com/download/mirrors/updates-released-fc6
enabled=1
|
- Dann kann mit der Installation begonnen werden und wird von folgendem Befehl in die Wege geleitet:
|
|
dom0:# yum -c /etc/yum.repos.d/fc6.conf --installroot=/mnt -y groupinstall Core
|
- Dann wird das Basissystem installiert und zusätzlich benötigen wir noch folgende:
|
|
dom0:# yum -c /etc/yum.repos.d/fc6.conf --installroot=/mnt -y install yum dhclient openssh openssh-server
|
- Ist dies ohne Fehler durchgelaufen, können wir das System konfigurieren:
|
|
dom0:# cp -a /lib/modules/`uname -r`/ /mnt/lib/modules/
dom0:# mount -o bind /proc/ /mnt/proc/
dom0:# mount -o bind /dev/ /mnt/dev/
dom0:# cp /etc/resolv.conf /mnt/etc/
|
- Dann benötigen wir eine entsprechende fstab:
|
|
/dev/sda1 / ext3 defaults 0 1
/dev/sda2 swap swap defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
|
- Um Problemen mit der Bibliothek zu vermeiden, müssen wir die Konfigurationsdatei der libc6 anpassen:
- /mnt/etc/ld.so.conf.d/libc6-xen.conf
- Natürlich möchten wir auch Netzwerk, daher erstellen wir auch die Netzwerk Parameter:
- /mnt/etc/sysconfig/network
|
|
NETWORKING=yes
HOSTNAME=fedora6
|
- /mnt/etc/sysconfig/network-scripts/ifcfg-eth0
|
|
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.1.10
NETMASK=255.255.255.0
NETWORK=192.168.1.0
GATEWAY=192.168.1.1
ONBOOT=yes
|
- Ich habe hier eine statische Konfiguration gewählt, und keine Automatische über DHCP. Sollte DHCP gewünscht werden, einfach in der BOOTPROTO=dhcp einfügen.
- Als nächstes wechseln wir per chroot in das Fedora 6 und schließen die arbeiten ab:
|
|
dom0:# chroot /mnt
fedora6:# pwconv
fedora6:# passwd
fedora6:# for i in console null zero ; do MAKEDEV -d /dev/ -x $i ; done
|
- Da ich ein Routen basiertes Setup gewählt habe, schaut die Xen DomU Konfiguration im folgenden aus:
|
|
kernel = '/boot/vmlinuz-2.6.18-xen'
ramdisk = '/boot/initrd.img-2.6.18-xen'
memory = '64'
root = '/dev/sda1 ro'
disk = [ 'phy:daten/fedora,sda1,w', 'phy:daten/fedora-swap,sda2,w' ]
name = 'fedora6'
vif = [ 'ip=192.168.1.10' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
|
- Nun kann unser Fedora entsprechend gestartet werden. Wer noch die 4gb fixup ... Meldungen erhalten sollte, führt ldconfig nochmal aus und startet den Gast neu.
- Sie sollten als nächstes Ihr Fedora auf den neuesten Stand bringen:
SLES10 (SP1) / OpenSUSE - Installation
Einfache Methode
- Für die Installation eines SLES / OpenSUSE Rechners unter einem Debian Host, sind zahlreiche und fingerbrechende Kommandos nötig, da es nicht ganz einfach ist, ein SUSE System per yum zu installieren. Der Grund liegt vor allem in der fehlenden Yum Konfiguration, und dem Wissen, welche Pakete denn nun wirklich wichtig sind.
- Daher gibt es eine einfache, aber effektive Methode, diesem Problem aus dem Weg zu gehen: Suse sich selbst in ein Verzeichnis installieren lassen. Dies bedeutet, es muss ein bereits laufendes SUSE vorhanden sein. Dies kann entweder in Form einer Live CD/DVD-Rom sein, oder eben einem bereits installiertem System (z.B. innerhalb von Vmware Player). Danach kann man über Software|Installation in ein Verzeichnis ein Verzeichnis angeben und wählt zum Schluß nur noch die Pakete aus, welche gewünscht werden. Es empfiehlt sich hier X, Gnome etc. zu deaktivieren. Das Image schlägt dann nur mit rund 600MB (gepackt ~200MB) zu Buche. Den Haken "SuSEconfig und Yast ausführen beim ersten Start" sollte unbedingt angehakt werden, welches dann die ersten Standardparameter abfragt.
- Danach kann man das Image unter jedem Wirt entpacken, sei es in einem Dateiimage welches per Loop gemountet wurde, oder auf einem anderen Datenträger.
- Danach gibt es nur noch wenig innerhalb des fast fertigen SuSE Systems zu tun:
|
|
/dev/sda1 / ext3 defaults 0 1
/dev/sda2 swap swap defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
|
- Da ich in meinem Fall den Debian Xen Dom0 Kernel verwende, benötigen wir innerhalb des Gastes noch die Module zum passenden Kernel. Dies ist mit folgender Zeile schnell erledigt:
|
|
dom0:# cp -r /lib/modules/`uname -r` /mnt/lib/modules
|
- Wobei /mnt für das gemountete SuSE Linux System steht.
- Einer der wichtigen Punkte wären zum Beispiel das Netzwerk. Bei jedem Start des Gastes wird eine neue MAC Adresse vom Xen generiert, was dann das SuSE System dazu veranlasst, für jede neue MAC Adresse eine neue Netzwerkkarte zu generieren. Dafür ist unter anderem das UDEV System verantwortlich. Dabei wird in der Datei /etc/udev/rules.d/30-net_persistent_names.rules die die Zuordnung erstellt.
- Was unter normalen Umständen eine gute Idee ist, die MAC an einen Namen zu binden (eth0,eth1 ...), erweist sich hier als ein Problem. Diesem kann auf zweierlei Wegen begegnet werden.
- Wir verhindern, dass SuSEconfig diese Bindung erstellt, in dem wir den Wert von "yes" auf "no" ändern:
- /etc/sysconfig/network/config
|
|
FORCE_PERSISTENT_NAMES=no
|
- Der elegante Weg um dieses Problem zu umschiffen, besteht einfach in einer Ãnderung der Xen Konfiguration des Gastes. Wir teilen Xen einfach mit, dass diesem Gast immer die selbe MAC zugewiesen werden soll.
- Am einfachsten ist dies nach dem ersten Start des Gastes zu erledigen. Wir verwenden dazu das Kommando xm network-list <Gast> um die derzeitige MAC zu erhalten. Eine Beispielausgabe kann in folgendem aussehen:
|
|
dom0:# xm network-list 6
Idx BE MAC Addr. handle state evt-ch tx-/rx-ring-ref BE-path
0 0 00:16:3e:00:fc:36 0 4 8 522 /523 /local/domain/0/backend/vif/6/0
|
Hier wird also die MAC 00:16:3e:00:fc:36 verwendet. Diese werden wir nun in der Konfiguration des Gastes hinterlegen:
|
|
[...]
vif = [ 'ip=192.168.3.152,mac=00:16:3e:00:fc:36' ]
[...]
|
- In diesem Beispiel verwende ich ein Routing Setup, weshalb noch die IP Adresse mit eingefügt wird. Bei einem normalen Bridge Setup, kann die IP Adresse entfallen.
- Nach einem erneuten Start des Gastes bleibt die MAC erhalten und die Netzwerkkonfiguration kann wie gehabt erfolgen.
|
|
Beim ersten Start von Yast und einer Konsole erscheint das Terminal ziemlich defekt und unleserlich. Da hilft es Yast zu beenden und ein reset im Terminal einzugeben
|
Debian Etch Wirt - Centos-5 Gast
- Eine Centos-5 Installation in einer domU funktioniert fast genauso wie die Fedora 6 Installation.
- Voraussetzung ist ein funktionierendes yum.
- Der große Unterschied ist das zu verwendende yum-Repository.
Repository in Yum eintragen
- Da wir in der Lage sein möchten, verschiedene Distributionen über yum zu installieren, benutzen wir ein eigenes Cache-Verzeichnis und eine eigene Logdatei.
- Folgende Konfiguration ist für Centos-5 passend:
- /etc/yum.repos.d/centos5.conf:
|
|
[main]
cachedir=/var/cache/yum/centos-5
debuglevel=2
logfile=/var/log/yum-centos-5.log
exclude=*-debuginfo
gpgcheck=0
obsoletes=1
reposdir=/dev/null
[base]
name=CentOS-5 - Base
mirrorlist=http://mirrorlist.centos.org/?release=5&arch=i386&repo=os
enabled=1
#baseurl=http://mirror.centos.org/centos/5/os/i386/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
protect=1
#released updates RPM-GPG-KEY-CentOS-5
[update]
name=CentOS-5 - Updates
mirrorlist=http://mirrorlist.centos.org/?release=5&arch=i386&repo=updates
#baseurl=http://mirror.centos.org/centos/5/updates/i386/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
protect=1
|
- Das Cache-Verzeichnis muss noch angelegt werden:
|
|
dom0:# mkdir /var/cache/yum/centos-5
|
Installation Centos-5
- Das Ziel-Filesystem muss unter /mnt gemountet sein, dann kann die Installation angestoßen werden:
|
|
# yum -c /etc/yum.repos.d/centos5.conf --installroot=/mnt -y groupinstall Core
# yum -c /etc/yum.repos.d/centos5.conf --installroot=/mnt -y install tzdata
|
Anpassungen am Gastsystem
- Danach müssen einige Anpassungen an dem resultierenden System vorgenommen werden:
- /mnt/etc/ld.so.conf.d/libc6-xen.conf:
|
|
dom0:# cp -a /lib/modules/`uname -r`/ /mnt/lib/modules/
|
- Konfiguration des Netzwerks
- /mnt/etc/sysconfig/network:
|
|
NETWORKING=yes
HOSTNAME=centos-5
|
- /mnt/etc/sysconfig/network-scripts/ifcfg-eth0:
|
|
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.1.11
NETMASK=255.255.255.0
NETWORK=192.168.1.0
GATEWAY=192.168.1.1
ONBOOT=yes
|
- Filesysteme passend konfigurieren
- /mnt/etc/fstab:
|
|
/dev/sda1 / ext3 defaults 0 1
/dev/sda2 swap swap defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
|
|
|
dom0:# cp /etc/resolv.conf /mnt/tmp/etc/
|
- Passende Zeitzone einstellen (hier Europe/Berlin):
|
|
dom0:# ln -sf /mnt/usr/share/zoneinfo/Europe/Berlin /mnt/etc/localtime
|
- Als nächstes werden noch Anpassungen in der Chroot-Umgebung durchgeführt.
|
|
dom0:# chroot /mnt
centos-5:# pwconv
centos-5:# passwd
centos-5:# for i in console null zero ; do MAKEDEV -d /dev/ -x $i ; done
|
- Damit Kudzu unsere Netzwerkkarte nicht wegkonfiguriert führt man in der chroot-Umgebung zusätzlich noch folgendes aus:
|
|
centos-5:# chkconfig kudzu off
|
XEN Konfigurationsdatei
- Als letztes muss noch eine passende Konfigurationsdatei für XEN erstellt werden. Die Disk-Konfiguration ist dabei an eure Umgebung anzupassen:
|
|
kernel = '/boot/vmlinuz-2.6.18-xen'
ramdisk = '/boot/initrd.img-2.6.18-xen'
memory = '128'
root = '/dev/sda1 ro'
disk = [ 'phy:daten/centos_root,sda1,w', 'phy:daten/centos_swap,sda2,w' ]
name = 'centos-5'
vif = [ 'ip=192.168.1.11' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
|
- Das war es. Jetzt kann die virtuelle Maschine benutzt werden.
Xen 3.0.4 Binär Installation unter Debian Etch - HVM Windows XP
- Sofern eine HVM kompatible Prozessoreinheit im Rechner steckt und das Mainboard und BIOS die Funktion freischalten, ist es auch möglich ein Betriebssystem zu installieren, welches nicht angepasst werden muss. Der Autor dieser Anleitung verfügt über einen AMD Athlon(tm) X2 Dual Core BE-2300 Prozessor und einem Asus M2NPV-VM Mainboard, welche die Möglichkeiten erst schafft.
Unter einem Intel Prozessor muß unter den Unterstützten Flags ein VMX und unter AMD ein SVM aufgelistet werden.
Hardware prüfen
- Wir können dies einfach mit folgendem Befehl überprüfen:
- Virtualisierung überprüfen:
|
|
xm dmesg | egrep '(SVM|VMX)'
(XEN) AMD SVM Extension is enabled for cpu 0.
(XEN) AMD SVM Extension is enabled for cpu 1.
|
- Ist dies der Fall, können wir nun ein Windows XP SP2 installieren. Doch zuvor ein Hinweis: Unter dem Debian Etch 3.0.3 Xen war es mir nicht möglich eine Installation einzuleiten, daher habe ich sämtliche Xen Pakete von Etch entfernt und das Binär Paket 3.0.4 installiert.
- Da nur die CPU Komponenten nicht emuliert werden müssen, benötigt es für einen vollständigen Rechner auch eine Grafikkarte, Netzwerkkarte und was es sonst noch so benötigt. Genau diese Komponenten werden mit Hilfe von Produkten aus dem Qemu Projekt emuliert. Da liegt auch das Problem. Ein solcher HVM Gast ist damit langsamer, als eine paravirtualisierte Installation. Des weiteren ist es auch nicht möglich PCI Geräte an den Gast durchzureichen, oder den Arbeitsspeicher zu vergrößern, respektive zu verkleinern.
HVM Konfiguration
- Wurde aus den Quellen installiert, sollten alle Pakete am richtigen Ort liegen, wer es dennoch mit den Etch Pakete versuchen möchte, benötigt dafür das Paket xen-ioemu-3.0.3-1.
- Sind alle Vorarbeiten erledigt, kann eine HVM Konfiguration angelegt werden:
|
|
# Pfad zum HVM Helfer
kernel = "/usr/lib/xen/boot/hvmloader"
# Die Art
builder = 'hvm'
memory = 512
name = 'xp'
# Von diesem Laufwerk wird zuerst gestartet
# Floppy, CD-Rom, Festplatte
# boot = adc
boot = "d"
# Bei einem Reboot soll der Gast wieder hochgefahren werden
on_reboot = 'restart'
# Die Netzwerkkarte wird emuliert
vif = [ 'type=ioemu' ]
# Die CD-Rom liegt als ISO vor. Wichtig, der phy Pfad muss Komplett sein, incl. /dev
disk = [ 'phy:/dev/daten/xp,hda,w','file:/mnt/WinXP.iso,hdc:cdrom,r' ]
shadow_memory = 8
# Pfad zur qemu-dm Datei
device_model = '/usr/lib/xen/bin/qemu-dm'
# Kein grafisches Fenster anzeigen lassen. Die SDL Bibliothek wird benoetigt
sdl = 0
# Der Eingebaute VNC Server wird aktiviert
vnc = 1
# ... und hört auf jede IP Adresse. Der Wirt muss natuerlich per IP ansprechbar sein
vnclisten = "0.0.0.0"
# USB wird aktiviert
usb = 1
# Und als Maus wird ein Tablet genommen, um Problemen mit dem Mauszeiger zu vermeiden
usbdevice = 'tablet'
stdvga = 0
serial = 'pty'
# Keine Soundkarte
audio = 0
# Ansonsten
soundhw='es1370'
|
- Danach kann der Gast normal gestartet werden und auf dem Client Rechner sollte sofort eine VNC Verbindung aufgebaut werden können. Dort zeigt sich dann der entsprechende Bildschirm und eine Installation kann durchgeführt werden.
- Aus noch unerfindlichen Gründen benötigte der Autor mehr als einen Anlauf, um eine Installation abzuschließen. Beim letzten Part "Komponenten werden registriert..." bleibt der Balken stehen. Zumeist hilft ein Neustart und viel Geduld (teils bis zu 3 Stunden). Möglicherweise betrifft dies nur Xen 3.0.4 und ist mit Xen 3.1 beseitigt worden.
Generelles zum Windows HVM
- Bei einem sollte man sich immer bewußt sein: Ein Windows in einem Xen erreicht derzeit noch nicht die Geschwindigkeit, das das System nativ hätte. Vor allem die Treiber sind nicht dafür optimiert. Für diesen Umstand gibt es jedoch von Novell/XenSource ein Treiberpaket, ähnlich wie die VMware Tools, welches für einen Betrag X im Jahr abonniert werden kann. Diese Treiber sollen eine nahezu native Ausführung erlauben und sind für Windows wie Linux geeignet.
- Es gibt analog dazu auch Treiber die unter der GPL Version von den Entwicklern von XEN entwickelt werden. XEN Treiber Diese Treiber bringen, nach meinem Gefühl und Performence Tests, mehr Leistung aus dem Host System. Der Nachteil ist allerdings das die Installation etwas aufwendiger ist. Man muss die Treiber installieren und den Windows Bootmanger erweitern. Die Installation ist aber sehr gut Dokumentiert auf der Wiki Seite von Xen-Soruce. Optimiert und getestet werden diese Treiber für Xen 3.1.X oder höher. Es wird auch empfohlen diese Versionen von Xen zu verwenden.
- Des weiteren bieten diese Treiber die Möglichkeit eine Art natives Netzwerkinterface zu betreiben. Dazu muss die Gast Konfiguration erweitert werden.
- Bevor nun Produktiv Systeme auf ein Windows Xen umgestellt werden, gilt es diese vorher ausführlich zu testen und Performance Messungen vorzunehmen, um nicht unliebsamen Überraschungen zu begegnen.
Zurück zur Seite 2 Zurück zum Start Weiter zur Seite 4
