Proxmox « tap device already exists » : corriger les conflits réseau au démarrage des VM

Ce que l’erreur signifie vraiment (et ce qu’elle ne signifie pas)

Dans Proxmox (PVE), les VM sont typiquement lancées par pve-qemu-kvm (QEMU) qui crée une NIC virtuelle
et la connecte à un bridge Linux (comme vmbr0) via une interface tap.
L’interface tap est un périphérique réseau noyau représentant un endpoint de couche 2. QEMU ouvre /dev/net/tun,
demande au noyau un nom d’interface tap (souvent tap<vmid>i<n>),
puis Proxmox ajoute cette interface au bridge.

L’erreur « tap device already exists » signifie généralement l’un des cas suivants :

• Une interface tap obsolète existe dans l’espace de noms du noyau, laissée par une instance QEMU précédente
  qui est morte brutalement ou par un rechargement réseau à moitié exécuté.
• Une collision d’ID de VM (moins fréquente, mais réelle lors de clones ou de configs mal gérées) pousse Proxmox à essayer
  de réutiliser exactement le même nom de tap pour deux démarrages différents.
• Un processus QEMU en cours possède toujours le tap et Proxmox tente un second démarrage ou un démarrage forcé.
• La plomberie du bridge a échoué (hooks iptables/nftables, Open vSwitch, ordre de reload ifupdown2), laissant les taps dans des états étranges.

Ce que cela ne signifie pas : que votre NIC physique est « pleine », que Linux a manqué d’interfaces réseau,
ou que vous devriez redémarrer l’hôte par défaut. Redémarrer fonctionne dans le même sens que
couper le courant du bâtiment règle l’imprimante.

Idée paraphrasée de Werner Vogels : « You build it, you run it » — le retour d’exploitation fait partie de l’ingénierie, pas un détail.

Guide de diagnostic rapide

Quand cela arrive, vous voulez une réponse en minutes, pas un débat philosophique sur les bridges.
Voici l’ordre qui trouve le goulot le plus vite.

1) Confirmer qu’il s’agit vraiment d’une collision de nom de tap

• Vérifiez le journal de tâche du démarrage de la VM et copiez le nom exact du tap mentionné (tap100i0, etc.).
• Immédiatement listez les interfaces et recherchez ce tap.

2) Déterminer si un processus QEMU le possède encore

• Recherchez un processus kvm/qemu-system en cours pour le VMID.
• Vérifiez les descripteurs de fichier vers /dev/net/tun si nécessaire.

3) Vérifier l’appartenance au bridge et l’état du lien

• Le tap est-il déjà esclave de vmbr0 ?
• vmbr0 est-il up ? La NIC hôte est-elle présente ? Les réglages VLAN sont-ils cohérents ?

4) Décider : nettoyer seulement le tap, ou corriger le problème de cycle de vie sous-jacent

• Si QEMU est mort et le tap est obsolète : supprimez le tap et relancez la VM.
• Si QEMU est vivant : arrêtez proprement la VM ; si elle est bloquée, terminez le processus QEMU puis supprimez le tap.
• Si un reload réseau/automatisation est le déclencheur : arrêtez de recharger le réseau comme s’il s’agissait d’un économiseur d’écran.

Blague n°1 : Une erreur « tap device already exists » est Linux qui dit poliment : « Je ne suis pas fâché, je suis juste déçu que tu n’aies pas nettoyé ton bazar. »

Comment fonctionnent les dispositifs tap dans Proxmox/QEMU (suffisant pour être dangereux)

QEMU attache les NIC des VM à l’hôte de plusieurs manières courantes :

• TAP + bridge Linux (le plus courant dans PVE) : création d’une interface tap ; elle est esclave de vmbrX.
• TAP + Open vSwitch : même idée, couche de commutation et outils différents.
• Paires veth / SDN (dans certaines configurations) : noms différents, modes de défaillance différents, symptômes semblables.

