Pourquoi une machine virtuelle Proxmox perd-elle l’accès au réseau après sa migration vers un autre pont réseau ?
Une VM Proxmox peut perdre l’accès réseau après une migration de bridge lorsque le nouveau bridge est associé à un VLAN, une liaison montante ou un chemin de couche 2 différent.
Le système invité peut conserver la même adresse MAC, la même adresse IP et la même passerelle, tandis que l’hôte modifie silencieusement la manière dont ses trames atteignent le commutateur. Comparez la configuration des anciens et nouveaux bridges, les paramètres de prise en charge des VLAN, les liaisons montantes physiques ou agrégées, ainsi que la visibilité des paquets au niveau du tap et de l’interface de l’hôte avant de modifier quoi que ce soit dans la VM.
Comparez les anciens et nouveaux bridges en tant que chemins de couche 2
Notez le modèle de carte réseau de la VM, son adresse MAC, le nom du bridge, l’étiquette VLAN, la configuration IP et la passerelle avant et après la migration. Le nom d’un bridge ne suffit pas à prouver que le réseau situé derrière est équivalent.
Un cas réel de homelab Proxmox montre comment les modifications du bridge et du mappage des VLAN dans Proxmox changent le trafic qui atteint réellement le réseau physique, même lorsque la configuration de la VM reste syntaxiquement valide.
Si le même système invité fonctionne immédiatement après avoir été replacé sur le bridge d’origine, conservez les deux configurations de bridge et comparez le chemin au lieu de réinitialiser le système d’exploitation invité.
Vérifiez l’étiquetage VLAN de bout en bout
Vérifiez si la carte réseau de la VM est étiquetée, si le bridge prend en charge les VLAN et si le port du commutateur attend des trames étiquetées ou non étiquetées pour ce réseau. Conservez l’adresse IP du système invité pendant ce test.
Un guide pratique sur la configuration des VLAN dans Proxmox aide à distinguer l’appartenance au bridge de la sémantique des VLAN ; le système invité peut être correctement connecté tout en envoyant ses trames dans le mauvais VLAN.
Capturez le trafic sur le bridge de l’hôte et sur la liaison montante physique. Si vous voyez les requêtes ARP quitter la VM sans jamais apparaître sur le VLAN prévu, cela identifie une limite au niveau de l’hôte ou du commutateur, avant le système invité.
Vérifiez que le nouveau bridge utilise la bonne liaison montante
Vérifiez quelle carte réseau physique, quelle interface agrégée ou virtuelle le nouveau bridge utilise. Confirmez l’état de la liaison, le débit négocié et l’absence d’un autre service de l’hôte qui utiliserait ou filtrerait déjà cette interface.
Le fonctionnement des bridges Linux est important ici, car un bridge Linux ne transfère les trames que par les ports qui lui sont réellement rattachés ; un bridge sans liaison montante utilisable peut malgré tout sembler sain dans la configuration.
Lorsque cela est pertinent, envoyez une requête ping vers la passerelle depuis l’hôte via le réseau prévu, puis comparez les captures de paquets au niveau du tap de la VM et de la liaison montante. Corrigez le port ou l’appartenance à l’interface agrégée manquants au lieu de modifier le DNS du système invité.
Effacez l’état obsolète des voisins uniquement une fois le chemin corrigé
Après avoir changé de bridge, la VM conserve la même adresse MAC, tandis que les équipements en amont peuvent l’avoir apprise sur un autre port ou VLAN. Vérifiez les entrées ARP ou de voisinage ainsi que l’état du transfert sur le commutateur.
Des exemples de VLAN étiquetés dans Proxmox montrent comment les décisions d’étiquetage du bridge et du commutateur déterminent l’endroit où cette adresse MAC est apprise, ce qui fait de l’état obsolète de la couche 2 un problème secondaire plausible après une migration correcte.
Après avoir corrigé la configuration, supprimez uniquement l’entrée de voisinage ou de transfert concernée, ou attendez son expiration normale. Effacer les caches avant de corriger le chemin peut créer une réussite temporaire qui disparaîtra de nouveau.
Vérifiez séparément la connectivité du système invité vers la passerelle et celle du client vers le système invité
Testez la connectivité du système invité vers la passerelle, du système invité vers un client du réseau local, du client du réseau local vers le système invité et l’accès aux applications. Cela permet de distinguer une route par défaut manquante des problèmes de pare-feu, de chemin retour ou de liaison du service à une interface.
Le guide associé de configuration d’un serveur domestique Proxmox de ZimaSpace fournit le contexte de virtualisation complémentaire nécessaire pour rendre reproductibles les modifications du bridge, du stockage et des VM sur un serveur domestique.
La migration n’est terminée que lorsque la VM redémarre correctement sur le nouveau bridge et que les deux directions du flux applicatif d’origine fonctionnent sans effacement manuel de l’ARP ni basculement du bridge.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
