1,203 26/03/2026 07/04/2026 7 min

Il sintomo arriva quasi sempre così: la VM parte, ma non prende IP. In virsh domiflist vedi ancora bridge=virbr0, mentre il guest resta isolato.

Nel log trovi spesso una riga poco utile ma molto indicativa:

error: internal error: Child process (VIR_BRIDGE=virbr0 /usr/libexec/qemu-bridge-helper ...) failed

In altri casi il problema nasce dopo uno snapshot LVM o un restore veloce. Il bridge esiste, ma non sale in tempo, oppure libvirt perde la configurazione del dispositivo di rete.

Qui non facciamo teoria. Partiamo dal guasto reale e lo chiudiamo passo passo.

Prerequisiti

  • Host Linux con KVM e libvirt.
  • VM collegata a un bridge, di solito virbr0 o un bridge custom come br0.
  • Accesso root o sudo.
  • Se usi snapshot, almeno uno tra LVM, qcow2 o backup via libvirt.

Note: i comandi cambiano poco tra Debian, Ubuntu e RHEL-like. Cambiano di più i nomi dei servizi e il path dei file di rete.

Step numerati

1) Verifica il sintomo dal lato host e dal lato guest

Prima di toccare la configurazione, devi capire se il problema è nel bridge, in libvirt o nel guest.

Dal lato host controlla stato rete e definizione VM.

ip link show virbr0
virsh domiflist nome-vm
virsh dumpxml nome-vm | sed -n '/<interface/,/<\/interface>/p'

# Output:

5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Interface  Type     Source   Model    MAC
vnet0      bridge   virbr0   virtio   52:54:00:ab:cd:ef

Se virbr0 risulta DOWN o manca del tutto, il guest non ha una strada valida. Se invece il bridge è UP ma la VM non naviga, il problema è più avanti.

Dal guest controlla IP e gateway.

ip a
ip r
ping -c 3 192.168.122.1

# Output:

default via 192.168.122.1 dev eth0
192.168.122.10/24 dev eth0 scope global dynamic

Warning: se il guest non vede neppure il gateway del bridge, non inseguire DNS o firewall applicativi. Prima va ripristinato il livello 2.

2) Controlla se libvirt ha perso il bridge dopo lo snapshot

Dopo snapshot e restore, può succedere che la definizione XML della VM punti a un bridge non più coerente con l’host.

Apri la configurazione della VM con libvirt.

virsh edit nome-vm

Verifica questa parte:

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

Se hai sostituito il bridge con un nome diverso, assicurati che esista davvero sull’host.

bridge link
ip link show br0

# Output:

3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
4: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> master virbr0 ...

Se la VM è stata clonato o ripristinata da snapshot, il MAC può cambiare oppure restare agganciato a una vecchia lease. In quel caso conviene liberare il lease DHCP del bridge e riavviare la VM.

virsh destroy nome-vm
virsh start nome-vm

# Output:

Domain nome-vm destroyed
Domain nome-vm started

Se usi virt-manager, il controllo è ancora più semplice: apri la VM, vai su Dettagli → NIC e verifica che la sorgente sia Bridge device e non una rete NAT diversa.

3) Riporta su il bridge prima del boot della VM

Il caso più comune è questo: la VM parte prima che il bridge sia davvero operativo. Succede dopo reboot, soprattutto con network manager, systemd-networkd o script custom.

Su sistemi con file di rete, controlla la configurazione del bridge.

