Xen 3.1.0 su Slackware 12 - Cronologia

Conraid il 12:52, 22 apr 2011

2011-04-22T12:52:47Z

Pedro: /* Aggiornamento di grub */

2007-11-21T19:57:56Z

‎Aggiornamento di grub

Pedro: /* Preparazione */

2007-11-08T20:37:16Z

‎Preparazione

Pedro: /* Compilazione del kernel domU */

2007-11-08T20:36:18Z

‎Compilazione del kernel domU

Pedro: /* Compilazione del kernel dom0 */

2007-11-08T20:35:51Z

‎Compilazione del kernel dom0

Pedro: /* Compilazione del kernel domU */

2007-11-08T20:02:45Z

‎Compilazione del kernel domU

Slacky: /* Una prima macchina virtuale ( Debian Etch ) */

2007-11-04T10:27:08Z

‎Una prima macchina virtuale ( Debian Etch )

Slacky: /* Configurazione di Xen */

2007-11-04T10:26:04Z

‎Configurazione di Xen

Pedro il 11:49, 3 nov 2007

2007-11-03T11:49:53Z

Nuova pagina

[[Category:Scritti misti]]

= Xen 3.1.0 on Slackware 12 =

== Introduzione ==

Con questo howto vorrei aiutare tutti quelli che come me si sono trovati in difficoltà nell'installazione di xen 3.1.0 sulla Slackware 12. Vedremo come, partendo dai sorgenti di xen, sia possibile creare dei pacchetti per Slackware.

Prima di tutto due paroline su Xen. ( da wikipedia ) Xen è un monitor di macchine virtuali Open Source rilasciato sotto licenza GPL per piattaforma x86 e compatibili (al momento sono in corso dei port per x86-64 e per IA-64) sviluppato presso il Computer Laboratory dell'Università di Cambridge.
Xen consente una completa emulazione hardware senza andare a ridurre in modo drastico le risorse del sistema, emulando sistemi operativi diversi tra loro. Contrariamente ad altri software di virtualizzazione, Xen non mira a creare un'emulazione dell'hardware di un generico computer x86 su cui far girare il sistema operativo, ma piuttosto di regolare e controllare l'accesso alle risorse fisiche della macchina da parte delle varie istanze delle macchine virtuali; questo approccio prende il nome di ''paravirtualizzazione'' ed è simile a ciò che si utilizza nel campo dei mainframe e dei supercomputer.
Il virtual machine monitor di macchine virtuali (in gergo hypervisor) è implementato direttamente nell'hardware dei processori. Questo tipo di approccio consente di ottenere un decadimento delle prestazioni minimo rispetto all'esecuzione non-virtualizzata, poiché le istruzioni provenienti dalle macchine virtuali vengono eseguite quasi tutte direttamente sul processore, senza l'intervento di un sistema operativo che si ponga tra la macchina virtuale e le risorse fisiche. Tuttavia questo comporta che il sistema operativo destinato a girare sulla macchina virtuale (''guest'') debba essere portato ( e io aggiungo patchato per chiarezza ) per essere reso compatibile con Xen, in quanto alcune chiamate di sistema del kernel non sarebbero possibili.Invece non è necessario ricompilare le applicazioni, in quanto i kernel ''Xenizzati'' espongono la stessa Application binary interface (ABI).

== Cosa faremo ==

* Pacchettizzeremo Xen 3.1.0 per Slackware

* Configureremo la nostra Slackware per essere la macchina virtualizzante ( Dom0 )

* Installeremo e configureremo una macchina virtualizzata Debian Etch ( DomU )

* Ricompileremo le glibc e sysvinit per rendere Xen più performante

== Sistema utilizzato ==

* Slackware 12 ( Dom0 )

* xen 3.1.0

* glibc 2.5 ricompilate ( vedi dopo )

* Debian Etch ( DomU )

== Preparazione ==

Innanzi tutto dobbiamo disporre dei sorgenti di xen3.1.0 reperibili all'indirizzo

http://xen.org/download/

oppure provate se funziona questo link diretto
<pre>
root@darkstar:/# wget http://bits.xensource.com/oss-xen/release/3.1.0/src.tgz/xen-3.1.0-src.tgz
</pre>
Scompattiamoli e lanciamo la prima compilazione che crea tutto l'ambiente necessario e si occupa di scaricare e patchare il kernel 2.6.18 per xen :
<pre>
root@darkstar:/# cd /
root@darkstar:/# tar -xzvf xen-3.1.0-src
root@darkstar:/# cd xen-3.1.0-src
root@darkstar:/xen-3.1.0-src# su
root@darkstar:/xen-3.1.0-src# make world
</pre>
e attendiamo con pazienza la fine della compilazione ... zzz...zzz...zz...z... .
Adesso andremo a preparare l'ambiente per la pacchettizzazione Slackware di Xen. Creeremo 5 pacchetti :
* xen_base-3.1.0.tgz