Dans le PVE classique, le nom de l’interface tap est déterministe. Proxmox utilise un schéma de nommage comme :
tap<VMID>i<N>. Ainsi VM 100, index NIC 0 devient tap100i0.
La détermination est pratique jusqu’à ce qu’elle ne le soit plus : si tap100i0 existe, un nouveau démarrage ne peut pas le créer.

Un cycle de vie sain ressemble à ceci :

1. Proxmox lance QEMU pour le VMID.
2. QEMU demande une interface tap au noyau.
3. Les scripts PVE l’ajoutent au bridge, appliquent les règles du pare-feu, filtres VLAN, MTU, etc.
4. La VM fonctionne ; le tap transporte des trames Ethernet.
5. La VM s’arrête ; QEMU ferme le tap ; le noyau supprime généralement l’interface automatiquement.

Quand cela casse, c’est typiquement parce que l’étape 5 n’a pas été complétée. QEMU a crashé, a reçu SIGKILL, le réseau hôte a été rechargé en plein vol,
ou quelque chose d’externe (automatisation, supervision, un humain trop zélé) a fait une course avec le teardown.

Si vous utilisez le firewall PVE, il y a plus d’éléments en mouvement : bridges par-VM (fwbr*),
périphériques de pare-feu (fwln*, fwpr* selon l’époque), et application de règles. Les erreurs peuvent mentionner
des devices tap alors que le vrai problème est un hook du pare-feu qui a échoué et a laissé une plomberie partielle.

Faits intéressants & contexte historique

• Fait 1 : Les dispositifs TAP/TUN existent depuis les débuts de la virtualisation réseau sous Linux ; TUN est couche‑3 (IP), TAP est couche‑2 (Ethernet).
• Fait 2 : L’interface /dev/net/tun est une frontière pilote noyau qui a rendu pratique le réseau en espace utilisateur bien avant la mode des containers.
• Fait 3 : QEMU s’appuyait à l’origine sur le user-mode networking pour la commodité ; TAP a apporté performance et réalisme pour les charges de production.
• Fait 4 : Les bridges Linux précèdent les buzzwords SDN modernes ; ils sont ennuyeux dans le bon sens—tables de forwarding simples et comportement prédictible.
• Fait 5 : Le nommage déterministe utilisé par Proxmox (tap<vmid>i<n>) est un compromis délibéré : dépannage plus simple, risque plus élevé de collisions quand le nettoyage échoue.
• Fait 6 : ifupdown2 existe parce que l’ancien ifupdown peinait avec l’ordre des dépendances complexes ; c’est mieux, mais les reloads peuvent toujours être perturbateurs s’ils sont mal utilisés.
• Fait 7 : Open vSwitch a gagné en popularité car il offrait des fonctions de commutation programmable en logiciel des années avant que le bridge noyau n’obtienne des fonctionnalités équivalentes pour beaucoup d’usage.
• Fait 8 : Le pare-feu Proxmox s’intègre au niveau de l’hôte ; il crée des périphériques virtuels supplémentaires pour appliquer des politiques par-VM sans que la VM en soit consciente.

Tâches pratiques : commandes, sorties, décisions (12+)

Ci‑dessous des vérifications adaptées à la production. Chacune inclut : une commande, à quoi ressemble une sortie « bonne » ou « mauvaise »,
et la décision à prendre. Exécutez-les sur l’hôte Proxmox.

Task 1: Get the exact error and tap name from the VM start log

cr0x@server:~$ qm start 100
kvm: tap100i0: Device or resource busy
TASK ERROR: start failed: command '/usr/bin/kvm -id 100 ...' failed: exit code 1

Signification : Le noyau a refusé la création/l’attachement de l’interface tap. Le nom tap100i0 est votre clé primaire.
Décision : Ne redémarrez pas. Allez chercher tap100i0 et qui le possède.

Task 2: Check whether the tap interface exists right now

cr0x@server:~$ ip -d link show tap100i0
26: tap100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 6a:4b:3c:de:11:90 brd ff:ff:ff:ff:ff:ff promiscuity 1 minmtu 68 maxmtu 65535
    tun type tap pi off vnet_hdr on persist off

