I followed the instructions in the official Xen wiki. Since i’m using Xen 3.4 and HVM, the only option available (according to the wiki) was to use the qemu-dm emulation/passthrough. So i’ve retrieved the vendorId and productId of my printer, using lsusb and modified the configuration file of my virtual machine as explained in the documentation.

Everything seemed to work, but when i powered off the printer and then powered it on again, the domU wasn’t able to “see” it anymore. This is very annoying since i don’t want to leave it powered on all the time. To re-add the printer to the domU while it’s running i discovered that i can use the command xm usb-add. The problem now was to find an automatic way to run this command when the printer is powered on/off or disconnected/reconnected.

The idea was to use udev. So i wrote a very simple rule that runs a script when the printer is powered off/on (or disconnected/reconnected).
I created the file /lib/udev/rules.d/96-printer.rules:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", RUN+="/etc/xen/scripts/printer"

Where xxxx and yyyy are the values retrieved from lsusb as explained in the xen instructions. Then i created the file /etc/xen/scripts/printer:

#!/bin/bash
/usr/sbin/xm usb-add domain host:xxxx:yyyy

That simply runs the usb-add command to re-add the printer to my domU (of course you must replace domain with the name of your domU and add the execution permission to the script).

No, non è uno scherzo.
Consigli sulla scelta di una “buona” password, sul sito Fineco

In ogni caso per installare Xen per prima cosa ho dovuto compilare manualmente un kernel adeguato. Esistono fondamentalmente 3 scelte:

1. Far compilare il kernel direttamente dal pacchetto di Xen (scaricabile dal sito ufficile). In questo caso però si tratta di una versione abbastanza vecchia, 2.6.18.
2. Scaricare un kernel vanilla ed applicare delle patch.
3. Utilizzare un kernel, ancora in versione di sviluppo, con paravit_ops.

Ho scelto l’opzione 2 e, dopo aver patchato e compilato manualmente il kernel, ho cercato invano il tradizionale file di Grub per farlo partire al boot. Con la nuova versione del bootloader però le cose sono cambiate ed i file sono differenti. Nello specifico il file di configurazione è /boot/grub/grub.cfg, anche se non è consigliato editarlo in quanto viene auto-generato a partire da altri file.

Anche la sintassi del file è cambiata però. In particolare per Xen ora bisogna utilizzare la parola ‘multiboot’, al posto della vecchia ‘kernel’. L’entry finale risulta quindi simile alla seguente:

menuentry "Xen 2.6.31.5" {
    .....
    multiboot /xen-3.4.gz dom0_mem=512M
    module    /vmlinuz-2.6.31.5 root=/dev/mapper/main-root ro
    module    /initrd.img-2.6.31.5
}

In particolare ora si utilizza la keywork ‘multiboot’ invece di ‘kernel’.

In ogni caso però una configurazione di questo tipo non ha avuto successo: il kernel parte ma presenta degli errori durante il montaggio della partizione root. Il problema deriva dal fatto che le opzioni non vengono passate al kernel (in particolare root=/dev/…). Questo poiché esistono ancora dei problemi in GRUB2 con la modalità multiboot.

La (bruttissima) soluzione è stata quella di ricompilare il kernel direttamente con le opzioni da passare. Questa tecnica si adotta in genere nei sistemi embedded, per passare sempre delle opzioni di default. In ogni caso, impostando come command line options appunto “root=/dev…. ro” (nel mio caso) il problema si risolve. Naturalmente se volessimo passare un’altra opzione al kernel sarebbe necessario ricompilarlo!

In aggiunta a quanto detto, naturalmente, è necessario compilare manualmente anche xen (nel caso si voglia utilizzare l’ultima versione 3.4, in quanto nei repository si trova la 3.3). Questo processo però non presenta particolari problemi.

In conclusione quindi l’installazione di Xen non è stata affatto semplice, in particolare stupisce l’inclusione in una versione server di ubuntu di un pacchetto (GRUB2 appunto) ancora in beta, con evidenti problemi.

