• Xen Wikipedia article
• Xen Official Home Page
• Users' Manual Xen v3.0
• Xen Networking
• Debian Sid gets Xen 3.0
• The Perfect Xen Setup For Debian And Ubuntu

La macchina non si avvia più dal kernel Linux originale, ma dal supervisore Xen (/boot/xen-3.0.1.gz). Il supervisore poi avvia - grazie all'opzione module di Grub - un kernel Linux speciale, chiamato dom0 (/boot/vmlinuz-2.6.12-xen0). E' questo kernel che gestisce l'hardware e fa girare il demone di controllo xend e l'utility xm. Tramite xm si creano le macchine virtuali, queste utilizzano un altro kernel Linux speciale, chiamato domU (/boot/vmlinuz-2.6.12-xenU) e faranno accesso a dispositivi hardware (dischi, schede di rete, …) virtuali.

Questi pacchetti Debian sono necessari alla compilazione e all'esecusione di Xen:

• zlib1g-dev
• python-dev
• iproute
• bridge-utils
• hotplug (vedi note troubleshooting)

Nei nostri esempi è stata creata la directory /home/xen/img/test/. In questa vengono creati i file che contegono le partizioni della macchina virtuale test.

La macchina fisica userà un kernel Xen specifico chiamato dom0, mentre le macchine virtuali useranno un altro kernel chiamato domU. Inoltre ci sono delle utility necessarie a gestire le macchine virtuali.

Xen fornisce tre configurazioni predefinite di kernel, chiamate xen, xen0 e xenU, le caratteristiche sono:

Nella nuova versione 3.0.2 il make world crea solo la versione xen del kernel.

Con questa procedura si compila e si installa tutto Xen, in particolare otteniamo i due kernel xen0 e xenU, il demone xend e le utility di supporto (xm, …).

cd /usr/local/src/
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2
wget http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-3.0.1-src.tgz
tar xjf linux-2.6.12.tar.bz2
tar xzf xen-3.0.1-src.tgz
chown -R root.root xen-3.0.1
cd xen-3.0.1
make world

Il target make world in realtà:

• Compila il demone xend e le utility (xm, …)
• Scarica (se necessario) e scompatta i sorgenti del kernel Linux 2.6, e applica le patch per utilizzarlo con Xen.
• Compila due kernel Linux, uno da usare nel Domain-0 e uno ridotto che può essere usato per le macchine virtuali.

Al termine della compilazione si trovano le directory linux-2.6.12-xen0/ e linux-2.6.12-xenU/ con dentro i sorgenti del kernel e i relativi .config. I file da installare sono invece nella dist/. La configurazione predefinita del kernel xen0 ha il supporto CONFIG_MD_RAID1 e CONFIG_EXT3_FS modulare, cosa che non mi piace molto (obbliga all'uso dell'initrd), il kernel xenU non ha netfilter, … vedi avanti come personalizzare i kernel.

Per compilare uno solo dei kernel (-xen, -xen0 o -xenU), invece del make world si esegue:

make KERNELS=linux-2.6-xenU kernels

la configurazione sarà quella predefinita, vedere avanti come fare per personalizzarla e ricompilare.

• Xen 3.0.1 si aspetta un file linux-2.6.12.tar.bz2 (senza il minor number, es. 2.6.12.1). Altrimenti durante il make world scarica nuovamente con wget i sorgenti e li mette nella sua directory.
• Il make world predefinito della versione 3.0.1 senza opzione KERNELS genera due kernel ridotti: vmlinuz-2.6.12-xen0 (con pochi e selezionati moduli) e vmlinuz-2.6.12-xenU (senza alcun driver per periferiche fisiche, quindi adatto per domini guest).
• Il make world predefinito della versione 3.0.2 crea un solo kernel linux-2.6.16-xen, adatto sia per dom0 e domU.

Eventualmente il target make install provvede a installare tutto, per un controllo maggiore di cosa installare…

Per installare il supervisore xen-3.0.1.gz, il kernel vmlinuz-2.6.12.6-xen0 e i moduli /lib/modules/ relativi:

cd /usr/local/src/xen-3.0.1/
make install-xen
make linux-2.6-xen0-install

Il boot loader deve essere configurato a mano, il comando update-grub di Debian non funziona in questo caso! La macchina deve partire dall'immagine di boot /boot/xen.gz che a sua volta usa come modulo il file /boot/vmlinuz-2.6-xen, quindi in /boot/grub/menu.lst si mette:

title           Xen 3.0.1 / XenLinux 2.6.12
root            (hd0,0)
kernel          /boot/xen.gz console=vga
module          /boot/vmlinuz-2.6-xen root=/dev/md0 ro
savedefault
boot

Eventuali altre opzioni per il kernel Linux (es. raid=noautodetect, ecc.) vanno sulla riga module.