Signification : Le tap existe. Il peut être obsolète ou détenu par un QEMU toujours en activité.
Décision : Vérifiez le processus VM et l’appartenance au bridge avant de supprimer quoi que ce soit.

Task 3: Check if the VM is actually running (sometimes it is)

cr0x@server:~$ qm status 100
status: stopped

Signification : Proxmox pense qu’elle est arrêtée. Cela ne garantit pas que QEMU est mort.
Décision : Cherchez le(s) processus QEMU référant le VMID 100.

Task 4: Find QEMU process for the VMID

cr0x@server:~$ pgrep -a -f "qemu.*-id 100"
21477 /usr/bin/kvm -id 100 -name vm100 -m 8192 -smp 4 ...

Signification : QEMU est encore actif. Votre tap n’est pas obsolète ; il est en usage.
Décision : Arrêtez proprement la VM (ou tuez le processus bloqué) plutôt que de supprimer l’interface sous son pied.

Task 5: Attempt a clean stop; then confirm process exit

cr0x@server:~$ qm stop 100 --timeout 60
stopping vm: 100

cr0x@server:~$ pgrep -a -f "qemu.*-id 100" || echo "no qemu process"
no qemu process

Signification : L’arrêt propre a réussi.
Décision : Vérifiez si le tap a disparu automatiquement ; sinon, vous avez de la plomberie résiduelle.

Task 6: If QEMU is gone but tap remains, confirm it’s not enslaved and delete it

cr0x@server:~$ bridge link show dev tap100i0
26: tap100i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0

Signification : Il est toujours attaché à vmbr0.
Décision : Retirez-le du bridge d’abord, puis supprimez-le. Sinon vous pouvez laisser le bridge dans un état incohérent.

cr0x@server:~$ ip link set dev tap100i0 nomaster
cr0x@server:~$ ip link delete tap100i0

Signification : Tap supprimé.
Décision : Retentez le démarrage ; si le problème réapparaît, enquêtez sur la raison pour laquelle les taps ne sont pas nettoyés à l’arrêt/crash.

Task 7: If QEMU is stuck and won’t stop, kill the right process (safely)

cr0x@server:~$ qm stop 100 --timeout 10
stopping vm: 100
TASK ERROR: timeout waiting on systemd

cr0x@server:~$ pgrep -a -f "qemu.*-id 100"
21477 /usr/bin/kvm -id 100 -name vm100 -m 8192 ...

cr0x@server:~$ kill -TERM 21477
cr0x@server:~$ sleep 3
cr0x@server:~$ kill -KILL 21477

Signification : La VM était bloquée ; vous avez terminé QEMU de force.
Décision : Nettoyez maintenant tout tap ou bridge de pare-feu résiduel et vérifiez la cohérence du stockage pour la VM si elle était sous charge.

Task 8: List all taps; spot a pattern (mass leakage)

cr0x@server:~$ ip -o link show | awk -F': ' '{print $2}' | grep -E '^tap[0-9]+i[0-9]+$' | head
tap100i0
tap104i0
tap104i1
tap205i0

Signification : Vous voyez les dispositifs tap existants. Si vous voyez des taps pour des VM « arrêtées », le nettoyage est cassé.
Décision : Corrélez les taps avec l’état des VM avant de supprimer en masse.

Task 9: Map a tap to a VM config (confirm NIC index)

cr0x@server:~$ qm config 100 | grep -E '^net[0-9]+:'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=1,tag=20

Signification : La VM 100 net0 devrait être sur vmbr0, tag VLAN 20, pare-feu activé.
Décision : Si le tap existe mais la VM est arrêtée, concentrez-vous sur le chemin d’arrêt/le pare-feu plutôt que sur les bases du bridge.

Task 10: Check the bridge is healthy and has the right ports

cr0x@server:~$ bridge -d link show master vmbr0 | head -n 15
2: eno1 state UP priority 32 cost 100 hairpin off guard off root_block off fastleave off learning on flood on mcast_flood on
26: tap100i0 state UP priority 32 cost 2 hairpin off guard off root_block off fastleave off learning on flood on mcast_flood on

