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:
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:
| xen | Un kernel unico, adatto sia per la macchina ospite che per quelle virtuali. |
|---|---|
| xen0 | Kernel adatto per la macchina ospite, ha il supporto modulare per molti dispositivi hardware. |
| xenU | Versione ridotta di kernel adatta alle macchine virtuali, privo di supporto per la maggior parte delle periferiche hardware. |
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à:
xm, …)
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.
make world scarica nuovamente con wget i sorgenti e li mette nella sua directory.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).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: