La guida galattica per KVM, QEMU, libvirt e Spice
Introduzione noiosa
La virtualizzazione dei server in ambito enterprise è ormai una pratica molto diffusa nei moderni data centre: i vantaggi sono in termini di consolidamento, ottimizzazione uso risorse, riduzione tempi di provisioning, riduzione costi, consumi e spazi, flessibilità, ecc. e potrei continuare per ore.
Meno evidenti sono i vantaggi che un utente medio potrebbe ottenere dall'utilizzo della virtualizzazione in ambito desktop. I casi d'uso possono essere:
- creazione di un ambiente di sviluppo e test dove sperimentare senza compromettere la sicurezza del proprio PC
- hosting di virtual appliance, cioè macchine virtuali preposte a scopi specifici (spesso si trovano in rete già fatte)
- creazione di architetture complesse (con più server interconnessi su un virtual layer) a scopi didattici o di demo
- esecuzione di altri sistemi operativi
- ecc.
Personalmente ho iniziato ad utilizzare la virtualizzazione nel 2006, quando l'acquisto di un nuovo PC con tanta memoria (per i tempi!) mi permise di iniziare ad esplorare questo campo che in quel tempo stava muovendo i suoi primi timidi passi in ambito enterprise e non era ancora così maturo come lo è ora.
Iniziai con VMware, non mi ricordo quale fosse la versione ma probabilmente era VMware Server; successivamente sperimentai VirtualBox ed infine KVM. L'uso che ne facevo prevalentemente per provare altri OS.
Il primo utilizzo serio della virtualizzazione in ambito lavorativo lo sperimentai nel 2010 quando presi una drastica decisione sul PC di lavoro che montava Windows: cancellai Windows (questa è stata la cosa più bella e divertente!), installai Debian ed iniziai a lavorare con Windows in modalità virtualizzata. Iniziai con VirtualBox, poi dopo la sciagurata acquisizione di Sun Microsystem da parte di Oracle passai a VMware.
Continuai con VMware, prima Player poi WorkStation con licenza aziendale, per diversi anni fino a quando..... vidi la luce!
Avevo già provato molte volte KVM, anzi lo usavo normalmente sul PC di casa per i miei test, ma non l'avevo mai pensato in un ambito lavorativo/desktop in quanto mancavano delle caratteristiche per me fondamentali:
- gestione grafica fluida e completamente integrata nel sistema operativo ospitante
- condivisione della clipboard tra la macchina virtuale ed il sistema ospitante
- gestione delle periferiche USB in maniera trasparente
Ho infatti la necessità di utilizzare un token USB di strong authentication e non ero mai riuscito a "passarlo" alle macchine virtuali KVM in maniera semplice ed immediata.
La svolta avvenne quando, su invito di un collega che aveva già fatto "il salto", decisi di riprovarci seriamente seguendo anche il suo consiglio di utilizzare Spice (http://www.spice-space.org/) per la gestione della connessione alla console della macchina virtuale. Ovviamente se sono qui a scrivere questa guida è perché l'esperienza è andata magnificamente e da diverso tempo uso ormai solo KVM per le mie virtualizzazioni.
I vantaggi rispetto alle altre due soluzioni di cui abbiamo parlato (VMware e VirtualBox) sono sicuramente in termini di:
- flessibilità e funzionalità avanzate
- integrazione totale in GNU/Linux e nelle più comuni distribuzioni
- velocità
Vi ho annoiato fin troppo con le mie chiacchiere, passiamo al sodo! Eviterò di entrare in discorsi tecnici di dettaglio, come ad esempio la differenza tra la full-virtualization e la para-virtualization, per chi volesse approfondire l'argomento c'è molta documentazione in Internet. I principali riferimenti sono riportati in fondo a questa guida.
Convenzioni
In questa guida, come del resto in tutti i documenti in cui compaiono comandi UNIX like, verrà utilizzato il simbolo "#' per denotare il prompt comandi di root (e quindi identificare i comandi che è necessario dare con l'utenza root) ed il simbolo "$" per denotare il prompt comandi di un utente qualsiasi non root.
I comandi e l'output a terminale verranno tutti mostrati con un carattere fisso all'interno di una cornice:
# ls -las total 16 4 drwxrwxrwt 4 root root 4096 Mar 28 13:18 . 4 drwxr-xr-x 22 root root 4096 Aug 1 2013 .. 4 drwxrwxrwt 2 root root 4096 Mar 28 12:06 .ICE-unix 4 drwxrwxrwt 2 root root 4096 Mar 28 12:06 .X11-unix #
Glossario e definizioni
In questa guida utilizzerò alcune abbreviazioni e termini che per chi non è dentro al mondo della virtualizzazione potrebbero risultare nuovi e quindi vale la pena definirli.
Console interfaccia principale di I/O di una macchina, nell'ambito della virtualizzazione si tratta di una console emulata
Hypervisor software di virtualizzazione. A volte il temine viene usato impropriamente per identificare la macchina host
Host macchina server sulla quale sono ospitate le macchine virtuali
KVM Kernel-based Virtual Machine, modulo del kernel che sfrutta le funzionalità di virtualizzazione dei processori
QEMU Quick EMUlator, l'hypervisor che che implementa lo strato di virtualizzazione; utilizza il modulo KVM
SPICE Simple Protocol for Independent Computing Environments, sistema di display remoto per ambienti virtualizzati
Virtual Hardware l'hardware virtuale che viene visto all'interno della macchina virtuale. Solitamente vengono utilizzati alcuni hardware reali come riferimento che vengono poi emulati e presentati all'interno della macchina virtuale come se fossero periferiche fisiche
VM Virtual Machine, macchina virtuale sulla quale viene installato un sistema operativo
VDI Virtual Desktop Interface, protocollo di accesso desktop remoto
Avvertenza: gli screenshot mostrati in questa guida sono stati presi dal mio laptop sul quale il software è stato già installato e configurato, quindi potranno differire leggermente dalle schermate di default che vedrete sul vostro PC.
Prerequisiti
Prima di iniziare il vostro viaggio galattico nel mondo della virtualizzazione, dovrete assicurarvi di soddisfare i requisiti richiesti da KVM. Per sfruttare al massimo le performance dell'hypervisor, è necessario infatti avere un processore che supporti le estensioni di virtualizzazione: per i processori Intel la tecnologia VT mentre per gli AMD la tecnologia SVM (o AMD-V). Il controllo è abbastanza facile perché sono informazioni che si ricavano da /proc/cpuinfo. Il comando per controllare se avete tali estensioni è il seguente:
$ egrep '^flags.*(vmx|svm)' /proc/cpuinfo
Se compare qualcosa vuol dire che il vostro processore supporta le estensioni di virtualizzazione. Se non doveste vedere nulla, prima di buttare il vostro PC dalla finestra, controllate che il supporto della virtualizzazione sia abilitato nel BIOS. Quindi spegnete il PC, entrate nel BIOS e cercate l'opzione sulla virtualizzazione. Qui non posso aiutarvi perché ogni BIOS fa storia a sè, ma non dovrebbe essere difficile individuare l'opzione corretta da abilitare. Se l'avete individuata ed era effettivamente disattivata, attivatela e fate un reboot dopo aver salvato. Ripetete il test fiduciosi che l'esito sarà questa volta positivo!
Tutti i comandi che seguono devono essere effettuati da un terminale grafico (xterm, gnome-terminal, ecc.), solo successivamente, una volta acquisita dimestichezza con l'interfaccia a riga di comando dell'hypervisor, potrete gestire le vostre macchine virtuali da una console di testo.
Setup
Questa guida è basata sull'attuale versione di Debian testing ma non avrete nessun problema ad utilizzarla anche con altri rami (es. stable): al massimo potrà cambiare qualche nome di pacchetto e qualche funzionalità, ma le linee guida rimangono le stesse. Tutto il software necessario lo trovate già pacchettizato nei repository standard.
Con poche modifiche, presumibilmente solo quelle relative all'installazione dei pacchetti, questa guida può essere utilizzata anche su altre distribuzioni GNU/Linux in quanto non utilizza nessuna particolare funzionalità presente solo in Debian.
Per prima cosa è necessario installare KVM col seguente comando:
# apt-get install kvm
Su Debian testing il pacchetto si chiama in realtà qemu-kvm, ma la redirezione viene effettuata in automatico. Ovviamente questo pacchetto avrà una serie di dipendenze che verranno automaticamente installate.
QEMU rappresenta il vero e proprio hypervisor mentre KVM è semplicemente un modulo del kernel che si occupa dell'interfacciamento di basso livello con il processore attraverso le primitive di virtualizzazione di cui abbiamo appena discusso.
L'installazione crea anche un gruppo chiamato "kvm" nel file /etc/group: in questo gruppo dovete aggiungere tutti gli utenti ai quali volete concedere il diritto di utilizzare kvm. Quindi, una volta finalizzata l'installazione tramite utenza root, vi consiglio caldamente di utilizzare il vostro normale utente per lanciare e gestire le macchine virtuali.
Dopo l'installazione fate un bel reboot ed una volta rientrati nuovamente nel sistema controllate la presenza dei moduli necessari a KVM:
# ls -l /dev/kvm crw-rw---- 1 root kvm 10, 232 Mar 28 22:04 /dev/kvm # # lsmod |fgrep kvm kvm_intel 130584 0 kvm 380340 1 kvm_intel #
Se il risultato è analogo a quanto riportato (se avete un processore AMD vedrete kvm_amd al posto di kvm_intel) allora siete a cavallo. Digitate il seguente comando in un terminale grafico:
# kvm
e dovreste vedere una console analoga a questa:
Se vedete questa finestra, complimenti! Avete fatto partire la vostra prima macchina virtuale in KVM!!! Visto com'è stato facile? Ovviamente la macchina è vuota, è come se aveste fatto partire un PC senza nessuna periferica installata, quindi il BIOS virtuale vi mostrerà dei normali messaggi di errore.
Ora potete chiudere la vostra macchina virtuale (con CTRL+C nel terminale oppure chiudendo la finestra) perché abbiamo bisogno di aggiungere l'hardware virtuale necessario all'installazione del sistema operativo. Per far questo ci sono due strade, una a riga di comando, passando le opzioni direttamente al comando "kvm" ed una utilizzando una comoda interfaccia grafica chiamata "virt-manager". Iniziamo con l'interfaccia grafica, successivamente vedremo come eseguire le operazioni più comuni direttamente da riga di comando.
Installiamo quindi il software:
# apt-get install virt-manager
e proviamo subito a lanciare l'interfaccia grafica digitando:
# virt-manager
dovrebbe apparire una finestra simile a questa:
lo screenshot è stato preso sul mio laptop dove ho già diverse macchine virtuali installate, di cui due in esecuzione (coew7 e debian-testing) e due spente (debian-stable e winxp).
Al centro della finestra, in corrispondenza di ogni VM, ci sono i grafici di performance, mentre la prima riga (denominata "isengard (QEMU) - Not Connected") è una connessione remota (al momento disconnessa) ad un altro hypervisor, cioè ad un software di virtualizzazione installato su un'altra macchina. Una delle funzionalità di QEMU che non trovate nelle versioni base degli altri prodotti è infatti la possibilità di collegarsi ad altri hypervisor e gestirli come in locale. In un'installazione pulita comparirà solo una riga con la connessione a localhost.
Da adesso in poi, se lo preferite, potete lavorare da utente normale anziché come root. Per far ciò dovete aggiungere il vostro utente ai gruppi "kvm" (già segnalato in precedenza), "libvirt" e "libvirt-qemu".
Non illustrerò in questa sede tutte le funzionalità di virt-manager, vi invito ad esplorare l'interfaccia e leggere la documentazione a riguardo. Mi limiterò a descrivere il minimo indispensabile per configurare l'hypervisor ed avere una macchina virtuale installata e funzionante.
Creazione delle macchine virtuali
Prima di creare le macchine virtuali occorre configurare l'hypervisor e/o cambiare le impostazioni di default se queste non dovessero essere di vostro gradimento.
Per prima cosa pensiamo alla rete: selezionate dal menu la voce "Edit -> Connection Details" e nella successiva finestra che si aprirà selezionate il tab "Virtual Networks". Vi apparirà la seguente finestra:
Prendete nota della subnet che è mostrata, la vostra VM avrà un IP all'interno del range indirizzi della sottorete di default che è stata definita. Se la rete è in stato "Inactive", provate a premere sul pulsante di start (triangolino nella barra nella parte inferiore della finestra) e se tutto è OK la rete dovrebbe partire. Ve ne accorgete dal cambio di stato (se è partita diventa "Active") e dalla presenza del nome del device che di default dovrebbe essere virbr0 (Virtual Bridge 0). Se non parte controllate che la sottorete non sia in conflitto con una delle sottoreti sulle quali sono attestate le vostre NIC fisiche del PC.
Potete anche sincerarvi della cosa col seguente comando:
$ /sbin/ifconfig
e dovreste vedere virbr0 tra le interfacce di rete. Selezionate "Autostart" se volete che l'interfaccia parta automaticamente al boot.
La rete è configurata in NAT che è un'impostazione che vi consente tranquillamente di uscire dalla VM con tutti i protocolli, di entrarci con tutti i protocolli dalla macchina host ma dovrete impostare delle regole di forwarding se volete accedervi da un'altra macchina diversa dall'hypervisor. Potete aggiungere anche altre interfacce di rete sia in NAT che in forwarding/routing, ma queste tematiche non saranno trattate in questa sede.
Bene! La rete è a posto, passiamo ai dischi. Cliccate sul tab "Storage" (sempre nella finestra "Connection Details") e vedrete la definizione di quelli che sono chiamati "storage pool" ovverosia delle aree sulle quali creare i dischi virtuali per le vostre VM.
Di default c'è un pool di tipo "Filesystem Directory": tutti i dischi virtuali che creerete in quel pool verranno installati di default nella directory mostrata che è "/var/lib/libvirt/images". Se questa "location" non vi soddisfa siete liberi di creare tutti i pool che volete sulle directory di vostro gradimento: il pool di default, infatti, non può essere cancellato.
Io solitamente creo due pool: uno per le immagini ISO dei media di installazione ed uno per i dischi virtuali, ma voi siete liberi di creare un solo pool. Di seguito i dettagli dei miei due pool storage:
Per ogni disco virtuale definito vengono mostrate le informazioni sulla dimensione, sul formato del file e sulle VM che lo usano.
Iniziamo ora a definire la nostra macchina virtuale iniziando proprio dallo storage. Dopo aver creato il pool destinazione posizionatevi col mouse nel pool appena definito (ma potete usare anche il pool di default) cliccate sul pulsante "New Volume" per creare un nuovo disco virtuale. Mettete un nome di vostra preferenza, come formato scegliete "qcow2", impostate la dimensione del file e cliccate su "Finish":
Il vostro file sarà ora visibile nel pool. QCOW2 è il formato di immagine più versatile, per la descrizione delle sue caratteristiche e per il confronto con altri formati consultate la documentazione di QEMU.
A questo punto possiamo anche già pensare ai media di installazione: reperite le immagini ISO dei CD/DVD di installazione del sistema operativo che volete installare nella vostra VM e depositatelo nella directory associata al pool destinazione (un click sul pulsante di refresh farà apparire l'immagine nella finestra). Come ho già accennato, ho un pool dove conservo tutte le immagini ISO: per la nostra installazione useremo l'attuale distribuzione GNU/Debian Stable, il cui CD è il primo della lista del pool "iso" in una delle schermate mostrate sopra.
Potete ora chiudere la finestra "Connection Details" e premere il primo pulsante in alto a sinistra della finestra principale di virt-manager per creare la vostra VM. Apparirà un wizard che vi guiderà in maniera semplice ed intuitiva attraverso i vari passi della definizione della macchina virtuale. La prima cosa da decidere è il nome ed il modo di installazione, se locale o in rete:
seguite le indicazioni mostrate nelle schermate ed ad ogni passo premete il pulsante "Forward". Nel passo numero due selezionate "Use ISO image" e scegliete l'immagine ISO del vostro media di installazione attraverso il pulsante "Browse" che vi porta direttamente sulla finestra dei pool storage che abbiamo appena visto. Posizionatevi nel pool dove avete memorizzato l'immagine e selezionatela. Impostate anche la tipologia di sistema operativo:
Premete il tasto "Forward" per andare nel passo numero tre dove selezionerete la RAM e le CPU virtuali da allocare alla VM. Non esagerate, potete sempre aumentarle dopo (uno dei tanti vantaggi della virtualizzazione che ho dimenticato di citare nell'introduzione noiosa). Io solitamente per le macchine Linux non vado oltre il mezzo giga di RAM e singola CPU. Per macchine Windows lascio sempre 1 CPU ma aumento la RAM ad almeno 1GB:
Premete nuovamente il tasto "Forward". Nel passo numero quattro selezionate il disco virtuale che avete creato, in maniera analoga a quanto avete fatto con l'immagine ISO nel passo due e non dimenticatevi di deselezionare la casella "Allocate entire disk now": questo ci consentirà di risparmiare spazio disco allocando solo i blocchi che sono utilizzati (una delle caratteristiche del formato QCOW2):
Un'ultimo click sul tasto "Forward" ci porta sull'ultima finestra di riepilogo in cui dovrete semplicemente selezionare la casella "Customize configuration before install" ed eventualmente controllare se le opzioni avanzate sono in linea con le vostre aspettative:
Premete il pulsante "Finish" e comparirà la seguente finestra in cui potete dare uno sguardo all'hardware virtuale che è stato definito per la vostra VM ed eventualmente apportare alcuni cambiamenti. Tenete presente che è possibile effettuare le modifiche anche a macchina virtuale già installata:
Le uniche cose che modificheremo prima dell'installazione sono relative allo storage per aumentarne le prestazioni velocizzando la procedura di installazione. Selezionate il disco nella lista a sinistra ed impostate il bus "SATA" e la cache "writeback" come mostrato di seguito:
Premete "Apply" e finalmente su "Begin installation" per far partire la vostra VM e l'installazione dell'OS. Se vedete la schermata qui sotto, con l'installazione Debian che scalpita per partire allora potete proseguire installando l'OS come se doveste installarlo su una macchina fisica.
Se il risultato non è quello mostrato sicuramente avete fatto un errore in uno dei passi precedenti o ho fatto un errore io in uno dei passi della guida. Nel primo caso rivedete accuratamente tutti i passaggi per individuare l'errore. Nel secondo caso fatemelo sapere che provvederò ad aggiornare il testo.
Ovviamente potete installare il sistema operativo che volete, i passi rimangono più o meno gli stessi.
Non mi dilungherò sull'installazione del sistema operativo, non è questa la sede, procedete pure nell'installazione fino ad arrivare al prompt di login. Sappiate solo che sulla rete virtuale in NAT che avete definito c'è un servizio DHCP che fornirà in automatico l'IP alla VM: se invece volete definirne uno fisso (es. per accedervi dall'esterno in ssh) fatelo all'interno della sottorete che avete definito ma al di fuori del range del DHCP.
Una volta finalizzata l'installazione accedete come root o con un utente se è stato creato durante l'installazione e fatevi un giro nella vostra macchina virtuale!
Da un punto di vista del sistema operativo non cambia praticamente nulla, tutto viene virtualizzato e mascherato, a meno che non andiate ad interrogare direttamente l'hardware non vi accorgerete minimamente di essere all'interno di una VM. Guardando ad esempio /proc/cpuinfo noterete che il modello della CPU riporta la scritta "QEMU Virtual CPU" ma è solo una stringa identificativa.
Provate ora a chiudere sia la finestra grafica che racchiude la vostra VM sia l'interfaccia virt-manager. Non vi preoccupate: la vostra VM rimarrà viva e vegeta in esecuzione! Per "rivedere" la VM vi basterà aprire nuovamente virt-manager e fare un doppio click sulla vostra VM, oppure potete anche selezionare la VM e premere il pulsante "Open" nella barra in alto. I primi due pulsanti della barra in alto della finestra della VM consentono di passare dalla console alla definizione dell'hw e viceversa: potete anche fare qualche modifica all'hw ma tenete presente che la maggior parte delle modifiche verranno prese in considerazione solo al prossimo reboot. Potete invece aggiungere on-line dischi di tipo hot-plug (es. SCSI) e cambiare il puntamento al DVD, ad esempio, cosa utilissima nel caso in cui l'installazione del sistema operativo sia divisa in più dischi.
Al momento l'hw non è molto ottimizzato, la scheda grafica di default probabilmente non vi permetterà di usare le funzionalità avanzate (es. gnome-shell) e le performance non saranno sicuramente al massimo. Proviamo quindi ad ottimizzare qualcosina.
Spegnete la macchina con un normale shutdown ed appena vi compare al centro il messaggio "Guest not running" cliccate sulla lampadina per entrare nella vista della configurazione della macchina, cliccando invece sul monitor ritornerete nella console che al momento è spenta. Come già detto potete passare da una modalità all'altra anche con la VM in esecuzione ma per cambiare la configurazione dell'hw bisogna spegnere la macchina virtuale.
Andiamo ora ad apportare i seguenti cambiamenti (premete il pulsante "Apply" prima di cambiare schermata):
- Sata Disk 1 -> Advanced Options -> Disk Bus: Virtio
- IDE CDROM 1 -> Advanced Options -> Performance Options -> Cache mode: writeback (lo so, sul CDROM non si scrive, ma serve comunque a velocizzare gli accessi abilitando la cache che viene usata anche per le letture)
- NIC -> Device model: Virtio (potrebbe già essere impostata così se avete mantenuto il default)
- Video Cirrus -> Model: QXL
e fate ripartire la VM per verificare che sia tutto OK. Sul disco e rete stiamo ora usando i driver di paravirtualizzazione virtio, che interagiscono direttamente con l'hypervisor, contrapposti ai normali driver che girano in modalità "cieca" full virtualization e che non beneficiano delle ottimizzazioni dovute alla comunicazione tra guest ed host possibili con virtio. È qui che entra maggiormente in gioco la libreria libvirt.
Non siamo ancora in grado, però, di sfruttare appieno le potenzialità del driver video QXL: è arrivato il momento di mettere la ciliegina sulla nostra torta virtuale ed iniziare a parlare di Spice!
Per chi non si accontenta: Spice
Finora abbiamo mostrato le funzionalità base della virtualizzazione in ambito QEMU/KVM che per la maggior parte dei casi è più chesufficiente. A questo punto potete decidere se fermarvi qui oppure continuare a seguire la guida per ottenere il massimo dal vostro hypervisor (la ciliegina sulla torta).
Il software che useremo si chiama "Spice" e fu sviluppato da una società acquisita da Red Hat nel 2008. Principalmente è una soluzione di Virtual Desktop Interface (VDI) ed astrazione delle periferiche:
Spice è completamente integrato in QEMU ed interagisce con i driver video installati nelle macchine virtuali e con gli agent che girano nelle macchine virtuali:
Per usare Spice dobbiamo installare dei pacchetti sia sul guest che sull'host. Sul guest installiamo i seguenti pacchetti:
# apt-get install spice-vdagent xserver-xorg-video-qxl
e facciamo uno shutdown. Non fate ancora partire la VM: dobbiamo prima installare i moduli Spice sull'host e modificare la configurazione della macchina virtuale per usare Spice.
Sull'host installate i seguenti pacchetti:
# apt-get install spice-client-gtk
Riaprite virt-manager (se l'avevate chiuso) ed aprite la configurazione della macchina virtuale.
Per prima cosa andiamo a rimuovere il device "Display VNC" in quanto dobbiamo sostituirlo con quello Spice. Potremmo anche entrare in modifica su quello esistente ma per una limitazione/bug dell'interfaccia grafica di virt-manager, sarà impossibile cambiare la configurazione del server socket (in particolare l'indirizzo sul quale viene aperto) che è necessaria per permettere l'accesso alla VM da un altro PC.
Dopo aver rimosso il display di tipo VNC aggiungete uno di tipo "Spice" con il solito pulsante "Add Hardware" che trovate in basso a sinistra. Selezionate "Listen to all public network interfaces" se volete accedere alla macchina da remoto e deselezionate l'opzione di allocazione automatica della porta, altrimenti ogni volta vi tocca vedere su che porta è partito il server (ma solitamente inizia dalla 5900):
Poi aggiungete un "Channel" di tipo "Spice agent" ed un paio di "USB Redirection" di tipo "Spice channel".
A questo punto è necessaria una piccola modifica manuale ad un file di configurazione: non inorridite, purtroppo virt-manager non è perfetto, ma per fortuna siamo utenti Linux e non ci arrendiamo davanti alle difficoltà!
Se cliccate nuovamente sul display Spice, noterete le due porte che sono state definite quando abbiamo aggiunto il device, che sono la 5900 e la 5901. La seconda è dedicata alla cifratura TLS del canale di comunicazione ma per usarla occorre configurare un certificato che noi al momento non abbiamo. Se lasciamo la porta configurata, però, l'hypervisor non sarà in grado di far partire la VM mostrando un messaggio di errore relativo alla configurazione TLS e/o alla mancanza di certificato. Occorre quindi eliminare la porta TLS ma dall'interfaccia grafica è impossibile.
La configurazione della macchina virtuale è in un file XML memorizzato nella directory:
/etc/libvirt/qemu/
Entrate quindi in quella directory con l'utente root, identificate il file della vostra macchina virtuale (nel nostro caso si chiama "debian-ildn.xml") ed apritelo col vostro editor di testo preferito. Cercate il punto dove è definita la porta TLS ed eliminate completamente l'attributo "tlsPort" ed il suo valore dal tag "graphics".
Prima della modifica:
<graphics type='spice' port='5900' tlsPort='5901'autoport='no' listen='0.0.0.0'> <listen type='address' address='0.0.0.0'/> </graphics>
dopo la modifica:
<graphics type='spice' port='5900' autoport='no' listen='0.0.0.0'> <listen type='address' address='0.0.0.0'/> </graphics>
Per leggere la nuova configurazione fate ripartire libvirt:
# service libvirt-bin restart
Tornate ora su virt-manager. Se avevate la finestra della VM attiva molto probabilmente riceverete un messaggio di errore per la disconnessione dall'hypervisor. Riconnettetevi all'hypervisor con il tasto destro su "localhost (QEMU)" e poi "connect" oppure doppio click sulla connessione. Ora riaprite la vostra macchina virtuale ed andate a vedere cosa compare nel display Spice: dovreste vedere "Automatically allocated" in corrispondenza della porta TLS. Se vedete ancora la porta precedente assicuratevi di aver seguito tutti i passi ed eventualmente fate un reboot.
Ora siamo pronti per accendere nuovamente la macchina virtuale. Andate quindi sulla console (tasto col monitor in alto a sinistra) e fate partire la macchina premendo il triangolino.
"Embè?" Direte voi: "Cos'è cambiato rispetto a prima? Dov'è Spice?". Spice è un protocollo di accesso remoto: il server sarà il vostro hypervisor (ricordate la porta 5900 configurata quando abbiamo aggiunto il display Spice?) mentre il client sarà un qualunque PC sulla rete locale che si connetterà utilizzando il client che abbiamo installato sull'host.
Quindi, con la macchina virtuale accesa, andate sul vostro PC host e digitate il seguente comando:
$ spicy -h localhost -p 5900
Se non avete commesso errori si aprirà una finestra con la vostra virtual machine! Ce l'avete fatta! State ora usando Spice per connettervi alla vostra VM! E se fate partire il client Spice subito dopo aver fatto partire la macchina, vedrete anche tutti i messaggi di boot.
Noterete anche che quando si apre il client Spice, la console viene disconnessa da virt-manager in quanto può esserci solo una connessione attiva (c'è comunque anche la possibilità di condividere il display).
Ora andate nella voce "Options" del menu del client Spice e modificate le impostazioni come mostrato di seguito:
Assicuratevi che nella barra di stato di Spice in basso a sinistra compaia la dicitura "agent: yes" che sta a significare che anche i "guest tool" funzionano correttamente (probabilmente prima del login grafico gli agent sono ancora disabilitati).
Ora potete provare le funzionalità avanzate di Spice, come ad esempio:
- ridimensionamento automatico della risoluzione del guest quando si ridimensiona la finestra di Spice
- condivisione della clipboard tra client e guest
- redirezione automatica delle periferiche USB dal client al guest
- redirezione dell'audio sul client
Spice, utilizzando un protocollo di rete, funziona anche in remoto. Anzi, è proprio questo il caso di utilizzo ideale e dove si nota la netta superiorità di questa soluzione rispetto agli altri protocolli di remote desktop proprietari.
Provate quindi a chiudere il client Spice ed a usare un'altra macchina per la connessione, o addirittura un cellulare Android connesso ovviamente in wi-fi alla stessa rete dell'hypervisor. Potete scaricare il client Spice per Android su Google Play al link che trovate in fondo a questa guida.
Non dovete far altro che lanciare il client spice da un'altra macchina o dal cellulare/tablet puntando all'indirizzo IP del vostro hypervisor (cioè il PC sul quale gira la vostra VM, non l'indirizzo IP interno della VM!) ed usando come porta la 5900 (o la porta che avete configurato nel display Spice).
Si seguito una schermata presa da un dispositivo portatile Android:
Le performance anche su rete locale cablata o wireless sono impressionanti: se entrate in modalità full screen e date il PC ad un'atra persona, faticherà a credere che sta lavorando con un PC remoto. Potete provare ad inserire una periferica USB sul client e vedrete che attraverso la rete verrà rediretta sulla macchina virtuale come se l'aveste inserita sull'host! Ovviamente è necessario avere in primo piano nel focus la finestra di Spice.
Se volete collegarvi con Spice ad una macchina virtuale Windows, seguite tutti i passi standard per la creazione della VM ed installazione dell'OS, poi modificate la configurazione per l'utilizzo di Spice ma nella macchina virtuale dovrete poi installare i driver QXL e guest tool specifici per Windows che trovate nella sezione Download del sito ufficiale di Spice: cercate "Windows guest tools" e scaricate il pacchetto di installazione del bundle contenente tutti i driver e gli agent necessari a far funzionare Spice al meglio.
Quando il gioco si fa duro: virsh
Per i patiti dell'interfaccia a riga di comando (io sono tra questi!), per coloro che intendono installare macchine virtuali su server remoti senza possibilità di accesso grafico o semplicemente per chi volesse automatizzare alcune attività, è disponibile una comoda CLI che permette di gestire il vostro sistema di virtualizzazione in maniera pressoché completa.
Aprite quindi una shell di comandi e digitate:
$ virsh -c qemu:///system
Entrerete nel terminale interattivo dell'hypervisor dove potete controllare le vostre macchine virtuali e la configurazione dell'hypervisor in maniera analoga a quanto avete appena fatto utilizzando l'interfaccia grafica. Provate a digitare "help" per rendervi conto di tutte le funzionalità di questa interfaccia. In questo contesto la parola "Domain" identifica una macchina virtuale.
Per vedere la lista della VM digitate "list" (con l'opzione "--all" per vedere anche quelle spente) mentre per far partire una VM digitate "start". Non descriveremo tutti i comandi di virsh, ci vorrebbe una guida dedicata, ma siete liberi di consultare la documentazione e di impratichirvi con i comandi che più vi tornano utili. Sicuramente è comodissimo far partire una VM direttamente da riga di comando, senza dover necessariamente far partire virt-manager ed agire sull'interfaccia grafica. Potete anche dare i comandi di virsh direttamente all'invocazione. Ad esempio per far partire la nostra vm basta digitare:
$ virsh -c qemu:///system start debian-ildn
Comodo no? Io solitamente accedo alle mie VM dall'host tramite SSH: quindi faccio partire la VM col comando appena descritto, aspetto un po' e poi entro con SSH, senza usare nessuna interfaccia grafica.
Altri comandi utili sono quelli per sospendere e far ripartire la VM ("suspend" e "resume").
Attualmente, utilizzo Spice per connettermi alla macchina virtuale Windows che utilizzo per lavoro: quindi uso questa configurazione tutti i giorni per almeno 10 ore al giorno e non rimpiango minimamente VMware, anzi sono convinto che questa soluzione sia migliore di quelle proprietarie per quanto riguarda prestazioni, funzionalità e flessibilità.
L'interfaccia virt-manager la uso solo quando voglio modificare i parametri della VM. ma avendo la necessità di accenderla e spegnerla ogni giorno, ho scritto un semplice script shell per automatizzare tutte le operazioni per gestire la mia VM. In particolare lo script controlla prima se la VM è stata sospesa o spenta, nel caso la ripristina o la fa partire e poi lancia il client Spice. Quando chiudo il client Spice, lo script chiede all'utente se sospendere o meno la VM.
Riporto qui di seguito lo script che uso ogni giorno per lanciare la VM, sicuramente potrà servire da spunto e base di partenza per sviluppare scenari alternativi (essendo la VM esposta in rete, uso una password per la connessione dal client Spice, parametro "-w" del client spicy):
#!/usr/bin/env bash # # Script to launch/manage the COE VM using libvirt # # 2013, 2014 Pietro Pizzo ###################################################################### typeset -l r # Domain to manage DOMAIN=coew7 # Connection to use CONN=qemu:///system # Make sure the domain is running if virsh -c $CONN domstate $DOMAIN |grep -qi off; then echo "$DOMAIN off: starting" virsh -c $CONN start $DOMAIN || exit 1 elif ! virsh -c $CONN domstate $DOMAIN |grep -qi running; then echo "$DOMAIN not running: resuming" virsh -c $CONN resume $DOMAIN || exit 1 fi # Fire up spice client (if not running) if ! ps aux |grep spicy |grep -qv grep; then spicy -f -h localhost -p 5900 -w PASSWORD >/dev/null 2>&1 </dev/null fi # Ask to suspend the domain if it is still running if virsh -c $CONN domstate $DOMAIN |grep -qi running; then read -p "Do you wish to suspend ${DOMAIN}? [Y/n] " r if [[ "$r" == "" || "$r" == "y" || "$r" == "yes" ]]; then virsh -c $CONN suspend $DOMAIN || exit 1 fi fi exit 0
Conclusioni
Questa guida non ha la pretesa di essere esaustiva: la virtualizzazione è un argomento talmente vasto che servirebbe un'enciclopedia per trattarlo in maniera completa, ma proprio per questa vastità di documentazione disponibile probabilmente questa guida "mirata" sarà di grande aiuto a coloro che stanno per avvicinarsi a questo meraviglioso mondo per la prima volta.
Spero che dopo aver letto questa guida ed implementato le vostre macchine virtuali, guarderete con un altro occhio la soluzione QEMU/KVM che nulla ha da invidiare alle soluzioni proprietarie leader del mercato della virtualizzazione ma che anzi si pone ad un gradino superiore a tutte le altre, solo che nessuno lo sa. Tranne voi, che avete avuto la pazienza di seguirmi fin qui.
Riferimenti
https://play.google.com/store/apps/details?id=com.iiordanov.freeaSPICE
Commenti
Inviato da pietro il Ven, 12/09/2014 - 09:44.
Re: La guida galattica per KVM, QEMU, libvirt e Spice
Bene! Un solo consiglio: non utilizzare porte standard e conosciute sull'IP pubblico perché sono quelle che vengono sondate dai port-scanner.
Scegli una porta alta, nel range di quelle allocate dinamicamente dai client, una casuale, non associata a nessun servizio. Non è la soluzione ai problemi di sicurezza (spero tu abbia messo almeno una password!) ma serve comunque a "nascondere" un po' il fatto che hai una VM accessibile su Internet (i port-scanner solitamente lavorano solo sulle porte note e la 5900 è una di quelle in quanto utilizzata anche per altri protocolli RDP).
Debian. Be unique.
Inviato da Jena72 il Ven, 12/09/2014 - 10:02.
Re: La guida galattica per KVM, QEMU, libvirt e Spice
Da ieri oltre a W7 ci faccio girare anche la nuova Debian Testing ed entrambe sono accessibili da ogni dove.

Unico problema è che non riesco a capire come far comunicare correttamente la tastiera remota. Ovvero, p.e., dallo smartphone mi collego alla Debian e, la mappatura della tastiera è differente. I due punti ( : ) sono interpretati come ç
Inviato da Jena72 il Ven, 12/09/2014 - 11:16.
Re: La guida galattica per KVM, QEMU, libvirt e Spice
Infatti. La mia era più curiosità (l'accesso dal web), ma ora che girano quasi bene, farò un settaggio ad hoc con porte "non standard" e le tengo accessibili.
L'utilizzo reale sarebbe quello che più o meno interessa a tutti. Ovvero poter avere a portata di mano un win per qualche sw che non gira sotto linux. Quindi probabile che alla fine renderò accessibile solo dalla rete interna.
Inviato da Jena72 il Dom, 21/09/2014 - 23:18.
Re: La guida galattica per KVM, QEMU, libvirt e Spice
Buona sera.
Esiste un modo se possibile, per aprire più sessioni sulla stessa vm?
Per esempio, creando una VM di W7 (o di CentOS) esiste la possibilità di emularne n in modo che n pc possano collegarsi? Non so se sono riuscito a spiegarmi.
Inviato da pietro il Dom, 21/09/2014 - 23:26.
Re: La guida galattica per KVM, QEMU, libvirt e Spice
Dai un'occhiata qua: http://www.spice-space.org/page/Features/MultipleClients
Debian. Be unique.
Inviato da restyle il Gio, 13/11/2014 - 03:31.
Re: La guida galattica per KVM, QEMU, libvirt e Spice
bella guida, complimenti!
volevo sapere se con kvm un os su virtuale può essere paragonato (come performance) allo stesso os ma installato nativamente.
ad esempio, potrei usare 3ds su un win8 virtualizzato senza sensibili cali prestazionali? eventualmente anche per renderizzare?
Inviato da pietro il Gio, 13/11/2014 - 07:58.
Re: La guida galattica per KVM, QEMU, libvirt e Spice
Tempo fa feci dei benchmark: tutto dipende dal tipo di carico. La parte grafica e storage si comporta male con la virtualizzazione, è un vero collo di bottiglia, ma per quanto riguarda la CPU ho rilevato un calo di performance del circa 3%/5%, un'inezia se confrontato ai benefici della virtualizzazione.
Non so come si comporta 3DS, non puoi far altro che provare! Tieni presente che ad una macchina virtuale gli dai solitamente una frazione delle risorse della macchina fisica. Ad esempio, se hai un PC con 4 CPU e crei una VM da 1 vCPU, le performance saranno 1/4 della macchina fisica, meno il piccolo overhead di cui sopra. Anche la RAM, ovviamente, gioca il suo ruolo e non potrai mai dare tutta la memoria alla VM altrimenti non te ne rimane niente sull'host!
Il confronto va quindi fatto a parità di risorse. Quando feci i benchmark non mi ricordo se allocai macchine virtuali con lo stesso numero dell'host oppure limitai il benchmark sull'host ad usare lo stesso numero di CPU delle VM, ma il concetto non cambia: paragonai le performance a parità di risorse.
Spero di aver risposto ai tuoi dubbi, ma ti ripeto che l'unica è provare: se 3DS, infatti, fa un uso esagerato dei dischi, aspettati un calo di performance significativo.
Debian. Be unique.
Inviato da Jena72 il Gio, 13/11/2014 - 10:03.
Re: La guida galattica per KVM, QEMU, libvirt e Spice
Se hai un macchina ben dotata, le differenze sono impercettibili.
Inviato da Jena72 il Gio, 13/11/2014 - 10:04.
Re: La guida galattica per KVM, QEMU, libvirt e Spice
Qualcuno ha provato (riuscendoci) a virtualizzare OSX?
Inviato da harkonnen il Sab, 17/09/2016 - 15:43.
Re: La guida galattica per KVM, QEMU, libvirt e Spice
Grazie per la guida, avrei la necessità di mettere le macchine virtuali sulla stessa classe di indirizzo IPV4 dell'host (gli ip vengono assegnati da un router casalingo)
Potresti cortesemente darmi qualche indicazione?