Archivi tag: kvm

OpenStack – Introduzione

OpenStack Cloud Software

OPENSTACK – PARTE PRIMA

Si parla molto di OpenStack e delle sue applicazioni. Ma che cos’è davvero, perché è stato sviluppato e quali sono i suoi vantaggi?

Che cos’è?
OpenStack è un sistema operativo per il cloud computing in grado di controllare componenti di storage, networking e computing. È open source e gratuito, di solito è installato sotto forma di soluzione IaaS. OpenStack fornisce un insieme di strumenti che servono a costruire e gestire piattaforme cloud sia pubbliche sia private. Permette agli utenti di installare macchine virtuali e si può accedere al codice sorgente per modificarlo in qualsiasi modo sia utile per gli scopi specifici del progetto.

Chi lo ha sviluppato?
Nel 2010 Rackspace e la NASA hanno collaborato a un progetto congiunto che è poi diventato OpenStack. Il codice iniziale è stato usato per Nebula, la piattaforma cloud della NASA, poi il progetto si è dato l’obiettivo più ampio di aiutare le aziende a far girare software cloud su hardware standard.

Chi lo usa?
Tra i vendor, alcuni dei nomi più importanti che attualmente supportano e distribuiscono OpenStack sono Canonical, Cisco, EMC, HP, Huawei, IBM, Oracle, Google e Red Hat. Tra gli utenti attuali ci sono Bloomberg, Comcast, PayPal e Wells Fargo. Ci sono incontri internazionali periodici su OpenStack – gli OpenStack Summit – in tutto il mondo, che raccolgono programmatori e utenti della piattaforma.

E’ quindi ormai innegabile l’interesse che tutto il mondo IT ha riservato in questi ultimi anni ad OpenStack.

Qual’è la ragione di tutto questo?

L’ormai tradizionale paradigma client-server, in progetti in cui la scalabilità e le finestre di picchi di carico sono variabili essenziali all’interno dell’equazione della produttività, presenta oggi giorno evidenti limiti di gestione dei carichi e della velocita’ di evoluzione dei progetti. Ecco quindi nascere l’esigenza di uno strumento che fosse flessibile ed allo stesso momento affidabile.

Questo concetto spiega quindi le motivazioni che possono spingere ad adottare una piattaforma cloud, ma perché fra tutte le piattaforme esistenti si parla sempre di OpenStack?

OpenStack è un progetto aperto
La sua natura aperta ha fatto sì che tutti i vendor interessati all’introduzione di specifiche funzionalità o determinati ambiti potessero contribuire in maniera attiva e funzionale al progetto, innescando un circolo virtuoso in cui ogni miglioramento apportato per favorire se stessi va a beneficio della comunità.

La sua natura aperta fa sì che chi adotta OpenStack per il proprio ambiente cloud è di fatto esente dal cosiddetto vendor lock-in, ossia l’essere vincolato ad un rivenditore specifico per le proprie tecnologie. Infatti se lo standard OpenStack è garantito, ogni venditore potrà essere valutato in modo paritetico a tutti gli altri, rendendo così il mercato più competitivo e conveniente per il cliente finale.

I presupposti di un progetto OpenStack

Bisogna subito tenere presente che “non tutti i progetti sono adatti al cloud“, nonostante cio che viene erroneamente interpretato leggendo in giro per il web, infatti questo principio sfugge a molti che guardano verso le nuvole vedono unicamente un posto differente da cui erogare i propri servizi. Esistono dei requisiti da tenere presente per capire se un progetto è adatto al cloud.

Un progetto OpenStack quindi deve essere:

** Non persistente: non deve basarsi sulla persistenza dei dati all’interno delle macchine coinvolte. Questo aspetto non va confuso con l’esigenza di avere uno storage solido e sicuro, si tratta invece di non giudicare le istanze che concorrono al progetto come perenni, ma come componenti utili al loro scopo e liberamente sacrificabili;

** Scalabile: deve supportare applicazioni che nativamente siano in grado di scalare. L’applicazione nasce già dallo sviluppo come pensata per il cloud;

