Using KVM with standalone QEMU

kvmbanner-logoIn questo post cercherò di riassumere quanto visto nei miei precedenti post in modo da poter fornire una visione d’insieme sull’utilizzo di questo virtualizzatore, in particolare ci soffermeremo sull’uso e sulla configurazione di un ambiente di virtualizzazione a partire dai sorgenti del progetto, in futuro parleremo di come realizzare una configurazione in cui si utilizza libvirt come frontend.

Prima d’iniziare ci tengo a sottolineare una cosa: KVM e QEMU sono due software in costante e veloce sviluppo, seppur ultimamente il tempo fra una release e l’altra inizi a ad aumentare, segno ormai che si sta in qualche modo convergendo verso una release stabile, difficilmente le comuni distribuzioni riescono ad integrare l’ultima release disponibile quindi se siete interessati ad una particolare release successiva a quella disponibile nel vostro kernel o nei repository della vostra distribuzione (ad esempio per ottenere un particolare bugfix oppure nuove feature) potreste comunque dover, o voler, compilare dai sorgenti.

Dalla release 85 in poi c’è stato uno split dei tarball in qemu-kvm-devel-85.tar.gz per l’userspace ed in kvm-kmod-devel-85.tar.gz per il modulo del kernel, fermo restando che è comunque disponibile il tarball contenente  sia userspace e modulo a cui siamo ormai abituati, in questo modo è più facile utilizzare l’ultima release del modulo in combinazione con la versione di QEMU disponibile nella nostra distribuzione.

Installazione & Configurazione

Analizziamo i singoli passi:

  • Verificare che il processore del sistema host (la macchina su cui volete installare KVM) supporti le istruzioni hardware per la virtualizzazione, in caso contrario non potrete eseguire un virtualizzatore basato su KVM:
root@merdbook:~# egrep '(vmx|svm)' /proc/cpuinfo

…se l’output del precedente comando non è vuoto (cioè se viene stampato qualcosa) il vostro processore supporta le suddette istruzioni. Volendo potreste voler eseguire anche un uname -m per vedere se il sistema host è  in grado di eseguire guest (le macchine virtuali) a 64 bit oppure solo a 32 bit (se l’uotput è x86_64 allora potete eseguire guest a 64bit, se è qualsiasi altra cosa allora no).

  • Verificare di avere tutti i pacchetti necessari alla compilazione dei moduli e dell’userspace, nel caso in cui la vostra distribuzione sia una Ubuntu oppure una Debian i pacchetti sono i seguenti:
root@merdbook:~# apt-get install gcc build-essential libsdl1.2-dev \
       zlib1g-dev libasound2-dev linux-headers-generic pkg-config libgnutls-dev

…dalla release 85 è necessaria anche libpci-dev.

  • Scaricare l’ultima release di KVM da sourceforge (al momento in cui scrivo kvm-85), estrarre i file contenuti nell’archivio, eseguire il configure, compilare moduli e userspace ed infine installare il tutto:
root@merdbook:~# tar -xzf kvm-85.tar.gz
root@merdbook:~# cd kvm-85
root@merdbook:~/kvm-85# ./configure
root@merdbook:~/kvm-85# make -j 2
root@merdbook:~/kvm-85# make install
  • A questo punto avrete installato i moduli kvm, kvm-amd e kvm-intel nel sistema operativo host, i programmi facenti parte l’userspace saranno in /usr/local, nel caso li volgliate in un’altra directory è necessario specificarlo con la direttiva –prefix nella riga di comando del ./configure.

Come ulteriore approfondimento potreste voler leggere questo post su NokOnline.

Un primo utilizzo

Ricordo che è necessario caricare il modulo con modprobe , nel caso in cui vogliate informazioni aggiuntive su versione e parametri del modulo attualmente caricato è possibile ottenerli tramite modinfo.

Ipotizzando che non abbiate alcuna macchina virtuale il primo step è creare l’immagine disco tramite qemu-img oppure convertire le immagini disco che eventualmente avete creato ed utilizzato in altri virtualizzatori. Ad esempio per creare un’immagine potreste voler digitare:

root@merdbook:~# qemu-img create -f qcow filename 4G

…ovviamente se volete alterare il formato basta sostituire qcow col formato da voi desiderato (comunque non consiglio di utilizzare formati diversi da qcow e qcow2), per la dimensione del file sostituite il 4G con la dimensione desiderata.

Una funzionalità molto utile offerta dai file immagine è la possibilità di definire delle base-images, un approfondimento su cosa sono e come poterle sfruttare per migliorare la nostra produttività è illustrata nella seguente serie di post pubblicati sul sito KVM – The Linux Kernel-Based Virtual Machine:

Nel caso in cui dobbiate effettuare una conversione troverete informazioni approfondite nei seguenti post:

Un consiglio spassionato è quello di organizzare le immagini delle vm ed eventuali iso necessarie in maniera intelligente o pseudo-tale, ad esempio io ho creato una cartella vm, che a sua volta contiene due altre cartelle (img ed iso) in cui sono contenuti i file necessari suddivisi per tipologia ed estensione:

root@merdbook:~# tree /media/sda5/vm
/media/sda5/vm
|-- img
|   |-- hellgate.img
|   |-- lennybox.img
|   |-- mrcrow.img
|   |-- openbsdbox.img
|   `-- sunshine.img
`-- iso
|-- NETKVM-20081229.iso
|-- gparted-live-0.4.1-2.iso
|-- osol-0811.iso
`-- udpcd.iso
2 directories, 9 files

Ora non resta che decidere con quali parametri avviare la macchina virtuale. L’opzione -drive si usa per passare a qemu l’immagine disco o l’immagine di un cd/dvd, si specifica un file, si specifica il tipo di interfaccia, è possibile utilizzare ide, scsi e virtio (per ora solo con linux). Il vantaggio di usare scsi è dato principalmente dal supporto all’hot-plug cosa che l’ide non permette, con virtio è possibile utilizzare i driver paravitualizzati, ovviamente per i sistemi operativi che lo supportano. Ulteriore attributo utilizzato nell’esempio è boot, se si vuole avviare dal nostro disco è necessario impostarlo ad on. Altri due attributi utili possono essere index e media, con index è possibile specificare l’ordine con cui devono essere visti i device all’interno del guest e con media è possibile comunicare a qemu se mostrare l’immagine come disco (valore disk) oppure cdrom (valore cdrom).

In questo mio post invece affronto la configurazione della rete.

Con -k è possibile specificare una lingua per la tastiera che viene fatta vedere da qemu al guest,  -smp permette di “mostrare” al guest due o più cpu virtuali ed infine con -m si può definire la quantità di memoria che il guest potrà vedere, per aggiungere un controller usb aggiungete il parametro -usb.

Nel caso in cui vogliate configurare i driver paravitualizzati per i guest che li supportano (linux e windows), ne ho parlato nei seguenti post:

Alla fine dovreste ottenere qualcosa di simile:

root@merdbook:~# qemu-system-x86_64 -drive file=/media/sda5/vm/img/lennybox.img,if=virtio,boot=on \
-net nic,model=virtio -net tap -usb -k it -localtime -smp 2 -m 512

Nel caso in cui necessitiate di maggiori informazioni su questi e altri parametri, a questo link è disponibile la documentazione ufficiale del progetto.

Script di gestione

Visto che digitare ogni volta una riga di comando chilometria non è molto comodo, potreste trovare utile semplificarvi la vita configurando degli appositi alias oppure utilizzando degli script di avvio appositamente scritti.

Personalmente una soluzione che mi piace particolarmente è quella di usare lo script kvmctl scaricabile dal wiki del progetto, questa è la pagina dove è possibile scaricare lo script ed avere delucidazioni sull’uso.

Con questo script potrete definire dei file di configurazione a partire da un template per le vostre varie macchine virtuali, configurare l’avvio in automatico di alcune VM allo startup della macchina, organizzare la gestione della console di QEMU, svolgere alcuni comuni task di amministrazione e tanto altro.

Inoltre la licenza BSD di tale script vi permetterà di effettuare modifiche allo script per meglio adattarlo a quelle che sono le vostre particolari esigenze (e si perchè non è mica detto che faccia esattamente quello di cui avete bisogno).

Visto che vari esempi d’uso sono già riportati sulla pagina che vi ho linkato precedentemente, in seguito vedremo le fasi setup di un sistema configurato per utilizzare questi script.

Il primo step è scaricare (ovviamente) e decomprimere l’archivio in qualche directory  nel vostro sistema, una volta fatto vi consiglio di dare un’occhiata al readme per avere una overview dei file contenuti. I file di nostro interesse sono kvmctl e kvm-init, gli altri sono esempi riguardanti la configurazione della rete, argomento da me già trattato (se non vi servono cancellateli pure).

Io di solito sposto lo script kvmctl nella directory /usr/local/sbin facendo attenzione a “chmoddarlo” e “chownarlo”  in modo che solo una selezione di utenti possa leggere ed eseguire il file (ad esempio con una maschera 750 e root:root come owner), lo script kvm-init lo posiziono in /etc/init.d (maschera 755, owner root:root), per impostare lo script come da eseguire allo startup della macchina sulle Debian-based basta digitare update-rc.d kvm-init defaults.

Ora è necessario creare una cartella per i file di configurazione ed il template (ad esempio /etc/kvm), mi raccomando ricordatevi di configurare nello script i path per programmi e directory utilizzati dal programma.

Per definire una nuova macchina virtuale è necessario digitare:

root@merdbook:~# kvmctl edit $nome_vm

…e per avviarla:

root@merdbook:~# kvmctl start $nome_vm

…per arrestarla con molta fantasia basta digitare:

root@merdbook:~# kvmctl stop $nome_vm

Per avviare le macchine in automatico è necessario creare all’interno della directory /etc/kvm una directory di nome auto, al suo interno creare dei link simbolici col nome della macchina virtuale ai file di configurazione contenuti nella cartella /etc/kvm, all’avvio ogni macchina virtuale elencata in quella directory verrà avviata e verrà arrestata quando il sistema verrà arrestato o riavviato, da notare che per utilizzare questo script avete bisogno di kvmctl.

Certo non è libvirt ma questi script il loro dovere lo fanno.

Se avete domande o se volete proporre degli approfondimenti chiedete pure, i commenti sono aperti per questo.

Be Sociable, Share!

    Related post:

    5 Comments

    1. Ci tengo a precisare che non sto commentando per empatia verso MRG, vista l’indifferenza nella quale sono passati gli ultimi 3 esilaranti post del suo angolo.

      Un articolo forse non utile per la massa, ma davvero chiaro e ben scritto. E grazie anche per le citazioni.

      P.S. Il fatto che io ti stia commentando è anche segno che ho tempo per scrivere qualcosa su nokonline 😉

    2. Gixeco says:

      Ciao,
      tra questo post ed altri sto cercando di uscirne 🙂

      Conosco bene i vari hypervisors che girano su tutte le piattaforme, ma ho deciso di “combattere” con KVM “perchè si”.

      Il post è chiaro e ben scritto, confermo!
      Ne approfitterei per chiedervi se siete riusciti a far andare il modulo Kvm con i servizi VBox attivi, sembra siano conflittuali uno con l’altro (basta spegnere/accendere a seconda delle necessità).
      Inoltre consiglio l’uso (per chi non ama le shell 🙂 ) l’utilizzo del virt-manager, che permette di gestire tutte e 3 le tipologie di hypervisor presenti in linux, cioè Qemu,Kvm, e Xen (spettacolare…ma ci vuole ancora un po’ 😉 )

      Cheers!

      • MRG says:

        I moduli vboxdrv e kvm continuano a non essere utilizzabili contemporaneamente.

        Se ti interessa di libvirt, virt-manager e di altri aspetti avanzati di questo hypervisor ne parlo nei post presenti nelle sotto-categorie “Virtualization” delle categorie “Software” e “linux howto”.