Ihre Proxmox-VM startet, aber Linux oder Windows sieht immer noch kein verwendbares Netzwerk. Bevor Sie eine Karte hinzufügen oder das Bridge des Hosts ändern, müssen Sie die Unterbrechung zwischen der virtuellen Karte, dem Bridge und der Schnittstelle des Gastbetriebssystems lokalisieren.
Die Methode umfasst das Lesen der aktuellen Konfiguration, eine Überprüfung von bridge und link_down, gefolgt von einer Überprüfung in der VM. Dadurch korrigieren Sie die kleinste mögliche Schicht, ohne einen VM-Ausfall in einen Vorfall beim Proxmox-Knoten umzuwandeln.
Die Unterbrechung zwischen Proxmox und dem Gast lokalisieren
Eine virtuelle Karte folgt einer einfachen Kette: simulierte Karte in der VM, Backend auf dem Host, Proxmox-Bridge, Netzwerk verbunden mit dem Host, dann Schnittstelle und IP-Adresse im Gast. Die QEMU-Dokumentation zur Netzwerksimulation beschreibt die simulierte Karte und ihren Link zu einem Host-Backend. Sie erwähnt TAP als Standardmittel zum Verbinden eines Gastbetriebssystems mit dem tatsächlichen Netzwerk, ohne den Leser zu bitten, dies hier manuell zu konfigurieren.
Das Bridge vmbrX verbindet die Gäste mit dem physikalischen Netzwerk wie ein virtuelles Switch. Eine VM, die an dieses Bridge angeschlossen ist, erscheint im physischen Netzwerk mit ihrer eigenen MAC-Adresse, gemäß der Proxmox-Dokumentation zur Netzwerkkonfiguration.
Notieren Sie vor jeglichen Änderungen die sichtbaren Elemente. Diese Liste verhindert, dass Sie zwei Schichten gleichzeitig ändern:
- die tatsächliche Zeile
net[n]; - das in dieser Zeile angegebene Bridge ;
- der Zustand
link_down; - das Modell der Karte, VirtIO oder E1000 ;
- die Anwesenheit der Schnittstelle und der erwarteten IP-Konfiguration im Gast.
Die VMID muss von Ihrer Instanz stammen. Keine Nummer kann aus dem hier beschriebenen Problem abgeleitet werden.
Die tatsächlich auf die VM angewandte Netzwerkkarte lesen
Beginnen Sie mit den aktuellen Werten, nicht mit einem Wert, der auf die Berücksichtigung wartet. Der im Proxmox VE Administrationshandbuch dokumentierte Befehl lautet:
qm config <vmid> --currentErsetzen Sie <vmid> durch die tatsächliche ID der VM. Das Ergebnis sollte es Ihnen ermöglichen, den betreffenden Eintrag net[n], sein Bridge und den Status des Links zu finden. Kein Typausdruck sollte anstelle der Antwort Ihres Knotens kopiert werden.
Der Parameter --current fordert die aktuellen Werte an, anstatt der Werte pending. Diese Unterscheidung verhindert, dass Sie eine Einstellung korrigieren, die noch nicht von der VM verwendet wird.
Feld von net[n] | Frage zu stellen | Rolle in der Diagnose |
|---|---|---|
bridge | zeigt die Karte auf das erwartete Bridge? | Ein falsches Attachment auf VM-Seite lokalisieren. |
link_down | ist der Link dieser Karte explizit deaktiviert? | Unterscheiden Sie zwischen einer vorhandenen Karte und einem deaktivierten Link. |
| Modell VirtIO oder E1000 | Welches Modell verwendet die VM? | Trennen Sie die Leistungswahl von der Aktivierungsprüfung. |
firewall | Verdient der Wert Beachtung für den vorliegenden Fall? | Halten Sie das Feld in der Erhebung, ohne das Diagnosethema zu verschieben. |
macaddr | muss die angegebene MAC-Adresse mit Ihrem Inventar verglichen werden? | Die von der virtuellen Karte angezeigte Kennung beibehalten. |
tag oder trunks | Erscheinen diese Felder in der Konfiguration? | Nur, wenn sie für das erwartete Attachment Licht bieten. |
rate oder queues | Sind diese Optionen notwendig, um das Problem zu verstehen? | Vermeiden Sie, dass eine sekundäre Option die Kontrolle über das Bridge und den Link verdeckt. |
Proxmox empfiehlt die Verwendung von VirtIO-Geräten, wenn diese verfügbar sind. In der Dokumentation wird angegeben, dass iperf-Messungen anzeigen, dass VirtIO bis zu dreimal die Bandbreite einer emulierten E1000 bereitstellen kann. Dieser Faktor stammt aus diesen Proxmox-Messungen: Übertragen Sie ihn nicht auf alle Lasten, Versionen oder Infrastrukturen.
Das Ändern von E1000 in VirtIO aktiviert nicht automatisch eine Karte, die an das falsche Bridge angeschlossen ist oder deren Link deaktiviert ist. Das Modell beantwortet eine Frage der Kompatibilität oder Leistung; bridge und link_down beantworten zuerst die Frage der Aktivierung.
Die VM korrigieren, ohne das Netzwerk des Hosts neu zu konfigurieren
Wenn das Lesen auf die Karte dieser VM hinweist, beschränken Sie die Korrektur auf diese Karte. Erfassen Sie zuerst die aktuellen Werte, damit Sie nur die vorherige Einstellung wiederherstellen können, wenn die Situation sich verschlechtert.
| Schicht | Element zu lesen | Interpretationszeichen | Begrenzte Aktion | Zu vermeidende Aktion |
|---|---|---|---|---|
| VM | net[n] in qm config <vmid> --current | Der Eintrag entspricht nicht der erwarteten Karte. | Erfassen Sie den betreffenden Eintrag vor einer Korrektur. | Mehrere Karten hinzufügen, um die Unsicherheit zu verschleiern. |
| Attachment | bridge | das angegebene Bridge entspricht nicht dem erwarteten Netzwerk. | Korrigieren Sie das Attachment der virtuellen Karte dieser VM. | Ändern Sie die Definition des Bridges auf dem Host. |
| Link-Status | link_down | Der Link der Karte ist explizit deaktiviert. | Aktivieren Sie nur den Status dieser Karte in Proxmox. | Das Modell ändern in der Hoffnung auf eine automatische Reparatur. |
| Host | Bridge und Erreichbarkeit des Knotens | Das Host-Bridge scheint abwesend oder inkohärent zu sein, oder der Knoten wird unerreichbar. | Hören Sie den Prozess auf und verlassen Sie den Umfang dieser Fehlersuche. | Ändern Sie das Hostnetzwerk ohne Beweise. |
| Gast | Schnittstelle, Status und IP-Adresse | Die Proxmox-Konfiguration ist konsistent, aber der Gast bleibt ohne IP. | Fahren Sie mit der Diagnose in Linux oder Windows fort. | Ändern Sie weiterhin Proxmox. |
Wenn Sie sich bei der Netzwerkanpassung unsicher sind, verwenden Sie das Proxmox-Grafikinterface anstelle einer direkten Bearbeitung. Die Bezeichnungen können je nach Version variieren; kein Klickprozess darf aus einer nicht beobachteten Version abgeleitet werden.
Warnung: Eine falsche Konfiguration des Hostnetzwerks kann den Knoten unerreichbar machen. Verwenden Sie ifdown vmbrX nicht als Testverfahren: Proxmox warnt, dass dieser Befehl den Datenverkehr von Gästen unterbrechen kann, ohne ihn nach ifup wiederherzustellen.
Falls die Korrektur die Situation verschlechtert, setzen Sie die zuvor erfassten Werte für diese einzige Karte zurück, und lesen Sie dann die aktuelle Konfiguration erneut. Dieser Rückschritt deckt kein Versagen des Host-Bridge selbst ab.
Den Diagnoseprozess in der VM Linux oder Windows abschließen
Wenn net[n], das Bridge und der Link-Status der Erwartung entsprechen, wechseln Sie zum Gastbetriebssystem. Es verbleiben drei Überprüfungen: Die Schnittstelle existiert, sie ist aktiv und erhält die geplante IP- oder DHCP-Konfiguration.
In einer Linux-VM
Überprüfen Sie die erwartete Schnittstelle und ihren Status mit den Tools Ihrer Distribution. Der LinuxEnCaja-Leitfaden zur Überprüfung der IP-Adresse mit ip addr beantwortet diesen Lesevorgang vor der Anpassung.
Wenn die Schnittstelle vorhanden ist, aber nicht die erwartete Adresse hat, gehen Sie weiter zur IP- oder DHCP-Konfiguration. Für eine feste Adresse unter Debian wird der Leitfaden eine feste IP-Adresse unter Debian konfigurieren erst relevant, nachdem der Netzwerkmanager und die betreffende Schnittstelle identifiziert wurden.
Um den Status eines Linux-Links genauer zu überprüfen, können Sie auch den Netzwerklink mit ethtool überprüfen. Halten Sie die Trennung zwischen der Kontrolle der virtuellen Schnittstelle im Gast und dem physischen Netzwerk des Hosts aufrecht.
Wenn NetworkManager diese Schnittstelle tatsächlich im Gast verwaltet, überprüfen Sie das Netzwerkprofil mit nmcli, was der passende Ansatz wäre. Ändern Sie während der Diagnose nicht den Netzwerkmanager.
In einer Windows-VM
Überprüfen Sie, ob die erwartete Schnittstelle erscheint, aktiv ist und eine IP- oder DHCP-Konfiguration dem vorgesehenen Netzwerk entspricht. Die Beweisführung führt keine Windows-Verfahrensweise für Treiber oder Menüs im Detail auf; kein Bildschirmname oder Befehl darf hier erfunden werden.
Die Korrektur validieren, ohne die Ursache des Problems dem Zufall zuzuschreiben
Die Überprüfung erfolgt in derselben Reihenfolge wie die Diagnose. Lesen Sie zunächst die VM mit qm config <vmid> --current und vergleichen Sie das Bridge und den Link-Status mit den gewünschten Werten.
Überprüfen Sie dann die Schnittstelle und die IP-Adresse in Ihrer eigenen VM. Der Artikel liefert keine tatsächliche Ausgabe: Das Ergebnis hängt von Ihrer VM, ihrem Gastbetriebssystem und dem Netzwerk ab, mit dem das Bridge verbunden ist.
- Kohärente Proxmox-Konfiguration: der Eintrag
net[n], das Bridge und der Link-Status entsprechen der gewünschten Korrektur. - Sichtbare Gäste-Schnittstelle: Linux oder Windows sieht die erwartete Karte und ihr Status ist aktiv gemäß ihren eigenen Tools.
- IP-Konfiguration vorhanden: die erwartete Adresse oder der DHCP erscheint im Gast.
- Problem weiterhin im Gast vorhanden: stoppen Sie die Änderungen am Host und fahren Sie nur mit dem Gastbetriebssystem fort.
- Host-Bridge als Ursache: stoppen Sie, da die sichere Reparatur des Proxmox-Netzwerks des Hosts außerhalb dieses Rahmens liegt.
Ausgabe-Checkliste
- Die verwendete VMID stimmt mit der betroffenen VM überein.
qm config <vmid> --currentwurde vor der Korrektur gelesen.- Der Eintrag
net[n], seinbridge, seinlink_downund sein Modell wurden erfasst. - Die Korrektur bezieht sich auf die betroffene virtuelle Karte, nicht auf das Bridge des Hosts.
- Der Befehl
ifdown vmbrXwurde nicht als Test verwendet. - Linux oder Windows sieht die erwartete Schnittstelle.
- Die Gästeschnittstelle ist aktiv und erhält die erwartete IP-Adresse oder den DHCP.
- Wenn die Proxmox-Schicht kohärent ist, der Gast jedoch ohne IP bleibt, wird die Diagnose im Gast fortgesetzt.
- Wenn das Host-Bridge als Ursache erscheint, stoppt das Verfahren.