Um einen fli4l als Xen DomU zu betreiben, war bisher der Boot Type "integrated" notwendig und die Dateien "kernel" und "rootfs.img" mussten immer von Hand auf die Dom0 kopiert und dort gestartet werden.
Ab sofort ist es aber nun möglich den fli ganz normal zu betreiben und Aktualisierungen per Remote Update durchzuführen. Dafür bedarf es allerdings ein paar kleiner Modifikationen die hier nachfolgend beschrieben werden.
Anlegen der notwenigen Partitionen auf der Dom0
Wir brauchen 2 LVM Volumes für unsere fli4l-DomU. Eins für /boot und eins für /data.
lvcreate -L 256M -n fli4l-boot xenvg lvcreate -L 1G -n fli4l-data xenvg
(Natürlich geht das auch mit Disk-Images, darauf werde ich hier aber nicht weiter eingehen. Wer dies nutzen möchte findet genügend Hinweise mit der Suchmaschine seiner Wahl.)
Die so erstellten Partitionen müssen nun beide mit ext3 formatiert werden
mkfs.ext3 /dev/xenvg/fli4l-boot mkfs.ext3 /dev/xenvg/fli4l-data
Erstellen einer fli4l Konfiguration
Nun erstellen wir uns eine ganz normale fli4l Konfiguration. Die Parameter können so wie bei einer regulären Installation auf normaler Hardware gesetzt werden.
Zum Einsatz kommen kann die Tarballversion von fli4l ab 3.9.0-rev27900. Als Kernel sollte einer der Kernel für den Betrieb virtueller Maschinen verwendet werden. Also entweder 3.2.x-virt oder 3.9.x-virt.
Wichtig sind folgende Parameter:
BOOT_TYPE='hd' MOUNT_BOOT='rw' NET_DRV_N='0'
(Auf die eigentliche Netzwerkkonfiguration werde ich hier auch nicht weiter eingehen, hierfür gibt es genügend Beispiele in der umfangreichen fli4l Dokumentation.)
OPT_HDDRV='no' OPT_MOUNT='yes' OPT_RECOVER='yes'
Im Anschluss mkfli4l starten und gucken ob alles sauber durchläuft.
Dateien auf die Boot Partition übertragen
Nun mounten wir auf der Dom0 die Boot Partition und kopieren die in Schritt 3 erzeugten Dateien dort hin. Gebraucht werden die Dateien "kernel", "rootfs.img", "opt.img" und "rc.cfg".
Erstellen weiterer benötigter Dateien
Als Nächstes erstellen wir auf der Boot Partition noch die Datei "hd.cfg" mit folgendem Inhalt:
hd_boot='xvda1' hd_data='xvda2'
Zusätzlich brauchen wir einen speziellen symbolischen Link, da pygrub eigentlich eine Root Partition erwartet und wir ja für fli4l nur die Boot Partition haben:
ln -s . boot
Weiterhin benötigen wir eine menu.lst im Unterverzeichnis "grub":
mkdir grub
In diesem Verzeichnis erstellen wir nun die Datei "menu.lst" mit folgendem Inhalt:
default 0
timeout 5
title fli4l Standard
root (hd0,0)
kernel /boot/kernel root=/dev/xvda1 load_ramdisk=1 inittmpfs=mode=755 fli4l_mode=normal printk.time=0
initrd /boot/rootfs.img
quiet
title fli4l Recovery
root (hd0,0)
kernel /boot/kernel2 root=/dev/xvda1 load_ramdisk=1 inittmpfs=mode=755 fli4l_mode=recover printk.time=0
initrd /boot/rootfs2.img
quiet
Jetzt haben wir alle nötigen Dateien zusammen.
Erstellen der DomU Config
Damit unsere Dom0 die fli4l DomU starten kann, braucht es natürlich noch eine Xen Config in /etc/xen. Diese könnte "fli4l.cfg" heissen und sollte in etwa folgenden Inhalt haben:
#
# Kernel + memory size
#
bootloader = '/usr/lib/xen-default/bin/pygrub'
memory = '256'
#
# Disk device(s).
#
root = '/dev/xvda1 ro'
disk = [
'phy:/dev/xenvg/fli4l-boot,xvda1,w',
'phy:/dev/xenvg/fli4l-data,xvda2,w',
]
#
# Hostname
#
name = 'fli4l'
#
# Networking
#
vif = [ 'bridge=eth0,vifname=vif-fli4l,mac=00:16:2A:CF:BA:DD' ]
#
# Behaviour
#
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
Starten der fli4l DomU
Nachdem nun alles am richtigen Ort ist, können wir die Boot Partition unmounten und einen ersten Startversuch unternehmen.
xm create fli4l.cfg -c
Hier sollte nach kurzer Anzeige des Bootmenüs nun der reguläre fli4l Bootvorgang zu beobachten sein.
Erstes Remote Update durchführen
Wenn unsere DomU erfolgreich gestartet wurde, können wir die nächsten Updates per Remote-Update durchführen. Dafür ändern wir folgende Parameter in der config/mkfli4l.conf:
REMOTEUPDATE='yes' REMOTEHOSTNAME='fli4l.dein.lan'
Ein anschliessedner Aufruf von mkfli4l sollte dann die neuen Dateien übertragen.
Herzlichen Glückwunsch! Du hast es geschafft :-).
Anhang
Nutzung von OPT-Recover:
Wie man an der menu.lst gemerkt hat, haben wir gleich die Verwendung des OPT_RECOVER aus dem HD Paket vorgesehen. Es reicht also aus, nun im Webinterface eine Recovery Version anzulegen. Sollte die DomU einmal aufgrund eines Configfehlers o.ä. nicht mehr starten, kann man im Bootmenü die Recovery Version auswählen und es nochmal neu versuchen.