** Dinamico: a fronte di un innalzamento delle richieste ricevute il progetto deve essere in grado in maniera autonoma di gestire le nuove componenti. Gli interventi manuali successivi all’implementazione sulle istanze coinvolte devono essere inesistenti;

** Rapido: deve essere passibile di provisioning, favorendo la velocità di creazione (e distruzione) di nuove istanze;

Se il vostro progetto risponde a questi requisiti messi in evidenza qui sopra, allora potete pensare ad integrare OpenStack ed è giunto quindi il momento di capire in cosa consiste.

Le componenti di OpenStack

La parola stack descrive un insieme di entità che concorrono ad uno scopo comune. OpenStack è composto da numerose elementi che devono comunicare fra loro, lo strato di comunicazione passa attraverso due filoni fondamentali: la memorizzazione delle informazioni e la coda delle azioni da svolgere. Queste due azioni sono coperte ciascuna da un elemento specifico:

MySQL

Il database MySQL è necessario per la memorizzazione delle informazioni di configurazione generali del sistema, per la memorizzazione delle informazioni di autenticazione relative a ciascun componente e per il mantenimento dinamico dello stato del sistema.
Ogni azione eseguita all’interno dell’infrastruttura OpenStack è tracciata all’interno del database. L’importanza di questa componente è evidentemente capitale.

RabbitMQ

RabbitMQ è uno scheduler, un software didicato alla gestione delle code ed all’organizzazione delle sequenze di operazioni. Tutti i nodi facenti parte dell’infrastruttura OpenStack comunicano con lo scheduler, ed anche in questo caso è presto spiegato come questa componente ricopra enorme importanza per il regolare funzionamento dell’ambiente.

Determinato quindi il sistema di circolazione e reperimento delle informazioni si può focalizzare l’attenzione sugli elementi peculiari di OpenStack, riassunti in questo diagramma che si trova sul sito ufficiale del progetto:

OpenStack Diagramma Software

                                                     OpenStack Diagramma Software

Keystone

Keystone è il software che gestisce il sistema di autenticazione di OpenStack. Il principio su cui si fonda è quello classico degli utenti e dei gruppi, ma di fatto si occupa di gestire le tre tipologie di utenti configurabili in OpenStack:

  • Cloud Provider Admins: ossia gli amministratori del sistema OpenStack;
  • Tenants: ossia i profili delle compagnie fruitrici dei servizi;
  • Users: ossia gli utenti delle compagnie fruitrici dei servizi;

Il concetto di “compagnia” si riferisce ad un sotto-ambiente interno alla stessa installazione di OpenStack. Applicato ad un provider esso potrebbe essere rappresentato dai clienti, mentre all’interno di un cloud privato potrebbe essere associato ad un dipartimento interno.

Glance

Glance si occupa del provisioning (ossia di fornire) delle immagini all’interno dell’ambiente. Questa componente fornisce un bacino di istanze gia preconfigurate, disponibili ai fruitori dei servizi, per effettuare il deploy (ossia la messa in produzione) dell’istanza desiderata all’interno del proprio ambiente.
Le immagini sono supportate nei formati KVM qcow, Aws, VMWare purché esista su queste un Master Boot Record.

Nova

Nova è il compute service, un servizio che permette di gestire i sistemi virtuali erogati all’interno dell’ambiente. All’interno della macchina definita controller il servizio nova-api guiderà l’avvio e la terminazione delle istanze comandando la sua controparte nova-compute, attiva su tutte le macchine hypervisor facenti parte della struttura OpenStack.
Le decisioni su dove e come le istanze dovranno essere avviata saranno gestite dal servizio nova-compute-service (basato su libvirt).

Horizon

Horizon è l’interfaccia web dalla quale è possibile controllare agevolmente le istanze in modalità point-and-click oltre che le immagini gestite da Glance. Il software Horizon è basato sul modulo wsgi del webserver Apache.

