oVirt 3.6 e le proposte per oVirt 4 al meetup di Milano

Giovedì 19 novembre ha avuto luogo il primo meetup italiano di oVirt. Subito dopo l'arrivo dei partecipanti, Sandro Bonazzola (Integration team lead di oVirt e RHEV) ha fatto gli onori di casa con una presentazione della community di oVirt; una community che funziona molto bene, come dimostrano le statistiche sul numero di utenti attivi di users@ovirt.org, il tempo medio di riposta alle richieste e il numero di messaggi che ricevono attenzione. Per approfondire i dettagli della presentazione vi invito a scaricare il documento (reperibile qui).

Dopo l'introduzione, alla quale ha partecipato in videoconferenza anche Mikey Ariel (Community lead di oVirt), è stata la volta dei festeggiamenti per la tanto attesa nuova release 3.6. Gli sviluppatori ci hanno raccontato gli sforzi profusi e le difficoltà incontrate durante il percorso. Dunque è stata la volta di torta e spumante.

La seconda parte del meetup è stata interamente dedicata alle proposte della community per la futura nuova major release, oVirt 4.0. Ne sono scaturiti desideri, riflessioni ed esigenze concrete provenienti dal mondo enterprise che, si sa, è il vero feedback di valore per gli sviluppatori. Possiamo qui riassumere alcune delle proposte avanzate per il prossimo futuro rilascio:

• [container] convergenza tra oVirt Node e Atomic Host: anziché sviluppare autonomamente un sistema operativo minimale, partire dal progetto Atomic e creare una variante con gluster, qemu, libvirt, vdsm e tutto quello che serve ad oVirt Node. In questo modo si diminuirebbe sensibilmente il carico di lavoro e si potrebbero sfruttare tutte le potenzialità di Atomic legate ai container (vedi punto successivo).
• [container] creazione e gestione dei container: dal momento che libvirt già supporta i container LXC, aggiungere un nuovo cluster type in modo da poter sfruttare l'integrazione con Docker/Kubernetes già presente in Atomic. Inizialmente sarebbe sufficiente poter creare i container per poi, in futuro, lavorare sulla migrazione dei processi tra un host e l'altro.
• [container] modalità VDSM_remote: così come avviene nel mondo HA cluster, aggiungere la possibilità di affiliare VM guest come nodi VDSM per i container, escludendo sostanzialmente il power management e tutto quello che riguarda il bare metal;
• [gluster] oVirt Node come storage appliance (Samba/CTDB/Ganesha): aggiungere all'oVirt Node funzioni avanzate di storage e inserire nell'Engine la configurazione automatica dei nodi in questo senso. GlusterFS già supporta Samba (liscio o clusterizzato con CTDB) ed NFS Ganesha; rimarrebbe quindi da integrare un provisioning della configurazione come avviene nelle più diffuse soluzioni NAS commerciali (funzionalità NetApp killer, come dice qualcuno).
• [network] supporto diretto ad Open vSwitch: ad oggi l'unico modo per dialogare con Open vSwitch è attraverso il provider esterno di Neutron. Sarebbe molto meglio avere OVS installato sui nodi e gestirlo direttamente attraverso la gestione delle network dell'engine; questo abiliterebbe gli utenti alla creazione di particolari topologie di rete ad oggi ottenibili in oVirt solo attraverso macchinose (e a volte pericolose) combinazioni di VLAN e vNIC secondarie sulle VM.

Questo è solo un estratto del lavoro svolto al meetup; vi invito a leggere la lista completa delle proposte, minuziosamente catalogate da Giuseppe Ragusa sulla mailing list, ordinate per oVirt Node, oVirt Engine e VDSM.

Un saluto da parte mia. Non dimenticatevi di iscrivervi alla nostra community italiana!

È uscito oVirt 3.6: tutte le novità

È finalmente stata rilasciata la versione finale di oVirt 3.6. È un traguardo molto importante per una suite che mira ad essere la migliore alternativa a VMware vSphere. In questa versione troviamo tante novità tra cui la possibilità di utilizzare FibreChannel o Gluster come backend per il Self-Hosted Engine (la modalità che permette di far girare l'engine su di una VM ospitata da un nodo di oVirt stesso). Inoltre troviamo un'integrazione sperimentale a Glance e Cinder attraverso Docker, il supporto ai nodi Debian e la nuova VirtIO Serial Console.

Cosa c'è di nuovo in oVirt 3.6?

• il Self-Hosted supporta FibreChannel e Gluster. Fino ad ora era possibile utilizzare solo NFS come storage backend del Self-Hosted Engine. Se da una parte NFS è sicuramente la soluzione di storage condiviso più veloce da implementare, dall'altra poneva diversi problemi di affidabilità, creando di fatto un single point of failure. Con Gluster e FiberChannel possiamo ora scegliere tra due importanti soluzioni che oVirt già da tempo supporta come storage per le VM.
• VirtIO Serial Console. Ora è possibile accedere alla console delle VM tramite un gateway SSH, senza dover passare dall'engine attraverso il browser.
• migliorata la gestione degli Affinity Rules. Tramite l'innovativo algoritmo UAV (Unified Affinity Group) ora i cluster vengono controllati periodicamente per risolvere eventuali conflitti e, in caso, migrare le VM.
  
• supporto per Fedora 22. È stato aggiunta la possibilità di usare Fedora 22 sia sia come distribuzione per l'engine, sia come distribuzione per l'host (nodo).
  
• [sperimentale] supporto per Debian. Ora è possibile utilizzare Debian come host di oVirt.
  
• [sperimentale] integrazione di Cinder e Glance attraverso Docker. I servizi Glance e Cinder sono ora disponibili come immagini Docker, installabili direttamente dall'engine-setup di oVirt. Le immagini sono fornite direttamente dal progetto Kolla così come altri container utilissimi per lavorare con OpenStack.

Potete trovare le note di rilascio e la lista completa delle funzionalità della versione 3.6 sul sito di oVirt.

Il gruppo di oVirt Italia sta preparando una guida di installazione di oVirt completamente in italiano! Tornate a trovarci presto e, se non l'avete ancora fatto, fatto un salto nella nostra community per tenervi aggiornati.