Signification : Le bridge voit la NIC physique et le tap (quand présent).
Décision : Si eno1 est manquant ou down, votre problème peut être un rechargement réseau raté, pas le nettoyage de tap.

Task 11: Check ifupdown2 / networking reload history (the usual suspect)

cr0x@server:~$ journalctl -u ifupdown2-pre -u ifupdown2 -u networking --since "2 hours ago" | tail -n 25
Dec 26 09:12:03 server ifupdown2[18210]: info: executing /usr/share/ifupdown2/sbin/ifreload -a
Dec 26 09:12:04 server ifupdown2[18210]: warning: vmbr0: port tap100i0 does not exist
Dec 26 09:12:06 server ifupdown2[18210]: error: vmbr0: bridge reload failed: Device or resource busy

Signification : Un reload a eu lieu ; il a buté sur des taps en plein milieu.
Décision : Évitez ifreload -a pendant les heures d’activité sur des hyperviseurs. Utilisez des changements ciblés et des fenêtres de maintenance.

Task 12: Check for a lock file or failed task holding state

cr0x@server:~$ ls -l /var/lock/qemu-server/ | head
-rw-r----- 1 root www-data 0 Dec 26 09:10 lock-100.conf

Signification : Un lock existe pour la VM 100. Il peut être légitime (opération en cours) ou obsolète (tâche crashée).
Décision : Vérifiez s’il y a une opération qm en cours. Ne supprimez pas les locks à l’aveugle à moins d’être sûr qu’aucune activité n’est en cours.

Task 13: Confirm no active qm operations for that VM

cr0x@server:~$ pgrep -a -f "qm (start|stop|migrate|clone|restore) 100" || echo "no active qm operation"
no active qm operation

Signification : Aucune opération qm évidente n’est en cours.
Décision : Si Proxmox refuse des actions à cause d’un lock, examinez les logs de tâche ; envisagez de supprimer le lock seulement après vérification que QEMU est arrêté et que les opérations de stockage ne tournent pas.

Task 14: Find who’s holding /dev/net/tun (advanced but decisive)

cr0x@server:~$ lsof -n /dev/net/tun | head -n 10
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
kvm     21477 root   19u   CHR  10,200      0t0  102 /dev/net/tun

Signification : Le PID 21477 possède /dev/net/tun. Si la VM est censée être arrêtée, vous avez trouvé votre fantôme.
Décision : Corrigez le cycle de vie du processus (arrêt propre, kill, investiguer pourquoi il est bloqué) avant d’entreprendre une chirurgie réseau.

Task 15: If Proxmox firewall is enabled, check for leftover fw bridges

cr0x@server:~$ ip -o link show | awk -F': ' '{print $2}' | grep -E '^(fwbr|fwln|fwpr)[0-9]+'
fwbr100i0
fwln100i0
fwpr100p0

Signification : Des périphériques spécifiques au pare-feu existent pour la VM 100.
Décision : Si la VM est arrêtée mais qu’ils restent, le chemin de teardown du pare-feu échoue—souvent dû à des tâches interrompues ou une application de règles ratée.

Task 16: Validate VLAN-aware bridge config vs VM tag usage

cr0x@server:~$ grep -nE '^(auto|iface|bridge-vlan-aware|bridge-vids|bridge-ports|mtu)' /etc/network/interfaces
12:auto vmbr0
13:iface vmbr0 inet static
17:    bridge-ports eno1
18:    bridge-stp off
19:    bridge-fd 0
20:    bridge-vlan-aware yes
21:    bridge-vids 2-4094
22:    mtu 1500

Signification : Le bridge VLAN-aware est activé et permet les tags 2–4094.
Décision : Si bridge-vlan-aware est off ou si bridge-vids exclut le tag VLAN de la VM, les démarrages peuvent échouer de façons étranges (y compris création partielle de device).

