Come installare KVM su Oracle Linux 9

Prendere il controllo del layer di virtualizzazione su Oracle Linux 9

Su Oracle Linux 9 KVM è la strada giusta quando vuoi una virtualizzazione nativa, con overhead basso e integrazione pulita con libvirt. La parte davvero importante non è “installare il pacchetto”, ma verificare che l’host sia pronto: CPU con estensioni VT-x o AMD-V abilitate, modulo kernel disponibile, servizi attivi e rete pensata per le VM. Se salti questi controlli, la classica installazione “andata a buon fine” ti lascia comunque con guest che non partono o che non escono in rete.

Qui l’obiettivo è un host KVM funzionante, gestibile da CLI e pronto per creare VM con virt-install o via interfacce grafiche/remote basate su libvirt. Il punto di partenza è un Oracle Linux 9 aggiornato, con accesso root o privilegi sudo.

Verifica preliminare: CPU, kernel e stato dei servizi

Prima di installare qualsiasi cosa, controlla che la CPU esponga la virtualizzazione hardware e che il sistema non stia già usando un hypervisor alternativo. Questa è la parte che distingue un’installazione pulita da un debug inutile dopo il reboot.

1. Verifica le estensioni CPU:

egrep -c '(vmx|svm)' /proc/cpuinfo

Se il risultato è maggiore di zero, la CPU supporta la virtualizzazione. Se è 0, il problema non è KVM: devi abilitare VT-x/AMD-V nel BIOS/UEFI o verificare che il nodo sia davvero un bare metal e non una VM senza nested virtualization.

2. Controlla che il modulo KVM sia disponibile:

lsmod | grep kvm

Su un host non ancora configurato può non comparire nulla: non è un errore. Dopo il caricamento dei moduli dovresti vedere almeno kvm e il modulo specifico della CPU, come kvm_intel o kvm_amd.

3. Controlla lo stato di libvirtd e dei socket:

systemctl status libvirtd
systemctl status virtlogd
systemctl status virtlockd

Su Oracle Linux 9 l’ecosistema libvirt è quello da usare per amministrare le VM in modo standard. Se i servizi non esistono ancora, è normale prima dell’installazione; dopo, devono risultare attivi o almeno abilitabili senza errori di unità mancanti.

Pacchetti da installare su Oracle Linux 9

Il set minimo per un host KVM con gestione via libvirt è composto da hypervisor, demone di gestione, strumenti CLI e dipendenze per la rete virtuale. In un ambiente server serio conviene installare anche gli strumenti di diagnostica, perché la differenza tra “funziona” e “funziona ma non so perché” si vede subito quando qualcosa non torna.

Installa i pacchetti principali:

sudo dnf install -y qemu-kvm libvirt virt-install virt-viewer virt-top edk2-ovmf bridge-utils cockpit-machines

Il pacchetto edk2-ovmf serve se vuoi avviare VM UEFI, che oggi è la scelta più sensata nella maggior parte dei casi. bridge-utils non è sempre indispensabile, ma resta utile in diversi scenari operativi e documenta chiaramente l’intenzione di usare bridge di rete. cockpit-machines è opzionale, ma utile se vuoi una gestione web integrata con Cockpit.

Se preferisci un set più minimale, puoi partire con:

sudo dnf install -y qemu-kvm libvirt virt-install

Il resto lo aggiungi solo se ti serve davvero. Meno pacchetti vuol dire meno superficie d’attacco e meno elementi da mantenere aggiornati.

Attivare i servizi e caricare i moduli

Una volta installati i pacchetti, abilita i servizi di libvirt e carica il supporto KVM. Su Oracle Linux 9 il percorso standard è chiaro e non richiede passaggi creativi.

1. Abilita e avvia libvirt:

sudo systemctl enable --now libvirtd

2. Verifica che il demone sia effettivamente operativo:

systemctl is-active libvirtd
virsh list --all

Il comando virsh list --all deve rispondere senza errori di connessione al socket. Se vedi problemi di accesso, spesso è un tema di permessi utente o di socket non attivo.

3. Carica i moduli KVM, se non sono già presenti:

sudo modprobe kvm
sudo modprobe kvm_intel   # su CPU Intel
sudo modprobe kvm_amd     # su CPU AMD

4. Rendi persistente il caricamento automatico solo se necessario. In molte installazioni il kernel carica i moduli giusti da solo, ma in ambienti particolari conviene fissare il comportamento con un file in /etc/modules-load.d/:

