Xen 3.1.0 on Slackware 12

Indice

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

root@darkstar:/# wget http://bits.xensource.com/oss-xen/release/3.1.0/src.tgz/xen-3.1.0-src.tgz

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 :

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

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.

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

Compilazione di Xen ( base – tools -docs )

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

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:

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

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.

root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-dom0” linux-2.6-xen0.build

Probabilmente in questo caso è inutile specificare la DESTDIR. Abbiate un pò di pazienza per il tempo di compilazione ... zzz ... .

root@darkstar:/xen-3.1.0-src# make DESTDIR=”/tmp/package-xen-kernel-dom0” linux-2.6-xen0.install

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.

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

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.

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

Ora nella directory /tmp ci ritroviamo I pacchetti tgz pronti per essere installati con installpkg.

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
...
...

Installazione pacchetti Slackware

Procediamo all'installazione :

root@darkstar:/tmp# installpkg xen_*

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:

# 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

Al posto di hdb2 dovete mettere l'hd dove è installato xen. Nel mio caso è hdb2, ossia l'hd dove risiede linux.

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

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:

*************************************************************** 
*************************************************************** 
** 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)                           ** 
*************************************************************** 
***************************************************************

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.

root@darkstar:/tmp# getconf GNU_LIBPTHREAD_VERSION 
NPTL 2.5 
root@darkstar:/tmp# getconf GNU_LIBC_VERSION 
glibc 2.5

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.

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

nel mio sistema il cdrom è hdc, vedete qual è nel vostro e sostituitelo se necessario a hdc.

root@darkstar:/tmp/package-glibc-2.5# cp /mnt/cdrom/source/l/glibc .
root@darkstar:/tmp/package-glibc-2.5# vi glibc.SlackBuild

Nel file glibc.SlackBuild sostituite

CFLAGS="-g $OPTIMIZ" \

con:

#CFLAGS="-g $OPTIMIZ" \
CFLAGS="-g $OPTIMIZ -mno-tls-direct-seg-refs" \

Ora lanciate lo slackbuild e aspettate:

root@darkstar:/tmp/package-glibc-2.5# ./glibc.SlackBuild

...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 ):

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

ed infine eseguite ldconfig per linkare le nuove librerie.

root@darkstar:/glibc-tmp-af6454d73fa56f5e4d21015a706c3d68#  ldconfig

Passiamo ora a sysvinit. Scarichiamo i sorgenti dal cdrom :

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

...z...

root@darkstar:/tmp# cd ..
root@darkstar:/tmp# upgradepkg –reinstall sysvinit%sysvinit.tgz

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:

root@darkstar:/# xend start

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 ).

root@darkstar:/# xm list
Name                                      ID   Mem VCPUs      State   Time(s)
Domain-0                                   0   256     1      r-----    193.1
root@darkstar:/#

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.

root@darkstar:/# mkdir -p /vserver/images
root@darkstar:/# mkdir -p /vserver/mount
root@darkstar:/# cd /vserver/images

Qui creeremo due file grandi a piacere, uno per il sistema operativo virtuale della domU e uno per lo swap:

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

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:

root@darkstar:/vserver/images# mkfs.ext3 vm01.img
root@darkstar:/vserver/images# mkswap vm01-swap.img

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 :

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

ed eseguite nell'ordine :

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

Ora montiamo la vm01:

root@darkstar:/vserver# mount -o loop images/vm01.img mount/

e installiamo la debian ( per questo è necessaria una connessione a internet ).

root@darkstar:/vserver# debootstrap --verbose --arch i386 etch mount/debian-4/ http://ftp.de.debian.org/debian

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:

root@darkstar:/vserver# chroot mount/ /bin/bash

Ora siamo nella debian. Editiamo il nostro source.list come segue :

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

Quindi eseguite:

darkstar:/# apt-get update

e installate quello che volete e torniamo nel nostro sistema digitando:

darkstar:/# exit

Ora siamo di nuovo nella Slackware. Creiamo quindi un file relativo alla vm01 nella directory /etc/xen:

root@darkstar:/vserver# cd /etc/xen
root@darkstar:/etc/xen# touch vm01-config.sxp

ed editiamolo. Di seguito potete vedere come ho settato il mio:

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'

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:

root@darkstar:/# xm create /etc/xen/vm01-config.sxp
Using config file "/etc/xen/vm01-config.sxp".
Started domain vm01

Lanciando:

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

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 :

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:

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 :

root@darkstar:/etc/xen# xm shutdown vm01

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

pedro