Blague n°2 : Les reloads réseau sur des hyperviseurs sont comme des « modifs rapides » d’un schéma de base de données—rapides jusqu’au moment où la réalité arrive.

Schémas de correction qui tiennent

Pattern A: Stale tap after crash → delete it, then investigate the crash path

Si QEMU est absent et que le tap reste, supprimer le tap est acceptable. Mais ne vous arrêtez pas là.
Les périphériques obsolètes signifient que quelque chose a interrompu le teardown normal. Trouvez ce « quelque chose », sinon cela se reproduira lors de la pire fenêtre de changement.

Coupables typiques :

• OOM du host tuant QEMU
• kill -9 manuel en situation de panique
• rechargement réseau pendant des événements du cycle de vie VM
• échecs de hooks de pare-feu laissant des devices partiels

Pattern B: “Stopped” VM but QEMU still running → fix state mismatch

Si qm status indique arrêté mais QEMU tourne toujours, vous avez un décalage entre le plan de gestion et le plan de données.
Cela peut arriver après une migration ratée, une opération d’arrêt bloquée, ou un redémarrage du démon de gestion au mauvais moment.

Procédure :

1. Confirmez le PID QEMU pour ce VMID.
2. Tentez un arrêt gracieux.
3. Si ça ne meurt pas, terminez-le et nettoyez les périphériques restants.
4. Puis regardez pourquoi il s’est bloqué : latence stockage, locks de sauvegarde, bug noyau, ou drivers invités défaillants.

Pattern C: Bridge reloads are causing tap collisions → stop reloading “everything”

ifupdown2 est puissant. Ce n’est pas magique. Recharger toute la pile réseau sur un hyperviseur avec des VM actives
est une excellente façon de créer des échecs éphémères et non reproductibles qui disparaissent dès que vous essayez de les déboguer.

Que faire à la place :

• Effectuez des changements ciblés : mettez à jour un seul stanza de bridge, appliquez un changement d’interface, validez, puis continuez.
• Planifiez les reloads réseau dans une fenêtre de maintenance avec plan de rollback.
• Si vous devez changer en live, migrez d’abord les VMs hors de l’hôte. Oui, c’est plus long. Mais ça évite le drame.

Pattern D: Proxmox firewall devices linger → treat firewall as a first-class dependency

Quand le pare-feu est activé par VM (firewall=1 dans la config VM), PVE insère des périphériques virtuels et des règles supplémentaires.
Si l’application des règles échoue (mismatch nftables/iptables, règles cassées, problèmes de modules noyau), vous pouvez vous retrouver avec des périphériques existants mais mal câblés.

Position pratique : si vous utilisez le pare-feu PVE, testez les reloads et mises à jour du pare-feu comme vous testez les upgrades de stockage. C’est du dataplane.

Pattern E: Open vSwitch environments → use OVS tools, not bridge tools

Si votre hôte Proxmox utilise OVS, les commandes bridge Linux peuvent vous induire en erreur. Un tap peut exister, mais être connecté (ou non) via OVS.
Confirmez votre stack : vmbr0 en tant que bridge Linux vs vmbr0 en tant que bridge OVS sont des bêtes différentes portant le même nom.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: VM start fails instantly; tap device exists; VM “stopped”

Cause racine : Interface tap obsolète laissée après crash/kill/reload.

Correction : Confirmez qu’aucun processus QEMU ne la possède ; retirez-la du bridge ; supprimez le tap ; retentez le démarrage. Puis enquêtez pourquoi QEMU est mort ou le teardown a échoué.

2) Symptom: VM shows “stopped” but you still see a QEMU process

Cause racine : Décalage d’état après arrêt/migration ratée ; tâche de gestion crashée ; redémarrage de démon au mauvais moment.

Correction : Arrêt gracieux ou terminer le PID QEMU ; nettoyer les taps restants ; vérifier les logs de tâche et l’historique de migration avant de relancer l’automatisation.

3) Symptom: Errors appear right after someone runs ifreload/ifupdown2

Cause racine : Le reload réseau en concurrence avec la création du tap/les changements de ports du bridge ; device busy ; reconfiguration partielle.

