QEMU Live, versione alpha in testing!

Qualche giorno fa ho cominciato a distribuire (a chi lo ha richiesto, e ai contatti che conosco) l'accesso ad una "versione alpha" del suddetto accrocco[1]. Lo scopo è fixare i bug che rimangono e riuscire a completare gli script almeno fino ad un 75% per poi passare ad una beta pubblica o semi-pubblica: alcune parti infatti non sono ancora del tutto implementate, altre soffrono di problemi noti e stra-noti.

Nonostante tutto però, devo dire che sia io che gli "alpha-tester" siamo abbastanza soddisfatti di questa web application. Non resta che ultimare il tutto per la versione beta ;-)

[1]: http://lists.linux.it/pipermail/latina/2009-July/009665.html

Enrico

QEMU Live, riparte la sua corsa

Dunque, recentemente nella mailing list del LUG di Latina è stato segnalata la presenza su ibiblo.org di una directory con le vecchie distribuzioni Linux. Preso da un forte senso di "nostalgia" (pur non avendole mai provate), ho deciso che saranno il punto di partenza per il betatesting del progetto :-D

Ora sto cercando di installarne qualcuna così da metterla nella lista di QEMU Live, successivamente darò il link ad un numero ristretto di persone per fare delle prove.

Enrico

QEMU Live 2, la vendetta

Dunque, dopo aver sviluppato QEMU Live un bel po', sono giunto a conclusione che dare la possibilità a PHP di lanciare alcuni script (con tutte le limitazioni del caso) e comunque di gestire tutto, non era il caso (anche se era il sistema più semplice), anche perché andiamo a minare la scalabilità di tale sistema (in un ipotetico sistema con un load balancing, sarà un reverse proxy o un DNS a dover bilanciare il carico, cosa che invece vorrei evitare - non tutti hanno voglia/tempo/denaro per qualcosa del genere). Ho deciso dunque di ridisegnare "QEMU Live" da zero.

La nuova "appliance" sarà formata da due componenti principali: il "controller" e l'esecutore (un po' come la tecnica Model-View-Controller, anche se non è che mi vada molto a genio...): ci sarà una applicazione "server" che gestirà firewall e macchine virtuali, e ci sarà una web application che farà da front-end per gli utenti. Le due "applicazioni" comunicheranno attraverso socket (di rete, altrimenti se avessi usato socket UNIX avrei perso la portabilità sotto Windows, anche se non escludo di metterlo nel file di configurazione insieme ai path dei vari programmi).

In questo modo, stabilendo un "protocollo" di comunicazione, sia il front-end sia il back-end possono essere scritti in linguaggi diversi, possono essere su diverse piattaforme. Inoltre il front-end può integrare del codice per il load balancing.

Per ora sto sviluppando il "demone" di back-end. Appena avrò finito di capire come fare la maggior parte delle cose, scriverò quattro righe su questo "protocollo" e poi comincierò ad implementarlo nel server. Successivamente farò lo stesso nel client. Il demone lo sto scrivendo in Java (vorrei farlo portabile) mentre l'interfaccia web la vorrei sviluppare in PHP. Ma nulla vieta di cambiare e/o di fare diverse versioni delle suddette in futuro (dotNet .aspx per IIS, JSP, ecc.)

Inoltre con la fine della scuola spero di avere più tempo anche per scrivere sul Blog ;-)

Enrico

QEMU Live va avanti

Il progetto QEMU Live sta andando avanti: ho inserito il famoso logging, sto testando l'autokill e sto sviluppando un mini-applicativo d'appoggio per il firewall. Ho anche una bozza di modifica al client VNC per fare in modo di sincronizzare il puntatore del client e della macchina virtuale, solo che devo trovare il tempo di applicarla al suddetto webclient in java.

Se qualcuno ha intenzione di collaborare, mi contatti ;-)

Enrico

Progetto QEMU Live

In un tempo molto lontano, Fabrice Bellard disse "qemu", e qemu fu. Poi disse "kqemu", e kqemu fu. Poi la gente si incacchiò nera perché kqemu non era open, e fu open. E poi venne l'Idea.

L'Idea, di Renzo Davoli, era quella di creare uno zoo di sistemi operativi. Difatti il progetto si chiama "Free Os Zoo", ed è un wiki dove è possibile scaricare immagini già installate di diversi sistemi operativi (ovviamente dove la licenza lo permette). Una "sezione" speciale si chiama "Live Os Zoo", che permette di prendere qualcuna di queste immagini e farle partire da remoto: una applet java (client vnc) ci farà vedere qemu da remoto.

Ora, nonostante il progetto non sembri morto, è un sacco di tempo che il server di Live Os Zoo non torna su, e che il loro blog non si aggiorna. Ergo, preso da una mania di scripting, mi sono messo a ricreare il sistema come me lo ricordavo, e come mi piacerebbe, e l'ho chiamato fantasticamente (e temporaneamente) "QEMU Live".

E' ancora in sviluppo, anche se per ora funziona (l'immagine si lancia, posso utilizzarla, la posso "uccidere"), ma ci sono numerosi bugs:

• Tutti possono vedere la macchina lanciata da tutti (nessuna regola sul firewall e nessun filtro). E' nella lista delle cose da fare :-D
  
• Il traffico VNC è inviato non criptato su internet, quindi qualcuno potrebbe intercettare i dati.
• Tutte le modifiche che si fanno nel sistema operativo andranno perdute quando si spegne (e forse rimane così).
  
