Perché una VM Proxmox perde l’accesso alla rete dopo la migrazione a un altro bridge?
Una VM di Proxmox può perdere l’accesso alla rete dopo la migrazione del bridge, quando il nuovo bridge è associato a una VLAN, un uplink o un percorso di livello 2 diverso.
Il guest può mantenere lo stesso indirizzo MAC, IP e gateway, mentre l’host cambia silenziosamente il modo in cui i suoi frame raggiungono lo switch. Prima di modificare qualsiasi impostazione all’interno della VM, confronta la configurazione del bridge precedente e di quello nuovo, le impostazioni VLAN-aware, gli uplink fisici o aggregati e la visibilità dei pacchetti sul tap e sull’interfaccia dell’host.
Confronta il bridge precedente e quello nuovo come percorsi di livello 2
Annota il modello della NIC della VM, l’indirizzo MAC, il nome del bridge, il tag VLAN, la configurazione IP e il gateway prima e dopo la migrazione. Il solo nome del bridge non dimostra che la rete sottostante sia equivalente.
Un caso reale di homelab con Proxmox mostra come le modifiche alla configurazione del bridge e al mapping delle VLAN in Proxmox cambino il traffico che raggiunge effettivamente la rete fisica, anche quando la configurazione della VM appare ancora sintatticamente valida.
Se lo stesso guest funziona immediatamente quando viene spostato di nuovo sul bridge originale, conserva entrambe le configurazioni dei bridge e confronta il percorso invece di reimpostare il sistema operativo guest.
Verifica il tagging VLAN end-to-end
Controlla se la NIC della VM usa un tag, se il bridge è VLAN-aware e se la porta dello switch prevede frame con o senza tag per quella rete. Mantieni invariato l’indirizzo IP del guest durante questo test.
Una guida pratica alla configurazione delle VLAN in Proxmox aiuta a distinguere l’appartenenza al bridge dalla semantica delle VLAN; il guest può essere collegato correttamente e tuttavia inviare i frame nella VLAN sbagliata.
Cattura il traffico sul bridge dell’host e sull’uplink fisico. Se vedi l’ARP uscire dalla VM ma non comparire sulla VLAN prevista, hai individuato un problema al confine tra host e switch, prima ancora del guest.
Dimostra che il nuovo bridge usa l’uplink corretto
Controlla quale NIC fisica, interfaccia aggregata o interfaccia virtuale utilizza il nuovo bridge. Conferma lo stato del collegamento, la velocità negoziata e che nessun altro servizio dell’host stia già utilizzando o filtrando quell’interfaccia.
Il comportamento dei bridge Linux è importante in questo caso, perché un bridge Linux inoltra i frame solo attraverso le porte effettivamente collegate; un bridge privo di un uplink utilizzabile può comunque apparire configurato correttamente.
Quando appropriato, esegui il ping del gateway dall’host attraverso la rete prevista, quindi confronta le catture dei pacchetti sul tap della VM e sull’uplink. Correggi la porta o l’appartenenza al gruppo mancanti invece di modificare il DNS del guest.
Cancella lo stato dei vicini obsoleto solo dopo aver corretto il percorso
Dopo la modifica dei bridge, la VM mantiene lo stesso MAC, mentre i dispositivi a monte potrebbero averlo appreso su una porta o una VLAN diversa. Controlla le voci ARP o dei vicini e lo stato di inoltro dello switch.
Gli esempi di VLAN con tag in Proxmox mostrano come le decisioni di tagging del bridge e dello switch determinino dove viene appreso il MAC, rendendo lo stato di livello 2 obsoleto una possibile causa secondaria dopo una migrazione corretta.
Svuota solo la voce pertinente dei vicini o della tabella di inoltro, oppure attendi il normale invecchiamento, dopo aver corretto la configurazione. Cancellare le cache prima di correggere il percorso può creare un successo temporaneo destinato a scomparire.
Verifica separatamente il percorso guest-gateway e client-guest
Testa il percorso dal guest al gateway, dal guest a un client della LAN, dal client della LAN al guest e l’accesso all’applicazione. In questo modo distingui una route predefinita mancante dai problemi di firewall, percorso di ritorno o associazione del servizio.
La guida correlata di ZimaSpace alla configurazione di un home server Proxmox fornisce il contesto di virtualizzazione adiacente per mantenere riproducibili le modifiche a bridge, storage e VM su un home server.
La migrazione è completa solo quando la VM supera un riavvio sul nuovo bridge e entrambe le direzioni del flusso applicativo originale funzionano senza dover cancellare manualmente l’ARP o attivare e disattivare il bridge.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
