Ho necessita’ di avere due macchine ‘up and running’ nonostante abbia, fisicamente, una sola macchina. La soluzione ? Virtualizzazione. Io pero’ non sono come tanti che pensano che la virtualizzazione sia la panacea di tutti i mali, infatti se si hanno 10 macchine che occupano il 20% delle risorse, bene, in un server ce ne possono stare 5 virtualizzate (facendo finta che il server non occupi risorse), ma se io ho 10 macchine ognuna occupa il 100% delle risorse, beh, a meno che le macchine non siano dei PII e’ molto difficile farle stare in un ambiente virtuale. Non e’ il mio caso, comunque, in quanto devo solo far apparire un dns primario ed uno secondario, che realmente occupano poche risorse di sistema.
La prima idea era di provare ad usare qemu, che ho gia’ messo in funzione qualche tempo fa, ma alla fine ho preso l’occasione per provare il tanto decantato xen.
Armato della mia Debian etch e del mio fido apt-get vediamo un po’ cosa fare. Innanzitutto si installano i pacchetti necessari:
apt-get update; apt-get install xen-linux-system-2.6.18-3-xen-k7 xen-tools bridge-utils iproute debootstrap
Se avete il lilo, dovete toglierlo e installare grub perche’ questo viene usato da xen, per cui:
dpkg –purge lilo; apt-get install grub; grub-install /dev/XXX dove XXX e’ il disco su cui avete installato il sistema, ad esempio nel mio casoe’ /dev/hda.
Molto probabilmente, o meglio sicuramente, vi e’ stato cambiato il kernel con un linux-image…-xen-…, per cui e’ necessario riavviare in modo che venga usato questo. Dopo il boot io noto un sacco di messaggi a console del tipo Feb 2 18:50:55 server kernel: 4gb seg fixup, process sshd (pid 1928), cs:ip 73:b7c66c1c ma per ora non mi preoccupo, vedremo in seguito se riesco a toglierlo 😉
A questo punto prendete una partizione del disco piuttosto ampia e createci una directory in cui andrete a create tutte le macchine virtuali. Io ne ho fatta una ad-hoc perche’ quelle che avevo sul sistema server erano tutte piuttosto piccole, ma se avete una partizione unica allora nessun problema, usate pure quella. Sempre per mantenere un po’ di ordine mi sono fatto una dir /virtual nella quale ho montato la partizione, voi vedete di fare quello che preferite 🙂 La dir di default negli xen-tools e’ la /home/xen.
xen-tools e’ un insieme di script per aiutare a creare le macchine virtuali, ed e’ configurabile tramite il file conf in /etc/xen-tools/xen-tools.conf, eccone qui un mio estratto:
server:/etc/xen-tools# grep -v ^# xen-tools.conf | grep -v ^$
dir = /virtual
debootstrap = 1
size = 4Gb # Disk image size.
memory = 128Mb # Memory size
swap = 128Mb # Swap size
fs = ext3 # use the EXT3 filesystem for the disk image.
dist = etch # Default distribution to install.
image = sparse # Specify sparse vs. full disk images.
gateway = 192.168.1.1
netmask = 255.255.255.0
passwd = 1
kernel = /boot/vmlinuz-2.6.18-3-xen-k7
initrd = /boot/initrd.img-2.6.18-3-xen-k7
mirror = https://ftp.debian.org/
Tutto il resto e’ lasciato di default. Probabilmente alcune altre cose sono da cambiare, ma insomma, piu’ o meno dovrebbe essere corretto e dare un’idea di massima.
Siamo pronti ora a lanciare il comando per generare la macchina virtuale:
xen-create-image –hostname vm01 –ip 192.168.1.10
Alla fine, dopo avere creato i file immagine, averli formattati, riempiti con i file di sistema (una etch come si vede nella c onfigurazione) tramite bootstrap ed avere applicato alcune patch, mi chiede, come richiesto nella configurazione, la password di root, e per terminare con un rassicurante All done.
Funziona ? Non funziona ? Vediamo un po’…
Per cominciare vediamo se la macchina virtuale e’ vista dal sistema:
# xen-list-images Name: vm01 Memory: 128 IP: 192.168.1.10
…ed infatti in /etc/xen/ troviamo il file vm01.cfg. Lanciamo ora la macchina virtuale:
# xm create vm01.cfg -c
L’opzione -c e’ utile nel caso la macchina virtuale non parta e si voglia capire perche’, ma solitamente la si omette perche’ poi si usa ssh per connetersi. Per fermare la macchina virtual, si puo’ dare uno shutdown dall’interno della stessa, oppure dal server host dare il comando xm shutdown vm01.
Ovviamente qualcosa non va 😉 Non viene trovato il bridge che viene cercato di default, e quindi la macchina virtuale non parte e poi…non parte in automatico (ma questo non so se sia dovuto a qualche impostazione in fase di creazione). Ovviamo a entrambe le cose, editando il file /etc/xen/xend-config.sxp, io ho tolto il commento alla configurazione indicante (network-script network-bridge) mentre ho commentato quella indicante (vif-script vif-bridge). Riavviate poi i demoni con:
# /etc/init.d/xend restart. /etc/init.d/xendomains restart
A questo punto per rendere automatico l’avvio, basta guardare in /etc/default/xendomains per capire che vengono lanciate in automatico le macchine virtuali la cui configurazione si trovi in /etc/xend/auto, per cui:
# cd /etc/xend; mkdir auto; cd auto; ln -s /etc/xend/vm01.cfg .
…e dovremmo esserci 🙂
Aggiornamento:
Per riavviare le macchine virtuali, semplicemente entrate in ssh e date il comando reboot
Vi consiglio di installare, poiche’ debootstrap non li installa al momento della creazione dello spazio virtuale, i seguenti pacchetti: postfix vim locales, dopodiche’ date il comando dpkg-reconfigure locales e selezionate it_IT.UTF-8
Altro consiglio, per evitare l’errore 4gb seg fixup e’ quello di installare il pacchetto libc6-xen che, stranamente, non viene fatto in automatico durante la prima fase.