Nell’ambiente desktop è molto utile per utilizzare altri sistemi operativi quando necessario. E’ possibile quindi, ad esempio, lanciare un applicativo disponibile solo per Windows su un sistema Linux oppure provare uno o più software senza dover installare e configurare nulla (scaricando direttamente una Virtual appliance). In questo segmento i software disponibili sono diversi, tra i più noti sicuramente VMware Workstation e VirtualBox.

La virtualizzazione è però usatissima anche in ambito server. In questo caso l’utilizzo però è un po’ diverso. Tipicamente infatti l’obiettivo è quello di minimizzare i costi e si cerca di usare un numero limitato di macchine fisiche, sulle quali si fanno girare diverse macchine virtuali. In questo modo si riescono ad avere delle macchine apparentemente separate (con tutti i relativi vantaggi come l’indipendenza, la possibilità di reinstallazioni, di gestione da parte di utenti separati, ecc) ma che in realtà condividono lo stesso hardware. Anche qui esistono diverse soluzioni, tra le quali sicuramente Xen e VMware Server.

In una tipica configurazione da data center quindi si avranno molte macchine virtuali installati su una stessa macchina fisica. Naturalmente però sarà necessario installare prima un sistema operativo sulla macchina, sul quale andrà poi installato un software di virtualizzazione (e.g. Xen) e quindi le varie macchine virtuali. L’utilità del sistema operativo in questo caso è quindi molto limitata (far girare il software di virtualizzazione).

Un’altra categoria che sta emergendo è dunque quella delle architetture cosiddette “bare-metal” (ovvero mero metallo). L’idea è quella di sbarazzarsi del sistema operativo tradizionale, ed avere invece una soluzione integrata formata da un mini sistema operativo e dal software di virtualizzazione. In questo caso quindi la macchina fisica ha il solo scopo di eseguire le macchine virtuali e non necessita praticamente di quasi alcuna configurazione/installazione. Tra i prodotti di questo tipo ci sono VMware ESXi e XenServer.

Il futuro, almeno nel campo dei datacenter, sembra dunque abbastanza delineato. E’ probabile infatti che nei prossimi anni domineranno le soluzioni dell’ultimo tipo e le macchine diventeranno veramente del semplice hardware al pari di una lampadina, sostituibili da un addetto che non sa nulla di informatica (la funzione di Live Migration è già un importante passo in questa direzione).

Le novità sono davvero moltissime, potete trovare varie informazioni qui e sul comunicato ufficiale del rilascio.

Una delle novità più significative, specie per gli utenti Mac, è l’update di SWT (il componente utilizzato per la GUI). Infatti finalmente è supportata la piattaforma Cocoa, utilizzata da OS X. Si risolvono quindi i problemi che avevo già evidenziato in un precedente post, ovvero la possiblità di utilizzare Java 6 a 64bit per lanciare Eclipse. Inoltre con l’utilizzo di Cocoa il look dell’interfaccia è sicuramente migliorato e si integra ora perfettamente con il sistema operativo.

Degno di nota anche la nuova versione del sistema per l’installazione e la gestione dei plug-in. La nuova finestra ora è sicuramente più chiara e meglio organizzata.

Tra le altre novità interessante l’aggiornamento al compare editor, che si utilizza per confrontare differenti versioni di un file (tipicamente quando si effettua una sincronizzazione con un repository). Questo componente è stato infatti migliorato, in maneira da consentire una più semplice modifica del file direttamente nel compare editor, evitando quindi di dover tornare al workspace.

Nel complesso quindi una release sicuramente positiva. Cosa non va? A mio parere una grave mancanza è il supporto ad SVN. Questo sistemo di controllo di versione è sicuramente tra i più utilizzati al mondo e non è possibile che non sia incluso in un IDE come Eclipse. A tal proposito è aperto un bug dal lontano 2003. In realtà subversive è incluso in Galileo, ma non lo è un connector che consenta la comunicazione con SVN. Per l’utente finale la situazione dunque non cambia molto: è sempre necessario installare separatamente un plug-in.