cat /etc/network/interfaces
cat /etc/systemd/network/*.network
nmcli connection show

Se il bridge è gestito da NetworkManager, verifica che la connessione sia autoconnect.

nmcli connection show virbr0
nmcli connection modify virbr0 connection.autoconnect yes
nmcli connection up virbr0

# Output:

Connection successfully activated

Se usi systemd-networkd, controlla che il servizio parta prima di libvirtd.

systemctl enable systemd-networkd
systemctl edit libvirtd

Inserisci un override semplice:

[Unit]
After=network-online.target
Wants=network-online.target

Poi ricarica e riavvia.

systemctl daemon-reload
systemctl restart libvirtd

# Output:

libvirtd.service: Restarted successfully

Note: su alcune distro il servizio può essere virtqemud invece di libvirtd. Il concetto non cambia: libvirt deve partire dopo la rete.

4) Se usi snapshot LVM, verifica che il restore non abbia rotto il mapping

Qui il problema è più subdolo. Il disco torna su correttamente, ma la VM riparte con timing diverso, e il bridge sembra sparire solo perché la NIC non si inizializza in tempo.

Controlla lo stato degli snapshot e delle logical volume coinvolte.

lvs -a -o lv_name,lv_attr,origin,lv_size,devices
lvdisplay /dev/vg/vm_disk

# Output:

vm_disk_snap  swi-a-s---  vm_disk  20.00g  /dev/nvme0n1p3(12345)
vm_disk       -wi-ao----          80.00g  /dev/nvme0n1p3(12300)

Se il restore ha cambiato device o path, aggiorna la definizione della VM o il symlink usato da libvirt.

virsh dumpxml nome-vm > /root/nome-vm.xml
virsh define /root/nome-vm.xml

Se invece il disco è corretto, ma la NIC no, aumenta il timeout di avvio del guest solo come test.

<on_reboot>restart</on_reboot>
<clock offset='utc'/>

Non è la cura definitiva. Serve solo a capire se il guest era in ritardo rispetto al bridge.

5) Se il bridge è custom, ricrealo in modo persistente

Un bridge creato a mano con ip link add vive fino al reboot. Dopo, sparisce. Se la VM punta a quel bridge, il problema è garantito.

Con NetworkManager puoi farlo da GUI su molte distro desktop o server con cockpit. Vai in Rete → Aggiungi connessione → Bridge, poi associa la scheda fisica come porta.

Da terminale, l’equivalente è questo:

nmcli connection add type bridge ifname br0 con-name br0 ipv4.method manual ipv4.addresses 10.10.10.2/24 ipv4.gateway 10.10.10.1 ipv4.dns 1.1.1.1
nmcli connection add type ethernet ifname enp3s0 con-name br0-port master br0
nmcli connection up br0
nmcli connection up br0-port

# Output:

Connection successfully activated

Se usi una rete libvirt NAT invece del bridge fisico, il fix è diverso. In virt-manager vai su Modifica → Dettagli connessione → Virtual Networks e verifica che la rete sia Autostart.

Note: questa opzione è disponibile solo se il bridge è gestito da libvirt, non se è un bridge Linux puro.

6) Sistema la NIC del guest se il driver non sale

In alcuni guest, soprattutto dopo clone o restore, il problema non è la rete host ma il driver della scheda virtuale.

Controlla il modello della NIC in XML. virtio è la scelta migliore per performance, ma in guest vecchi può servire e1000 per il primo boot.

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

Se il guest non ha ancora i driver, passa temporaneamente a e1000, avvia la VM, installa i driver, poi torna a virtio.

virsh edit nome-vm

# Output:

Domain nome-vm XML configuration edited.

Warning: non lasciare e1000 in produzione se ti serve throughput alto. È un piano di recupero, non la configurazione finale.

Verifica finale

Dopo il fix, devi vedere tre cose insieme.

  • Il bridge è UP all’avvio.
  • La VM mostra una vnet agganciata al bridge corretto.
  • Il guest riceve IP, gateway e raggiunge l’host.

Esegui questi controlli rapidi:

ip link show virbr0
virsh domiflist nome-vm
ping -c 3 192.168.122.1
virsh net-dhcp-leases default

# Output:

virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP>
vnet0 bridge virbr0 virtio
MAC                IP address     Hostname
52:54:00:ab:cd:ef  192.168.122.10 vm01

Se vuoi una prova più concreta, fai un reboot dell’host e controlla che la VM salga senza interventi manuali. È il test che separa una correzione vera da un workaround fragile.

Troubleshooting

Errore 1: error: internal error: Child process ... qemu-bridge-helper ... failed

Causa: il bridge indicato nell’XML non esiste, non è autorizzato, oppure non è ancora UP.

Fix:

ip link show virbr0
cat /etc/qemu/bridge.conf
systemctl restart libvirtd

Se usi qemu-bridge-helper, assicurati che il bridge sia consentito in /etc/qemu/bridge.conf.

Errore 2: Network is not active

Causa: la rete libvirt o il bridge non sono stati avviati automaticamente.

Fix:

virsh net-start default
virsh net-autostart default
nmcli connection up br0

Errore 3: RTNETLINK answers: File exists

Causa: stai cercando di creare un bridge o una porta già presente con un nome duplicato.

Fix:

ip link show br0
nmcli connection delete br0-port
nmcli connection add type ethernet ifname enp3s0 con-name br0-port master br0

Conclusione

Quando una VM KVM perde rete dopo reboot o snapshot, il colpevole è quasi sempre il bridge, non il guest. La correzione giusta mette in ordine avvio rete, definizione libvirt e modello NIC.

Il prossimo passo concreto è semplice: fai un reboot completo dell’host e verifica che la VM torni online senza manualità. Se fallisce ancora, salva virsh dumpxml e i log di boot: lì c’è quasi sempre la causa reale.

Note: se vuoi, nel prossimo articolo posso mostrarti come evitare questo problema con una rete bridge persistente gestita da NetworkManager o systemd-networkd.