1,645 25/03/2026 07/04/2026 8 min

Il caso è meno raro di quanto sembri: un host KVM riparte, il bridge sembra vivo, ma il guest non prende più rete. Poco dopo, un snapshot qcow2 creato in fretta durante l’incidente rifiuta il revert con un errore di coerenza. Qui non serve la teoria. Serve capire dove si è rotto il chain: libvirt, bridge Linux, MAC filtering, oppure il file backing dello snapshot.

Lo scenario è quello tipico di produzione. Un VPS o un nodo bare metal ospita una VM critica. Dopo un riavvio dell’host, il guest resta isolato. In parallelo, un’operazione di rollback fatta con poca calma lascia uno snapshot che non si può più usare con fiducia. Il punto non è solo “far tornare su la VM”. Il punto è ripristinarla senza perdere dati e senza peggiorare lo stato del disco virtuale.

Prerequisiti

Questo articolo assume:

  • host Linux con KVM/libvirt;
  • guest su qcow2;
  • bridge Linux, non NAT;
  • accesso root o sudo all’host;
  • console del guest disponibile tramite virsh console o accesso out-of-band;
  • possibilità di fermare la VM per qualche minuto se il ripristino lo richiede.

Note: i comandi sono pensati per ambienti Debian, Ubuntu e RHEL-like. I nomi delle interfacce possono cambiare. Il metodo resta lo stesso.

Warning: se hai già creato snapshot multipli, non cancellare file a mano prima di capire la catena. Con qcow2, un errore di fretta può rendere irrecuperabile il backup più utile.

Step numerati

1) Capire se il problema è il bridge o il guest

Il sintomo tipico è semplice: la VM parte, ma non risponde a ping o SSH. Prima di toccare la configurazione del guest, va verificato il bridge host. Se il bridge non ha porte, il problema non è dentro la VM.

ip link show type bridge
bridge link show
ip addr show br0
virsh domiflist vm-prod

# Output:

3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
4: enp3s0 master br0 state forwarding
Interface  Type       Source   Model    MAC
vnet0      bridge     br0      virtio   52:54:00:ab:cd:ef

Se br0 è UP ma non vedi vnet0, libvirt ha perso il collegamento della NIC virtuale. Se vedi vnet0 ma il bridge non ha porte fisiche, il problema è lato host, non nel guest.

2) Verificare la definizione XML della NIC e il binding al bridge

Molti incidenti nascono da una modifica minima. Un bridge rinominato, un profilo di rete non caricato, oppure un XML della VM che punta a un bridge inesistente. Con libvirt, il nome del bridge è il primo indizio utile.

virsh dumpxml vm-prod | sed -n '/<interface/,/<\/interface>/p'
virsh net-list --all
virsh net-info default

# Output:

<interface type='bridge'>
  <source bridge='br0'/>
  <model type='virtio'/>
</interface>

Se il bridge nel file XML non esiste più, il guest può partire senza rete oppure non agganciare l’interfaccia corretta dopo il reboot. Non correggere a occhi chiusi. Prima conferma il nome reale del bridge con ip link.

Warning: se la VM è definita con rete libvirt “default” e non con bridge esplicito, il sintomo può sembrare identico. In realtà stai guardando due architetture diverse.

3) Ripristinare il bridge dopo reboot senza rompere l’host

Qui il problema classico è la persistenza. Il bridge esiste in memoria, ma non viene ricreato all’avvio. In altri casi, la scheda fisica non è enslaved al bridge perché NetworkManager o systemd-networkd ha applicato una configurazione incompleta.

nmcli con show
nmcli con mod br0 connection.autoconnect yes
nmcli con up br0
bridge link show

# Output:

enp3s0 master br0 state forwarding
vnet0 master br0 state forwarding

Se usi systemd-networkd, il controllo equivalente va fatto sui file .network e .netdev. L’obiettivo non è “farlo andare una volta”. L’obiettivo è farlo tornare identico al prossimo reboot.

networkctl status br0
networkctl status enp3s0

Note: su host con più NIC, il bridge deve avere una sola porta fisica attiva. Due uplink messi male sullo stesso bridge possono creare loop o ARP instabile.

4) Se il guest è vivo ma non ha rete, controllare driver e MAC

Se il bridge è corretto e la VM è collegata, il problema può stare nel guest. Un update del kernel o un cambio di udev può rinominare l’interfaccia. Oppure il guest non ha più il driver virtio caricato e cade su un nome diverso.

virsh console vm-prod
ip link
ip addr
journalctl -b | grep -iE 'dhcp|eth|ens|enp|virtio'

# Output:

2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000

Se la NIC ha un nome diverso, il problema può essere un file di configurazione interno che punta a eth0 e non a ens3. Se la MAC è cambiata, DHCP e firewall possono trattare il guest come un host nuovo.

Un controllo rapido utile è questo:

virsh domifaddr vm-prod --source agent
virsh domiflist vm-prod

# Output:

Name       MAC address          Protocol     Address
ens3       52:54:00:ab:cd:ef     ipv4         192.0.2.44/24

5) Isolare lo snapshot qcow2 che non torna indietro

Il secondo guasto è più subdolo. Il revert fallisce, o la VM riparte ma mostra dati vecchi, filesystem sporco, oppure un errore sul backing file. Qui il problema è la catena qcow2, non la rete.

