Dépannage réseau KVM/libvirt

Ce guide de dépannage réseau KVM/libvirt couvre les problèmes les plus fréquents : VM sans IP, NAT cassé, bridge non fonctionnel, DNS KO, conflits Docker, firewall guest bloquant. Chaque section propose un diagnostic précis et une solution testée.

Ce que vous trouverez :

• Diagnostic Host vs Guest — identifier où ça coince (50% des pannes sont côté VM)
• Recettes par topologie — NAT, Bridge, DNS en onglets séparés
• Services modularisés — virtnetworkd vs libvirtd sur distros récentes
• Firewall backend — nftables/iptables selon votre distribution
• Pièges classiques — virsh domifaddr vide, virbr0 in use, conflits Docker

Utilisez l’arbre de décision pour aller directement à votre problème, ou parcourez les onglets NAT/Bridge/DNS.

Où est la panne : hôte ou VM ?

Avant de plonger dans le dépannage, identifiez où ça coince. 50% des pannes sont côté VM (guest), pas côté hôte.

Vérification	Côté	Commande
Réseau libvirt actif	Hôte	virsh net-list --all
Bridge existe	Hôte	ip link show virbr0 ou br0
Services libvirt	Hôte	systemctl status virtnetworkd
Interface up	VM	ip -br link
IP attribuée	VM	ip -br addr
Route par défaut	VM	ip route
DNS fonctionnel	VM	resolvectl status ou cat /etc/resolv.conf

Glissez pour voir

Diagnostic rapide côté VM

Exécutez ces commandes dans la VM pour un diagnostic rapide :

ip -br a                # interfaces et IPs
ip route                # route par défaut
ping -c2 192.168.122.1  # gateway NAT
ping -c2 8.8.8.8        # Internet
nslookup google.com     # DNS

Arbre de décision

0) Confirmer la topologie (sinon vous dépannez le mauvais réseau)

Avant tout diagnostic, vérifiez sur quelle topologie vous êtes réellement :

# Quelle interface la VM utilise ?
virsh domiflist ma-vm

# Quels réseaux libvirt existent ?
virsh net-list --all

Source affichée	Topologie	DHCP fourni par
default / virbr0	NAT	dnsmasq (libvirt)
br0	Bridge	DHCP du LAN
Autre nom	Réseau custom	Dépend de la config

Glissez pour voir

Multi-NIC : piège classique

Si la VM a 2 interfaces (une en NAT + une en bridge), elle peut avoir une IP sur l’une mais router sur l’autre. Symptôme : “IP OK mais pas Internet” alors que le NAT fonctionne.

# Dans la VM : quelle interface a la route par défaut ?
ip route | grep default

1) Pas d’IP dans la VM (ou 169.254.x.x)

• Côté hôte : Le réseau fournit-il du DHCP ?
  • NAT → Réseau default non démarré ou dnsmasq KO
  • Bridge → Bridge mal configuré
• Côté VM : Le client DHCP tourne-t-il ?
  • → DHCP client absent/cassé
• Cloud-Init / clone : machine-id, netplan
  • → Problème après clonage

2) IP OK, pas de gateway

• Firewall guest bloque → Firewall côté VM
• Mauvais réseau / route → VM connectée au mauvais bridge

3) Gateway OK, pas Internet (ping 8.8.8.8 KO)

• ip_forward désactivé → NAT vers Internet ne fonctionne pas
• Règles NAT absentes → Firewall backend
• Conflit Docker → Conflit avec Docker

4) Internet OK, DNS KO

• dnsmasq ne répond pas → DNS ne fonctionne pas
• systemd-resolved interfère → DNS cassé par systemd-resolved

5) Bridge ne marche pas / VM pas joignable depuis LAN

• Interface Wi-Fi ? → Bridge sur Wi-Fi
• STP / port-security / VLAN → VM bridge : pas d’IP du LAN
• MTU mismatch → Problème de MTU

6) Intermittent / après reboot / après Docker

• MTU qui change → Problème de MTU
• Docker écrase les règles → Conflit avec Docker
• Service libvirt down → Services libvirt

7) virsh domifaddr ne voit pas l’IP

• Source incorrecte → Piège : virsh domifaddr
• Guest agent manquant → Installer qemu-guest-agent

---

