La tua VM Proxmox si avvia, ma Linux o Windows non vedono ancora alcuna rete utilizzabile. Prima di aggiungere una scheda o modificare il bridge dell’host, è necessario individuare l’interruzione tra la scheda virtuale, il bridge e l’interfaccia del sistema ospite.
Il metodo consiste in una lettura della configurazione corrente, un controllo di bridge e di link_down, quindi una verifica nella VM. In questo modo correggi il livello più piccolo possibile, senza trasformare un guasto della VM in un incidente sul nodo Proxmox.
Localizzare l’interruzione tra Proxmox e l’ospite
Una scheda virtuale segue una catena semplice: scheda simulata nella VM, backend sull’host, bridge Proxmox, rete collegata all’host, quindi interfaccia e indirizzo IP nell’ospite. La documentazione QEMU sull’emulazione di rete descrive la scheda simulata e il suo collegamento a un backend host. Cita TAP come mezzo standard per collegare un ospite alla rete reale, senza chiedere al lettore di configurarlo manualmente qui.
Il bridge vmbrX collega gli ospiti alla rete fisica come uno switch virtuale. Una VM collegata a questo bridge appare sulla rete fisica con il proprio indirizzo MAC, secondo la documentazione Proxmox sulla configurazione di rete.
Prima di apportare modifiche, annota gli elementi visibili. Questa lista evita di cambiare due livelli alla volta:
- la riga
net[n]realmente interessata; - il bridge indicato in questa riga;
- lo stato
link_down; - il modello di scheda, VirtIO o E1000;
- la presenza dell’interfaccia e della configurazione IP attesa nell’ospite.
Il VMID deve provenire dalla tua istanza. Nessun numero può essere dedotto dal problema descritto qui.
Leggere la scheda di rete realmente applicata alla VM
Inizia dai valori correnti, non da un valore in attesa di approvazione. Il comando documentato dal guida all’amministrazione Proxmox VE è:
qm config <vmid> --currentSostituisci <vmid> con l’identificativo reale della VM. Il risultato dovrebbe permetterti di ritrovare l’entry net[n] interessata, il suo bridge e lo stato del link. Nessun output di esempio deve essere copiato al posto della risposta del tuo nodo.
Il parametro --current richiede i valori correnti piuttosto che i valori pending. Questa distinzione evita di correggere un’impostazione che non è ancora quella utilizzata dalla VM.
Campo di net[n] | Domanda da porre | Ruolo nella diagnostica |
|---|---|---|
bridge | La scheda punta al bridge atteso? | Localizzare un attaccamento errato lato VM. |
link_down | Il link di questa scheda è esplicitamente disattivato? | Distingue una scheda presente da un link disattivato. |
| Modello VirtIO o E1000 | Quale modello utilizza la VM? | Separare la scelta delle prestazioni dalla ricerca di attivazione. |
firewall | Il valore vale la pena di essere sollevato per il caso in esame? | Mantenere il campo nel rilievo senza spostare la diagnosi su un altro argomento. |
macaddr | L’indirizzo MAC visualizzato deve essere confrontato con il tuo inventario? | Conservare l’identificativo presentato dalla scheda virtuale. |
tag o trunks | Questi campi appaiono nella configurazione? | Annotarli solo se illuminano l’attacco atteso. |
rate o queues | Queste opzioni sono necessarie per comprendere il guasto? | Evita che un’opzione secondaria mascheri il controllo del bridge e del link. |
Proxmox raccomanda i dispositivi VirtIO quando disponibili. La sua documentazione cita misurazioni iperf in cui VirtIO può fornire fino a tre volte la larghezza di banda di una E1000 emulata. Questo fattore deriva da queste misurazioni Proxmox: non trasportarlo su tutti i carichi, versioni o infrastrutture.
Cambiare E1000 in VirtIO non riattiva automaticamente una scheda collegata al bridge sbagliato o il cui link è disattivato. Il modello risponde a una questione di compatibilità o prestazioni; bridge e link_down rispondono prima alla domanda dell’attivazione.
Correggere la VM senza riconfigurare la rete dell’host
Quando la lettura punta alla scheda di questa VM, limita la correzione a questa scheda. Prima annota i valori correnti in modo da poter ripristinare solo l’impostazione precedente se la situazione peggiora.
| Livello | Elemento da leggere | Segno da interpretare | Azione limitata | Azione da evitare |
|---|---|---|---|---|
| VM | net[n] in qm config <vmid> --current | L’entry non corrisponde alla scheda attesa. | Annotare l’entry interessata prima di qualsiasi correzione. | Aggiungere più schede per mascherare l’incertezza. |
| Attacco | bridge | Il bridge indicato non corrisponde alla rete attesa. | Correggere l’attaccamento della scheda virtuale di questa VM. | Modificare la definizione del bridge sull’host. |
| Stato del link | link_down | Il link della scheda è esplicitamente disattivato. | Riattivare solo lo stato di questa scheda in Proxmox. | Cambiare il modello sperando in una riparazione automatica. |
| Host | Bridge e accessibilità del nodo | Il bridge host sembra assente, incoerente o il nodo diventa inaccessibile. | Fermare la procedura ed uscire dal perimetro di questo intervento. | Modificare la rete host senza prove. |
| Ospite | Interfaccia, stato e indirizzo IP | La configurazione Proxmox è coerente, ma l’ospite rimane senza IP. | Proseguire con la diagnosi in Linux o Windows. | Continuare a modificare Proxmox. |
Se non sei sicuro della modifica della rete, utilizza l’interfaccia grafica di Proxmox piuttosto che un’editing diretto. Le etichette possono variare a seconda della versione; nessuna procedura di clic deve essere dedotta da una versione non osservata.
Avvertenza: una configurazione errata della rete dell’host può rendere il nodo inaccessibile. Non utilizzare ifdown vmbrX come test di risoluzione dei problemi: Proxmox avverte che questo comando può interrompere il traffico degli ospiti senza ripristinarlo dopo ifup.
Se la correzione peggiora la situazione, ripristina i valori precedentemente annotati per questa sola scheda, quindi rileggi la configurazione corrente. Questo passo indietro non copre un guasto del bridge host stesso.
Terminare la diagnosi nella VM Linux o Windows
Quando net[n], il bridge e lo stato del link corrispondono all’atteso, passa al sistema ospite. Rimangono tre controlli: l’interfaccia esiste, è attiva e riceve la configurazione IP o DHCP prevista.
In una VM Linux
Controlla l’interfaccia attesa e il suo stato con gli strumenti della tua distribuzione. La guida LinuxEnCaja per verificare l’indirizzo IP con ip addr risponde a questo passo di lettura prima della modifica.
Se l’interfaccia esiste ma non ha l’indirizzo atteso, procedi con la configurazione IP o DHCP. Per un indirizzo fisso su Debian, la guida configurare un indirizzo IP fisso su Debian diventa pertinente solo dopo aver identificato il gestore di rete e l’interfaccia coinvolta.
Per approfondire lo stato di un link Linux, puoi anche consultare il controllo del link di rete con ethtool. Ricorda di mantenere la separazione tra il controllo dell’interfaccia virtuale nell’ospite e la rete fisica dell’host.
Se NetworkManager gestisce realmente questa interfaccia nell’ospite, verificare il profilo di rete con nmcli diventa la pista adatta. Non cambiare gestore di rete in corso di diagnosi.
In una VM Windows
Controlla che l’interfaccia attesa appaia, sia attiva e che una configurazione IP o DHCP corrisponda alla rete prevista. Il documento di prova non dettagli alcuna procedura Windows per i driver o i menu; nessun nome di schermo o comando deve essere inventato qui.
Validare la correzione senza attribuire il guasto al caso
La verifica avviene nello stesso ordine della diagnosi. Rileggi prima la VM con qm config <vmid> --current e confronta il bridge e lo stato del link con i valori desiderati.
Verifica quindi l’interfaccia e l’indirizzo IP nella tua VM. L’articolo non fornisce alcun output reale: il risultato dipende dalla tua VM, dal suo sistema ospite e dalla rete a cui il bridge è collegato.
- Configurazione Proxmox coerente: l’entry
net[n], il bridge e lo stato del link corrispondono alla correzione desiderata. - Interfaccia ospite visibile: Linux o Windows vede la scheda attesa e il suo stato è attivo secondo i propri strumenti.
- Configurazione IP presente: l’indirizzo o il DHCP atteso appare nell’ospite.
- Guasto ancora presente nell’ospite: interrompere le modifiche sull’host e proseguire solo lato sistema ospite.
- Bridge host in causa: fermati, poiché la riparazione certa della rete Proxmox dell’host esce da questo perimetro.
Checklist di uscita
- Il VMID utilizzato corrisponde alla VM interessata.
qm config <vmid> --currentè stato letto prima della correzione.- L’entry
net[n], il suobridge, il suolink_downe il suo modello sono stati registrati. - La correzione riguarda la scheda virtuale interessata, non il bridge dell’host.
- Il comando
ifdown vmbrXnon è stato utilizzato come test. - Linux o Windows vede l’interfaccia attesa.
- L’interfaccia ospite è attiva e riceve l’indirizzo IP o il DHCP atteso.
- Se il livello Proxmox è coerente ma l’ospite rimane senza IP, la diagnosi continua nell’ospite.
- Se il bridge host sembra in causa, la procedura si ferma.
