Come installare KVM su Ubuntu 20.04 LTS Server

KVM su Ubuntu 20.04 LTS Server: cosa serve davvero

Su Ubuntu 20.04 LTS Server KVM non è “solo un hypervisor”: è la combinazione tra supporto hardware della CPU, modulo kernel, librerie di virtualizzazione e un metodo chiaro per esporre la rete alle VM. Se salti una verifica iniziale, ti ritrovi con VM che partono ma non vedono la rete, oppure con un host che virtualizza in emulazione lenta invece che in accelerazione hardware.

La strada più lineare è questa: confermi il supporto CPU, installi i pacchetti base, abiliti il servizio di gestione, poi decidi se restare su NAT o passare a un bridge. Per un server reale, il bridge è quasi sempre la scelta più utile perché lascia alle VM indirizzi IP raggiungibili in modo nativo sulla LAN.

Prima di toccare il sistema, chiarisci lo stato atteso: host Ubuntu 20.04 aggiornato, CPU con estensioni di virtualizzazione, pacchetti `qemu-kvm` e `libvirt` installati, rete gestita in modo coerente con l’architettura del server. Lo stato osservato tipico, quando qualcosa non va, è una VM che non parte, un errore su `libvirtd`, oppure una scheda di rete che resta isolata dietro NAT senza che fosse il comportamento richiesto.

Verifica preliminare della CPU e del modulo KVM

Il primo controllo non è il package manager, ma l’hardware. Senza virtualizzazione assistita dalla CPU, il setup può risultare incompleto o inutilmente lento. Su un host Intel cerchi VMX, su AMD cerchi SVM.

Esegui questi comandi:

egrep -c '(vmx|svm)' /proc/cpuinfo
lsmod | grep kvm
kvm-ok 2>/dev/null || true

Se il primo comando restituisce `0`, il problema è a livello di CPU o BIOS/UEFI: la virtualizzazione potrebbe essere disabilitata nel firmware. Se `lsmod` non mostra `kvm_intel` o `kvm_amd`, il modulo non è caricato; in quel caso il kernel può non averlo attivato automaticamente o il supporto firmware può essere incompleto. Se `kvm-ok` dice che KVM non può essere usato, fermati lì e chiudi il gap verificando l’impostazione di virtualizzazione nel BIOS/UEFI, senza andare avanti a installare pacchetti inutilmente.

Su macchine virtuali annidate, il discorso cambia: devi avere nested virtualization abilitata dall’host. Senza quel pezzo, KVM nel guest può installarsi ma non accelerare davvero. Se non sai se sei in nesting, controlla il vendor della CPU e l’output di `systemd-detect-virt`.

Pacchetti da installare su Ubuntu 20.04

Su un server minimale la base corretta è questa:

sudo apt update
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst cpu-checker

`qemu-kvm` porta l’emulatore con accelerazione KVM. `libvirt-daemon-system` avvia il demone di gestione. `libvirt-clients` aggiunge gli strumenti a riga di comando. `bridge-utils` è ancora utile in molti ambienti, anche se la bridge configurata via Netplan può non richiederlo strettamente. `virtinst` è comodo per creare VM da CLI. `cpu-checker` ti dà `kvm-ok`, utile per un controllo rapido.

Dopo l’installazione, verifica subito che i servizi siano presenti e attivi:

systemctl status libvirtd --no-pager
virsh --version
virsh list --all

Se `libvirtd` non è attivo, non forzare subito cambi di configurazione: guarda i log. Il punto di partenza è quasi sempre `journalctl -u libvirtd -b`. Lì trovi errori di socket, permessi, o conflitti con altri demoni che usano la stessa rete o lo stesso storage.

Abilitare i gruppi corretti per amministrare le VM

Per evitare di lavorare sempre come root, aggiungi l’utente amministrativo ai gruppi giusti. In pratica, il gruppo `libvirt` è il più importante per usare `virsh` senza privilegi elevati; spesso serve anche `kvm` per l’accesso ai device di virtualizzazione.

sudo usermod -aG libvirt,kvm $USER

La modifica non è immediata sulla sessione corrente: fai logout/login oppure apri una nuova shell e verifica con:

id
virsh -c qemu:///system list --all

Se `virsh` restituisce un errore di autenticazione o accesso negato, il gruppo non è stato applicato alla sessione oppure il socket di libvirt richiede una policy diversa. In quel caso non inventare permessi a caso: controlla l’appartenenza ai gruppi e l’accesso a `/var/run/libvirt/libvirt-sock`.