C’è ancora un’ultimo aspetto da tenere presente, come è deducibile dallo schema, lo storage.
In un setup base le macchine possono essere erogate direttamente dai dischi degli hypervisor, ma in ambienti di larga scala ciò potrebbe non essere auspicabile. In questi casi fare riferimento ad un gestore dello spazio centralizzato permetterebbe di utilizzare gli hypervisor come semplici erogatori, valorizzando la scalabilità generale del progetto, ed ecco dunque venirci in aiuto questo componente per la gestione dei volumi, Cinder.

Cinder

In origine parte del progetto Nova (chiamato nova-volume) e dal 2012 progetto a se stante, Cinder è il servizio che fornisce il block storage per le istanze, uno storage gestito e centralizzato che funziona da dispositivo a blocchi per le virtual machines. Le macchine virtuali risiedono quindi su un device dedicato, definito sulla base di quello che è la modalità con cui l’hypervisor ha accesso allo storage.
Cinder supporta diverse modalità per essere visto dagli hypervisors: è possibile infatti utilizzare dischi locali o sistemi storage esterni, quali NFS, FibreChannel, DRBD o iSCSI.

Swift

A differenza di Cinder, Swift è un servizio di storage online che si occupa di rendere disponibile spazio all’interno dell’ambiente OpenStack mediante la modalità object storage. I dati non vengono registrati direttamente su dispositivi a blocchi, ma preventivamente convertiti in oggetti binari, distribuiti all’interno di più device in modo da garantirne la massima accessibilità oltre che la replica.
Swift è compatibile con il servizio di storage Amazon S3 e funziona con lo stesso principio: fornire uno storage web accessibile e scalabile.

Conclusioni

In questa lunga introduzione sono stati illustrati filosofia, componenti e soprattutto potenzialità di OpenStack, ma sebbene la lettura possa essere apparsa lunga, questa tocca appena la superficie dell’universo relativo a questo grande progetto.
Nel prossimo articolo verrà avviato un piccolo studio di fattibilità vero e proprio con lo scopo di mettere su strada tutti i vari software che lo compongono ed iniziare cosi ad adoperare OpenStack.

CoreOS anche su Big G

CoreOS Cloud System

CoreOS Cloud System

Da meta’ Maggio la piattaforma di cloud IaaS di “Big G” è in grado di ospitare virtualizzazioni del sistema operativo CoreOS; tramite un annuncio sul blog del servizio è stata resa nota la disponibilità alla creazione di infrastrutture basate su questo sistema innovativo e che permetterà di realizzare infrastrutture in maniera semplice ed efficace.

Il progetto CoreOS è nato da due ingegneri di Rackspace, Alex Polvi e Brandon Philips, e da un ex dipendente Google, Michael Marineu: i tre hanno dato vita ad un sistema operativo dedicato alla tecnologia cloud, molto leggero nel consumo di risorse e in grado di attivare un cluster complesso in poco tempo grazie a degli strumenti di orchestrazione unici. I due componenti chiave di CoreOS si chiamano etcd e fleet: entrambi sono scritti nel linguaggio Go e servono ad alimentare rispettivamente le configurazioni del cluster e il deploy delle applicazioni tramite dei container Docker.

Google si allinea quindi a Amazon EC2, Rackspace Cloud e altri provider di infrastrutture cloud dove CoreOS è già selezionabile, il sistema operativo è già compatibile con OpenStack e KVM, aspettiamoci di vedere presto crescere le quote di mercato di questo prodotto possiamo ritenere che riempa il buco dei sistemi operativi dedicati al clouding.

 

#Coreoscloudcomputingsystem

Virtualizzazione e provisioning senza sforzo

Vagrant Virtualization Box

Vagrant Virtualization Box

La virtualizzazione ha sicuramente cambiato il modo di lavorare e di pensare alla gestione dei sistemi informatici aziendali o dei service provider, ed il cloud ha aggiunto un’ulteriore strato, sia di liberta’, ma anche di complicazione in piu’, nella gestione dei nuovi sistemi ad alta affidabilita’ che devono essere in grado di scalare nel minor tempo possibile ecc….

