Rétablir le réseau d’une VM Proxmox, du bridge à l’invité

Votre VM Proxmox démarre, mais Linux ou Windows ne voit toujours aucun réseau utilisable. Avant d’ajouter une carte ou de toucher au bridge de l’hôte, il faut localiser la coupure entre la carte virtuelle, le bridge et l’interface du système invité.

La méthode tient en une lecture de la configuration courante, un contrôle de bridge et de link_down, puis une vérification dans la VM. Vous corrigez ainsi la plus petite couche possible, sans transformer une panne de VM en incident sur le nœud Proxmox.

Localiser la coupure entre Proxmox et l’invité

Une carte virtuelle suit une chaîne simple : carte simulée dans la VM, backend sur l’hôte, bridge Proxmox, réseau relié à l’hôte, puis interface et adresse IP dans l’invité. La documentation QEMU sur l’émulation réseau décrit la carte simulée et son lien vers un backend hôte. Elle cite TAP comme moyen standard pour relier un invité au réseau réel, sans demander au lecteur de le configurer manuellement ici.

Le bridge vmbrX relie les invités au réseau physique comme un switch virtuel. Une VM attachée à ce bridge apparaît sur le réseau physique avec sa propre adresse MAC, selon la documentation Proxmox sur la configuration réseau.

Avant toute modification, notez les éléments visibles. Cette liste évite de changer deux couches à la fois :

1. la ligne net[n] réellement concernée ;
2. le bridge indiqué dans cette ligne ;
3. l’état link_down ;
4. le modèle de carte, VirtIO ou E1000 ;
5. la présence de l’interface et de la configuration IP attendue dans l’invité.

Le VMID doit venir de votre instance. Aucun numéro ne peut être déduit du problème décrit ici.

Lire la carte réseau réellement appliquée à la VM

Commencez par les valeurs courantes, pas par une valeur en attente de prise en compte. La commande documentée par le guide d’administration Proxmox VE est :

qm config <vmid> --current

Remplacez <vmid> par l’identifiant réel de la VM. Le résultat doit vous permettre de retrouver l’entrée net[n] concernée, son bridge et l’état du lien. Aucune sortie type ne doit être copiée à la place de la réponse de votre nœud.

Le paramètre --current demande les valeurs courantes plutôt que les valeurs pending. Cette distinction évite de corriger un réglage qui n’est pas encore celui utilisé par la VM.

Proxmox recommande les périphériques VirtIO lorsqu’ils sont disponibles. Sa documentation cite des mesures iperf dans lesquelles VirtIO peut fournir jusqu’à trois fois le débit d’une E1000 émulée. Ce facteur vient de ces mesures Proxmox : ne le transposez pas à toutes les charges, versions ou infrastructures.

Changer E1000 en VirtIO ne réactive pas automatiquement une carte attachée au mauvais bridge ou dont le lien est désactivé. Le modèle répond à une question de compatibilité ou de performance ; bridge et link_down répondent d’abord à la question de l’activation.

Corriger la VM sans reconfigurer le réseau de l’hôte

Quand la lecture pointe vers la carte de cette VM, bornez la correction à cette carte. Relevez d’abord les valeurs courantes afin de pouvoir remettre uniquement le réglage précédent si la situation se dégrade.

Si vous n’êtes pas sûr de la modification réseau, utilisez l’interface graphique Proxmox plutôt qu’une édition directe. Les libellés peuvent varier selon la version ; aucune procédure de clic ne doit être déduite d’une version non observée.

Si la correction aggrave la situation, remettez les valeurs précédemment relevées pour cette seule carte, puis relisez la configuration courante. Cette marche arrière ne couvre pas une panne du bridge hôte lui-même.

Terminer le diagnostic dans la VM Linux ou Windows

Quand net[n], le bridge et l’état du lien correspondent à l’attendu, passez dans le système invité. Il reste trois contrôles : l’interface existe, elle est active et elle reçoit la configuration IP ou DHCP prévue.

Dans une VM Linux

Vérifiez l’interface attendue et son état avec les outils de votre distribution. Le guide LinuxEnCaja pour vérifier l’adresse IP avec ip addr répond à cette étape de lecture avant modification.

Si l’interface existe mais n’a pas l’adresse attendue, poursuivez sur la configuration IP ou DHCP. Pour une adresse fixe sous Debian, le guide configurer une adresse IP fixe sous Debian ne devient pertinent qu’après identification du gestionnaire réseau et de l’interface concernée.

Pour approfondir l’état d’un lien Linux, vous pouvez aussi consulter le contrôle du lien réseau avec ethtool. Gardez la séparation entre le contrôle de l’interface virtuelle dans l’invité et le réseau physique de l’hôte.

Si NetworkManager gère réellement cette interface dans l’invité, vérifier le profil réseau avec nmcli devient la piste adaptée. Ne changez pas de gestionnaire réseau en cours de diagnostic.

Dans une VM Windows

Vérifiez que l’interface attendue apparaît, qu’elle est active et qu’une configuration IP ou DHCP correspond au réseau prévu. Le dossier de preuve ne détaille pas de procédure Windows pour les pilotes ou les menus ; aucun nom d’écran ni commande ne doit être inventé ici.

Valider la correction sans attribuer la panne au hasard

La vérification se fait dans le même ordre que le diagnostic. Relisez d’abord la VM avec qm config <vmid> --current et comparez le bridge et l’état du lien aux valeurs voulues.

Vérifiez ensuite l’interface et l’adresse IP dans votre propre VM. L’article ne fournit aucune sortie réelle : le résultat dépend de votre VM, de son système invité et du réseau auquel le bridge est relié.

• Configuration Proxmox cohérente : l’entrée net[n], le bridge et l’état du lien correspondent à la correction voulue.
• Interface invitée visible : Linux ou Windows voit la carte attendue et son état est actif selon ses propres outils.
• Configuration IP présente : l’adresse ou le DHCP attendu apparaît dans l’invité.
• Panne toujours présente dans l’invité : arrêtez les changements sur l’hôte et poursuivez uniquement côté système invité.
• Bridge hôte en cause : arrêtez-vous, car la réparation sûre du réseau Proxmox de l’hôte sort de ce périmètre.

Checklist de sortie

• Le VMID utilisé correspond à la VM concernée.
• qm config <vmid> --current a été lu avant la correction.
• L’entrée net[n], son bridge, son link_down et son modèle ont été relevés.
• La correction porte sur la carte virtuelle concernée, pas sur le bridge de l’hôte.
• La commande ifdown vmbrX n’a pas servi de test.
• Linux ou Windows voit l’interface attendue.
• L’interface invitée est active et reçoit l’adresse IP ou le DHCP attendu.
• Si la couche Proxmox est cohérente mais que l’invité reste sans IP, le diagnostic continue dans l’invité.
• Si le bridge hôte semble en cause, la procédure s’arrête.

body.postid-37933 .lec-reading-card,body.postid-37933 .entry-content{box-sizing:border-box;max-width:100%;}body.postid-37933 pre.wp-block-code{max-width:100%;overflow-x:auto;}body.postid-37933 .lec-callout,body.postid-37933 .lec-code-block,body.postid-37933 .lec-sidebar .lec-related,body.postid-37933 .lec-sidebar .lec-side-card:not(.lec-toc){display:none!important;}@media(max-width:700px){body.postid-37933 .lec-reading-card{width:calc(100vw – 28px);max-width:calc(100vw – 28px);margin-left:auto;margin-right:auto;}body.postid-37933 .entry-content{min-width:0;overflow-wrap:anywhere;}}