Rete: NAT va bene per test, bridge serve quasi sempre in produzione

Qui si decide gran parte della qualità dell’installazione. Con NAT la VM esce su Internet, ma dall’esterno non è raggiungibile senza regole aggiuntive. Con un bridge la VM riceve un indirizzo sulla stessa rete dell’host e si comporta come una macchina fisica. Per ambienti di hosting, lab condivisi o servizi che devono essere visibili in LAN, il bridge è la scelta più pulita.

Su Ubuntu 20.04 puoi configurare il bridge con Netplan. Prima identifica l’interfaccia fisica, ad esempio `ens3`, `enp0s31f6` o simili:

ip link
ip addr

Poi crea o modifica un file in `/etc/netplan/`, per esempio `/etc/netplan/01-br0.yaml`. Esempio con DHCP sulla bridge:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: no
  bridges:
    br0:
      interfaces: [ens3]
      dhcp4: yes
      parameters:
        stp: false
        forward-delay: 0

Applica con prudenza, perché un errore di YAML o un’interfaccia sbagliata ti può tagliare fuori dalla macchina. Prima di confermare, usa:

sudo netplan try

Se tutto è corretto, conferma la configurazione. Se perdi connettività, il rollback è semplice: ripristina il file precedente o correggi l’interfaccia, poi riesegui `netplan try`. Il blast radius qui è l’accesso di rete dell’host, quindi questa è la parte dove serve più disciplina.

Creare la prima VM con virt-install

Una volta che libvirt funziona e la rete è pronta, puoi creare una VM in modo ripetibile. `virt-install` è più utile di una GUI se stai documentando un processo o devi rifarlo più volte.

sudo virt-install \
  --name ubuntu-test01 \
  --ram 2048 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/ubuntu-test01.qcow2,size=20,bus=virtio \
  --os-variant ubuntu20.04 \
  --network bridge=br0,model=virtio \
  --graphics none \
  --console pty,target_type=serial \
  --location 'http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/' \
  --extra-args 'console=ttyS0,115200n8 serial'

L’esempio usa installazione via rete e console seriale, utile su server headless. Se preferisci ISO locale, sostituisci `--location` con `--cdrom /percorso/ubuntu-20.04.iso`. Il formato `qcow2` è comodo perché supporta snapshot e crescita dinamica, quindi è più flessibile del raw in molti casi d’uso.

Dopo il primo avvio, controlla lo stato:

virsh list --all
virsh dominfo ubuntu-test01
virsh console ubuntu-test01

Se la VM non prende rete, il problema non è quasi mai “KVM non funziona”, ma più spesso il bridge non è collegato all’interfaccia giusta, oppure il guest usa un modello NIC non ideale. `virtio` è la scelta giusta nella maggior parte dei casi. Se hai dubbi, controlla dal guest con `ip a` e dal host con `bridge link` o `ip link show br0`.

Storage: disco, permessi e prestazioni

Il percorso standard per le immagini è `/var/lib/libvirt/images/`. È una scelta comoda perché segue le convenzioni di libvirt e semplifica backup e inventory. Se usi storage separato, meglio montarlo in modo stabile e documentato, anziché spargere dischi virtuali in directory improvvisate.

Controlla spazio e inode prima di creare più VM:

df -h /var/lib/libvirt/images
df -i /var/lib/libvirt/images
ls -lh /var/lib/libvirt/images

Se il filesystem è quasi pieno, le VM possono andare in errore in modo poco elegante, soprattutto durante installazioni o aggiornamenti del sistema guest. Il sintomo classico è un disco che non cresce, un guest che si blocca su I/O, oppure un log con errori di write failure. In quel caso la soluzione minima è liberare spazio o spostare l’immagine su storage adeguato, poi verificare che il servizio riparta senza corruzione.

Per prestazioni migliori, il controller virtio e il bus virtio sono la scelta standard. Se devi fare tuning serio, il passo successivo è valutare cache mode, I/O thread e backing storage, ma non partire da lì: prima assicurati che la VM funzioni in modo prevedibile.

Gestione quotidiana con virsh

Per un server amministrato bene, `virsh` è il pannello operativo reale. Ti permette di avviare, fermare, definire e ispezionare le VM senza dipendere da una GUI. I comandi base sono pochi ma vanno usati con metodo.

