====== Paravirtualizzatore Xen ====== ===== Web References ===== * [[wp>Xen|Xen Wikipedia article]] * [[http://www.cl.cam.ac.uk/Research/SRG/netos/xen/|Xen Official Home Page]] * [[http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html|Users' Manual Xen v3.0]] * [[http://wiki.xensource.com/xenwiki/XenNetworking|Xen Networking]] * [[http://www.debian-administration.org/articles/396|Debian Sid gets Xen 3.0]] * [[http://www.howtoforge.com/perfect_xen_setup_debian_ubuntu|The Perfect Xen Setup For Debian And Ubuntu]] ===== Cosa accade in una macchina Xenizzata ===== 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. ===== Prerequisiti ===== 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//. ===== Compilazione ===== 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. ==== Compilazione dei kernel Xen e utility ==== 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à: * 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. ==== Note ==== * 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. ===== Installazione ===== Eventualmente il target ''**make install**'' provvede a installare tutto, per un controllo maggiore di cosa installare... ==== Supervisore Xen e kernel per dom0 ==== 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). ==== Utility ==== 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 ==== Kernel per domU ==== 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. ===== Avvio automatico in Debian ===== 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 ===== Personalizzazione dei kernel ===== ==== Kernel per la macchina ospite: xen0 ==== 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**''. ==== Kernel per le macchine virtuali: xenU ==== 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. ===== Preparazione di una macchina virtuale ===== **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 [[linux:sa:debootstrap|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. ==== Avviare il demone Xen e la macchina virutale ==== 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. ==== Gestione delle macchine virtuali ==== Il programma ''**xm**'' è lo strumento principale per amministrare Xen da console, dialoga con ''**xend**''. Ecco alcuni esempi: xm create -c /etc/xen/.sxp xm shutdown xm list xm console 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 ===== Troubleshooting ===== ==== hotplug ==== 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. ==== loop ==== 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. ==== Reboot ==== 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**'' 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? ==== Console ==== 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