Riferimento tecnico · GNU/Linux

KVM, QEMU, libvirt e Spice: guida pratica

Un laboratorio virtuale affidabile nasce dalla separazione dei ruoli: accelerazione nel kernel, emulazione dei dispositivi, gestione delle macchine e console remota.

Server con ambienti virtuali isolati rappresentati da livelli traslucidi

I quattro livelli della pila

KVM espone nel kernel Linux l’accelerazione hardware per la virtualizzazione. QEMU costruisce la macchina virtuale e presenta CPU, dischi, rete e periferiche al sistema ospite. libvirt aggiunge un modello di gestione stabile: definizioni persistenti, reti virtuali, pool di storage e un’API comune. Spice fornisce un protocollo di visualizzazione e integrazione della console grafica.

Tenere distinti questi livelli rende la diagnosi più rapida. Se manca /dev/kvm, il problema precede libvirt. Se una macchina esiste ma non parte, si osservano definizione, storage e log. Se il sistema ospite funziona ma la console è poco reattiva, si controllano il dispositivo grafico e l’agente Spice. Le fonti di progetto per approfondire sono QEMU, libvirt e Spice.

Verificare i prerequisiti

L’accelerazione richiede una CPU compatibile e la virtualizzazione abilitata nel firmware della macchina. Prima di installare software, verificare l’esistenza del dispositivo KVM e dei moduli. Un risultato vuoto non si risolve aggiungendo opzioni a QEMU: occorre controllare firmware, supporto del processore e caricamento del modulo appropriato.

test -e /dev/kvm && echo "KVM disponibile"
lsmod | grep -E '^kvm'
ls -l /dev/kvm

I permessi su /dev/kvm determinano quali utenti possono usare l’accelerazione. Non allargare i permessi del device manualmente: la gestione tramite gruppi e regole del sistema è più leggibile e sopravvive ai riavvii. Dopo una modifica ai gruppi è necessario aprire una nuova sessione affinché l’appartenenza venga riletta.

Installare gli strumenti

Una postazione grafica può partire dai pacchetti qemu-system-x86, qemu-utils, libvirt-daemon-system, libvirt-clients e virt-manager. Sono nomi presenti nei depositi Debian correnti e coprono l’emulatore per macchine x86, gli strumenti per le immagini disco, il servizio di gestione, il client virsh e l’interfaccia grafica.

sudo apt update
sudo apt install qemu-system-x86 qemu-utils libvirt-daemon-system libvirt-clients virt-manager

Dopo l’installazione, aprire virt-manager e verificare la connessione locale. In alternativa, sudo virsh list --all interroga libvirt e distingue un problema del demone da un problema dell’interfaccia grafica. Evitare di lanciare l’intero ambiente grafico come root: concedere soltanto l’accesso necessario attraverso i meccanismi previsti dal pacchetto.

Immagini disco e pool di storage

QCOW2 è utile per un laboratorio perché supporta allocazione dinamica e copie differenziali. L’allocazione dinamica riduce lo spazio iniziale, ma non sostituisce il monitoraggio: il file cresce quando il sistema ospite scrive dati. Un pool di storage separato aiuta a controllare capacità, permessi e backup senza mescolare immagini ISO, dischi attivi e copie.

qemu-img create -f qcow2 laboratorio.qcow2 40G
qemu-img info laboratorio.qcow2

Il numero indicato è la capacità virtuale, non una prenotazione garantita sul filesystem host. Prima di creare o espandere un disco controllare lo spazio reale disponibile. Non modificare un’immagine mentre la macchina che la usa è attiva; per cloni e copie coerenti usare le funzioni di libvirt o arrestare correttamente l’ospite.

Creare la macchina virtuale

Nel wizard di virt-manager scegliere l’origine di installazione, assegnare CPU e memoria con moderazione, selezionare il disco e lasciare la rete predefinita in NAT se non serve esporre servizi. La rete NAT permette in genere all’ospite di uscire e all’host di raggiungerlo, senza inserirlo direttamente nella rete fisica. Un bridge è adatto quando la macchina deve apparire come un nodo distinto, ma richiede una configurazione consapevole.

Prima dell’avvio rivedere il riepilogo: tipo di firmware, ordine di boot, modello del disco, interfaccia di rete e origine di installazione. Per sistemi moderni, i dispositivi virtio offrono in genere un percorso efficiente; la compatibilità del sistema ospite resta però il criterio decisivo. Conservare una nota delle scelte rende più semplice ricreare il laboratorio.

Rete virtuale e diagnosi

libvirt può definire reti isolate, NAT o collegate a un bridge. Partire dall’opzione meno esposta che soddisfa il test. Se l’ospite non ottiene un indirizzo, controllare prima la scheda virtuale, poi lo stato della rete libvirt e infine la configurazione interna dell’ospite. Cambiare contemporaneamente modello della scheda, firewall e DNS nasconde la causa.

sudo virsh net-list --all
sudo virsh domiflist nome-macchina
sudo virsh domifaddr nome-macchina

L’ultimo comando dipende dalla disponibilità di informazioni dall’ospite e può non mostrare nulla anche quando la rete funziona. La console dell’ospite rimane quindi essenziale. Per testare, separare sempre connettività IP, risoluzione DNS e raggiungibilità della singola porta.

Console grafica e agente Spice