virsh list --all
virsh start ubuntu-test01
virsh shutdown ubuntu-test01
virsh reboot ubuntu-test01
virsh domifaddr ubuntu-test01

`virsh domifaddr` funziona bene se il guest ha strumenti e integrazione adeguati, ma non prenderlo come unica fonte di verità. Se non mostra nulla, usa anche `arp`, `ip neigh`, o la console del guest. La diagnostica migliore è sempre quella che incrocia host e guest, non un solo comando isolato.

Per vedere la definizione XML della VM e capire davvero come è costruita, usa:

virsh dumpxml ubuntu-test01

Questo è utile quando devi fare audit o migrare configurazioni. Ti dice rete, disco, firmware, driver e opzioni della macchina virtuale senza dover andare a memoria.

Accesso remoto, sicurezza minima e superficie d’attacco

KVM in sé non è il problema di sicurezza; il problema è come esponi gli strumenti di gestione. Su un server che ospita VM, la superficie d’attacco da tenere stretta è soprattutto quella di libvirt, SSH e qualsiasi console remota. Non aprire servizi inutili e non lasciare porte di management esposte senza filtro.

Se usi SSH per amministrare il nodo, tieni l’accesso a chiave, limita l’accesso root e conserva log sufficienti per l’audit minimo. Per libvirt, evita configurazioni permissive senza necessità. Se devi collegarti da remoto, meglio farlo tramite canali già controllati, non esponendo socket o interfacce amministrative su rete pubblica senza motivo.

Controlla anche che il nodo sia aggiornato:

sudo apt update
sudo apt upgrade

Se il server è in produzione, pianifica l’aggiornamento con finestra e rollback. Un aggiornamento del kernel può cambiare il comportamento di KVM, del networking o dei driver storage. Non è un motivo per evitare patching, ma per farlo con controlli prima e dopo.

Problemi tipici e come chiuderli senza perdere tempo

Il primo errore comune è installare i pacchetti giusti su un host con virtualizzazione disabilitata nel BIOS. Sintomo: `kvm-ok` fallisce e `egrep -c '(vmx|svm)' /proc/cpuinfo` torna `0`. Soluzione: entra nel firmware e abilita Intel VT-x o AMD-V.

Il secondo errore è una rete bridge configurata male. Sintomo: la VM parte, ma non prende connettività o l’host perde accesso dopo `netplan apply`. Verifica il nome dell’interfaccia, usa `netplan try`, e tieni a portata di mano una console out-of-band se stai lavorando da remoto.

Il terzo errore è confondere il demone di gestione con il supporto hardware. `libvirtd` può essere attivo anche se KVM non è realmente disponibile. Per questo conviene controllare sia il servizio sia il modulo kernel, non solo uno dei due. Se vuoi una verifica sintetica, `virt-host-validate` è un buon riassunto operativo dello stato dell’host.

virt-host-validate

Se quel controllo segnala warning su network, storage o CPU, trattalo come un elenco di gap da chiudere, non come un messaggio decorativo. È spesso il modo più rapido per passare da “installato” a “utilizzabile davvero”.

Checklist finale per un host KVM pulito

Un’installazione fatta bene non si misura dal fatto che un comando è andato a buon fine, ma dal fatto che puoi ripeterla e mantenerla. La checklist minima è questa:

1. CPU con virtualizzazione abilitata e verificata con `kvm-ok` o `egrep -c '(vmx|svm)' /proc/cpuinfo`.
2. Pacchetti base installati: `qemu-kvm`, `libvirt-daemon-system`, `libvirt-clients`, `virtinst`.
3. Servizio `libvirtd` attivo e leggibile con `systemctl status libvirtd`.
4. Utente amministrativo nel gruppo `libvirt` e sessione aggiornata.
5. Rete definita: NAT per test, bridge per uso serio.
6. Storage dimensionato e monitorato su `/var/lib/libvirt/images/` o percorso equivalente.
7. Prima VM creata, avviata e raggiungibile dalla rete prevista.

Se vuoi fare un passo in più, documenta anche la versione del kernel, il tipo di rete usata e la definizione XML della VM. Sono dettagli che sembrano secondari finché non devi ripristinare un host, migrare una macchina o capire perché una VM su un secondo nodo si comporta diversamente.

Assunzione: il server è Ubuntu 20.04 LTS aggiornato, con accesso amministrativo locale o via SSH e possibilità di intervenire sul firmware se la virtualizzazione CPU non è già attiva.