Queste esigenze hanno portato alla nascita di innumerevoli sistemi di virtualizzazione, tra i piu’ conosciuti sicuramente ci sono Xen, Vmware, Kvm, Virtuozzo, Virtualbox, Openvz …..! che per certi versi si trasformano in un incubo per gli amministratori di sistema, costretti ad avere diversi ambienti di gestione delle VM su diversi sistemi e con molteplici file di configurazione da settare.

Infatti quando ci troviamo ad amministrare un ambiente cloud con molte macchine, il rischio di dover aggiungere una macchina in più e doverla successivamente configurare in poco tempo per il deploy e la messa in produzione insieme a tutte le altre è molto alto. In più, se siamo all’interno di un’architettura che deve scalare rapidamente per rispondere in modo agile alle esigenze degli utenti (e chiaramente dell’azienda), dover attendere l’installazione del sistema operativo e poi del software non è certamente divertente. Per tutte queste esigenze, Vagrant potrebbe risultare la giusta soluzione che può semplificarci la vita, permettendoci di aggirare tutte queste “rogne”

Vagrant è un gestore di macchine virtuali che può usare parecchi hypervisor tra cui VirtualBox, il predefinito, ma anche VMWare, Xen e KVM. Attraverso questo software infatti potremo basarci su una struttura di base comune a tutte le macchine, che contiene il sistema operativo (anche se poi vedremo come personalizzare questa alberatura), e mantenere degli step comuni nella configurazione delle nostre istanze virtuali, per poi dedicarci solo alle rifiniture, risparmiando tantissimo tempo grazie alle capacità di elaborazione dei datacenter che abbiamo in-house o magari in cloud.

Per inizializzare il nostro primo progetto Vagrant, abbiamo solo bisogno di spostarci in una directory vuota e dare il comando (avendo già installato il software):

Installazione Vagrant

### Verificare di aver installati i seguenti pacchetti : rubygems ruby1.9.1-dev virtualbox-4.2 (o superiori)
# sudo apt-get install vagrant
# vagrant plugin install vagrant-vbguest

Le Box di Vagrant
Il primo concetto fondamentale da fare nostro, per quanto riguarda Vagrant, è quello del concetto di Box. Una Box per quanto riguarda questo ambiente di virtualizzazione infatti è una vera e propria scatola che contiene il sistema operativo, e tutto quello di cui abbiamo bisogno come i software di base ed ogni loro configurazione di base. Al punto di partenza abbiamo delle Box rese disponibili dai server di Vagrant, ma possiamo tranquillamente aggiungerne altre: tutto quello di cui abbiamo bisogno è un po’ di fantasia coi nomi, e di conoscere l’URL remoto tramite il quale scaricare la Box (ne trovate parecchie già fatte su Vagrantbox.es oppure su Hasicorp), con questa sintassi da riga di comando.

# vagrant init
# vagrant box add name url

che, traducendolo con un esempio reale:

# vagrant box add precise32 http://files.vagrantup.com/precise32.box

Che non farà altro che aggiungere al nostro progetto Vagrant una Box Ubuntu 12.04 a 32 bit.

Il Vagrantfile
Una volta scaricata la nostra Box di partenza, possiamo cominciare a configurare il nostro progetto Vagrant tramite il Vagrantfile che abbiamo a disposizione e che si presenta essenzialmente come un file Ruby con vari namespace, ma niente paura, non è necessario conoscere direttamente Ruby per la configurazione (anche se può aiutare), ed è possibile fare riferimento alla documentazione per conoscere i vari prefissi e le possibilità che abbiamo a disposizione. Ogni volta che eseguiamo un comando Vagrant, il Vagrantfile viene cercato in tutte le directory di livello superiore nell’albero.

Il file può avere grossomodo un aspetto del genere:

Esempio di un cluster di 7 Boxes. Preso da:
### https://github.com/patrickdlee/vagrant-examples

domain   = 'example.com'
 
nodes = [
  { :hostname => 'ex7proxy',   :ip => '192.168.0.42', :box => 'precise32' },
  { :hostname => 'ex7db',      :ip => '192.168.0.43', :box => 'precise32' },
  { :hostname => 'ex7web1',    :ip => '192.168.0.44', :box => 'precise32' },
  { :hostname => 'ex7web2',    :ip => '192.168.0.45', :box => 'precise32' },
  { :hostname => 'ex7static1', :ip => '192.168.0.46', :box => 'precise32' },
  { :hostname => 'ex7static2', :ip => '192.168.0.47', :box => 'precise32' },
  { :hostname => 'ex7cache',   :ip => '192.168.0.48', :box => 'precise32' },
]
 