Test en escalier (diagnostic universel)

Exécutez ces commandes dans la VM pour identifier où ça coince :

# 1. Interface up et IP ?
ip -br link
ip -br addr

# 2. Ping gateway
ping -c2 192.168.122.1   # NAT
# ou
ping -c2 <gateway-lan>   # Bridge

# 3. Ping Internet
ping -c2 8.8.8.8

# 4. DNS
nslookup example.com

Résultat	Diagnostic	Section
(1) KO : pas d’IP	DHCP host ou guest	Pas d’IP
(1) OK, (2) KO	L2/L3 local, firewall guest	Firewall guest
(2) OK, (3) KO	NAT/forwarding	ip_forward + NAT
(3) OK, (4) KO	DNS	DNS

Glissez pour voir

---

Problèmes par topologie

NAT (default)

Réseau default non démarré

Symptôme : virsh net-list --all montre “default” en état “inactive”.

# Démarrer et activer au boot
virsh net-start default
virsh net-autostart default

Si ça échoue avec “Network is already in use by interface virbr0”, voir virbr0 already in use.

dnsmasq ne tourne pas

libvirt lance un processus dnsmasq pour fournir DHCP et DNS aux VMs. S’il est absent, pas de DHCP.

# Vérifier le processus
ps aux | grep dnsmasq | grep virbr0

Si absent :

# Redémarrer le réseau (relance dnsmasq)
virsh net-destroy default
virsh net-start default

Service réseau libvirt

Sur les distributions récentes, le réseau est géré par virtnetworkd (daemon modulaire), pas libvirtd. Vérifiez ce service :

systemctl status virtnetworkd
systemctl restart virtnetworkd

Vérifier les leases DHCP

Avant de supposer que le DHCP ne marche pas, vérifiez les baux existants :

# Voir les IPs attribuées par libvirt
virsh net-dhcp-leases default

# Ou directement le fichier
cat /var/lib/libvirt/dnsmasq/default.leases

Si la VM a un bail mais virsh domifaddr ne montre rien, c’est un problème de source (voir piège ci-dessous).

Piège : virsh domifaddr ne voit pas l’IP

virsh domifaddr peut renvoyer “rien” alors que la VM a une IP. Par défaut, il utilise la source “lease” qui peut être vide si le bail a expiré ou si la VM a une IP statique.

Testez les différentes sources :

virsh domifaddr ma-vm --source lease   # depuis les baux DHCP
virsh domifaddr ma-vm --source arp     # depuis la table ARP
virsh domifaddr ma-vm --source agent   # via qemu-guest-agent

Pour fiabiliser --source agent, installez qemu-guest-agent dans la VM :

# Debian/Ubuntu
sudo apt install qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

# RHEL/Rocky/Alma
sudo dnf install qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

NAT vers Internet ne fonctionne pas

Symptôme : La VM a une IP (192.168.122.x), peut ping la gateway (192.168.122.1), mais pas 8.8.8.8.

1. Vérifier ip_forward

   cat /proc/sys/net/ipv4/ip_forward
   # Doit être 1

   Si 0 :

   # Activer de façon permanente
   echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/99-ip-forward.conf
   sudo sysctl -p /etc/sysctl.d/99-ip-forward.conf

2. Vérifier les règles NAT (voir section Firewall backend)

3. Redémarrer le réseau libvirt pour régénérer les règles :

   virsh net-destroy default
   virsh net-start default

DHCP client absent ou cassé dans la VM

Symptôme : Côté hôte tout est OK (dnsmasq tourne, leases disponibles), mais la VM n’a pas d’IP.

C’est très fréquent avec les cloud images minimalistes ou après modification de la config réseau.

Diagnostic dans la VM :

# Interface up ?
ip -br link
# Si DOWN : sudo ip link set eth0 up

# Client DHCP actif ?
# Debian/Ubuntu (systemd-networkd)
systemctl status systemd-networkd

# Debian/Ubuntu (NetworkManager)
nmcli dev status

# RHEL/Rocky/Alma
nmcli connection show

Solutions selon le gestionnaire réseau :

systemd-networkd