Correction : Évitez les reloads globaux sur des hyperviseurs actifs. Si c’est déjà cassé : arrêtez les VMs affectées (ou migrez), stabilisez la config réseau, puis redémarrez les VMs.

4) Symptom: Tap exists but not attached to the intended bridge

Cause racine : Échec d’un script hook lors de l’esclavage du tap ; plomberie du pare-feu échouée ; mauvais nom de bridge dans la config VM.

Correction : Vérifiez que qm config bridge correspond aux bridges de l’hôte. Contrôlez la présence des devices de pare-feu. Supprimez les périphériques obsolètes et retentez le démarrage après correction de la config.

5) Symptom: Only VMs with firewall enabled fail to start

Cause racine : Backend pare-feu PVE en problème (nftables/iptables mismatch), règles cassées, ou devices de pare-feu persistants.

Correction : Validez le service pare-feu et les règles ; nettoyez les devices fwbr*/fwln* pour les VMs arrêtées ; redémarrez les services de pare-feu si nécessaire (avec précaution).

6) Symptom: Happens intermittently under load; “Device or resource busy”

Cause racine : Pression sur les ressources hôte, stockage lent provoquant des séquences stop/start bloquées, ou bugs noyau/driver retardant le nettoyage.

Correction : Vérifiez la pression mémoire hôte, la latence I/O, et la file de tâches. Corrigez la pression racine d’abord ; sinon vous courrez après des « taps obsolètes » indéfiniment.

7) Symptom: Two VMs or clones fight over the same tap name

Cause racine : Duplication de VMID entre nœuds, éditions manuelles erronées, ou workflow de restore/clone ayant causé des IDs conflictuels sur un même hôte.

Correction : Assurez des VMIDs uniques par hôte ; corrigez les configurations ; ne copiez pas manuellement les fichiers de configuration sans ajuster les IDs et l’état associé.

Trois mini-récits d’entreprise (parce que la réalité a une intrigue)

Mini-story 1: The incident caused by a wrong assumption

Une entreprise de taille moyenne exploitait un cluster Proxmox hébergeant des agents de build internes et quelques services « temporaires » devenus permanents.
Un vendredi soir, une VM refusa de démarrer avec l’erreur tap-already-exists. L’ingénieur d’astreinte vit l’interface tap dans ip link
et supposa qu’il était sûr de la supprimer car qm status affichait « stopped ».

La suppression a fonctionné—en partie. La VM a démarré, mais la connectivité réseau a fluctué. Quelques minutes plus tard, un autre service sur le même hôte devint indisponible.
Ils constatèrent alors un processus QEMU encore en cours pour la VM « arrêtée ». Proxmox avait perdu sa trace après un arrêt raté lors d’une fenêtre de sauvegarde antérieure.
Le tap n’était pas obsolète ; il était actif et transportait du trafic.

Supprimer le tap sous un QEMU actif a forcé le réseau de QEMU dans un comportement indéfini. Certains invités continuaient d’envoyer des trames dans le vide,
d’autres se reconnectaient après des tentatives. On a cru à un souci de switch car les symptômes étaient distribués et étranges.

La correction a été ennuyeuse : identifier le PID QEMU errant, l’arrêter proprement (ou le terminer), nettoyer les interfaces restantes, puis démarrer la VM une seule fois.
Ils ont aussi ajouté une étape au runbook : ne jamais faire confiance uniquement à qm status quand le problème implique des taps—confirmez toujours le PID QEMU.

Mini-story 2: The optimization that backfired

Une autre organisation jugeait que leurs nœuds Proxmox mettaient trop de temps à appliquer les changements réseau pendant les déploiements. Quelqu’un a introduit une « optimisation » :
une étape de pipeline qui exécutait ifreload -a sur chaque hyperviseur après mise à jour d’un template partagé de /etc/network/interfaces.
L’idée était simple : « La config réseau reste cohérente ; le reload n’est pas disruptif. »