• La rete nei sistemi virtualizzati NON funziona. This is in ToDo list ;-)
• I puntatori dei mouse del guest e dell'host non sono sincronizzati. Anche questo è nella lista delle cose da fare (diciamo che il programma c'è, devo solo capire come integrarlo nella java applet).
  

E queste invece sono le cose che vorrei fare (la ToDo List):

• IP Logging (eh si, ancora non c'è)
  
• Auto-kill dopo X ore (per tuti) oppure X minuti per quelle istanze di qemu senza connessione associata (qualcosa c'è)
  
• Solo l'IP che ha lanciato l'immagine la può "uccidere"
• Filtri sul firewall per l'accesso VNC
• Crittazione sessione VNC
• Sincronizzazione puntatori VNC (guest e host). (qualcosa c'è, ma è da adattare, vedi su)
  
• Remote networking (VPN or VDE)
• Implementare più opzioni da passare a qemu nel file di config del sistema operativo.
• Image-to-image networking
• Pagine di amministrazione
• Source code and scripts release (ovvero, download e reinstall)
  

Quando sarà a buon punto creerò una pagina web e darò la possibilità a tutti di scaricare i sorgenti degli script. Per ora, è sul mio server casalingo, e inaccessibile da fuori (per ovvi motivi, no security) ma se qualcuno volesse collaborare e/o volesse qualche informazione a riguardo, mi può contattare ;-)

Enrico

Virtualizzazione: Processor emulators VS hypervisors

Virtualizzazione. Scritta così, può significare tante cose. Vediamo di spiegare i diversi tipi di "virtualizzazione".

Generalmente con virtualizzazione in ambito SOHO si intende l'operazione di avviare, in un sistema "host" già avviato, un kernel con i relativi tools (generalmente un sistema operativo) come se fosse "un processo". Gli viene assegnato un quantitativo di memoria, eventualmente un certo "tempo di processore" (ovvero quanta potenza del processore può usare), le varie schede, ecc. L'hardware della macchina virtualizzata quindi dipende solo per una minima parte (anche se importante) dal sistema reale: solo il processore e le memorie (disco e RAM) sono effettivamente una parte di quelle reali: eventuali schede o periferiche aggiuntive possono essere completamente virtuali (più schede di rete, più lettori cdrom). Questo permette, ad esempio, di avere a portata di mano un sistema operativo "diverso" che si usa per una sola applicazione che non funziona con il sistema usato nella macchina reale (pensiamo ad esempio ad un'applicazione scritta per Windows: si può far girare in una macchina virtuale sotto Linux, o viceversa). Questo è quello che si chiama "virtualizzazione completa", ovvero l'emulazione completa (o quasi) dell'intero sistema "guest". Un esempio di prodotti di questo genere sono qemu, VirtualBox, VirtualPC, VMware Workstation/Player, ecc.)

Esiste anche un altro tipo di virtualizzazione, chiamata paravirtualizzazione, presente soprattutto in ambito Enterprise (o semi-Enterprise). Questo tipo particolare di virtualizzazione, al contrario di quella "completa", non emula il "sistema virtuale", ma bensì divide le risorse del sistema reale tra più kernel/sistemi operativi, mediante un kernel che gira "al di sopra delle parti", chiamato Hypervisor (supervisore appunto). Questo Hypervisor, a seconda delle configurazioni, farà girare con più o meno priorità i vari sistemi operativi avviati.
Di solito, un Hypervisor ha bisogno di un sistema di controllo: facendo l'esempio di Xen, c'è una macchina GNU/Linux avviata con "priorità alta", in grado di controllare e di fornire delle impostazioni al kernel supervisore. Questo di fatto vuol dire che ci sarà una macchina virtuale che, per forza di cose, avrà come scopo quello di interfacciarsi con il supervisore, e di solito è chi progetta l'Hypervisor che stabilisce quale può essere il sistema operativo da utilizzare (GNU/Linux, Windows, Mac OS X, ecc.).
Alcuni sistemi inoltre sono in grado di spostare le macchine virtuali accese "al volo", con un downtime di circa 300 ms al massimo, cioò vuol dire che per l'utente la differenza non esiste. Le connessioni non vengono resettate, quindi ogni trasferimento di dati (sessione terminale remota ad esempio) continuerà senza alcun rallentamento visibile o downtime.
Un esempio di tali soluzioni sono: Xen, Microsoft HyperV, VMware ESX.

Ma quali sono i vantaggi di una o dell'altra soluzione? Certo, la virtualizzazione completa ci da un controllo maggiore del sistema guest, poiché possiamo personalizzarlo pressoché totalmente e possiamo applicargli limitazioni tipiche di un processo (in ambito UNIX ad esempio), mentre in un sistema dove l'ipervisore, solo se tale software è stato progettato per lo scopo si riesce a limitare l'uso delle macchine virtuali ad un certo "tot" di tempo di CPU. I vantaggi sono visibili tuttavia in campo "prestazionale": non c'è dubbio che, dovendo passare per un programma che simula un processore, il sistema rallenti, cosa che non succede se il processo/sistema operativo viene eseguito direttamente nel processore "reale" (in condivisione con altri processi).

Possiamo quindi desumere che, dove le prestazioni e la ridondanza sono importanti (in ambito aziendale), soluzioni di virtualizzazione che puntano a maggiori prestazioni, uniti alla possibilità di migrare in tempo reale le macchine virtuali da un server ad un altro (per permettere ad esempio manutenzioni programmate), sono la scelta migliore. Per gli sviluppatori, gli "smanettoni", soluzioni di virtualizzazione completa possono essere la scelta migliore, poiché incidono poco sul sistema "ospitante", permettendo un'elevata possibilità di configurazione nel sistema "ospitato".

Enrico