KVM: bridge `virbr0` o `br0` dopo reboot?

Quando una VM KVM deve essere raggiungibile in rete, la scelta non è solo “configurare un bridge”: spesso il punto vero è quale architettura adottare. In molti ambienti libvirt si usano due approcci distinti: il bridge gestito da libvirt con rete NAT su virbr0, oppure un bridge di host reale, di solito br0, collegato alla scheda fisica. Entrambi funzionano, ma non risolvono gli stessi problemi.

Questo articolo confronta i due modelli in modo pratico: quando scegliere virbr0, quando passare a br0, quali sintomi aspettarsi dopo reboot o snapshot, e quali controlli fare per evitare VM isolate, IP irraggiungibili o performance strane. L’obiettivo è aiutare chi gestisce un host KVM a decidere in base a scenario, non per abitudine.

Diagnosi probabile

Se una VM KVM “sparisce” dalla rete dopo un riavvio, la causa più comune non è la VM in sé, ma l’architettura di rete scelta o la sua persistenza. Con virbr0 il servizio di rete virtuale può essere attivo, ma la VM resta dietro NAT e quindi non riceve mai un IP della LAN. Con br0, invece, il problema tipico è un bridge non agganciato correttamente alla NIC fisica, oppure una configurazione gestita da NetworkManager, systemd-networkd o ifupdown che non viene ricreata nel modo atteso al boot.

Un secondo caso frequente è lo snapshot: dopo un ripristino, la VM torna allo stato precedente ma la rete del guest o dell’host può essere cambiata nel frattempo. Questo crea sintomi ambigui: ping assente, DHCP che non risponde, SSH non raggiungibile, ma console VNC attiva e disco regolare. Se il tuo obiettivo è offrire una VM in LAN come un server fisico, br0 è in genere la strada giusta. Se invece ti serve isolamento, test rapidi o un ambiente da laboratorio, virbr0 è spesso più semplice e meno rischioso.

In termini operativi, la diagnosi si riassume così: problema di raggiungibilità esterna con virbr0 significa quasi sempre limite di NAT o port-forward, non guasto; con br0 significa quasi sempre bridge, VLAN, MTU, driver o persistenza della configurazione. Le performance percepite cambiano anche per questo: con NAT c’è un piccolo overhead e più variabili sul path di rete, con bridge reale la VM si comporta più come un nodo della LAN, ma richiede una configurazione host più rigorosa.

Verifiche immediate

Prima di cambiare qualsiasi cosa, conviene capire quale modello è già in uso e se il guasto è sul bridge, sul DHCP o sul profilo della VM.

1. Controlla le reti libvirt attive: il comando virsh net-list --all ti dice se default o una rete custom è attiva. Esito atteso: una rete “attiva” associata a virbr0 se stai usando NAT.
2. Verifica il bridge dell’host con ip link show e bridge link. Esito atteso: in caso di bridge reale, l’interfaccia fisica deve risultare slave di br0 e il bridge deve essere UP.
3. Controlla la VM: virsh domiflist NOMEVM. Scopo: verificare se la scheda virtuale è collegata a default, a br0 o a un altro switch virtuale.
4. Osserva il lease DHCP della VM, se usi NAT: in molte installazioni è in /var/lib/libvirt/dnsmasq/. Condizione di successo: il lease compare e la VM ottiene un indirizzo coerente con la subnet prevista.
5. Se il problema nasce dopo snapshot o restore, controlla il MAC della NIC virtuale e il profilo di rete del guest. Esito atteso: MAC invariato, altrimenti il DHCP può assegnare un IP diverso o il lease precedente può diventare inutile.

Un controllo rapido utile è anche dal guest: se la VM ha IP ma non esce, il problema è spesso gateway o firewall; se non ha IP, il punto è rete, bridge o DHCP. Con Linux guest, ip a e ip route bastano per distinguere quasi subito i due casi. Con Windows guest, lo stato della scheda e il gateway si vedono da “Connessioni di rete” o con ipconfig /all.

Soluzione consigliata passo-passo

La scelta più sicura dipende dallo scopo. Se il tuo obiettivo è avere una VM facilmente gestibile e isolata, resta su virbr0. Se invece la VM deve essere visibile come server nella LAN, usa br0. Non è una questione di “meglio o peggio”, ma di livello di esposizione e manutenzione.

Approccio 1: virbr0 con NAT, quando conviene

Usa questo modello se vuoi creare VM di test, ambienti temporanei, laboratori o macchine che devono navigare in uscita senza essere pubbliche in LAN. Il vantaggio principale è la semplicità: libvirt può creare la rete, dare DHCP alle VM e mantenere l’host separato.

1. Verifica che la rete default sia attiva in libvirt. Se non lo è, riattivala da virt-manager oppure con la rete predefinita di libvirt. Successo atteso: la VM riceve un IP dalla subnet virtuale, di solito qualcosa come 192.168.122.0/24.
2. Se ti serve accesso dall’esterno, usa port forwarding sul firewall dell’host o sul router. Scopo: esporre solo le porte necessarie, senza rendere la VM parte della LAN.
3. Controlla che DNS e gateway interni siano corretti. Esito atteso: la VM riesce a fare ping verso l’esterno e a risolvere nomi, mentre dall’esterno non è raggiungibile direttamente se non tramite inoltro porte.

Questo approccio è ideale anche quando fai snapshot frequenti. Il motivo è pratico: la rete resta più prevedibile, perché il guest parla con un DHCP e un gateway controllati dall’host. Se ripristini uno snapshot, di solito non devi rincorrere switch fisici, VLAN o policy della rete aziendale. Il limite è ovvio: non è la soluzione giusta per servizi che devono essere raggiunti con un IP della stessa LAN del resto dell’infrastruttura.