qemu-img info /var/lib/libvirt/images/vm-prod.qcow2
virsh snapshot-list vm-prod --tree
virsh snapshot-dumpxml vm-prod snap-pre-update

# Output:

file format: qcow2
backing file: /var/lib/libvirt/images/vm-prod-base.qcow2
virtual size: 80 GiB

Se lo snapshot è esterno, la catena deve essere intatta. Se il backing file è stato spostato, rinominato o compattato senza merge, il revert può fallire con una richiesta di file mancante o con inconsistenza del formato.

Warning: non eseguire qemu-img rebase o commit senza una copia offline del disco. Sono operazioni potenti. In emergenza, diventano irreversibili molto in fretta.

6) Fare rollback sicuro con VM ferma e verifica della chain

Se il revert è necessario, ferma la VM e valida prima il disco. Il rollback “a caldo” è una scorciatoia che spesso lascia il guest peggio di prima.

virsh shutdown vm-prod
virsh domstate vm-prod
qemu-img check /var/lib/libvirt/images/vm-prod.qcow2
virsh snapshot-revert vm-prod snap-pre-update --running

# Output:

Domain 'vm-prod' reverted to snapshot 'snap-pre-update'

Se qemu-img check segnala errori, fermati. Prima copia il file, poi valuta qemu-img convert per ricreare un qcow2 pulito. Il rollback non deve appoggiarsi a un disco già corrotto.

cp --reflink=auto /var/lib/libvirt/images/vm-prod.qcow2 /var/lib/libvirt/images/vm-prod.qcow2.bak
qemu-img convert -O qcow2 /var/lib/libvirt/images/vm-prod.qcow2 /var/lib/libvirt/images/vm-prod-fixed.qcow2

# Output:

Image created successfully

7) Ripristinare il guest e validare performance di base

Il ripristino non è completo finché non misuri il comportamento del guest. Dopo uno snapshot o un revert, il disco può funzionare ma essere lento. Questo capita con caching incoerente, driver mancanti o storage host saturo.

virsh start vm-prod
virsh domifstat vm-prod
virsh domblkstat vm-prod vda
virsh dominfo vm-prod

# Output:

rx_bytes  124000
rx_packets 820
rd_req    1200
wr_req    430

Se i contatori rete salgono ma il guest non risponde, il problema è interno alla VM. Se i contatori disco sono alti e la latenza resta pessima, vai a guardare lo storage host e i parametri cache del disco virtuale.

Un controllo utile lato guest è questo:

iostat -xz 1
systemd-analyze blame
ethtool -i ens3

Note: dopo un revert, alcune applicazioni vedono timestamp vecchi, lock scaduti o token invalidati. Non è un errore di KVM. È una conseguenza del ripristino.

Verifica finale

Prima di chiudere l’incidente, fai questa sequenza minima:

  • il bridge br0 è UP e ha la porta fisica corretta;
  • la vNIC del guest è presente in virsh domiflist;
  • il guest ottiene IP e gateway;
  • lo snapshot revertito è quello giusto;
  • qemu-img check non segnala errori residui;
  • le performance base del guest non mostrano I/O anomalo;
  • il reboot dell’host non rompe di nuovo il binding del bridge.

Se una sola voce manca, non considerare l’incidente chiuso. Il rischio maggiore è la ricorrenza al prossimo reboot.

Troubleshooting

Errore 1: “error: Requested operation is not valid: network 'br0' is not active”

Causa: la VM punta a un bridge o a una rete libvirt non avviata dopo il boot.

Fix:

virsh net-start br0
virsh net-autostart br0
virsh domiflist vm-prod

# Output:

Network br0 started
Network br0 marked as autostarted

Errore 2: “error: unsupported configuration: snapshot is not compatible with external disk”

Causa: la catena qcow2 è stata alterata, o il tipo di snapshot non corrisponde al disco attuale.

Fix:

qemu-img info /var/lib/libvirt/images/vm-prod.qcow2
virsh snapshot-list vm-prod --tree
qemu-img check /var/lib/libvirt/images/vm-prod.qcow2

Errore 3: “qemu-img: Could not open '/var/lib/libvirt/images/vm-prod-base.qcow2': No such file or directory”

Causa: manca il backing file originale, spesso per spostamento, cleanup manuale o rename.

Fix:

find /var/lib/libvirt/images -name 'vm-prod-base.qcow2'
qemu-img rebase -u -b /nuovo/percorso/vm-prod-base.qcow2 /var/lib/libvirt/images/vm-prod.qcow2

Warning: usa -u solo se sai esattamente cosa stai facendo. Se sbagli il percorso, puoi rompere la chain in modo definitivo.

Conclusione

Quando una VM KVM perde rete dopo un reboot e uno snapshot qcow2 non si lascia più revertire, il problema quasi mai è unico. Di solito hai due guasti sovrapposti: bridge instabile e chain disco fragile.

La diagnosi corretta separa i piani. Prima rete, poi storage, poi rollback. Il prossimo passo concreto è trasformare questi controlli in una checklist post-reboot con virsh, qemu-img e un test automatico sul bridge.

Se vuoi evitare il bis, programma un controllo al boot dell’host che verifichi br0, la NIC fisica e l’ultimo snapshot valido prima che il traffico reale arrivi sulla VM.