* xen_kernel_dom0-3.1.0.tgz

* xen_kernel_domU-3.1.0.tgz

* xen_tools-3.1.0.tgz

* xen_docs-3.1.0.tgz

Creiamo le directory che utilizzeremo come appoggio per la creazione dei pacchetti Slackware. In queste directory verranno installati i binari frutto delle diverse compilazioni.
<pre>
root@darkstar:/# cd tmp/
root@darkstar:/tmp# mkdir package-xen-base
root@darkstar:/tmp# mkdir package-xen-tools
root@darkstar:/tmp# mkdir package-xen-kernel-dom0
root@darkstar:/tmp# mkdir package-xen-kernel-domU
root@darkstar:/tmp# mkdir package-xen-docs
</pre>

== Compilazione di Xen ( base – tools -docs ) ==
<pre>
root@darkstar:/tmp# cd /xen-3.1.0-src
root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-base” install-xen
root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-tools” install-tools
root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-docs” install-docs
</pre>
== Compilazione del kernel dom0 ==

Procediamo ora alla configurazione e compilazione del kernel dom0. Nella directory buildconfigs ( ''xen-3.1.0-src/buildconfigs'' ) ci sono una serie di file del tipo 'mk.linux-X.Y-*'', dove X.Y sta per la versione del kernel di xen ( nel mio caso è la 2.6 ) e * sta per xen, xen0, xenU, native e altro ancora. A noi interessano xen0 per dom0 e xenU per i domU. Procediamo allora creazione del nostro kernel per la dom0:
<pre>
root@darkstar:/xen-3.1.0-src# make linux-2.6-xen0.config CONFIGMODE=menuconfig
</pre>
Si aprirà il pannello di configurazione per il kernel dom0. Io vi consiglio di lasciare per ora tutto com'è. I raffinamenti sul kernel possono essere fatti anche in un secondo momento.
<pre>
root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-dom0” linux-2.6-xen0.build
</pre>
Probabilmente in questo caso è inutile specificare la DESTDIR. Abbiate un pò di pazienza per il tempo di compilazione ... zzz ... .
<pre>
root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-dom0” linux-2.6-xen0.install
</pre>
A questo punto nella directory ''/tmp/package-xen-kernel-dom0'' ci troveremo I binari compilati pronti per essere pacchettizzati.

== Compilazione del kernel domU ==

Passiamo ora alle domU. Il procedimento è praticamente identico a quello effettuato per la dom0.

root@darkstar:/xen-3.1.0-src# make linux-2.6-xenU.config CONFIGMODE=menuconfig

Si aprirà il pannello di configurazione per il kernel domU. In questo caso ha senso modificare la configurazione del kernel, poichè le domU non hanno bisogno di tutti i moduli necessari alla gestione dell'hardware; di questo penso se ne occupi la dom0. E' infatti buona norma cercare di rendere il più leggeri possibile i kernel delle domU. Comunque anche in questo caso vi consiglio di lasciare per ora tutto com'è. I raffinamenti sul kernel dei domU possono essere fatti anche in un secondo momento.
<pre>
root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-domU” linux-2.6-xenU.build
root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-domU” linux-2.6-xenU.install
</pre>
A questo punto nella directory /tmp/package-xen-kernel-domU ci troveremo I binari compilati.

== Creazione dei pacchetti Slackware ==

Ora che tutto il necessario è stato compilato, procediamo alla creazione dei pacchetti per Slackware.
<pre>
root@darkstar:/xen-3.1.0-src# cd /tmp/package-xen-base
root@darkstar:/tmp/package-xen-base# makepkg -l y -c n /tmp/xen_base-3.1.0-i386-1pedro.tgz
root@darkstar:/tmp/package-xen-base# cd /tmp/package-xen-tools
root@darkstar:/tmp/package-xen-tools# makepkg -l y -c n /tmp/xen_tools-3.1.0-i386-1pedro.tgz
root@darkstar:/tmp/package-xen-tools# cd /tmp/package-xen-docs
root@darkstar:/tmp/package-xen-docs# makepkg -l y -c n /tmp/xen_docs-3.1.0-i386-1pedro.tgz
root@darkstar:/tmp/package-xen-docs# cd /tmp/package-xen-kernel-dom0
root@darkstar:/tmp/package-xen-kernel-dom0# makepkg -l y -c n /tmp/xen_kernel_dom0-3.1.0-i386-1pedro.tgz
root@darkstar:/tmp/package-xen-kernel-dom0# cd /tmp/package-xen-kernel-domU
root@darkstar:/tmp/package-xen-kernel-domU# makepkg -l y -c n /tmp/xen_kernel-domU-3.1.0-i386-1pedro.tgz
</pre>
Ora nella directory ''/tmp'' ci ritroviamo I pacchetti tgz pronti per essere installati con ''installpkg''.
<pre>
root@darkstar:/tmp/package-xen-kernel-dom0# cd /tmp
root@darkstar:/tmp# ls
...
...
xen_base-3.1.0-i386-1pedro.tgz
xen_kernel_dom0-3.1.0-i386-1pedro.tgz
xen_kernel_domU-3.1.0-i386-1pedro.tgz
xen_tools-3.1.0-i386-1pedro.tgz
xen_docs-3.1.0-i386-1pedro.tgz
...
...
</pre>