Approccio 2: br0 su NIC fisica, quando conviene

Questo è il modello da usare per server veri e propri: web server, database, reverse proxy, NAS virtualizzati, appliance o ambienti che devono essere visibili come host normali nella rete locale. La VM riceve un IP della LAN, può essere gestita da DHCP o statico, e non dipende dal NAT dell’host.

1. Crea un bridge persistente sull’host e collega la NIC fisica al bridge. Scopo: spostare l’indirizzo IP dell’host da eth0 o ens18 a br0.
2. Assegna alla VM la NIC virtuale collegata a br0. Esito atteso: il guest ottiene un IP della stessa rete del router o del DHCP aziendale.
3. Verifica la persistenza al reboot. Condizione di successo: dopo riavvio, il bridge è ancora UP, la NIC fisica è agganciata e la VM riparte con connettività.

Qui la parte delicata è la gestione dell’host. Se il bridge viene configurato male, puoi perdere accesso SSH alla macchina fisica. Per questo conviene applicare la modifica in finestra di manutenzione, con console locale o accesso out-of-band se disponibile, e con un piano di rollback pronto. In ambienti moderni, la configurazione può cambiare a seconda del gestore di rete: su NetworkManager conviene usare nmcli o il pannello grafico; su server minimal può essere più affidabile un profilo statico ben definito.

Se vuoi un criterio semplice per decidere: scegli virbr0 se vuoi semplicità e isolamento; scegli br0 se vuoi integrazione con la LAN e comportamento da server reale. La differenza pratica non è marginale: con br0 devi pensare a VLAN, MTU, spanning tree, eventuale bonding e policy della rete; con virbr0 pensi soprattutto a DHCP interno e forwarding.

Confronto pratico: prestazioni, snapshot e manutenzione

Dal punto di vista delle prestazioni, il bridge reale br0 è spesso preferibile per servizi che fanno molto traffico o hanno bisogno di latenza prevedibile. Il NAT di virbr0 aggiunge uno strato in più, non enorme ma presente, e complica l’analisi quando qualcosa rallenta. Se devi misurare una VM che serve pagine web, database o API, conviene osservare non solo la CPU del guest ma anche throughput, perdita pacchetti, latenze e saturazione dell’host.

Con snapshot e backup, invece, virbr0 è più comodo nei test: puoi tornare indietro spesso senza ricostruire la rete esterna. br0 è migliore in produzione quando vuoi che lo snapshot non alteri l’esposizione della macchina, ma richiede più attenzione nei restore. In particolare, se fai snapshot di dischi e poi cambi la configurazione della NIC virtuale, puoi ritrovarti con una VM che parte ma non torna online perché il naming del dispositivo nel guest, il MAC o il DHCP reservation non corrispondono più.

Dal punto di vista della manutenzione, virbr0 richiede meno tempo iniziale e meno conoscenza della rete fisica. br0 richiede più disciplina ma dà più controllo. È il classico compromesso tra “funziona subito” e “si integra bene nel resto dell’infrastruttura”. Se gestisci più host, VLAN o reti separate per produzione e test, il bridge reale diventa quasi obbligatorio. Se invece hai un solo server e poche VM interne, il NAT di libvirt può essere più che sufficiente.

Esempi di scelta in scenari reali

Un piccolo laboratorio di sviluppo con una VM Debian per provare aggiornamenti PHP, plugin WordPress o configurazioni di Apache può stare benissimo dietro virbr0. In questo caso ti interessa isolare il guest, fare snapshot frequenti e non esporlo in LAN. Se un test rompe la rete, il danno resta confinato.

Un server KVM che ospita un pannello come Plesk, un’applicazione ERP o un database MariaDB usato da altri host deve invece stare su br0. Qui il requisito è essere raggiungibile con un IP normale, integrabile nel monitoraggio e nelle regole firewall della rete. Anche eventuali backup agent, sistemi di monitoraggio o scanner di vulnerabilità funzionano più serenamente quando la VM appare come un host standard.

Un caso intermedio è la macchina bastion o jump host. Qui puoi usare br0 se serve accesso diretto dalla LAN, ma anche virbr0 con regole di port forwarding se vuoi limitare l’esposizione. La scelta dipende da quanto vuoi semplificare l’accesso rispetto a quanto vuoi restringere la superficie d’attacco.

Controlli finali / rollback

Prima di considerare chiusa la configurazione, fai sempre questi controlli finali:

1. Dal guest verifica IP, gateway e DNS. Successo atteso: ping verso gateway e risoluzione nomi funzionanti.
2. Dal host verifica che il bridge o la rete libvirt restino attivi dopo un reboot di prova. Esito atteso: virbr0 o br0 presenti e in stato corretto.
3. Controlla accesso SSH, pannello o servizio applicativo della VM. Condizione di successo: il servizio è raggiungibile nello stesso modo atteso prima dello snapshot o del riavvio.
4. Se hai cambiato architettura e qualcosa non torna, fai rollback ripristinando la vecchia rete della VM e l’eventuale snapshot precedente della configurazione host. Nota: il rollback è più semplice se hai documentato MAC, subnet, gateway e file di configurazione modificati.

In pratica, la regola da ricordare è questa: virbr0 per semplicità e isolamento; br0 per integrazione e prestazioni più lineari. Se il tuo problema nasce dopo reboot o snapshot, la priorità non è “aggiustare il ping” in astratto, ma capire quale dei due modelli stai usando, dove si interrompe la catena rete-bridge-DHCP e quali elementi devono sopravvivere al riavvio.

Assunzione: l’host usa libvirt/KVM su Linux e la VM deve restare raggiungibile in modo stabile dopo reboot e snapshot.