Quelltext betrachten

aus PUG, der Penguin User Group

Du bist nicht berechtigt, die Aktion auszuführen. Grund:
Diese Aktion ist beschränkt auf Benutzer, die der Gruppe „user“ angehören.
Quelltext dieser Seite:
== Aufteilung ==

: Aufgrund der Länge habe ich die Anleitung nun aufgeteilt. Am Ende der jeweiligen Seite findet einen Link zur nachfolgenden Seite.

<ul>
<li> [[Xen-Installation|Startseite]] </li>
<li> [[Xen-Installation-Seite-2|Seite 2]] </li>
<li> [[Xen-Installation-Seite-3|Seite 3]] </li>
<li> [[Xen-Installation-Seite-4|Seite 4]] </li>
<li> [[Xen-Installation-Seite-5|Seite 5]] </li>
</ul>

=== 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''':

:*'''etc/xen/xend-config.sxp'''
{{Code|
 (network-script network-bridge)
 (vif-script vif-bridge)
}}
:*Gast erstellen
:Hier erstellen wir nun unseren Gast mit dem Debian Xen Tool, wobei wir als Hostname ''vm01'' mitgeben:

{{Shell|
<pre>
 dom0:# xen-create-image --hostname=vm01
</pre>
}}

:Eine Ausgabe schaut dann so aus:

{{Shell|
<pre>
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
</pre>
}}

{{Hinweis2|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:

{{Shell|
<pre>
 dom0:# tail -f  /var/log/xen-tools/<domainname>.log
</pre>
}}

{{Hinweis2|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'''

{{Hinweis2|
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. }}


:*'''/etc/xen/vm01.cfg'''
{{Code|
<pre>
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'
</pre>
}}