== Installazione pacchetti Slackware ==

Procediamo all'installazione :
<pre>
root@darkstar:/tmp# installpkg xen_*
</pre>
e attendiamo ... z ... .
Ora il vostro sistema xen è pronto per essere operativo. Mancano però ancora alcuni “piccoli” accorgimenti!
Nella directory /boot vi ritroverete 2 immagini del kernel vmlinuz-2.6.18-xen0 e vmlinuz-2.6.18-xenU fiammanti e uno xen-3.1.0.gz con diversi link simbolici che lo puntano.

== Aggiornamento di grub ==

Diciamo ora a grub che esiste xen aggiungendo le seguenti righe al file ''/boot/grub/menu.lst'' o chi per lui:
<pre>
# Xen bootable partition config begins
title Xen on (/dev/hdb2)
root (hd1,1)
kernel /boot/xen-3.1.0.gz mem=512M dom0_mem=262144
module /boot/vmlinuz-2.6-xen0 root=/dev/hdb2 ro console=vga vga=791
boot
savedefault fallback
# Xen bootable partition config ends
</pre>
Al posto di hdb2 dovete mettere l'hd dove è installato xen. Nel mio caso è hdb2, ossia l'hd dove risiede linux.
<pre>
root@darkstar:/tmp# cat /etc/fstab
/dev/hdb1 swap swap defaults 0 0
/dev/hdb2 / ext3 defaults 1 1
/dev/hda1 /Win ntfs ro 1 0
/dev/hda5 /WinShared ntfs ro,users 1 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
shm /dev/shm tmpfs defaults 0 0

</pre>
Vi ricordo che in grub hda1 viene indicato con (hd0,0) e quindi nel mio caso hdb2 corrisponde a (hd1,1).
Vediamo ora nel dettaglio cosa abbiamo a grub:

* ''mem'' indica quanta memoria fisica ( espressa in Megabyte ) dedicare a xen;

* ''dom0_mem'' indica quanta di questa memoria dedicare alla dom0; vi confesso che non mi è molto chiara la distinzione, quindi si accettano chiarimenti in merito.

* ''savedefault'' fallback serve per indicare a grub cosa far partire nel caso in cui fallisse il boot dell'hypervisor. Per questo comando vi rimando alla documentazione relativa al grub.

== Ricompilazione delle glibc-2.5 e di sysvinit ==

