= 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