A volte è utile saltare alcuni test, in base a certe condizioni. Per esempio si potrebbe avere un test che abbia senso solamente su piattaforma Linux. Per realizzare questo comportamente si posso utilizzare i metodi del tipo assume. Quindi ad esempio assumeTrue( condition) eseguirà il test solamente se condition è verificata.

Un altro tool molto utile è EMMA, che si occupa di “copertura di codice”. Per chi utilizza Eclipse esiste poi il relativo plugin EclEmma. Queste librerie si occupano di analizzare l’esecuzione di codice Java, in maniera da identificare quali linee vengono effetivamente eseguite. In questo modo è possibile, ad esempio, avere una idea di quanto un processo di testing sia comprensivo, identificando le aree del programma testate e quelle rimaste invece “scoperte”. L’analisi di copertura del codice può avere anche molti altri usi, ad esempio per effettuare un veloce “debugging” in alcune situazioni. Si può infatti scoprire in maniera molto rapida se in un comando condizionale venga seguito il ramo “if” o quello “else”, ecc.

Un ultimo tool, questa volta disponibile solamente per l’IDE Eclipse fa parte del progetto TPTP (Test & Performance Tools Project) e si occupa del profiling di programmi. In maniera molto intuitiva è possibile effettuare diverse analisi nell’esecuzione di codice. In particolare si possono scovare le parti di codice che rallentano l’esecuzione, studiando i tempi impiegati durante una esecuzione a partire dal livello di package e restringendosi via via fino al singolo metodo. Per tutte le informazioni si rimanda alla guida ufficiale o ad uno dei vari screencast.

A quanto pare (e per la delusione di molti) le closures non saranno incluse in questa release. Qui potete trovare una lista (non ufficiale) con le features che probabilmente verranno incluse o meno, con molti link alle relative discussioni. Oltre al nuovo garbage collector od ai superpackage (ora modules), una cosa abbastanza interessante è la presenza di nuove classi per gestire la concorrenza. Al package java.util.concurrent (presente già da Java 5) vengono infatti aggiunte nuove classi. Una serie di esse realizza un sistema di decomposizione fork-join.

L’idea è quella di dividere il problema in unità più picoole, da svolgersi in parallelo, per poi comporre i risultati. Non si tratta di nulla di nuovo, ma di tradizionali tecniche per aumentare il parallelismo (in particolare nell’ottica dell’aumento dei core nei processori). In dettaglio sono state create le classi ForkJoinPool e ForkJoinTask. Idealmente la seconda rappresenta un task da eseguire, mentre la prima un insieme di tali task. Ad esempio, nell’ordinamento tramite mergesort, si avrà un task per ogni sottoporzione da ordinare in parallelo. Naturalmente la questione è molto più articolata, per una spiegazione approfondita si rimanda quindi alle numerose risorse presenti in rete.

E’ quello che mi è capitato ad esempio oggi, aggiornando il mail server (per la cronica Courier). Nella nuova versione, infatti, era stato modificato un parametro per la gestione di SSL. Mantenendo il vecchio file di configurazione, il risultato è stato il mancato funzionamento del mail server, che restituiva un errore quando si tentava di collegarsi:

“couriertls: accept: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number”

Per risolvere il problema ho quindi scaricato dal sito ufficiale l’archivio con la versione appena installata, alla ricerca dei file di configurazione “originali”.
A quel punto, trovate le differenze rilevanti, ho provveduto ad aggiornare i file di configurazione “vecchi”.
C’è naturalmente da dire che in molte distribuzioni, quando si aggiorna un pacchetto, viene notificato il fatto che i file di configurazione sono cambiati, proponendo in genere la possibilità di confrontarli con quelli attuali. Va però detto che l’operazione è abbastanza macchinosa, specie se la configurazione riguarda più file, magari molto lunghi!