echo kvm | sudo tee /etc/modules-load.d/kvm.conf

Se vuoi aggiungere il modulo specifico della CPU, puoi inserirlo nello stesso file. È una modifica reversibile e semplice da rimuovere in caso di troubleshooting.

Controllare che KVM sia davvero in uso

Il fatto che i pacchetti siano installati non significa che il kernel stia effettivamente usando l’accelerazione hardware. La verifica corretta passa da pochi controlli, e uno solo sbagliato basta per scoprire troppo tardi che stai facendo emulazione software.

1. Controlla i device KVM:

ls -l /dev/kvm

Se il device esiste, il kernel sta esponendo l’interfaccia necessaria. Se manca, torna ai moduli e alla virtualizzazione nel BIOS/UEFI.

2. Verifica che il driver sia riconosciuto da libvirt:

virt-host-validate

Questo è uno dei comandi più utili perché riassume in modo concreto i punti deboli dell’host: virtualizzazione, device, networking, bridge, permessi. Non sostituisce il ragionamento, ma ti dice subito dove guardare.

3. Leggi il log del servizio se qualcosa non torna:

journalctl -u libvirtd -b --no-pager

Per errori di avvio guest o problemi di rete, questo è spesso più utile del resto della documentazione. Cerca riferimenti a qemu, bridge, permission denied o SELinux.

Permessi utente e accesso a libvirt

Se non vuoi lavorare sempre come root, devi autorizzare il tuo utente a parlare con libvirt. È un passaggio banale, ma quando manca sembra un problema di hypervisor e invece è solo un problema di gruppi.

Aggiungi l’utente ai gruppi necessari:

sudo usermod -aG libvirt,kvm $USER

Poi scollegati e rientra nella sessione, oppure verifica con:

id

Nel risultato devono comparire libvirt e kvm. Se lavori su un server condiviso, il principio di privilegio minimo resta valido: non aggiungere utenti a questi gruppi senza motivo.

Rete: bridge consigliato invece di NAT “di default”

La rete è il punto dove molte installazioni KVM restano “funzionanti” solo sulla carta. NAT va bene per test, ma in produzione o in un host che deve ospitare servizi reali il bridge è quasi sempre la scelta più pulita. Così le VM stanno sulla stessa rete L2 dell’host e sono gestibili in modo prevedibile.

Su Oracle Linux 9 la gestione di rete passa spesso da NetworkManager. Crea un bridge, poi sposta l’interfaccia fisica sotto il bridge. L’idea è che l’host mantenga il suo indirizzo sul bridge, non sulla NIC fisica.

Esempio con nmcli:

sudo nmcli con add type bridge ifname br0 con-name br0 ipv4.method auto ipv6.method auto
sudo nmcli con add type bridge-slave ifname enp1s0 master br0 con-name br0-slave-enp1s0
sudo nmcli con up br0
sudo nmcli con up br0-slave-enp1s0

Sostituisci enp1s0 con la tua interfaccia reale. Se la macchina è remota, questa è una modifica da fare con attenzione: il rischio è perdere la connettività se il bridge non viene configurato correttamente. Il rollback, in caso di problema, è riportare l’indirizzo IP sulla connessione originale con NetworkManager o da console locale.

Verifica il bridge con:

ip addr show br0
bridge link
nmcli con show --active

Se il bridge è corretto, vedrai l’IP sull’interfaccia br0 e la NIC fisica senza indirizzo proprio. Le VM dovranno poi collegarsi a br0 nel profilo di rete del loro dominio.

SELinux e firewall: non disattivarli per comodità

Su Oracle Linux 9 la tentazione di spegnere SELinux “per far partire tutto” è un errore classico. Di solito non serve. Se una VM non comunica o non parte, prima controlla il contesto del problema e i log AVC, poi eventualmente correggi la policy o il tipo di rete. Disabilitare SELinux sposta soltanto il problema, non lo risolve.

Controlla lo stato di SELinux:

getenforce
sestatus

Lo stato atteso è Enforcing o almeno Permissive durante il troubleshooting. Se trovi blocchi, guarda i log:

sudo ausearch -m avc -ts recent
sudo journalctl -t setroubleshoot --no-pager

Per il firewall, apri solo ciò che serve. Un host KVM con bridge e guest pubblici potrebbe non richiedere regole speciali sul bridge stesso, ma se usi servizi di gestione remota o network particolari devi verificare la policy attiva. Il controllo base resta:

sudo firewall-cmd --state
sudo firewall-cmd --list-all

Se usi Cockpit, la porta 9090/tcp va aperta solo se il servizio è esposto e davvero necessario:

sudo firewall-cmd --permanent --add-service=cockpit
sudo firewall-cmd --reload

Creare la prima VM di prova

La verifica finale dell’installazione non è “libvirtd gira”, ma “una VM si crea, si avvia e risponde sulla rete prevista”. Il modo più rapido è creare una macchina di test con virt-install.

Esempio minimale con immagine ISO locale:

sudo virt-install \
  --name test-ol9 \
  --memory 2048 \
  --vcpus 2 \
  --disk size=20,bus=virtio \
  --cdrom /var/lib/libvirt/boot/OracleLinux-R9-Ux-x86_64-dvd.iso \
  --network bridge=br0,model=virtio \
  --os-variant oracle9 \
  --graphics vnc

Se l’ISO non è nel path indicato, sostituiscilo con quello reale. Non inventare percorsi: verifica prima con ls o con il file manager del tuo ambiente. La parte importante è che il disco sia virtio e che la rete sia agganciata al bridge corretto.

Controlla lo stato della VM:

virsh list --all
virsh domifaddr test-ol9

virsh domifaddr funziona bene quando il guest ha un agente o un meccanismo di discovery disponibile; se non restituisce nulla, non significa necessariamente che la VM sia guasta. In quel caso verifica dal lato guest o dalla tabella DHCP/ARP della rete.

Problemi tipici e come riconoscerli in fretta

Ci sono tre errori ricorrenti che valgono quasi sempre la pena di controllare per primi.

1. Virtualizzazione disabilitata nel BIOS/UEFI. Sintomo: /dev/kvm assente, virt-host-validate segnala fallimenti sulla CPU. Conferma con egrep -c '(vmx|svm)' /proc/cpuinfo. Rimedi: abilitare VT-x/AMD-V e riavviare.

2. Bridge configurato male. Sintomo: host raggiungibile localmente ma VM senza rete, oppure perdita di connettività dopo il cambio. Conferma con ip addr show br0 e bridge link. Rimedi: correggere la connessione NetworkManager e, se necessario, fare rollback alla configurazione precedente.

3. Permessi o SELinux. Sintomo: errori di accesso a libvirt, VM che non si avviano, denial nei log. Conferma con journalctl -u libvirtd -b e ausearch -m avc -ts recent. Rimedi: aggiungere l’utente ai gruppi corretti, ripristinare i contesti, non disabilitare SELinux in modo permanente senza motivo operativo.

Gestione quotidiana e manutenzione

Una volta completata l’installazione, la parte più importante è mantenere l’host in uno stato prevedibile. Aggiorna regolarmente il sistema, monitora spazio disco e memoria, e non lasciare crescere immagini disco e snapshot senza controllo. Un host KVM in saturazione non si comporta bene, soprattutto se le VM condividono lo stesso storage locale.

Controlli utili da tenere in routine:

df -h
free -h
virsh list --all
virsh domstats test-ol9

Se usi storage file-based, controlla anche la directory dei dischi virtuali, tipicamente sotto /var/lib/libvirt/images/. Se invece integri LVM, i volumi logici vanno osservati con la stessa attenzione degli altri componenti di produzione.

Per aggiornamenti del sistema:

sudo dnf update -y

Dopo gli update del kernel, pianifica il reboot e ricontrolla che /dev/kvm, libvirtd e il bridge siano ancora coerenti. È il tipo di verifica che costa due minuti e evita mezz’ora di debugging dopo il riavvio.

Decisione pratica: quando KVM su Oracle Linux 9 è la scelta giusta

Se hai bisogno di VM Linux o Windows con controllo diretto dell’host, KVM su Oracle Linux 9 è una scelta solida: supporto nativo nel kernel, stack libvirt maturo, tooling standard e integrazione semplice con bridge, storage locale o remoto. La configurazione giusta non è quella più corta, ma quella che ti lascia un host leggibile, manutenibile e recuperabile senza trucchi.

In pratica: installa i pacchetti minimi, verifica l’hardware, abilita i servizi, costruisci la rete con criterio, lascia SELinux attivo e valida tutto con una VM di prova. Se uno di questi passaggi fallisce, non andare avanti “sperando”: fermati, leggi i log, correggi il singolo punto e riprova. È così che un host KVM resta affidabile nel tempo.