Per evitare che l'esecuzione di update-grub corrompa il file /boot/grub/menu.lst (aggiungendo una voce per ogni kernel Xen) conviene configurare la sezione di cui sopra come istanza statica e impostare # howmany=0 (nota: il cancelletto iniziale deve rimanere).

Oltre al kernel bisogna installare anche le utility tipo /usr/sbin/xend, /usr/sbin/xm, ecc. Non si sa come, ma noi ce le siamo trovate già installate, forse il make linux-2.6-xen0-install ha provveduto. Eventualmente questi i target papabili del make:

make install-tools    - build and install the control tools
make install-xen      - build and install the Xen hypervisor
make install-kernels  - build and install guest kernels
make install-docs     - build and install user documentation

cd /usr/local/src/xen-3.0.1
make linux-2.6-xenU-install

Questo target installa il kernel in /boot/vmlinuz-2.6.12-xenU e i moduli in /lib/modules/2.6.12.6-xenU/. Mentre il kernel è sufficiente lasciarlo in /boot/, i moduli vanno copiati nel filesystem /lib/modules/ delle macchine virtuali.

Avendo installato dai sorgenti, bisogna provvedere a mano ad aggiungere i link opportuni per lo start/stop dei servizi:

update-rc.d xend defaults
update-rc.d xendomains defaults 40 10

Per cambiare la configurazione del kernel:

cd /usr/local/src/xen-3.0.1
make linux-2.6-xen0-config CONFIGMODE=menuconfig
make linux-2.6-xen0-build
make linux-2.6-xen0-install

In alternativa al menuconfig si può fare un oldconfig, utile per aggiornare un .config di una vecchia versione kernel. Il vecchio .config deve essere preventivamente copiato nella directory linux-2.6.12-xen0.

Questo è il kernel per le macchine virutali (emulate), viene generato con il target make world di cui sopra. Tuttavia la configurazione predefinita di questo kernel non ha il supporto netfilter, per riconfigurare e ricompilare solo questo kernel:

cd /usr/local/src/xen-3.0.1
make linux-2.6-xenU-config CONFIGMODE=menuconfig
make linux-2.6-xenU-build
make linux-2.6-xenU-install

L'installazione provvede a copiare il kernel in /boot/ e i moduli in /lib/modules/2.6.12.6-xenU/, però i moduli devono essere copiati a mano nei dischi (virtuali) delle macchine virtuali.

NOTA: con le ultime release di Debian Etch non si riesce ad usare facilmente debootstrap, conviene fare un'installazione su una macchina reale oppure usare Qemu.

Si fa un'installazione su un file immagine con la procedura debootstrap, impostare /etc/fstab tenendo conto che i dischi virtuali saranno presentati da Xen alla macchina virtuale come /dev/hda1, /dev/hda2, …

Si monta provvisoriamente l'immagine disco della macchina virtuale, ci si mette il kernel domU con i suoi moduli e si disabilita tls (?):

mount -o loop /home/xen/img/test/root.img /mnt
cp -dpR /usr/local/src/xen-3.0.1/dist/install/lib/modules/2.6.12.6-xenU /mnt/lib/modules
mv /mnt/lib/tls /mnt/lib/tls.disabled
umount /mnt

In realtà non è strettamente necessario copiare l'immagine del kernel nel filesystem della macchina virtuale. Xen infatti avvia il dominio virtuale attivando il kernel che trova nella /boot/ del sistema ospite.

Poi bisogna creare un file di configurazione per ogni macchina virtuale: /etc/xen/name-config.sxp, se si vuole che tale host virtuale sia avviato automaticamente dal demone Xen si crea un link al file di configurazione in /etc/xen/auto/.

kernel = "/boot/vmlinuz-2.6.12.6-xenU"
memory = 128
name = "test"
vif = [ '' ]
disk = [ \
    'file:/home/xen/img/test/root.img,hda1,w', \
    'file:/home/xen/img/test/var.img,hda2,w',  \
    'file:/home/xen/img/test/home.img,hda3,w', \
    'file:/home/xen/img/test/swap.img,hda4,w'  \
]
root = "/dev/hda1 ro"

Per avviare il demone supervisore: /etc/init.d/xend start, per avviare tutti gli host virtuali: /etc/init.d/xendomains start.

Per usare un'immagine ISO come se fosse un CD-ROM ed avviare da questo:

boot="d"
disk=[ ‘file:/usr/local/src/systemrescue-x86.iso,hdc:cdrom,r’ , ]

La lettera passata al parametro boot segue la logica delle lettere assegnate dal sitema operativo Windows.

Il programma xm è lo strumento principale per amministrare Xen da console, dialoga con xend. Ecco alcuni esempi:

xm create -c /etc/xen/<name>.sxp
xm shutdown <name>
xm list
xm console <name>
xm help

Con l'opzione -c veniamo collegati immediatamente alla console della macchina virtuale creata, per scollegarsi e tornare alla console della macchina ospite si usa Ctrl+]. Attenzione che esiste una solo console, se ci si collega due volte si accede in realtà alla stessa istanza di console.

