12
VM NIC nicht mehr erreichbar
Hallo zusammen,
ich habe ein seltsames Problem wo ich ehrlich gesagt gerade am verzweifeln bin.
Und zwar habe ich hier einen VMWare ESXi 5.0 Server mit einigen VM´s (Meist W2K8R2 SP1)
Es wurden keine Änderungen an der VM oder am VMWare ESXi vorgenommen.
Jetzt musste eine VM (W2K8R2 SP1) neugestartet werden.
Nach dem Neustart war die VM nicht mehr vom Netzwerk aus erreichbar.
Folgendes habe ich ausprobiert (Statische IP auf DHCP umgestellt) - Bekommt keine IP zugewiesen
NIC Adapter deinstalliert / Reboot der VM - nicht erreichbar
Wieder Statische IP vergeben (die selbige wie vorher), erscheint die Fehlermeldung IP-Adresskonflikt (Dies ist ausgeschlossen) Gleiche Meldung, auch wenn ich andere IP´s vergebe.
DNS Cache + arp -d durchgeführt, danach war die Meldung weg, jedoch immer noch nicht erreichbar.
VMWare Tools deinstalliert | System Reboot - nicht erreichbar
VMWare Tools installiert | System Reboot | statische IP vergeben | Meldung IP Adresskonflikt - nicht erreichbar
PING auf localhost und 127.0.0.1 funktioniert auf die statische IP (von der VM aus) Meldung Fehler bei der Übertragung. Allgemeiner Fehler.
Andere NIC vom VMWare ESXi genommen, gleiche Problem.
Jedoch funktioniert dies bei allen anderen VM´s, welche die NIC nutzen.
Hat jemand eine Idee wie ich das wieder in den Griff bekomme?
Vielen Dank schon mal im voraus.
ich habe ein seltsames Problem wo ich ehrlich gesagt gerade am verzweifeln bin.
Und zwar habe ich hier einen VMWare ESXi 5.0 Server mit einigen VM´s (Meist W2K8R2 SP1)
Es wurden keine Änderungen an der VM oder am VMWare ESXi vorgenommen.
Jetzt musste eine VM (W2K8R2 SP1) neugestartet werden.
Nach dem Neustart war die VM nicht mehr vom Netzwerk aus erreichbar.
Folgendes habe ich ausprobiert (Statische IP auf DHCP umgestellt) - Bekommt keine IP zugewiesen
NIC Adapter deinstalliert / Reboot der VM - nicht erreichbar
Wieder Statische IP vergeben (die selbige wie vorher), erscheint die Fehlermeldung IP-Adresskonflikt (Dies ist ausgeschlossen) Gleiche Meldung, auch wenn ich andere IP´s vergebe.
DNS Cache + arp -d durchgeführt, danach war die Meldung weg, jedoch immer noch nicht erreichbar.
VMWare Tools deinstalliert | System Reboot - nicht erreichbar
VMWare Tools installiert | System Reboot | statische IP vergeben | Meldung IP Adresskonflikt - nicht erreichbar
PING auf localhost und 127.0.0.1 funktioniert auf die statische IP (von der VM aus) Meldung Fehler bei der Übertragung. Allgemeiner Fehler.
Andere NIC vom VMWare ESXi genommen, gleiche Problem.
Jedoch funktioniert dies bei allen anderen VM´s, welche die NIC nutzen.
Hat jemand eine Idee wie ich das wieder in den Griff bekomme?
Vielen Dank schon mal im voraus.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 262114
Url: https://administrator.de/forum/vm-nic-nicht-mehr-erreichbar-262114.html
Ausgedruckt am: 23.12.2024 um 13:12 Uhr
12 Kommentare
Neuester Kommentar
Hast du im ESXi einen vSwitch konfiguriert so wie du ihn hier VMWare-Host erreicht Gateway nicht! im Screenshot sehen kannst ?
Das wäre hilfreich wenn du den auch mal posten könntest und beschreiben kannst wie der mit der Peripherie verbunden ist.
Das wäre hilfreich wenn du den auch mal posten könntest und beschreiben kannst wie der mit der Peripherie verbunden ist.
Hi auch,
ja wurde als vSwitch angebunden
VMWare ESXi NIC
Gerät | Geschw. | Konfiguriert | Switch | Mac | überwachte IP Bereiche | Wake-on-LAN
vmnic0 | 1000Voll | Verhandeln | vSwtich0 | MAC | 192.168.0.1 - 192.168.255.255 | Ja
vSwitch0 (wurde vom Standard her nicht weiter konfiguriert)
Anzahl Ports 120
MTU 1500
Promiscuous-Modus Ablehnen
MAC Änderung Akzeptieren
gefälschte Übertragung Akzeptieren
Der vSwitch ist an einen eigene NIC gebunden. VLAN´s im Netz gibt es keine. Und die NIC an sich hat auch keine IP-Adresse
ja wurde als vSwitch angebunden
VMWare ESXi NIC
Gerät | Geschw. | Konfiguriert | Switch | Mac | überwachte IP Bereiche | Wake-on-LAN
vmnic0 | 1000Voll | Verhandeln | vSwtich0 | MAC | 192.168.0.1 - 192.168.255.255 | Ja
vSwitch0 (wurde vom Standard her nicht weiter konfiguriert)
Anzahl Ports 120
MTU 1500
Promiscuous-Modus Ablehnen
MAC Änderung Akzeptieren
gefälschte Übertragung Akzeptieren
Der vSwitch ist an einen eigene NIC gebunden. VLAN´s im Netz gibt es keine. Und die NIC an sich hat auch keine IP-Adresse
192.168.255.255
Nur mal doof nachgefragt: Ist das richtig das du auf einen Class C IP Adresse mit einer Class B Maske arbeitest ???Und die NIC an sich hat auch keine IP-Adresse
Na ja wenigstens eine, nämlich die des Hypervisors muss sie ja zwingend haben.Aus dem Rest entnehmen wir dann mal das die Hypervisor NIC dann im Bridging Mode auf dem vSwitch arbeitet und der untagged mit allen Ports arbeitet, richtig ?
D.h. deine VMs arbeiten alle im gleichen IP Netz als auch der Hypervisor selber, da simples Bridging.
Hier verwirrt dann was du oben unter "überwachte IP Bereiche" angegeben jast, denn der Bereich inkludiert alle Netze im Bereich 192.168.0.0 /16 was etwas ungewöhnlich ist. Fragt sich auch was genau mit "überwacht" denn gemeint ist !?
Ein simpler L2 Switch überwacht ja nix im Netzwerk Sinne...?!
Zitat von @aqui:
Hier verwirrt dann was du oben unter "überwachte IP Bereiche" angegeben jast, denn der Bereich inkludiert alle
Netze im Bereich 192.168.0.0 /16 was etwas ungewöhnlich ist. Fragt sich auch was genau mit "überwacht" denn
gemeint ist !?
Hier verwirrt dann was du oben unter "überwachte IP Bereiche" angegeben jast, denn der Bereich inkludiert alle
Netze im Bereich 192.168.0.0 /16 was etwas ungewöhnlich ist. Fragt sich auch was genau mit "überwacht" denn
gemeint ist !?
Da darf man nicht zu viel drauf geben. VMWare setzt diese Werte automatisch nach irgendwelchen seltsamen Mechanismen.
Ein Screenshot vom vSwitch wäre deutlich hilfreicher als die ASCII-Art
Gruß
Bernhard
Hi,
wir haben solche Problem öfter in Zusammenhang mit vCloud Networking and Security erlebt bzw. gesehen. Dies ließ sich dann nur durch Entfernen der NIC aus der VM und anschließend der NIC-Einträge in der .VMX Datei zu entfernen. Bei vCNS liegt dies zumeist am dvFilter Treiber der auf die NIC gesetzt wird, um den Traffic mitzulesen und per vShield hostbasiertes Antivirus nutzen zu können.
Welchen Typ NIC hast du in der VM installiert?
e1000? e1000e? VMXNET3?
Hast du mal alle NICs aus der VM entfernt?
Geklont wurde die VM nicht zufällig oder? Dabei kann es zu Problemen mit den MAC-Adressen der NICs kommen. Also mal die MAC-Adressen aller VMs überprüfen oder der VM manuell eine andere MAC-Adresse geben (geht nur im ausgeschalteten Zustand)
Wir konnten es wie folgt lösen:
1. VM herunterfahren
2. VM aus der Bestandsliste des ESXi entfernt per Rechtsklick
3. Den Datastore geöffnet in dem sich die VM befindet und die .VMX Datei der VM heruntergeladen
4. Kopie von der .VMX Datei gemacht, als Sicherung
5. Die Original .VMX Datei mit einem gescheiten Texteditor öffnen (Notepad++ z.B.)
6. Herauslöschen aller Einträge die in Zusammenhang mit den NICs stehen
Sehen z.B. so aus:
ethernet0.present = "true"
ethernet0.virtualDev = "e1000"
ethernet0.networkName = "FOSA.LAN"
ethernet0.addressType = "vpx"
ethernet0.generatedAddress = "00:50:56:94:59:39"
ethernet0.pciSlotNumber = "32"
Es kann möglicherweise auch weitere Einträge mit ethernet1 etc. geben. Die alle einfach mal rauslöschen und anschließend Speichern.
7. Die bearbeitete .VMX Datei wieder hochladen auf den Datastore und das Original dort ersetzen.
8. Die VM wieder der Bestandsliste des ESXi hinzufügen per Rechtsklick.
9. VM starten ohne NIC und nach dem Bootvorgang wieder herunterfahren.
10. E1000 NIC zur VM hinzufügen und anschließend booten, feste IP vergeben und Glücklich sein
11. Überprüfen ob euer Backup-Programm die VM weiterhin erkennt. Die VM bekommt bei diesem Vorgang eine neue UUID im ESXi-Server und muss dann u.U. im Backupprogramm dem Sicherungsauftrag neu hinzufügt werden.
Gruß
Christian
CTO @ www.mgn-computing.de
wir haben solche Problem öfter in Zusammenhang mit vCloud Networking and Security erlebt bzw. gesehen. Dies ließ sich dann nur durch Entfernen der NIC aus der VM und anschließend der NIC-Einträge in der .VMX Datei zu entfernen. Bei vCNS liegt dies zumeist am dvFilter Treiber der auf die NIC gesetzt wird, um den Traffic mitzulesen und per vShield hostbasiertes Antivirus nutzen zu können.
Welchen Typ NIC hast du in der VM installiert?
e1000? e1000e? VMXNET3?
Hast du mal alle NICs aus der VM entfernt?
Geklont wurde die VM nicht zufällig oder? Dabei kann es zu Problemen mit den MAC-Adressen der NICs kommen. Also mal die MAC-Adressen aller VMs überprüfen oder der VM manuell eine andere MAC-Adresse geben (geht nur im ausgeschalteten Zustand)
Wir konnten es wie folgt lösen:
1. VM herunterfahren
2. VM aus der Bestandsliste des ESXi entfernt per Rechtsklick
3. Den Datastore geöffnet in dem sich die VM befindet und die .VMX Datei der VM heruntergeladen
4. Kopie von der .VMX Datei gemacht, als Sicherung
5. Die Original .VMX Datei mit einem gescheiten Texteditor öffnen (Notepad++ z.B.)
6. Herauslöschen aller Einträge die in Zusammenhang mit den NICs stehen
Sehen z.B. so aus:
ethernet0.present = "true"
ethernet0.virtualDev = "e1000"
ethernet0.networkName = "FOSA.LAN"
ethernet0.addressType = "vpx"
ethernet0.generatedAddress = "00:50:56:94:59:39"
ethernet0.pciSlotNumber = "32"
Es kann möglicherweise auch weitere Einträge mit ethernet1 etc. geben. Die alle einfach mal rauslöschen und anschließend Speichern.
7. Die bearbeitete .VMX Datei wieder hochladen auf den Datastore und das Original dort ersetzen.
8. Die VM wieder der Bestandsliste des ESXi hinzufügen per Rechtsklick.
9. VM starten ohne NIC und nach dem Bootvorgang wieder herunterfahren.
10. E1000 NIC zur VM hinzufügen und anschließend booten, feste IP vergeben und Glücklich sein
11. Überprüfen ob euer Backup-Programm die VM weiterhin erkennt. Die VM bekommt bei diesem Vorgang eine neue UUID im ESXi-Server und muss dann u.U. im Backupprogramm dem Sicherungsauftrag neu hinzufügt werden.
Gruß
Christian
CTO @ www.mgn-computing.de
Hi Christian,
ich hab die e1000 drin, habe diese auch schon mal deinstalliert und es mal mit der VMXNET3 ausprobiert, jedoch komplett ohne Erfolg.
Die VM wurde neu erstellt, lief auch über ein Jahr ohne Probleme, jedoch nachdem ich nach Monaten (ohne Änderungen an der VM) einen Neustart gemacht habe, trat der Fehler auf.
Deine Lösung hat leider nicht funktioniert.
Jedoch kann es an dem Cisco Switch liegen,diesen Tip gab mir ein Bekannter.
Doch da weiß ich bisher noch nicht wonach ich suchen soll.
Was ich bisher gefunden hatte war, dass im ARP Table des Ciscos der Eintrag mit der MAC von der VM auf incomplete steht.
Muss noch mal schauen wie ich da weiterkomme.
ich hab die e1000 drin, habe diese auch schon mal deinstalliert und es mal mit der VMXNET3 ausprobiert, jedoch komplett ohne Erfolg.
Die VM wurde neu erstellt, lief auch über ein Jahr ohne Probleme, jedoch nachdem ich nach Monaten (ohne Änderungen an der VM) einen Neustart gemacht habe, trat der Fehler auf.
Deine Lösung hat leider nicht funktioniert.
Jedoch kann es an dem Cisco Switch liegen,diesen Tip gab mir ein Bekannter.
Doch da weiß ich bisher noch nicht wonach ich suchen soll.
Was ich bisher gefunden hatte war, dass im ARP Table des Ciscos der Eintrag mit der MAC von der VM auf incomplete steht.
Muss noch mal schauen wie ich da weiterkomme.
Moin,
Um den Fehler etwas einzukreisen könntest Du einen separaten vSwitch erstellen, der an keine Hardware-NIC gebunden ist. Dann stellst Du Deine VM auf diesen (isolierten) vSwitch um. Wenn der Fehler dann nicht mehr auftritt, kannst Du von Einflüssen außerhalb der VM ausgehen.
Der Cisco-Eintrag muss nicht unbedingt die Ursache sein, es kann auch sehr gut die Folge sein
Gruß
Bernhard
Um den Fehler etwas einzukreisen könntest Du einen separaten vSwitch erstellen, der an keine Hardware-NIC gebunden ist. Dann stellst Du Deine VM auf diesen (isolierten) vSwitch um. Wenn der Fehler dann nicht mehr auftritt, kannst Du von Einflüssen außerhalb der VM ausgehen.
Der Cisco-Eintrag muss nicht unbedingt die Ursache sein, es kann auch sehr gut die Folge sein
Gruß
Bernhard
Mhh. Hast du schon mal im Windows der VM alle NICs deinstalliert und die Treiber vollständig entfernt? Der e1000 Treiber ist ja bereits im Windows enthalten und nur der für VMXNET3 wird erst mit den VMWare Tools nachinstalliert.
Einfach mal im Gerätemanager alle ausgeblendeten Geräte einblenden und unter Netzwerkkarten alle Gerät über Eigenschaften entfernen. Also nicht nur das Gerät entfernen, sondern den Treiber auch rausschmeissen. Und dann die VM neustarten im Anschluss. Ggf. dann nochmal die VMware Tools und die NICs neuinstallieren über den vSphere Client.
Die Ursache muss ja weder am vSwitch/vDS liegen, noch an der virtuellen NIC. Wenn Windows selber ein Problem mit dem NIC Treiber hat. Haben wir auch schon vereinzelt gesehen.
Und zur Sicherheit starte doch einfach msl den Cisco Switch neu. Der baut danach seine MAC Tabelle wieder neu auf.
Gruß
Christian
Einfach mal im Gerätemanager alle ausgeblendeten Geräte einblenden und unter Netzwerkkarten alle Gerät über Eigenschaften entfernen. Also nicht nur das Gerät entfernen, sondern den Treiber auch rausschmeissen. Und dann die VM neustarten im Anschluss. Ggf. dann nochmal die VMware Tools und die NICs neuinstallieren über den vSphere Client.
Die Ursache muss ja weder am vSwitch/vDS liegen, noch an der virtuellen NIC. Wenn Windows selber ein Problem mit dem NIC Treiber hat. Haben wir auch schon vereinzelt gesehen.
Und zur Sicherheit starte doch einfach msl den Cisco Switch neu. Der baut danach seine MAC Tabelle wieder neu auf.
Gruß
Christian
Hi auch,
die NIC habe ich schon komplett deinstalliert sowie die Treiber entfernt.
Auch mit dem VMXNET3 bringt es nichts.
Jedoch ist es so, dass gestern die interne Kommunikation getestet wurde (Ohne ESXi NIC), dies funktionierte ohne Probleme.
Ich habe gestern Nacht noch mal gesucht, dass werde ich in der kommenden Woche mal testen
http://arstechnica.com/civis/viewtopic.php?p=22441907
Da sind es die Cisco Switche die ich überprüfen darf.
SObald Besserung in sicht ist, poste ich das Resultat
Danke an alle für die Unterstützung
die NIC habe ich schon komplett deinstalliert sowie die Treiber entfernt.
Auch mit dem VMXNET3 bringt es nichts.
Jedoch ist es so, dass gestern die interne Kommunikation getestet wurde (Ohne ESXi NIC), dies funktionierte ohne Probleme.
Ich habe gestern Nacht noch mal gesucht, dass werde ich in der kommenden Woche mal testen
http://arstechnica.com/civis/viewtopic.php?p=22441907
Da sind es die Cisco Switche die ich überprüfen darf.
SObald Besserung in sicht ist, poste ich das Resultat
Danke an alle für die Unterstützung
Guten Nabend zusammen,
nach einem Wochenende konnte das Problem geortet werden.
Es liegt nicht am VMWare ESXi bzw. Windows System.
Es kann sich jedoch auch auf physikalische Systeme übertragen.
So wie es aussieht ist es ein netzwerkseitiges Problem (Teaming mit Ciscos).
Vielen dank für die intensive Unterstützung
nach einem Wochenende konnte das Problem geortet werden.
Es liegt nicht am VMWare ESXi bzw. Windows System.
Es kann sich jedoch auch auf physikalische Systeme übertragen.
So wie es aussieht ist es ein netzwerkseitiges Problem (Teaming mit Ciscos).
Vielen dank für die intensive Unterstützung
So wie es aussieht ist es ein netzwerkseitiges Problem (Teaming mit Ciscos).
Wie immer der klasssiche Fehler vermutlich: beim Cisco vergessen den Standard 802.3ad mit LACP einzustellen !!Macht man das nicht macht Cisco sein proprietäres PaGP.
Wie man das auf dem Cisco richtig macht sagt dir dieser Link Aggregation / Temaing Tutorial Auszug:
Netzwerk Management Server mit Raspberry Pi