# Vérifier la config
cat /etc/systemd/network/*.network

# Exemple de config DHCP
cat << 'EOF' | sudo tee /etc/systemd/network/20-dhcp.network
[Match]
Name=en* eth*

[Network]
DHCP=yes
EOF

# Redémarrer
sudo systemctl restart systemd-networkd

NetworkManager

# Voir les connexions
nmcli connection show

# Activer DHCP sur eth0
sudo nmcli connection modify "Wired connection 1" ipv4.method auto
sudo nmcli connection up "Wired connection 1"

netplan (Ubuntu)

# Vérifier la config
cat /etc/netplan/*.yaml

# Exemple de config DHCP
cat << 'EOF' | sudo tee /etc/netplan/01-dhcp.yaml
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
EOF

# Appliquer
sudo netplan apply

Problème après clonage (Cloud-Init)

Symptôme : Après clonage d’une VM, le réseau ne fonctionne plus ou est aléatoire.

Causes :

1. machine-id dupliqué : Le DHCP attribue la même IP à toutes les clones
2. Cloud-Init ne rejoue pas : La config réseau n’est pas régénérée
3. Netplan avec config statique : L’ancienne IP/MAC est hardcodée

Solutions :

# 1. Régénérer le machine-id
sudo rm /etc/machine-id
sudo systemd-machine-id-setup

# 2. Forcer Cloud-Init à rejouer
sudo cloud-init clean
sudo cloud-init init

# 3. Si netplan : vérifier qu'il n'y a pas de MAC/IP hardcodée
cat /etc/netplan/*.yaml

Avant de cloner

Pour éviter ces problèmes, utilisez virt-sysprep qui nettoie automatiquement machine-id, clés SSH, etc. :

virt-sysprep -d ma-vm-template

Bridge

Bridge mal configuré

Symptôme : La VM en mode bridge n’obtient pas d’IP du LAN.

1. Vérifier que le bridge existe

   ip link show br0

   Si “Device not found”, le bridge n’est pas créé. Voir recette bridge ifupdown.

2. Vérifier que l’interface physique est dans le bridge

   bridge link show
   # Doit montrer eno1 (ou votre interface) sous br0

3. Vérifier que l’IP est sur br0, pas sur l’interface physique

   ip addr show eno1   # ne doit PAS avoir d'IP
   ip addr show br0    # DOIT avoir l'IP

   Si l’IP est sur eno1, reconfigurer le bridge.

VM connectée au mauvais bridge

virsh domiflist ma-vm
# Vérifiez que "Source" indique br0 (pas virbr0)

Pour modifier :

virsh edit ma-vm
# Cherchez <interface type='bridge'> et corrigez <source bridge='br0'/>

VM bridge : pas d’IP du LAN

Symptôme : Bridge OK côté hôte, mais la VM n’obtient pas d’IP du serveur DHCP du LAN.

Causes possibles :

1. Le DHCP du LAN ne répond pas : testez avec une autre machine sur le même segment

2. STP bloque le trafic : le switch met 30s à converger

   # Désactiver STP sur le bridge (si pas de boucle)
   sudo ip link set br0 type bridge stp_state 0

3. MTU incompatible : voir Problème de MTU

Problème de MTU

Symptôme : DHCP OK, ping gateway OK, mais trafic applicatif intermittent (gros paquets perdus).

# Comparer les MTU
ip link show br0
ip link show eno1
# Doivent être identiques (généralement 1500)

Si vous êtes sur un réseau avec VLAN ou VPN, le MTU peut être réduit :

# Ajuster le MTU du bridge
sudo ip link set br0 mtu 1450

Bridge sur Wi-Fi

Le bridge L2 sur Wi-Fi est souvent impossible

La plupart des points d’accès Wi-Fi bloquent le bridge L2 car ils n’acceptent qu’une seule adresse MAC par client. C’est une limitation fondamentale, pas un bug de libvirt.

Symptômes :

• DHCP ne passe pas (pas d’IP pour la VM)
• ARP bizarre, paquets perdus
• Ça marche 5 minutes puis plus rien

Alternatives au bridge sur Wi-Fi :

Solution	Avantage	Inconvénient
NAT (default)	Fonctionne toujours	VM non joignable depuis LAN
Routed	VM joignable si routes configurées	Config manuelle
macvtap (vepa)	Parfois fonctionne	Dépend du driver Wi-Fi

Glissez pour voir

Configuration NAT (recommandé sur Wi-Fi) :

# Vérifier que la VM est sur le réseau NAT
virsh domiflist ma-vm
# Si elle est sur br0, la basculer sur default :
virsh edit ma-vm
# Modifier <source bridge='br0'/> en <source network='default'/>

DNS

DNS ne fonctionne pas

Symptôme : La VM peut ping 8.8.8.8 mais pas résoudre de noms (ping google.com échoue).

1. Vérifier la config DNS dans la VM

   # Systemd-resolved (Ubuntu, Fedora récent)
   resolvectl status
   
   # Ou classique
   cat /etc/resolv.conf

   En NAT, le DNS doit pointer vers 192.168.122.1 (le dnsmasq de libvirt).

2. Tester le DNS de libvirt

   # Depuis la VM
   nslookup google.com 192.168.122.1

   Si ça échoue, le dnsmasq de libvirt ne tourne pas. Côté hôte :

   ps aux | grep dnsmasq | grep virbr0

3. Redémarrer le réseau pour relancer dnsmasq

   virsh net-destroy default
   virsh net-start default

DNS cassé par systemd-resolved

Sur les distributions modernes, systemd-resolved peut interférer. Si /etc/resolv.conf pointe vers 127.0.0.53 :

# Vérifier la config effective
resolvectl status

Si le DNS upstream n’est pas correct, forcez-le :

# Dans la VM
sudo resolvectl dns eth0 192.168.122.1

---

Services libvirt : libvirtd vs virtnetworkd

Sur les distributions récentes, libvirt est modularisé. La partie réseau est gérée par virtnetworkd, pas libvirtd.

# Vérifier quel daemon est actif
systemctl status libvirtd       # daemon monolithique (ancien)
systemctl status virtnetworkd   # daemon réseau (nouveau)
systemctl status virtqemud      # daemon QEMU (nouveau)

Si virtnetworkd est arrêté

Le réseau libvirt ne fonctionnera pas, même si libvirtd tourne. Démarrez-le :

sudo systemctl enable --now virtnetworkd

Logs des services

# Daemon modularisé (préféré)
journalctl -u virtnetworkd --since "10 minutes ago"

# Daemon monolithique
journalctl -u libvirtd --since "10 minutes ago"

# Logs dnsmasq (si syslog)
sudo grep dnsmasq /var/log/syslog | tail -20

---

Firewall backend : nftables/iptables

libvirt gère automatiquement les règles firewall pour le NAT, mais selon le backend (iptables ou nftables), le comportement diffère.

Identifier le backend

# Fedora/RHEL 9+ : nftables par défaut
sudo nft list ruleset | grep -i libvirt | head -5

# Debian/Ubuntu : souvent iptables
sudo iptables -t nat -L -n | grep -i virbr

Vérifier les règles NAT

Les règles essentielles pour le NAT :

Règle	Rôle
MASQUERADE (POSTROUTING)	Traduit les IPs des VMs vers l’IP de l’hôte
ACCEPT (FORWARD)	Autorise le trafic des VMs vers l’extérieur
ACCEPT (INPUT)	Autorise DHCP (port 67) et DNS (port 53) vers dnsmasq

Glissez pour voir

# nftables
sudo nft list chain ip nat POSTROUTING 2>/dev/null | grep -i masq

# iptables
sudo iptables -t nat -S POSTROUTING | grep -i virbr
sudo iptables -S FORWARD | grep -i virbr

Règles absentes : régénérer

# Redémarrer le réseau régénère les règles
virsh net-destroy default
virsh net-start default

# Si ça ne suffit pas, redémarrer le daemon réseau
sudo systemctl restart virtnetworkd

Conflit avec d'autres firewalls

Si vous avez configuré manuellement iptables/nftables/firewalld, vos règles peuvent écraser celles de libvirt. Vérifiez que vos scripts ne vident pas les chaînes libvirt.

---

Conflit avec Docker

Docker et libvirt peuvent entrer en conflit : Docker modifie ip_forward, ajoute ses propres règles NAT, et peut interférer avec les bridges.

Diagnostic

# Voir tous les bridges
ip -br link | grep -E 'docker0|virbr0|br0'

# Vérifier les règles NAT de Docker vs libvirt
sudo nft list ruleset | grep -nE 'docker|libvirt' | head -20
# ou
sudo iptables -t nat -L -n | grep -E 'DOCKER|virbr'

Solutions

1. Docker désactive ip_forward au redémarrage : ajoutez explicitement dans sysctl :

   echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/99-ip-forward.conf

2. Collision de subnet : Docker utilise 172.17.0.0/16, libvirt 192.168.122.0/24. Normalement pas de conflit, mais vérifiez :

   ip route | grep -E '172.17|192.168.122'

3. Règles iptables écrasées : redémarrez le réseau libvirt après Docker :

   sudo systemctl restart docker
   virsh net-destroy default && virsh net-start default

---

Firewall côté VM (guest)

Symptôme : IP OK, ping gateway OK, mais rien d’autre ne passe.

C’est souvent le firewall de la VM qui bloque. Vérifiez dans la VM :

# iptables
sudo iptables -S | head -20

# nftables
sudo nft list ruleset 2>/dev/null | head -20

# UFW (Ubuntu)
sudo ufw status

# firewalld (RHEL/Fedora)
sudo firewall-cmd --list-all

Désactiver temporairement pour tester

# UFW
sudo ufw disable

# firewalld
sudo systemctl stop firewalld

# iptables (flush)
sudo iptables -F

Réactivez le firewall

N’oubliez pas de réactiver le firewall après le diagnostic !

---

Erreurs courantes

virbr0 already in use

Symptôme :

error: Failed to start network default
error: internal error: Network is already in use by interface virbr0

Causes :

1. Le bridge virbr0 existe mais n’est pas géré par libvirt
2. Collision avec un autre réseau libvirt

Diagnostic :

# Voir si virbr0 existe
ip link show virbr0

# Voir la définition du réseau
virsh net-dumpxml default | grep -E 'bridge|ip address'

# Vérifier les routes
ip route | grep 192.168.122

Solution :

# Si virbr0 est orphelin, le supprimer
sudo ip link delete virbr0 2>/dev/null

# Puis redémarrer
virsh net-start default

Avant de supprimer virbr0

Vérifiez qu’aucune VM n’utilise ce bridge :

virsh list --all
for vm in $(virsh list --name --all); do virsh domiflist $vm 2>/dev/null | grep virbr0; done

Le réseau default n’existe pas

Symptôme : virsh net-list --all ne montre pas “default”.

# Vérifier si le fichier XML existe
ls /etc/libvirt/qemu/networks/default.xml
ls /usr/share/libvirt/networks/default.xml

# Recréer depuis le template
virsh net-define /usr/share/libvirt/networks/default.xml
virsh net-start default
virsh net-autostart default

Si le fichier template n’existe pas, créez-le :

cat << 'EOF' | sudo tee /tmp/default-network.xml
<network>
  <name>default</name>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>
EOF

virsh net-define /tmp/default-network.xml
virsh net-start default
virsh net-autostart default

---

Restaurer une configuration fonctionnelle

Opérations destructrices

Ces commandes suppriment la configuration réseau. Assurez-vous de comprendre ce que vous faites et d’avoir un accès console à l’hôte.

Reset complet du réseau NAT default

# 1. Arrêter toutes les VMs utilisant ce réseau
for vm in $(virsh list --name); do
  if virsh domiflist $vm | grep -q default; then
    virsh shutdown $vm
  fi
done

# 2. Supprimer le réseau
virsh net-destroy default 2>/dev/null
virsh net-undefine default 2>/dev/null

# 3. Supprimer le bridge orphelin
sudo ip link delete virbr0 2>/dev/null

# 4. Recréer
virsh net-define /usr/share/libvirt/networks/default.xml
virsh net-start default
virsh net-autostart default

Reset du bridge (NetworkManager)

# 1. Supprimer le bridge
sudo nmcli connection delete br0 2>/dev/null
sudo nmcli connection delete bridge-slave-eno1 2>/dev/null

# 2. Réactiver la connexion directe
sudo nmcli connection up "Wired connection 1"

---

Commandes de diagnostic (récapitulatif)

État général

# Interfaces réseau
ip -br link
ip -br addr

# Bridges
bridge link show

# Routes
ip route

# Réseaux libvirt
virsh net-list --all

Pour le NAT

# ip_forward
cat /proc/sys/net/ipv4/ip_forward

# Règles NAT
sudo iptables -t nat -L -n -v 2>/dev/null | head -20
sudo nft list chain ip nat POSTROUTING 2>/dev/null

# Processus dnsmasq
ps aux | grep dnsmasq

# Leases DHCP
virsh net-dhcp-leases default
cat /var/lib/libvirt/dnsmasq/default.leases

Pour le Bridge

# Membres du bridge
bridge link show br0

# Adresses sur le bridge
ip addr show br0

# STP
cat /sys/class/net/br0/bridge/stp_state

---

À retenir

1. Séparez Host vs Guest : la moitié des pannes sont côté VM (firewall, DHCP client, DNS)
2. virsh domifaddr peut mentir : utilisez --source lease/arp/agent ou virsh net-dhcp-leases
3. virtnetworkd remplace libvirtd pour le réseau sur les distros modernes
4. Les règles firewall sont régénérées au redémarrage du réseau libvirt
5. Docker peut interférer : vérifiez ip_forward et l’ordre des règles NAT
6. “virbr0 in use” = bridge orphelin ou collision de réseau
7. Le firewall du guest est souvent le coupable quand “tout est OK côté hôte”
8. Testez toujours : ping gateway → ping 8.8.8.8 → nslookup

Prochaines étapes

Guide réseau KVM Comprendre NAT vs Bridge en détail

Port forwarding NAT Exposer un service d'une VM NAT

Bridge ifupdown Configurer un bridge sur Debian/Ubuntu

qemu-guest-agent Installer l'agent pour domifaddr fiable

Ressources

• Firewall and network filtering in libvirt — Documentation officielle NAT/firewall
• virtnetworkd manpage — Daemon réseau modulaire
• Libvirt Virtual Network NFTables — Backend nftables (Fedora)
• libvirt Networking — Wiki réseau NAT/Bridge
• QEMU guest agent — Documentation SUSE

FAQ - Questions fréquentes

Pourquoi ma VM KVM a une adresse IP en 169.254.x.x (APIPA) ?

Une IP 169.254.x.x (APIPA) signifie que la VM n'a pas reçu de réponse DHCP. Vérifiez que le réseau libvirt est actif (virsh net-list), que dnsmasq tourne, et redémarrez le réseau si nécessaire.

Pourquoi virsh domifaddr ne renvoie rien alors que ma VM a une IP ?

virsh domifaddr utilise par défaut les baux DHCP qui peuvent être vides. Essayez --source arp ou --source agent. Pour une détection fiable, installez qemu-guest-agent dans la VM.

Pourquoi le NAT fonctionne vers la gateway mais pas vers Internet ?

Ping gateway OK mais pas Internet = problème de NAT ou firewall. Vérifiez ip_forward (doit être 1), les règles MASQUERADE, et redémarrez le réseau libvirt pour régénérer les règles.

Pourquoi ma VM peut ping mais pas résoudre de noms DNS ?

Ping IP OK mais DNS KO = mauvaise config DNS. En NAT, /etc/resolv.conf doit pointer vers 192.168.122.1. Testez avec nslookup et redémarrez le réseau libvirt si dnsmasq ne répond pas.

Pourquoi l'erreur 'Network is already in use by interface virbr0' ?

L'erreur 'virbr0 already in use' signifie que le bridge existe mais n'est pas géré par libvirt. Supprimez le bridge orphelin avec 'ip link delete virbr0' puis redémarrez le réseau.

Pourquoi ma VM en bridge n'obtient pas d'IP du LAN ?

VM bridge sans IP : vérifiez que le bridge existe, que l'interface physique est dedans, que l'IP est sur br0 (pas l'interface), et que la VM est connectée au bon bridge. STP peut aussi causer un délai.

Comment savoir si c'est l'hôte ou la VM qui a un problème réseau ?

Côté hôte : virsh net-list, ip link, systemctl status virtnetworkd. Côté VM : ip link/addr, ip route, ping gateway. 50% des pannes sont côté VM (firewall, DHCP client, DNS).

Comment résoudre les conflits entre Docker et libvirt ?

Docker peut désactiver ip_forward et écraser les règles NAT. Forcez ip_forward dans sysctl et redémarrez le réseau libvirt après Docker pour régénérer les règles.

×

📖 Voir la documentation →