En réalité, des VM actives avaient des taps apparaissant et disparaissant constamment à cause des charges CI.
Le reload global s’exécutait parfois exactement au moment où une nouvelle VM démarrait ou s’arrêtait. La plupart du temps, ça passait.
Parfois non—et ce sont ces tickets dont les gens se souvenaient.

Le mode d’échec était méchant : un démarrage de VM créait le tap, mais le reload tentait de réconcilier les ports du bridge et le filtrage VLAN en plein processus de création.
On obtenait des collisions de tap, des erreurs bridge busy, et des devices de pare-feu laissés sur le côté. L’hyperviseur n’était pas « down », mais dans un état semi-cassé.

Ils ont annulé l’étape du pipeline et l’ont remplacée par une politique : les changements réseau nécessitent une évacuation (migration live des VMs hors),
appliquer les changements, puis réintroduire la capacité. Plus lent ? Oui. Mais leur « optimisation » échangeait la fiabilité contre la commodité sans prévenir personne.

Mini-story 3: The boring but correct practice that saved the day

Une équipe de services financiers exploitait Proxmox avec un contrôle des changements strict. Leur habitude était simple : chaque hyperviseur avait une procédure de maintenance commençant par
migrer les VMs clients et se terminant par une validation post‑changement incluant la vérification des taps et devices pare-feu restants.

Un après-midi, un nœud a rencontré un stall de stockage transitoire. Quelques VMs sont devenues non réactives, et un processus QEMU a planté sévèrement.
Quand l’équipe a tenté de redémarrer la VM, ils ont rencontré l’erreur tap-already-exists. Rien de surprenant.

Le salut est venu de leur processus : vérifier le PID QEMU, vérifier l’existence du tap, supprimer seulement s’il n’est pas possédé, et confirmer la santé du bridge.
Ils ont rétabli le service rapidement sans impacter d’autres VMs. Le postmortem a été propre car leurs checklists avaient capturé timestamps et sorties.

La leçon n’était pas « soyez prudents ». C’était que des mécanismes répétables battent les exploits héroïques. Leur routine ennuyeuse était une caractéristique, pas un défaut.

Check-lists / plan étape par étape

Checklist 1: Single VM won’t start (tap already exists)

1. Récupérez le nom du tap depuis la tâche de démarrage échouée (tap<vmid>i<n>).
2. Confirmez que le tap existe : ip link show tapX.
3. Confirmez si QEMU tourne pour ce VMID : pgrep -a -f "qemu.*-id <vmid>".
4. Si QEMU tourne : arrêtez proprement la VM (qm stop). Si bloqué : terminez le PID QEMU.
5. Si QEMU ne tourne pas : retirez le tap de tout bridge (ip link set dev tapX nomaster).
6. Supprimez le tap : ip link delete tapX.
7. Si le pare-feu est activé : vérifiez et nettoyez les devices fwbr*/fwln* restants pour ce VMID.
8. Retentez : qm start <vmid>.
9. Après récupération : inspectez les logs autour du moment du plantage (reload réseau, OOM, crash).

Checklist 2: Many VMs failing (systemic issue)

1. Arrêtez les changements. Surtout les reloads réseau.
2. Vérifiez la charge hôte et la pression mémoire ; si l’OOM tue QEMU, les taps fuiront et les redémarrages seront chaotiques.
3. Consultez les logs ifupdown2/networking pour les tentatives de reload et les erreurs.
4. Validez l’état des bridges : NIC physique présente, bridge up, paramètres VLAN cohérents.
5. Choisissez une VM et suivez la checklist « single VM » pour valider la méthode de nettoyage.
6. Ensuite seulement, envisagez un nettoyage par lot (et uniquement pour des taps appartenant à des VMs arrêtées sans PID QEMU).

Checklist 3: Prevent recurrence (what to change in how you operate)

1. Interdisez « recharger le réseau sur tous les nœuds » comme étape d’automatisation par défaut.
2. Intégrez « vérifier PID QEMU vs qm status » dans votre procédure standard de dépannage.
3. Mettez à jour et changez les backends pare-feu avec précaution ; testez la création/suppression des devices pare-feu.
4. Surveillez les taps résiduels appartenant à des VMs arrêtées ; alertez avant que cela ne devienne une panne.
5. Documentez une procédure de nettoyage sûre et exigez-la dans la réponse aux incidents.