Se ora provate a riavviare la macchina e a far partire xen selezionandolo dal menu di avvio al boot, dovrebbe andare tutto bene tranne che per un messaggio di warning:
<pre>
***************************************************************
***************************************************************
** WARNING: Currently emulating unsupported memory accesses **
** in /lib/tls glibc libraries. The emulation is **
** slow. To ensure full performance you should **
** install a 'xen-friendly' (nosegneg) version of **
** the library, or disable tls support by executing **
** the following as root: **
** mv /lib/tls /lib/tls.disabled **
** Offending process: init (pid=1) **
***************************************************************
***************************************************************
</pre>
Questo messaggio è causato dalle nuove glibc 2.5 presenti in Slackware 12 ( da che era una distribuzione conservativa a quanto pare ha cominciato a correre anche lei ) che utilizzano le librerie NPTL per la gestione dei thread invece delle libpthreads ormai considerate deprecate.
<pre>
root@darkstar:/tmp# getconf GNU_LIBPTHREAD_VERSION
NPTL 2.5
root@darkstar:/tmp# getconf GNU_LIBC_VERSION
glibc 2.5
</pre>
Sembra però che tuttora xen preferisca le libpthread alle NPTL. Xen funziona comunque con le NPTL ma al 50% delle sue potenzialità ( almeno così dicono su xen.org ). Dobbiamo quindi ricompilare le glibc 2.5 e sysvinit ( si occupa dell'avvio del sistema ) per abilitare le libpthread ( che comunque sono presenti nel sistema ).
Riavviamo il sistema con il nostro kernel preferito ( non xen ) e scarichiamo i sorgenti delle glibc e di sysvinit dal cdrom della Slackware.
<pre>
root@darkstar:/# mkdir /tmp/package-glibc-2.5
root@darkstar:/# cd /tmp/package-glibc-2.5
root@darkstar:/tmp/package-glibc-2.5# mount /dev/hdc /mnt/cdrom
</pre>
nel mio sistema il cdrom è hdc, vedete qual è nel vostro e sostituitelo se necessario a hdc.
<pre>
root@darkstar:/tmp/package-glibc-2.5# cp /mnt/cdrom/source/l/glibc .
root@darkstar:/tmp/package-glibc-2.5# vi glibc.SlackBuild
</pre>
Nel file <pre>glibc.SlackBuild</pre> sostituite
<pre>
CFLAGS="-g $OPTIMIZ" \
</pre>
con:
<pre>
#CFLAGS="-g $OPTIMIZ" \
CFLAGS="-g $OPTIMIZ -mno-tls-direct-seg-refs" \
</pre>
Ora lanciate lo slackbuild e aspettate:
<pre>
root@darkstar:/tmp/package-glibc-2.5# ./glibc.SlackBuild
</pre>
...zzz...zzz...zzz...

Alla fine della compilazione vi troverete una directory sulla root del tipo /glibc-tmp-xxxxxxxxxxxxxxxxxxxxxxxxxx . Entrateci dentro ed eseguite upgradepkg ( upgradepkg –reinstall oldpackagename%newpackagename ):
<pre>
root@darkstar:/tmp/package-glibc-2.5# cd glibc-tmp-af6454d73fa56f5e4d21015a706c3d68

root@darkstar:/glibc-tmp-af6454d73fa56f5e4d21015a706c3d68# upgradepkg –reinstall glibc-2.5-i486-4%glibc-2.5-i486-4.tgz

root@darkstar:/glibc-tmp-af6454d73fa56f5e4d21015a706c3d68# upgradepkg –reinstall glibc-debug-2.5-i486-4%glibc-debug-2.5-i486-4.tgz

root@darkstar:/glibc-tmp-af6454d73fa56f5e4d21015a706c3d68# upgradepkg –reinstall glibc-i18n-2.5-noarch-4%glibc-i18n-2.5-noarch-4.tgz

root@darkstar:/glibc-tmp-af6454d73fa56f5e4d21015a706c3d68# upgradepkg –reinstall glibc-profile-2.5-i486-4%glibc-profile-2.5-i486-4.tgz

root@darkstar:/glibc-tmp-af6454d73fa56f5e4d21015a706c3d68# upgradepkg –reinstall glibc-solibs-2.5-i486-4%glibc-solibs-2.5-i486-4.tgz

root@darkstar:/glibc-tmp-af6454d73fa56f5e4d21015a706c3d68# upgradepkg –reinstall glibc-zoneinfo-2.5-noarch-4%glibc-zoneinfo-2.5-noarch-4.tgz
</pre>
ed infine eseguite ldconfig per linkare le nuove librerie.
<pre>
root@darkstar:/glibc-tmp-af6454d73fa56f5e4d21015a706c3d68# ldconfig
</pre>
Passiamo ora a sysvinit. Scarichiamo i sorgenti dal cdrom :
<pre>
root@darkstar:/# mkdir /tmp/package-sysvinit
root@darkstar:/# cd /tmp/package-sysvinit
root@darkstar:/tmp/package-sysvinit# cp /mnt/cdrom/source/a/sysvinit .
root@darkstar:/tmp/package-sysvinit# sysvinit.SlackBuild
</pre>
...z...
<pre>
root@darkstar:/tmp# cd ..
root@darkstar:/tmp# upgradepkg –reinstall sysvinit%sysvinit.tgz
</pre>
Ecco fatto. Ora finalmente possiamo riavviare il sistema con xen funzionante al 100%!

== Configurazione di Xen ==

Passiamo ora alla configurazione di xen vero e proprio. Premetto che qualsiasi apporto a questa parte è ben voluto. Ci sto smanettando da poco quindi non ho ancora chiarissimi alcuni aspetti propri della configurazione. Da quanto ho capito il file principale di configurazione è ''/etc/xen/xend-config.sxp''. Questo file si occupa di richiamare gli script necessari alla vostra configurazione e voi stessi dovete decidere quali richiamare per ogni azione poichè sono presenti diverse alternative. Per quanto mi riguarda per ora lo ho lasciato com'era tranne che per la parte relativa al networking. Aprite il file ''xend-config.sxp'' e commentate tutte le voci (network-script .......... ) tranne (network-script 'network-bridge bridge=xenbr1'). In tal modo diciamo a xen di creare nella dom0 ( xenbr1 ) un bridge nel quale verranno bridgiate la vif0.0, peth1 e le varie interfacce vifx.y delle x macchine guest virtuali domU.
Lanciamo finalmente xen:
<pre>
root@darkstar:/# xend start
</pre>
e verifichiamo con ifconfig che le iterfacce di rete siano state create correttamente. Verifichiamo inoltre con ''brctl show'' se il bridge contiene effettivamente la peth0 e la vif0.0 ( le vifx.y non sono presenti poichè non abbiamo ancora creato una o più macchine virtuali guest ).
<pre>
root@darkstar:/# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 256 1 r----- 193.1
root@darkstar:/#
</pre>
ci mostra quante macchine virtuali sono effettivamente in piedi. Lanciandolo ora ne vedremo solo una: la dom0.

== Una prima macchina virtuale ( Debian Etch ) ==

Creiamo ora un macchina virtuale. Personalmente io ho installato una debian come prima guest. Creiamo una dir sulla root che ospiterà le nostre virtual machine.
<pre>
root@darkstar:/# mkdir -p /vserver/images
root@darkstar:/# mkdir -p /vserver/mount
root@darkstar:/# cd /vserver/images
</pre>
Qui creeremo due file grandi a piacere, uno per il sistema operativo virtuale della domU e uno per lo swap:
<pre>
root@darkstar:/vserver/images# dd if=/dev/zero of=/vserver/images/vm01.img bs=1024k count=4000
root@darkstar:/vserver/images# dd if=/dev/zero of=/vserver/images/vm01-swap.img bs=1024k count=500
</pre>
Quindi stiamo dedicando alla nuova debian 4Gbyte ( 4000 blocchi da 1024 kilobyte ) di spazio e 500Mbyte di swap. Creiamo I file system su tali file:
<pre>
root@darkstar:/vserver/images# mkfs.ext3 vm01.img
root@darkstar:/vserver/images# mkswap vm01-swap.img
</pre>
Ora ci serve il debootstrap. Scaricatevi dai repository Debian ( o googlate e trovatelo ) il pacchetto debootstrap_0.3.3.2etch1_all.deb o versione equivalente per debian etch :
<pre>
root@darkstar:/vserver/images# cd ..
root@darkstar:/vserver# wget http://ftp.de.debian.org/debian/pool/main/d/debootstrap/debootstrap_0.3.3.2etch1_all.deb
</pre>
ed eseguite nell'ordine :
<pre>
root@darkstar:/vserver# ar x debootstrap_0.3.3.2etch1_all.deb
root@darkstar:/vserver# mv data.tar.gz debootstrap_0.3.3.2etch1_all.tgz
root@darkstar:/vserver# installpkg debootstrap_0.3.3.2etch1_all.tgz
</pre>
Ora montiamo la vm01:
<pre>
root@darkstar:/vserver# mount -o loop images/vm01.img mount/
</pre>
e installiamo la debian ( per questo è necessaria una connessione a internet ).
<pre>
root@darkstar:/vserver# debootstrap --verbose --arch i386 etch mount/debian-4/ http://ftp.de.debian.org/debian
</pre>
Una volta finita l'installazione della debian etch possiamo passare alla configurazione di xen per la nuova macchina virtuale. Prima però “aggiustiamo“ il nuovo sistema:
<pre>
root@darkstar:/vserver# chroot mount/ /bin/bash
</pre>
Ora siamo nella debian. Editiamo il nostro source.list come segue :
<pre>
darkstar:/# cat /etc/apt/sources.list
deb http://ftp2.de.debian.org/debian etch main
deb-src http://ftp2.de.debian.org/debian etch main
deb http://security.debian.org/ etch/updates main contrib
deb-src http://security.debian.org/ etch/updates main contrib
</pre>
Quindi eseguite:
<pre>
darkstar:/# apt-get update
</pre>
e installate quello che volete e torniamo nel nostro sistema digitando:
<pre>
darkstar:/# exit
</pre>
Ora siamo di nuovo nella Slackware.
Creiamo quindi un file relativo alla vm01 nella directory /etc/xen:
<pre>
root@darkstar:/vserver# cd /etc/xen
root@darkstar:/etc/xen# touch vm01-config.sxp
</pre>

ed editiamolo. Di seguito potete vedere come ho settato il mio:
<pre>
root@darkstar:/etc/xen# cat /etc/xen/vm01-config.sxp
name ="vm01"
kernel ="/boot/vmlinuz-2.6.18-xenU"
root ="/dev/sda1 ro"
memory =64
disk = ['file:/vserver/images/vm01.img,sda1,w','file:/vserver/images/vm01-swap.img,sda2,w']
# network
#nics=1
#dhcp ="on"
vif=[ "" ]
#ip="192.168.0.101"
#netmask="255.255.255.0"
#gateway="192.168.0.1"
hostname="vm01.fabriziog.homelinux.org"
#extra="3"
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
</pre>
Vediamo nel dettaglio il significato delle voci che lo compongono:

* ''name'' è il nome che vogliamo dare alla macchina virtuale guest ed è il nome che verrà visualizzato quando eseguiamo xm list

* ''kernel'' va indicato il path del kernel per la domU che si vuole utilizzare ( presente nella directory di boot )

* ''root'' il dispositivo di domU che verrà montato come root / ( non mi è molto chiaro. Inizialmente avevo messo hdb2, ossia l'hd dove effettivamente risiedeva il file vm01.img ma non funzionava. Con sda1 funziona ). Qui si possono specificare I paramentri da passare al kernel se ne avete bisogno.

* ''memory'' quanta memoria fisica si vuole assegnare alla domU in questione.

* ''disk'' mappaggio dei dischi nella macchina virtuale. phy = dischi fisici (i parametri sono: il nome del disco o del file su dom0, il nome che prenderà in domU, il tipo di accesso, cioè r per lettura e w per scrittura), file = immagini di disco su file. Nel nostro caso utilizziamo ovviamente file.

* ''ip'' se si vuole assegnare un ip fisso alla domU

* ''netmask'' per la netmask

* ''gateway'' per il gateway

* ''hostname'' hostname vero e proprio

* ''vcpus'' se avete un sistema multiprocessore, indica quale cpu usare ( da 0 in poi )

* ''nics'' quante interfacce di rete creare

* ''vif'' viene riempito con una lista di MAC address e bridge da usare nella domU vm01. Per esempio :
'' vif = [ 'mac=00:16:3E:00:00:11, bridge=xen-br0','bridge=xen-br1' ] ''
assegna un MAC address e un bridge alla prima interfaccia, e un bridge differente per la seconda interfaccia. Se si lascia vuoto viene riempito automaticamente da xen con uno dei MAC address assegnati standard.

* ''extra'' indica quante stringhe possono essere passate al massimo al kernel nella voce root.

Ci sono altre istruzioni che qui non elenco. Se quelle elencate qui sopra non dovessero bastarvi ( come per chi vuole utilizzare un server NFS ), vi rimando alla documentazione ufficiale. Vi consiglio di iniziare con file di configurazione semplice, senza troppe opzioni, per prendere dimestichezza con il sistema.

Ora siamo pronti ad avviare la nuova macchina virtuale guest domU.

== Comandi utili ==

Facciamo partire la nuova macchina virtuale:
<pre>
root@darkstar:/# xm create /etc/xen/vm01-config.sxp
Using config file "/etc/xen/vm01-config.sxp".
Started domain vm01
</pre>
Lanciando:
<pre>
root@darkstar:/etc/xen# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 256 1 r----- 214.6
vm01 1 64 1 -b---- 8.6
</pre>
possiamo ora vedere che le macchine virtuali in esecuzione ora sono due: la dom0 e una domU chiamata vm01. Se vogliamo entrare nella nuova macchina virtuale digitiamo :
<pre>
root@darkstar:/etc/xen# xm console vm01
...
...
Setting kernel variables...done.
Mounting local filesystems...done.
Activating swapfile swap...done.
Setting up networking....
Configuring network interfaces...done.
INIT: Entering runlevel: 3
Starting system log daemon: syslogd.
Starting kernel log daemon: klogd.
* Not starting internet superserver: no services enabled. <-----piccolo problema dovuto al file di configurazione vm01-config.sxp
Starting OpenBSD Secure Shell server: sshd.
Starting periodic command scheduler: crond.
Debian GNU/Linux 4.0 (none) tty1
(vm01) login:
</pre>
e siamo dentro la nostra macchina virtuale guest pronti a fare tutti I danni che vogliamo senza che il sistema base ne risenta.
Per spegnere una domU ( per esempio vm01 ) basta digitare dalla dom0 il comando :
<pre>
root@darkstar:/etc/xen# xm shutdown vm01
</pre>
Per altri comandi vi rimando alla documentazione ufficiale.
== Riferimenti ==

http://tx.downloads.xensource.com/downloads/docs/user/

http://www.howtoforge.com/debian_etch_xen_3.1

http://www.debianitalia.org/modules/wfsection/article.php?articleid=122&page=0

http://www.pervasive.jku.at/About_Us/Staff/Hochreiter/Server_Virtualization/

http://www.google.it

Autore: pedro

← Versione meno recente		Versione delle 12:52, 22 apr 2011
Riga 1:		Riga 1:
−	[[Category:Scritti misti]]	+	[[Category:Scritti misti-12]]

	= Xen 3.1.0 on Slackware 12 =		= Xen 3.1.0 on Slackware 12 =

@@ Riga 156: / Riga 156: @@
   root (hd1,1)
   kernel /boot/xen-3.1.0.gz mem=512M dom0_mem=262144
-  module /boot/vmlinuz-2.6-xen0 root=/dev/hdb2 ro console=vga vga=791
+  module /boot/vmlinuz-2.6-xen0 root=/dev/hdb2 ro console=vga vga=791 max_loop=32
   boot
   savedefault fallback
@@ Riga 182: / Riga 182: @@
 * ''savedefault'' fallback serve  per indicare a grub cosa far partire nel caso in cui fallisse il boot  dell'hypervisor. Per questo comando vi rimando alla documentazione relativa al grub.
 == Ricompilazione delle glibc-2.5 e di sysvinit ==

@@ Riga 39: / Riga 39: @@
 oppure provate se funziona questo link diretto
 <pre>
-root@darkstar:/# wget http://bits.xensource.com/oss-xen/release/3.1.0/src.tgz/xen-3.1.0-src.tgz
+notorious@darkstar:~$ wget http://bits.xensource.com/oss-xen/release/3.1.0/src.tgz/xen-3.1.0-src.tgz
 </pre>
 Scompattiamoli e lanciamo la prima compilazione che crea tutto l'ambiente necessario e si occupa di scaricare e patchare il kernel 2.6.18 per xen :
 <pre>
-root@darkstar:/# cd /
+notorious@darkstar:~$ cd /
-root@darkstar:/# tar -xzvf xen-3.1.0-src
+notorious@darkstar:~$ tar -xzvf xen-3.1.0-src
-root@darkstar:/# cd xen-3.1.0-src
+notorious@darkstar:~$ cd xen-3.1.0-src
 root@darkstar:/xen-3.1.0-src# su
 root@darkstar:/xen-3.1.0-src# make world

@@ Riga 98: / Riga 98: @@
 Passiamo ora alle domU. Il procedimento è praticamente identico a quello effettuato per la dom0.
 <pre>
 root@darkstar:/xen-3.1.0-src# make linux-2.6-xenU-config CONFIGMODE=menuconfig
 </pre>
 Si aprirà il pannello di configurazione per il kernel domU. In questo caso ha senso modificare la configurazione del kernel, poichè le domU non hanno bisogno di tutti i moduli necessari alla gestione dell'hardware; di questo penso se ne occupi la dom0. E' infatti buona norma cercare di rendere il più leggeri possibile i kernel delle domU. Comunque anche in questo caso vi consiglio di lasciare per ora tutto com'è. I raffinamenti sul kernel dei domU possono essere fatti anche in un secondo momento.
 <pre>

@@ Riga 83: / Riga 83: @@
 Procediamo ora alla configurazione e compilazione del kernel dom0. Nella directory buildconfigs ( ''xen-3.1.0-src/buildconfigs'' ) ci sono una serie di file del tipo 'mk.linux-X.Y-*'', dove X.Y sta per la versione del kernel di xen ( nel mio caso è la 2.6 ) e * sta per xen, xen0, xenU, native e altro ancora. A noi interessano xen0 per dom0 e xenU per i domU.  Procediamo allora creazione del nostro kernel per la dom0:
 <pre>
-root@darkstar:/xen-3.1.0-src# make linux-2.6-xen0.config CONFIGMODE=menuconfig
+root@darkstar:/xen-3.1.0-src# make linux-2.6-xen0-config CONFIGMODE=menuconfig
 </pre>
 Si aprirà il pannello di configurazione per il kernel dom0. Io vi consiglio di lasciare per ora tutto com'è. I raffinamenti sul kernel possono essere fatti anche in un secondo momento.
 <pre>
-root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-dom0” linux-2.6-xen0.build
+root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-dom0” linux-2.6-xen0-build
 </pre>
 Probabilmente in questo caso è inutile specificare la DESTDIR. Abbiate un pò di pazienza per il tempo di compilazione ... zzz ... .
 <pre>
-root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-dom0” linux-2.6-xen0.install
+root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-dom0” linux-2.6-xen0-install
 </pre>
 A questo punto nella directory ''/tmp/package-xen-kernel-dom0'' ci troveremo I binari compilati pronti per essere pacchettizzati.
 == Compilazione del kernel domU ==

@@ Riga 100: / Riga 100: @@
 Passiamo ora alle domU. Il procedimento è praticamente identico a quello effettuato per la dom0.
-root@darkstar:/xen-3.1.0-src# make linux-2.6-xenU.config CONFIGMODE=menuconfig
+root@darkstar:/xen-3.1.0-src# make linux-2.6-xenU-config CONFIGMODE=menuconfig
 Si aprirà il pannello di configurazione per il kernel domU. In questo caso ha senso modificare la configurazione del kernel, poichè le domU non hanno bisogno di tutti i moduli necessari alla gestione dell'hardware; di questo penso se ne occupi la dom0. E' infatti buona norma cercare di rendere il più leggeri possibile i kernel delle domU. Comunque anche in questo caso vi consiglio di lasciare per ora tutto com'è. I raffinamenti sul kernel dei domU possono essere fatti anche in un secondo momento.
 <pre>
-root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-domU” linux-2.6-xenU.build
+root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-domU” linux-2.6-xenU-build
-root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-domU” linux-2.6-xenU.install
+root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-domU” linux-2.6-xenU-install
 </pre>
 A questo punto nella directory /tmp/package-xen-kernel-domU ci troveremo I binari compilati.

@@ Riga 379: / Riga 379: @@
 * ''kernel''	va indicato il path del kernel per la domU che si vuole utilizzare ( presente nella directory di boot )
-* ''root''	il dispositivo di domU che verrà montato come root / ( non mi è molto chiaro. Inizialmente avevo messo hdb2, ossia l'hd dove effettivamente risiedeva il file vm01.img ma non funzionava. Con sda1 funziona ). Qui si possono specificare I paramentri da passare al kernel se ne avete bisogno.
+* ''root''	il dispositivo di domU che verrà montato come root / ( non mi è molto chiaro. Inizialmente avevo messo hdb2, ossia l'hd dove effettivamente risiedeva il file vm01.img ma non funzionava. Con sda1 funziona ). Qui si possono specificare I parametri da passare al kernel se ne avete bisogno.
 * ''memory''	quanta memoria fisica si vuole assegnare alla domU in questione.

@@ Riga 274: / Riga 274: @@
 == Configurazione di Xen ==
-Passiamo ora alla configurazione di xen vero e proprio. Premetto che qualsiasi apporto a questa parte è ben voluto. Ci sto smanettando da poco quindi non ho ancora chiarissimi alcuni aspetti propri della configurazione. Da quanto ho capito il file principale di configurazione è ''/etc/xen/xend-config.sxp''. Questo file si occupa di richiamare gli script necessari alla vostra configurazione e voi stessi dovete decidere quali richiamare per ogni azione poichè sono presenti diverse alternative. Per quanto mi riguarda per ora lo ho lasciato com'era tranne che per la parte relativa al networking. Aprite il file  ''xend-config.sxp'' e commentate tutte le voci (network-script .......... ) tranne (network-script 'network-bridge bridge=xenbr1'). In tal modo diciamo a xen di creare nella dom0 ( xenbr1 ) un bridge nel quale verranno bridgiate la vif0.0, peth1 e le varie interfacce vifx.y delle x macchine guest virtuali domU.
+Passiamo ora alla configurazione di xen vero e proprio. Premetto che qualsiasi apporto a questa parte è ben voluto. Ci sto smanettando da poco quindi non ho ancora chiarissimi alcuni aspetti propri della configurazione. Da quanto ho capito il file principale di configurazione è ''/etc/xen/xend-config.sxp''. Questo file si occupa di richiamare gli script necessari alla vostra configurazione e voi stessi dovete decidere quali richiamare per ogni azione poiché sono presenti diverse alternative. Per quanto mi riguarda per ora lo ho lasciato com'era tranne che per la parte relativa al networking. Aprite il file  ''xend-config.sxp'' e commentate tutte le voci (network-script .......... ) tranne (network-script 'network-bridge bridge=xenbr1'). In tal modo diciamo a xen di creare nella dom0 ( xenbr1 ) un bridge nel quale verranno bridgiate la vif0.0, peth1 e le varie interfacce vifx.y delle x macchine guest virtuali domU.
 Lanciamo finalmente xen:
 <pre>
 root@darkstar:/# xend start
 </pre>
-e verifichiamo con ifconfig che le iterfacce di rete siano state create correttamente. Verifichiamo inoltre con ''brctl show'' se il bridge contiene effettivamente la peth0 e la vif0.0 ( le vifx.y non sono presenti poichè non abbiamo ancora creato una o più macchine virtuali guest ).
+e verifichiamo con ifconfig che le interfacce di rete siano state create correttamente. Verifichiamo inoltre con ''brctl show'' se il bridge contiene effettivamente la peth0 e la vif0.0 ( le vifx.y non sono presenti poiché non abbiamo ancora creato una o più macchine virtuali guest ).
 <pre>
 root@darkstar:/# xm list