Spice gestisce la console grafica e alcune integrazioni, ma non è necessario esporre una porta pubblica per usare virt-manager localmente. La configurazione predefinita mediata da libvirt è preferibile a un listener aperto su tutte le interfacce. Per migliorare ridimensionamento e integrazione del puntatore, installare spice-vdagent nel sistema ospite quando è supportato.

sudo apt install spice-vdagent
systemctl --user status spice-vdagent 2>/dev/null || true

Il secondo comando è solo diagnostico e la forma esatta del servizio può dipendere dall’ambiente grafico. Verificare prima che il pacchetto sia installato e che la sessione grafica dell’ospite sia attiva. Non disattivare autenticazione o cifratura per aggirare un problema di connessione remota.

Arresto, punti di ripristino e copie

Una macchina virtuale va spenta dal sistema ospite quando possibile. Lo spegnimento forzato equivale a togliere alimentazione a un computer fisico e può lasciare filesystem o applicazioni in stato incoerente. Un punto di ripristino è utile prima di una prova breve, ma non è un backup: dipende spesso dal disco di base e accumula complessità nel tempo.

sudo virsh list --all
sudo virsh shutdown nome-macchina
sudo virsh domstate nome-macchina

Per un backup definire insieme configurazione, dischi e stato dell’applicazione. Verificare poi il ripristino in una posizione separata. Le immagini sparse possono occupare più spazio quando copiate con strumenti che non preservano i buchi; controllare dimensione apparente e spazio effettivo prima e dopo.

Prestazioni senza scorciatoie

Le prestazioni dipendono da CPU assegnate, memoria, pressione sullo storage, modello dei dispositivi e carico dell’host. Più risorse virtuali non significano automaticamente più velocità: assegnare tutte le CPU può danneggiare la reattività dell’host, mentre una memoria eccessiva può provocare swapping. Misurare un collo di bottiglia alla volta.

Per il disco osservare latenza e saturazione sull’host; per la CPU distinguere tempo realmente consumato dall’ospite e attesa; per la rete confrontare il percorso virtuale con quello fisico. Cache aggressive e modalità non sicure possono produrre numeri migliori ma aumentano il rischio in caso di interruzione. In un laboratorio affidabile, coerenza e ripetibilità vengono prima del picco.

Conservare e confrontare le definizioni

Una macchina gestita da libvirt è descritta da una definizione che comprende dispositivi, ordine di avvio, memoria, CPU, interfacce e riferimenti allo storage. Prima di una modifica importante, leggere il riepilogo con virsh dominfo ed esportare la definizione in una posizione protetta. Il file descrittivo è utile per un confronto, ma non contiene i dati del disco e non costituisce da solo un backup della macchina.

sudo virsh dominfo nome-macchina
sudo virsh dumpxml nome-macchina > nome-macchina.xml

Nel file possono comparire indirizzi, percorsi locali e identificativi della macchina: trattarlo quindi come configurazione sensibile. Per applicare un cambiamento, preferire virt-manager o i comandi di libvirt alla modifica di file interni. Confrontare la definizione prima e dopo consente di individuare subito un controller rimosso, un percorso cambiato o una interfaccia collegata alla rete sbagliata.

Se la macchina deve essere trasferita, inventariare separatamente definizione, volumi, firmware virtuale e dipendenze di rete. Sul nuovo host controllare disponibilità dei percorsi e compatibilità dei dispositivi prima del primo avvio. Accendere contemporaneamente due copie con identici indirizzi e identità di rete può creare conflitti: la copia di verifica va isolata finché non è stata adattata.

Diagnosi per strati

Quando l’avvio fallisce, raccogliere prima lo stato senza cambiare la definizione. Verificare che libvirt elenchi la macchina, che i volumi referenziati esistano e siano leggibili dal processo corretto, quindi consultare gli eventi di servizio e il log associato al dominio. Un messaggio relativo al disco richiede un’indagine diversa da un errore della rete virtuale o del firmware.

sudo virsh list --all
sudo virsh domblklist nome-macchina
sudo virsh domiflist nome-macchina
sudo journalctl -b --no-pager | grep -i -E 'libvirt|qemu|kvm'

Il filtro sul journal è un punto di partenza e può includere righe non pertinenti. Conservare l’errore completo con le righe vicine, poi controllare il servizio o il componente nominato. Riavviare ripetutamente tutti i demoni, cambiare permessi in modo globale o ricreare la macchina cancella indizi senza dimostrare la causa.

Per un ospite avviato ma lento, separare avvio, interazione grafica, disco e rete. Una console rallentata non dimostra che la CPU virtuale sia satura; un download lento non dimostra un problema del bridge. Misurare dall’host e dall’ospite nello stesso intervallo, modificare un solo parametro e annotare l’esito rende il test confrontabile.

Una procedura di collaudo

  1. Confermare accelerazione KVM e permessi del device.
  2. Creare una VM piccola sulla rete NAT predefinita.
  3. Installare il sistema ospite e applicare gli aggiornamenti.
  4. Verificare arresto e riavvio attraverso libvirt.
  5. Controllare console Spice e ridimensionamento.
  6. Creare una copia di prova e documentare il ripristino.

Quando ogni passaggio produce un risultato osservabile, un errore rimane confinato. Questo approccio è più lento nei primi minuti e molto più rapido quando il laboratorio cresce. Per i dettagli delle opzioni usare le pagine di manuale e la documentazione dei progetti collegati, perché sintassi e capacità seguono le versioni installate.