FAQ

1) Is it safe to delete a tap interface manually?

Oui—si aucun processus QEMU ne la possède. Vérifiez avec pgrep et/ou lsof /dev/net/tun.
Si QEMU est actif, supprimer le tap peut casser le réseau d’une VM en cours d’exécution de façons créatives.

2) Why does Proxmox reuse the same tap name every time?

Le nommage déterministe lie les taps aux VMIDs et index NIC, ce qui facilite le dépannage et la plomberie du pare-feu.
Le compromis est des collisions quand le nettoyage échoue.

3) Why does this happen after cloning or restore operations?

Les clones/restores peuvent laisser des désaccords d’état : locks, plomberie de périphérique partielle, ou tentatives de démarrage multiples.
De plus, si quelqu’un a copié manuellement des fichiers de configuration et dupliqué des VMIDs sur le même hôte, des conflits de nommage véritables peuvent survenir.

4) Does enabling Proxmox firewall make this worse?

Cela ajoute des éléments en mouvement. Plus de périphériques, plus de hooks, plus de chances de laisser des restes quand une opération est interrompue.
Cela ne veut pas dire « n’utilisez pas le pare-feu ». Cela signifie testez et opérez-le intentionnellement.

5) I deleted the tap but the error comes back immediately—why?

Souvent parce qu’un processus QEMU bloqué le recrée ou parce qu’une autre tentative de démarrage est en concurrence avec vous.
Vérifiez la présence de plusieurs processus QEMU, des locks obsolètes, ou une automatisation qui essaie sans cesse de démarrer la VM.

6) Can I just reboot the host to fix it?

Le redémarrage efface les devices noyau et les processus, donc oui, cela « fonctionne ».
Mais cela coupe aussi toutes les VMs de l’hôte et masque la cause racine. Utilisez-le en dernier recours, pas comme réflexe.

7) How do I know if ifupdown2 reload is the trigger?

Cherchez une corrélation temporelle dans journalctl pour les services ifupdown2/networking et des erreurs sur les reloads de bridge, devices occupés,
ou ports tap manquants. Si le cluster d’erreurs apparaît juste après des reloads, vous avez trouvé le déclencheur.

8) Does this relate to MTU or VLAN settings?

Parfois. Une configuration MTU/VLAN incorrecte provoque généralement des problèmes de connectivité, mais lors du démarrage elle peut faire échouer des scripts hook,
laissant des devices partiellement créés. Validez les paramètres bridge VLAN-aware vs les tags VM.

9) What about containers (LXC)—do they use tap devices too?

LXC utilise typiquement des paires veth plutôt que des taps, donc l’erreur exacte « tap already exists » est davantage liée aux VM/QEMU.
Mais le thème opérationnel est le même : interfaces virtuelles résiduelles après des événements de cycle de vie interrompus.

Conclusion : prochaines étapes pratiques

« Tap device already exists » n’est pas une malédiction mystérieuse de Proxmox. C’est un problème de cycle de vie des ressources avec un nom.
Corrigez-le en étant systématique : identifiez le tap, identifiez le processus propriétaire, nettoyez en sécurité, puis traitez le déclencheur.

Prochaines étapes qui rapportent immédiatement :

• Adoptez le guide de diagnostic rapide : nom du tap → PID QEMU → appartenance au bridge → nettoyage.
• Arrêtez les reloads réseau larges sur des hyperviseurs actifs. Évacuez ou planifiez.
• Ajoutez un audit léger : alertez sur les taps appartenant à des VMs arrêtées (c’est une fumée précoce).
• Si le pare-feu est utilisé, traitez-le comme du code dataplane : les changements nécessitent test et plan de rollback.

Vous n’avez pas besoin de plus de chance. Vous avez besoin de moins d’inconnues.