XEN 4

From Gcom-Wiki
Jump to: navigation, search


DomU-Vorlage aktualisieren

Das Vorgehen ist relativ einfach, das Device, das die Templates enthält, wird gemountet, das gewählte Image wird einem Loop-Device zugewiesen. Dieses wird gemountet. Es wird in die Installation chrootet. Diese wird dann aktualisiert. Nach Abschluss aller Arbeiten wird die chroot-Umgebung verlassen, die Platten werden synchronisiert, das Loop-Device und das Laufwerk mit den Vorlagen werden ausgehängt.

# Image mounten als Loop-Device mounten
mount /dev/vg0/xen_tpl /mnt
losetup /dev/loop0 /mnt/01-sid_xentpl.img 
mount /dev/loop0 /source
# chrooten
mount --bind /proc /source/proc
mount --bind /sys /source/sys
mount --bind /dev /source/dev
chroot /source /bin/bash
# aktualisieren
apt-get update
apt-get upgrade
apt-get clean
# chroot verlassen und alles aushängen
exit
sync
umount /source/sys
umount /source/proc
umount /source/dev
umount /source
losetup -d /dev/loop0
umount /mnt

Beim Prozess der Aktualisierung auftretende Fehler, dass nicht auf /dev/pts geschrieben werden kann, können beruhigt ignoriert werden. andere Fehler nicht.

DomU-Laufwerk aus Vorlage erstellen

Prinzipiell kann eine DomU auf einem Image laufen. Dann ist die Erstellung einer DomU einfach, kopieren des Images, setzen der Rechte und des Eigentümers. Das wars.

Will man seine DomU auf einem physikalischen Laufwerk haben, bietet sich die Anlage des Laufwerks auf einer LVM-Partition an. Prinzipiell kann man aber auch jede andere Partition verwenden.

mount /dev/vg0/xen_tpl /mnt 
losetup /dev/loop0 /mnt/02-squeeze_xen_tpl.img
mount -o noatime,nodiratime,data=writeback,commit=1000 /dev/loop0 /source
mount -o noatime,data=writeback,commit=1000 /dev/vg0/websvr_root /target
cp -ax /source/* /target
# damit ist das Kopieren des Images erledigt, es kann abgeräumt werden
sync
umount /source
umount /target
losetup -d /dev/loop0
umount /mnt

Das komplette Abräumen ist zu empfehlen, die Mount-Optionen sind nicht wirklich dazu da, um dauerhaft mit ihnen zu arbeiten. Für den Vorgang des Kopierens sind sie toll, sie beschleunigen den Vorgang wirklich.

DomU anpassen

Das Laufwerk der neuen DomU ist erstellt, jetzt muss die DomU auf ihren ersten Einsatz vorbereitet werden. Am besten arbeitet man bei der Vorbereitung in einer chroot-Umgebung.

mount /dev/vg0/websvr_root /mnt
mount --bind /dev  /mnt/dev
mount --bind /sys  /mnt/sys
mount --bind /proc /mnt/proc
chroot /mnt /bin/bash

Die Einstellungen der fstab wurden schon während der Anlage der Vorlage erledigt, dank virtuellen Devices ändert sich daran erst einmal nichts. Anzupassen sind aber in jedem Fall die Netzwerkeinstellungen, hosts und hostname.

nano /etc/hostname
websrv.g-com.eu #abspeichern

nano /etc/hosts
192.168.150.41  websvr.g-com.eu websvr #abspeichern 

nano /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
  address 192.168.150.41 
  netmask 255.255.255.0
  gateway 192.168.150.15

nano /etc/resolv.conf
nameserver 192.168.150.30 #asterix (change to your nameserver)
nameserver 8.8.8.8 #google ns
nameserver 8.8.8.4 #google fallback
search g-com.eu

(FixMe) Das sollte so funktionieren, das mit der Namensauflösung kommt zu gebebener Zeit noch mal dran, momentan habe ich das so gelöst, dass auf der Dom0 ein dnsmasq läuft, einiges spricht für diese Lösung.

Die Google-Nameserver sind sauschnell, deshalb diese Wahl. hier können je nach Gusto auch eigene Einstellungen verwendet werden.

Das waren die Vorbereitung der DomU auf Plattenseite. Die chroot-Umgebung kann verlassen werden, die Mounts werden abgeräumt:

exit 
sync
umount /mnt/dev
umount /mnt/sys
umount /mnt/proc
umount /mnt

Im nächsten Schritt geht es an die XEN-Konfiguration der neuen DomU. Dazu wird ein Konfigurationsfile erstellt, was mindestens die folgenden Einträge haben sollte.

nano /etc/xen/websvr.conf
kernel='/boot/vmlinuz-2.6.32-5-amd64'
ramdisk='/boot/initrd.img-2.6.32-5-amd64'
vcpus  = '4'
maxmem = 1024
memory = 768
extra = '2 earlyprintk=xen console=hvc0 root=/dev/xvda1 ro nf_conntrack.act=1'
disk=['phy:/dev/vg0/websvr_root,xvda1,w', 'phy:/dev/vg0/websvr_swap,xvda2,w']
name='websvr'
vif=['']
on_poweroff='destroy'
on_reboot='restart'
on_crash='reset'

Wie wir feststellen können, fehlt uns noch eine Partition für Swap. Diese wird wie folgt angelegt.

lvcreate -L 1G --name websvr_swap vg0

Nach der Anlage der Konfigurationsdatei machen wir uns das Leben ein wenig einfacher: Damit die DomU automatisch gestartet wird, packen wir einen symbolischen Link in das auto-Verzeichnis, damit die DomU unter dem selben Namen auch manuell gestartet werden kann, noch einen symblischen Link auf die Konfigurationsdatei.

ln -s /etc/xen/websvr.conf /etc/xen/auto/websvr
ln -s /etc/xen/websvr.conf /etc/xen/websvr

Wenn alles erledigt ist starten wir die DomU ein erstes Mal mit

xm create websvr -c

Viel Spass mit der neuen DomU. Eine Anmerkung noch an dieser Stelle: Die Xen-Vorlage sollte so angelegt werden, dass ein ssh-Zugriff mit root-Rechten erst einmal nicht erlaubt ist. Benötigt man diesen wirklich, dann der Zugang freigeschaltet werden <syntaxhiglight lang="bash"> nano /etc/ssh/sshd_config

  1. Authentication:

LoginGraceTime 120 PermitRootLogin no # ==> 'yes' StrictModes yes </source> <syntaxhiglight lang="bash"> /etc/init.d/ssh restart </source>

Generell sollte man sich überlegen, ob root-Zugang über ssh sinnvoll ist, da dieser, falls er kompromittiert wird, einem Supergau gleichkommt. Besser ist es, den root-Zugang nicht zu ermöglichen, sich über einen normalen Benutzer mit sudo-Rechten anzumelden und bei Bedarf entweder sudo oder auch su zu verwenden.

Ubuntu 10.04 als DomU (Xen) “debootstrappen” http://www.google.de/url?sa=t&source=web&cd=1&ved=0CBkQFjAA&url=http%3A%2F%2Fblog.rootserverexperiment.de%2F2010%2F09%2F01%2Fubuntu-lucid-xen4-domu-debootstrappen%2F&ei=7-J-TKnoEM-YONLo9LsJ&usg=AFQjCNEb2xlFxlINJN85CeKVhaL-leuJyQ&sig2=mDr2ta_MV-RBR40d6EbT3Q

DomU auf Partition installieren http://blog.elsobrino.org/2008/02/05/installing-domu-on-single-partition/