Vagrant::Config.run do |config|
  nodes.each do |node|
    config.vm.define node[:hostname] do |node_config|
      node_config.vm.box = node[:box]
      node_config.vm.host_name = node[:hostname] + '.' + domain
      node_config.vm.network :hostonly, node[:ip]
 
      memory = node[:ram] ? node[:ram] : 256;
      node_config.vm.customize [
        'modifyvm', :id,
        '--name', node[:hostname],
        '--memory', memory.to_s
      ]
    end
  end
 
  config.vm.provision :puppet do |puppet|
    puppet.manifests_path = 'puppet/manifests'
    puppet.manifest_file = 'site.pp'
    puppet.module_path = 'puppet/modules'
  end
end

Prima di arrivare a questo livello tuttavia, è necessario cominciare dalle basi: il primo file di configurazione di Vagrant che andremo a scrivere conterrà ben poche specifiche, e si baserà esclusivamente sulla Box che abbiamo scelto per la nostra prima macchina virtuale.

# Una singola Box.
#
Vagrant.configure(“2”) do |config|
config.vm.box = “precise32”
end

Esempio per una singola Box.

Vagrant.configure("2") do |config|
config.vm.box = "precise32"
end

Inoltre il Vagrantfile deve essere soggetto a version control (tramite git ad esempio) per tenere traccia di ogni modifica e rendere il tutto facilmente riportabile in una nuova architettura

Avviamo la Box

# sudo vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'precise32'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Mounting shared folders...
[default] -- /vagrant

Adesso che abbiamo il nostro progetto funzionante, basterà dare

# vagrant ssh
Last login: Fri Apr 15 05:43:58 2011 from 10.0.2.2
[vagrant@localhost ~]$

per collegarci ed esserne subito operativi all’interno della nostra box.

Provisioning
Vagrant non è solo un sistema per avviare velocemente delle macchine virtuali, infatti ci permette anche di controllarle, e di controllarne le impostazioni nel tempo, insieme al software installato. Possiamo quindi gestire la configurazione automatica secondo le nostre esigenze delle varie Box che abbiamo, attraverso una struttura di provisioning abbastanza flessibile che supporta normali shell script (Bash), il buon vecchio Puppet, ma anche Chef e Ansible.

Tramite questa infrastruttura possiamo modificare il Vagrantfile per eseguire quindi qualsiasi istruzione, che sia configurata per script Puppet oppure attraverso Bash. Ad esempio, possiamo utilizzare la piccola struttura riportata di seguito, che proviene direttamente dalla documentazione di Vagrant e che mostra come sia facile scriversi uno script di configurazione da mandare poi in pasto alla propria Box.

$script = <<SCRIPT
echo I am provisioning...
date > /etc/vagrant_provisioned_at
SCRIPT
Vagrant.configure("2") do |config|
config.vm.provision "shell", inline: $script
end

Non solo VirtualBox

Una volta imparato a usare Vagrant, avremo comunque basato tutto il nostro lavoro su VirtualBox. Tuttavia, potremmo anche avere qualcosa in contrario sull’uso di VirtualBox, e voler usare altri provider che ci permettano un’amministrazione più efficace o semplicemente il riciclo di competenze che già abbiamo. Ad esempio, Vagrant supporta tramite plugin anche l’integrazione con VMWare o con Xen; questi plugin sono installabili attraverso il gestore integrato nel software, semplicemente tramite un singolo comando, esattamente come in un classico gestore di pacchetti:

# vagrant plugin install vagrant-vmware-fusion

Oppure se invece di VMWare Fusion usate la variante Workstation:

# vagrant plugin install vagrant-vmware-workstation

Una volta installato il plugin, ed ovviamente il software di providing delle macchine virtuali che vogliamo testare, ci bastera’ modificare il Vagrantfile, con istruzioni come queste nell’ esempio:

Esempio tratto da [ http://puppetlabs.com/blog/new-vmware-provider-gives-vagrant-a-boost ]

config.vm.provider :vmware_workstation do |v|
v.vmx["memsize"] = "2048"
end

Vagrant può ovviamente essere configurato per essere alla base di una complessa configurazione in ambiente cloud, o della propria infrastruttura più modesta.

Se questo primo articolo vi ha incuriositi, la documentazione ufficiale, passo passo, vi sta aspettando : VAGRANT DOC

Nel prossimo articolo vedremo come sfruttare le potenzialita’ di Vagrant + Docker.

#VagrantVirtualizzazioneeProvisioning

Proxmox Virtual Environment

 

 

logo_proxmoxProxmox VE è un software open source, ottimizzato per le prestazioni e l’usabilità a cui viene aggiunta´ anche la massima flessibilità, grazie alla possibilita` di utilizzo di ben due tecnologie di virtualizzazione – KVM (per la Full Virtualization) e OpenVZ (per la Paravirtualization).

Proxmox VE si basa su Debian 5 e non necessita di particolari prerequisiti software. Dal punto di vista hardware richiede i 64 Bit e c’è una ampia lista di hardware ufficialmente supportato.

Con Proxmox VE possiamo migrare phisical machine (PM) su virtual machine (VM) oppure VM su altre VM, possiamo inoltre aggiungere degli storage e gestire il backup delle macchine virtuali. Il Cluster di Proxmox VE ci permette anche di migrare VM tra nodi e di amministrare da un’unica console centrale i vari nodi e, le VM distribuite nei vari nodi.

New Virtual Environment 3.3

Il 15 Settembre 2014 Proxmox Server Solutions ha annunciato l’uscita  della versione 3.3 di Proxmox Virtual Environment (VE).
Questa versione e` molto interessante poiche’ aggiunge diverse novita’ , in particolare questa versione ha come focus la sicurezza dell’infrastruttura virtuale, e introduce tra le altre cose il Proxmox Ve Firewall e la doppia autenticazione (two-factor authentication).
E’ stata  implementata inoltre una console in HTML5, un plug-in per lo storage ZFS e un’interfaccia ottimizzata per l’utilizzo con il mobile, ovvero la Mobile touch interface.

Ma vediamo nel dettaglio in cosa consistono le principali novità:

Proxmox VE Firewall
E’ stato progettato per proteggere l’ infrastruttura IT, ed è completamente integrato nell’interfaccia web, permettendo cosi’ all’utente di creare regole per gli host, i cluster e le singole macchine virtuali e containers.  Per semplificare la gestione sono state introdotte macro, security groups, settaggi per IP e aliases.
La configurazione del firewall viene salvata a livello di cluster e le regole sono valide e applicate per tutti i nodi che compongono il cluster, permettendo l’isolamento completo  delle singole macchine virtuali.
Questo fa si che, al contrario delle soluzioni firewall centralizzate, Proxmox VE Firewall è un po’ piu’ dispendioso in termini di banda ma evita allo stesso tempo i single point of failure.

Two-factor authentication
Questa nuova feature aggiunge un’ ulteriore livello di sicurezza, introducendo una seconda fase di autenticazione per l’accesso all’interfaccia web amministrativa di Proxmox VE.
In aggiunta all’ inserimento del classico nome utente / password, viene utilizzata una one-time password (OTP) che sarà richiesta per ogni nuova sessione di login. Una volta generata rimarrà valida per 30 min (valore di default, modificabile a piacimento).

HTML5 Console 
E’ la nuova console di default di Proxmox VE, multi piattaforma (Windows/Linux/Osx), utilizzabile anche su piattaforme mobile e, sostituisce l’installazione del plug-in Java e dello Spice viewer.

Proxmox VE mobile
E’ una interfaccia touch progettata specificamente per l’uso su dispositivi mobili (cellulari e tablet). E ‘ un app realizzata in HTML5 (sviluppato con Sencha touch) e funziona su qualsiasi cellulare con un browser moderno.
Comprende molte funzionalità necessarie all’amministratore per la gestione da remoto dell’infrastruttura virtuale, compresa la console SPICE (Software per la gestione della connessione alla console della macchina virtuale), ma non è sostitutiva della full admin console stessa.
Proxmox VE Mobile supporta anche la two-factor authentication con Yubykey con protocollo NFC.
Nota : per tutti coloro che fossero gia in possesso della versione 3.2 l’upgrade alla 3.3 si effettua con due semplici comandi :
NB : ( prima di aggiornare un host spegnere o migare tutte le vm/containers)

~root # apt-get update
~root # apt-get dist-upgrade

 

Se l’articolo ha stuzzicato la vostra curiosita’ e volete saperne ancora di piu’ potete visionare questo Video che illustra tutte le novita’ di cui sopra:

Proxmox VE Video

Virtualizzazione oltre confini con KVM

kvm-vitrualization

PREMESSA

Una delle crescenti necessità dei grandi sistemi server Linux, cosi come dei piccoli esperimenti casalinghi, è fornire la possibilità ad amministratori, sistemisti ed utenti smanettoni di godere delle funzionalità di più sistemi operativi. Questo genere di richieste può essere soddisfatto dal supporto alla virtualizzazione, ovvero la possibilità di rendere virtuali le risorse hardware di cui un sistema operativo ha bisogno, per poi installare l’intera piattaforma “virtualmente” su di esse. Per capire quanto ciò sia conveniente, si pensi ai dischi che un sistema virtuale utilizza, che in realtà non sono altro che semplici file, e come essi si prestino meglio alle operazioni di backup, ed anche le periferiche virtuali sono facilmente standardizzabili e, quindi, uniformabili; ciò rende l’hardware (che può essere cosi’ molto vario…), “virtualmente compatibile” con qualsiasi sistema virtualizzato, azzerando i problemi di compatibilità, ed è a questo che serve KVM.

KVM = Kernel-based Virtual Machine
(KVM) è un’infrastruttura di virtualizzazione del kernel Linux. KVM attualmente supporta una completa virtualizzazione usando Intel VT o AMD-V. KVM è implementato come un modulo kernel caricabile, e dotato d’interfaccia grafica, un vero e proprio Virtual Manager Interface , per la gestione completa delle vostre VM. Il progetto nato gia nel 2007, grazie all’opera di Moshe Bar (gia fondatore di Xensource) che fonda l’azienda Qumranet per occuparsi dello sviluppo di questo nuovo modo di fare virtualizzazione. La Qumranet verra’ acuistata circa un anno piu’ tardi direttamente da RedHat che passera’ tutti i suoi progetti di virtualizzazione proprio su KVM.

I vantaggi di KVM
come dicevamo poco fa, per prima cosa KVM è integrato nel kernel di Linux, quindi dal punto di vista di un sysadmin, ci sono molti meno problemi, basta effettuare i normali update della tua distribuzione e sei a posto (per Xen invece sono una vagonata di Patch, non incluse nel kernel).

KVM non richiede alcun kernel modificato lato guest, quindi meno problemi e più libertà per gli utenti. Ed in caso di distribuzioni Linux come guest, anche qui fai i normali update della distro, senza preoccuparci di quale kernel installare (sembra una sciocchezza ma non è così.)

Ciascun guest KVM viene visto a livello di sistema come un normalissimo processo e puo’ essere gestito con i comandi più consueti (top, ps, kill, etc). Xen ad esempio ti obbliga ad usare una vagonata di strumenti e per sapere quanto sta occupando un domU sei costretto ad installare i tools lato client.

KVM è più flessibile in ambienti eterogenei, ad esempio puoi migrare da un nodo 32 bit verso un 64 e viceversa (ovviamente il guest può essere solo a 32 in questo caso, un 64 su un 32 non può andare mentre il 32 può andare sul 64). Puoi migrare da AMD a Intel e viceversa. Xen ti obbliga ad avere un cluster di nodi tutti uguali, o per meglio dire *identici*.

Verificare il supporto alla virtualizzazione

KVM sfrutta il supporto hardware alla virtualizzazione che il processore installato nel PC deve, necessariamente, poter implementare. Molte delle moderne CPU soddisfano questo requisito, considerando che sia AMD che Intel (che insieme raggiungono circa il 98% del mercato dei processori) includono da tempo le tecnologie AMD-V ed Intel VT-x rispettivamente, in grado proprio di supportare la virtualizzazione. Ciò è fondamentale, poiché senza tale supporto hardware, KVM non può funzionare.

Quindi, prima d’installare KVM dobbiamo verificare che l’hardware supporti la virtualizzazione. Per farlo, possiamo digitare, sul terminale, il comando seguente:

Per farlo, possiamo digitare, sul terminale, il comando seguente:

egrep -c ‘(svm|vmx)’ /proc/cpuinfo

Se l’output è diverso da 0, siamo certi che la nostra CPU è compatibile con la virtualizzazione, e possiamo passare al processo di installazione vera e propria. Altrimenti, ahimé, non sarà possibile sfruttare questo potentissimo strumento.

Installare KVM

A questo punto possiamo finalmente installare KVM. La procedura è abbastanza semplice, soprattutto se si utilizzano le maggiori distribuzioni server :

# apt-get install qemu-kvm libvirt-bin bridge-utils virt-manager

Se, invece, non è così, e possiamo avvalerci di yum, utilizzeremo i comandi seguenti:

# yum groupinstall "Virtualisation Tools" "Virtualization Platform"
# yum install python-virtinst

oppure, in alternativa:

# yum install kvm qemu-kvm python-virtinst libvirt libvirt-python virt-manager libguestfs-tools

Terminata l’installazione, c’è ancora un dettaglio da tenere in considerazione. Di norma, le virtual machine di KVM possono essere gestite ed utilizzate soltanto dall’utente root, o da tutti gli utenti appartenenti al gruppo libvirtd. Per questo motivo, se vogliamo utilizzare KVM con il nostro account (diciamo, ad esempio, con l’account pippo), dovremo ultimare l’installazione con il comando seguente:

# adduser pippo libvirtd

Fatto ciò, possiamo verificare che KVM sia stato correttamente installato, riavviando il sistema e verificando che il comando seguente:

$ virsh -c qemu:///system list
@lorenzo:~# virsh -c qemu:///system list
Id    Nome                           Stato
—————————————————-

Se ciò non dovesse accadere, potrebbe non essere stato avviato libvirtd, il demone che gestisce il sistema di virtualizzazione. Possiamo avviarlo con i seguenti comandi:

# chkconfig libvirtd on
# service libvirtd start

A questo punto non resta che configurare in maniera esauriente KVM, ed iniziare a creare ed avviare le macchine virtuali. Se abbiamo a disposizione un ambiente grafico, possiamo affidarci a virt-manager.

virt-manager

Una volta avviato, possiamo subito creare una nuova virtual machine, cliccando sul primo pulsante da sinistra, sulla barra principale della finestra di virt-manager. Qui possiamo:

  • inserire il nome della macchina virtuale
  • scegliere come installare il sistema operativo guest (se utilizzando un’immagine ISO locale, o se effettuare un’installazione via network)
  • selezionare il tipo di sistema operativo che stiamo installando
  • impostare la quantità di memoria RAM da assegnare al sistema, nonché il numero di CPU
  • definire alcune impostazioni avanzate, come l’architettura del sistema, nonché le preferenze di rete

Una nota importante riguarda proprio queste ultime impostazioni relative alla rete. Per default, la virtual machine accede ad internet non come macchina a sé stante, ma tramite un NAT bridge che la rende, dal punto di vista della rete, un tutt’uno col sistema host. E’ possibile modificare questa impostazione tramite le Opzioni avanzate subito prima della fine del processo di creazione della macchina virtuale. Ciò può risultare molto utile se si vuole utilizzare la macchina virtuale come server accessibile all’esterno (una situazione abbastanza tipica). Non resta che giocarci il piu’ possibile ed impratichirsi con tutte le opzioni a disposizione. Buon divertimento.