Chiediamo l'elenco delle macchine virtuali in esecuzione:

# xm list
Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                           0      300     2 r-----   262.6
test                              21      128     1 -b----     9.5

Avviando una macchina virtuale si ottiene il seguente errore:

VmError: Device 769 (vbd) could not be connected. Hotplug scripts not working.

L'errore avviene nel momento in cui vengono creati i dischi virtuali, nel caso nostro il problema era dovuto alla mancanza del pacchetto hotplug. Dentro lo pseudo file /proc/sys/kernel/hotplug si legge quale script viene utilizzato dal kernel per gestire l'hotplug, nel nostro caso era /sbin/hotplug che però non esisteva. Xen potrebbe utilizzare udev al posto di hotplug.

Ecco alcune indicazioni su come debuggare gli eventi hotplug di Xen:

> By the way, I've never had to deal with any of the hotplug stuff
> on Xen/ia64... did some new requirement get added in the last few
> days (post-8006)?

No extra requirement, no.  We've been using hotplug scripts for ages.  There
have been changes to these scripts recently, so something might have broken,
but no extra requirements.

If you're not seeing any hotplug script logging at all you are going to have to
trace the hotplug event until you find out where it disappears.  Start with
cat /proc/sys/kernel/hotplug.  If that's udevsend and udevinfo -V reports 
greater than 059 then you are using udev, so check that
/etc/udev/rules.d/xen-backend.rules is in place, otherwise you are using 
hotplug, so put logging into /sbin/hotplug (usually a script)
and /etc/hotplug/xen-backend.agent.  Either way, you'll need logging in
/etc/xen/scripts/block.

Avviano una macchina virtuale si ottiene il seguente errore:

VmError: Device 770 (vbd) could not be connected. Backend device not found.

Ogni disco virtuale di tipo file: viene montato come loop device (anche se non si vede con il comando mount), pare che anche il Domain-0 consumi alcuni loop. Il modulo loop del kernel supporta per default solo 8 device, bisogna usare l'opzione max_loop mettendo in /etc/modprobe.d/local la riga:

options loop max_loop=256

Ricordarsi anche di fare MAKEDEV loop8 per creare il /dev/loop8 e tutti gli altri necessari.

Se il supporto loop è compilato statico dentro al kernel non ho trovato alcun parametro di boot utile ad aumentare il valore predefinito di 8.

Rebooting a virtual machine, it does not reboot.

From /var/log/xend.log:

[2006-07-07 11:14:45 xend.XendDomainInfo] INFO (XendDomainInfo:836) Domain has shutdown: name=inside id=6 reason=reboot.
[2006-07-07 11:14:46 xend] INFO (image:135) buildDomain os=linux dom=7 vcpus=1
[2006-07-07 11:14:46 xend.XendDomainInfo] DEBUG (XendDomainInfo:877) XendDomainInfo.handleShutdownWatch
[2006-07-07 11:14:47 xend.XendDomainInfo] WARNING (XendDomainInfo:819) Domain has crashed: name=inside id=7.
[2006-07-07 11:14:47 xend.XendDomainInfo] ERROR (XendDomainInfo:1467) VM inside restarting too fast (1.638361 seconds since the last restart).                  
                                          Refusing to restart to avoid loops.

From /var/log/syslog:

Jul  7 11:14:46 texen logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/7/770
Jul  7 11:14:47 texen logger: /etc/xen/scripts/block: Writing backend/vbd/7/770/hotplug-status error to xenstore.
Jul  7 11:14:47 texen logger: /etc/xen/scripts/block: Failed to find an unused loop device

Again a loop device problem. How to solve? Some debugging information:

texen:~# dmesg | grep loop
loop: loaded (max 256 devices)

texen:~# ps uax | grep loop
root     10523  0.0  0.0      0     0 ?        S<   Jul06   0:02 [loop4]
root     10727  0.0  0.0      0     0 ?        S<   Jul06   0:00 [loop5]
root     10909  0.0  0.0      0     0 ?        S<   Jul06   0:00 [loop6]
root     11069  0.0  0.0      0     0 ?        S<   Jul06   0:00 [loop7]
root     17086  0.0  0.0      0     0 ?        S<   11:14   0:00 [loop0]
root     17205  0.0  0.0      0     0 ?        S<   11:14   0:00 [loop1]
root     17320  0.0  0.0      0     0 ?        S<   11:14   0:00 [loop2]

First: remember to create all the /dev/loop<N> entries, but why Xen does not reuse the used loops?

May be this is related to FAQ 4.11, how to check for really used xenstore and how to free unused ones?

A standard Debian Testing (Etch) installation running as domU, produces this error message at bootstrap:

Problem when loading /etc/console/boottime.kmap.gz, use install-keymap

You should really remove console related packages, because Xen provides a serial terminal, not a standard Linux console. Remove the following packages:

• console-common
• console-data
• console-tools
• libconsole