{{Hinweis2|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:

{{Shell|
<pre>
 dom0:# brctl show
 bridge name     bridge id               STP enabled     interfaces
 xenbr0              8000.feffffffffff       no                     vif0.0
                                                                                peth0
</pre>
}}

:Dann starten wir unseren Gast

{{Shell|
<pre>
 dom0:# xm create vm01.cfg
</pre>
}}

:Wir können uns von dem Start mit '''xm''' überzeugen:

{{Shell|
<pre>
 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
</pre>
}}

:und die Bridge sieht nun folgendermaßen aus:

{{Shell|
<pre>
 dom0:# brctl show
 bridge name     bridge id               STP enabled     interfaces
 xenbr0              8000.feffffffffff       no                     vif0.0
                                                                                peth0
                                                                                vif5.0
</pre>
}}

:Wir können nun erkennen, dass die virtuelle Netzwerkkarte '''vif5.0''' hinzugekommen ist. Auch mit '''ip''' od. ifconfig können wir uns davon überzeugen:


{{Shell|
<pre>
 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
</pre>
}}

:*'''xm console'''

:Nachdem das geklappt hat, können wir uns mit dem Gast verbinden. Dazu verwenden wir erneut '''xm''' mit dem Parameter '''console vm01'''

{{Shell|
<pre>
 dom0:# xm console vm01
</pre>
}}

: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:

{{Shell|
<pre>
 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
</pre>
}}

:Die Adresse kann natürlich im selben Netz liegen, wie unser Wirt. Sollte '''ip''' nicht funktionieren, dann geht das auch über '''ifconfig'''

{{Shell|
<pre>
 vm01:# ifconfig eth0 192.168.1.100 up
 vm01:# route add default gw 192.168.1.254
</pre>
}}

: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:

:*'''/etc/network/interfaces'''

{{Code|
<pre>
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
</pre>
}}

: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:

{{Shell|
<pre>
STRG + Alt + ]
</pre>
}}

: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:

{{Shell|
<pre>
 dom0:# xm reboot vm01
 dom0:# xm shutdown vm01
</pre>
}}

==== 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
{{Code|
<pre>
 # dir = /home/xen
 lvm = daten
</pre>
}}

:Die restlichen Werte können wir belassen. Nun konfigurieren wir den '''Xend''' um, sodass er nun Routing für die Gäste benutzt:

:*'''/etc/xen/xend-config.sxp'''
{{Code|
<pre>
 # (network-script network-bridge)
 # (vif-script vif-bridge)
 (network-script network-route)
 (vif-script     vif-route)
</pre>
}}

:Danach nicht vergessen, den Xen Daemon neuzustarten:

{{Shell|
<pre>
 dom0:# /etc/init.d/xend restart
</pre>
}}

:Danach genügt wieder ein einfacher Aufruf der Xen Tools

{{Shell|
<pre>
 dom0:# xen-create-image --hostname=vm02
</pre>
}}

:Auch die Ausgabe ist mit der von '''vm01''' weitestgehend identisch:
<pre>
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
</pre>

: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'''
{{Code|
<pre>
 vif = <nowiki>[ '' ]</nowiki>
</pre>
}}

:Nun '''müssen''' wir dieses Mal eine IP Adresse eintragen, und zwar aus dem '''selben''' Netz, in welchem sich auch der Wirt (Dom0) befindet.

:*'''/etc/xen/vm01.cfg'''

{{Code|
<pre>
 vif = [ 'ip=192.168.1.100' ]
</pre>
}}

:*'''/etc/xen/vm02.cfg'''

{{Code|
<pre>
  vif = [ 'ip=192.168.1.101' ]
</pre>
}}
: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:

{{Hinweis2|Die Nummern der '''vif''' werden sukzessive herauf gezählt und fangen erst nach einem Reboot wieder bei '''vif1.0''' an.}}

{{Shell|
<pre>
 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 
</pre>
}}

:Wir können nun sehen, das '''vif6.0''' erzeugt, eine Route hinzugefügt und der Arp Proxy aktiviert wurde:
{{Shell|
<pre>

 dom0:# cat /proc/sys/net/ipv4/ip_forward 
 1
 dom0:# cat /proc/sys/net/ipv4/conf/vif6.0/proxy_arp
 1
</pre>
}}

: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:

{{Shell|
<pre>
 dom0:# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
</pre>
}}

:Siehe auch den Teil [[Xen-Installation#Routen|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'''
{{Code|
<pre>
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
</pre>
}}

: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:

:*'''/etc/network/interfaces'''
{{Code|
<pre>
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
</pre>
}}

:Die Netzwerkkonfiguration von '''vm01''' und '''vm02''' kann so aussehen:

:*'''/etc/network/interfaces
{{Code|
<pre>
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
</pre>
}}

: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 [[Xen-Installation#NAT|NAT]].

===== Möglichkeit 1 mit NAT =====


:Um dies zu konfigurieren, bedarf es nur einer Anpassung des Xend Daemons:

:*'''/etc/xen/xend-config.sxp'''
{{Code|
<pre>
 (network-script network-nat)
 (vif-script     vif-nat)
</pre>
}}

:Die Bridge und Routing Scripte sollten dementsprechend deaktiviert werden. Nun können wir den DomUs ein völlig anderes Netz geben:

:*'''/etc/xen/vm01.cfg'''

{{Code|
<pre>
 vif = [ 'ip=192.168.4.10,mac =00:16:3E:27:1F:A6' ]
</pre>
}}

:*'''vm01: /etc/network/interfaces'''
{{Code|
<pre>
 auto eth0
 iface eth0 inet static 
 address 192.168.4.10
 netmask 255.255.255.0
 gateway 192.168.4.137
</pre>
}}

: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:

{{Shell|
 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:

{{Shell|
<pre>
 dom0:# ip addr add 192.168.10.1/24 brd + dev xen-intern
 dom0:# ip link set up xen-intern
</pre>
}}

:Danach passen wir die Xend Daemon Konfigurationsdatei an:

:*'''/etc/xen/xend-config.sxp'''
{{Code|
<pre>
 (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)
</pre>
}}

:Nun passen wir den Gast an:

:*'''/etc/xen/vm01.cfg
{{Code|
<pre>
 vif = ['bridge=xen-intern,vifname=vm01.1,mac=00:16:3E:55:3D:AC']
</pre>
}}

{{Vorsicht| 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}}

{{Hinweis2|
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:

{{Shell|
<pre>
 dom0:# brctl show
 bridge name          bridge id               STP enabled     interfaces
 xen-intern              8000.feffffffffff       no                     vif8.0
                                                                                     vif9.0
</pre>
}}

: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:

{{Shell|
<pre>
 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
</pre>
}}

: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 [http://www.fwbuilder.org fwbuilder] erstellt. Dieses lässt sich [[Media:Xen-dom0-firewall.txt|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:

:*'''/etc/network/interfaces'''
{{Code|
<pre>
 # 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
</pre>
}}

==== 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:

:*'''/etc/xen/vm01.cfg'''
{{Code|
<pre>
 [...]
 vif = [ 'bridge=xenbr0' ]
</pre>
}}

:*'''/etc/xen/vm02.cfg'''
{{Code|
<pre>
 [...]
 vif = [ 'bridge=xenbr1' ]
</pre>
}}

: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'''
{{Code|
<pre>

 #!/bin/sh
 dir=$(dirname "$0")
 "$dir/network-bridge" "$@" vifnum=0 netdev=eth0 bridge=xenbr0
 "$dir/network-bridge" "$@" vifnum=1 netdev=eth1 bridge=xenbr1
</pre>
}}

:Nach einem ...:

{{Shell|
<pre>
 dom0:# chmod +x /etc/xen/scripts/2nics-network-script
</pre>
}}

: ... ist das Script nun ausführbar und kann von Xen genutzt werden, nachdem wir ihm dies mitgeteilt haben:

:*'''/etc/xen/xend-config.sxp'''
{{Code|
<pre>
 [...]
 (network-script 2nics-network-script)
 (vif-script vif-bridge)
 [...]
</pre>
}}

: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 [http://linux.duke.edu/projects/yum/index.ptml 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 =====

{{Shell|
<pre>
dom0:# apt-get install python-sqlite python-celementtree python-libxml2 python-urlgrabber rpm python-rpm
</pre>
}}

:Dann laden wir die passende Yum Version herunter und installieren sie:

{{Shell|
<pre>
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=/
</pre>
}}

{{Hinweis2|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'''

{{Code|
<pre>
[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
</pre>
}}

:Dann kann mit der Installation begonnen werden und wird von folgendem Befehl in die Wege geleitet:

{{Shell|
<pre>
dom0:#  yum -c /etc/yum.repos.d/fc6.conf --installroot=/mnt -y groupinstall Core
</pre>
}}

:Dann wird das Basissystem installiert und zusätzlich benötigen wir noch folgende:

{{Shell|
<pre>
dom0:#  yum -c /etc/yum.repos.d/fc6.conf --installroot=/mnt -y install yum dhclient openssh openssh-server
</pre>
}}

:Ist dies ohne Fehler durchgelaufen, können wir das System konfigurieren:

{{Shell|
<pre>
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/
</pre>
}}

:Dann benötigen wir eine entsprechende '''fstab''':

:*'''/mnt/etc/fstab'''

{{Code|
<pre>
/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
</pre>
}}

:Um Problemen mit der Bibliothek zu vermeiden, müssen wir die Konfigurationsdatei der '''libc6''' anpassen:

:*'''/mnt/etc/ld.so.conf.d/libc6-xen.conf'''
{{Code|
<pre>
hwcap 0 nosegneg
</pre>
}}

:Natürlich möchten wir auch Netzwerk, daher erstellen wir auch die Netzwerk Parameter:

:*'''/mnt/etc/sysconfig/network'''
{{Code|
<pre>
NETWORKING=yes
HOSTNAME=fedora6
</pre>
}}

:*'''/mnt/etc/sysconfig/network-scripts/ifcfg-eth0'''
{{Code|
<pre>
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
</pre>
}}

: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:

{{Shell|
<pre>
dom0:# chroot /mnt

fedora6:# pwconv
fedora6:# passwd
fedora6:# for i in console null zero ; do MAKEDEV -d /dev/ -x $i ; done
</pre>
}}

:Da ich ein Routen basiertes Setup gewählt habe, schaut die Xen DomU Konfiguration im folgenden aus:

{{Code|
<pre>
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'
</pre>
}}

: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:

{{Shell|
<pre>
fedora:# yum update
</pre>
}}

==== 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:

:* '''/etc/fstab'''
{{Code|
<pre>
/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
</pre>
}}

:*'''Module'''

: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:

{{Shell|
<pre>
dom0:# cp -r /lib/modules/`uname -r` /mnt/lib/modules
</pre>
}}

:Wobei /mnt für das gemountete SuSE Linux System steht.

:*''' Netzwerk'''

: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.

:** '''Lösung 1'''

:Wir verhindern, dass SuSEconfig diese Bindung erstellt, in dem wir den Wert von "yes" auf "no" ändern:

:* /etc/sysconfig/network/config
{{Code|
<pre>
FORCE_PERSISTENT_NAMES=no
</pre>
}}

:** '''Lösung 2'''

: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:

{{Shell|
<pre>
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
</pre>
}}

Hier wird also die MAC '''00:16:3e:00:fc:36''' verwendet. Diese werden wir nun in der Konfiguration des Gastes hinterlegen:

:* /etc/xen/sles10.cfg
{{Code|
<pre>
[...]
vif  = [ 'ip=192.168.3.152,mac=00:16:3e:00:fc:36' ]
[...]
</pre>
}}

: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.

{{Hinweis2|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:
{{Code|
<pre>
[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 
</pre>
}}

:Das Cache-Verzeichnis muss noch angelegt werden:
{{Shell|
<pre>
dom0:# mkdir /var/cache/yum/centos-5
</pre>
}}

===== Installation Centos-5 =====
:Das Ziel-Filesystem muss unter /mnt gemountet sein, dann kann die Installation angestoßen werden:
{{Shell|
<pre>
# 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
</pre>
}}

===== Anpassungen am Gastsystem =====
:Danach müssen einige Anpassungen an dem resultierenden System vorgenommen werden:
* Libc6

:*/mnt/etc/ld.so.conf.d/libc6-xen.conf:
{{Code|
<pre>
hwcap 0 nosegneg
</pre>
}}

:* Kernel-Module kopieren
{{Shell|
<pre>
dom0:# cp -a /lib/modules/`uname -r`/ /mnt/lib/modules/
</pre>
}}

:* Konfiguration des Netzwerks

:*/mnt/etc/sysconfig/network:
{{Code|
<pre>
NETWORKING=yes
HOSTNAME=centos-5
</pre>
}}

:*/mnt/etc/sysconfig/network-scripts/ifcfg-eth0:
{{Code|
<pre>
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
</pre>
}}

:* Filesysteme passend konfigurieren
:* /mnt/etc/fstab:
{{Code|
<pre>
/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
</pre>
}}

{{Shell|
<pre>
dom0:# cp /etc/resolv.conf /mnt/tmp/etc/
</pre>
}}

:Passende Zeitzone einstellen (hier Europe/Berlin):
{{Shell|
<pre>
dom0:# ln -sf /mnt/usr/share/zoneinfo/Europe/Berlin /mnt/etc/localtime
</pre>
}}

:Als nächstes werden noch Anpassungen in der Chroot-Umgebung durchgeführt.
{{Shell|
<pre>
dom0:# chroot /mnt

centos-5:# pwconv
centos-5:# passwd
centos-5:# for i in console null zero ; do MAKEDEV -d /dev/ -x $i ; done
</pre>
}}

:Damit Kudzu unsere Netzwerkkarte nicht wegkonfiguriert führt man in der chroot-Umgebung zusätzlich noch folgendes aus:

{{Shell|
<pre>
centos-5:# chkconfig kudzu off
</pre>
}}

===== XEN Konfigurationsdatei =====
:Als letztes muss noch eine passende Konfigurationsdatei für XEN erstellt werden. Die Disk-Konfiguration ist dabei an eure Umgebung anzupassen:

:*/etc/xen/centos-5.cfg:
{{Code|
<pre>
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'
</pre>
}}

: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:'''
{{Shell|
<pre>
xm dmesg | egrep '(SVM|VMX)'
(XEN) AMD SVM Extension is enabled for cpu 0.
(XEN) AMD SVM Extension is enabled for cpu 1.
</pre>
}}

: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 [http://xensource.com/download/index_3.0.4.html 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 [http://fabrice.bellard.free.fr/qemu/ 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:

:*'''/etc/xen/winxp-hvm.cfg:'''
{{Code|
<pre>
# 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'
</pre>
}}

: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 [http://www.novell.com/de-de/products/vmdriverpack/ Treiberpaket], ähnlich wie die VMware Tools, welches für einen [http://www.novell.com/de-de/products/vmdriverpack/pricing.html 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. [http://wiki.xensource.com/xenwiki/XenWindowsGplPv 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.
:*'''/etc/xen/winxp-hvm.cfg:'''
{{Code|
<pre>
vif = ['']
</pre>
}}

: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.

----

[[Xen-Installation|Zurück zur Seite 2]]                 [[Xen-Installation|Zurück zum Start]]                              [[Xen-Installation-Seite-4|Weiter zur Seite 4]]
Folgende Vorlagen werden von dieser Seite verwendet:
Zurück zur Seite Xen-Installation-Seite-3.
Von „http://www.pug.org/mediawiki/index.php/Xen-Installation-Seite-3“
Quelltext betrachten

aus PUG, der Penguin User Group

Ansichten

Persönliche Werkzeuge

Penguin User Group

Navigation

Suche

Werkzeuge
