Hyper-V unter Win10 - Default Switch verliert IP Konfiguration

shawly

Lt. Commander
Registriert
Jan. 2012
Beiträge
1.291
Servus,

ich habe auf meinem Laptop Hyper-V installiert, seit Windows Version 1709, ist es ja so, dass ein Default Switch erzeugt wird von Hyper-V welcher als NAT läuft.
Das Problem ist, nach ein paar Minuten, verliert er seine Standard IP Konfiguration (192.168.133.129/28) und die IP wird aus irgendeinem Grund auf 169.254.163.178/16 gestellt, was dazu führt, dass alle VMs ihre Netzwerkverbindung verlieren.

Habe bereits versucht, dem Netzwerkadapter eine zweite IP hinzuzufügen 192.168.133.1/24, das funktioniert zwar und die behält er auch, aber Hyper-V fügt immer die Standard IP 192.168.133.129/28 hinzu welche er nach ein paar Minuten wieder verliert. Zwar ist die manuell hinzugefügte IP noch vorhanden, aber die VMs haben trotzdem keine Verbindung mehr zum Netzwerk.

Ich muss den Adapter dann in Windows deaktivieren und wieder aktivieren, dann bekommt er wieder die richtige IP Config und alles funktioniert wieder. Es liegt NICHT an den VMs, es ist definitiv der Virtual-Ethernet Adapter welcher von Hyper-V erzeugt wurde.
Verstehe aber nicht, wie ein Netzwerk-Adapter seine statische IP Konfiguration verlieren kann.

Kennt jemand dieses Phänomen und eine Lösung?

Und nein ein zweiter externer vSwitch in Hyper-V ist keine Lösung, wenn ich schon Workarounds nutzen muss, dann steige ich lieber gleich auf VirtualBox um. Würde aber gerne das Problem mit Hyper-V lösen, statt auf VirtualBox zu wechseln.
 
Was steht im Ereignisprotokoll dazu? Adresse möglicherweise doppelt vergeben?
 
shawly schrieb:
Im Ereignisprotokoll wurde nichts gelogged,

Ich halte es für unwahrscheinlich, dass gar nichts geloggt wurde, richtig unter den "Anwendungs- und Dienstprotokollen" geschaut und "Administrative Ereignisse" geprüft?

Unter Windows geschieht eigentlich gar nichts mehr ohne zig Protokolle dazu.
 
shawly schrieb:
dass ein Default Switch erzeugt wird von Hyper-V welcher als NAT läuft.

Ein HyperV Switch nutzt doch kein NAT.
Der ist entweder intern, privat oder extern.
Poste bitte mal Bild der Einstellungen des Switches.
Ergänzung ()

Und warum soll das ein /28 Netzwerk sein?
Und was ist das 192.168.133.0 Netzwerk?
Dein lokales LAN hinter deinem Router?
 
  • Gefällt mir
Reaktionen: shawly
xexex schrieb:
Ich halte es für unwahrscheinlich, dass gar nichts geloggt wurde, richtig unter den "Anwendungs- und Dienstprotokollen" geschaut und "Administrative Ereignisse" geprüft?

Unter Windows geschieht eigentlich gar nichts mehr ohne zig Protokolle dazu.

Ich habe Administrative Ereignisse geprüft aber unter Anwenduns und Dienstprotokolle wurde auch nichts diesbezüglich gelogged.
Unter Windows Logs > System gibt es ein paar info logs, dass der Switch erfolgreich initialisiert wurde. Tatsächlich hat der Switch-Netzwerkadapter nun auch wieder eine IP und die VM hat Zugriff auf das Netz. Sprich wenn man lange genug wartet, dann behebt sich das Problem nach einer gewissen Zeit von selbst. Tritt aber weiterhin willkürlich auf.

In den System Logs stehen diese INFO Logs:
13:19:48 The start type of the Gemeinsame Nutzung der Internetverbindung service was changed from disabled to demand start.
13:19:50 NIC E2CB537E-DCAE-4094-A260-ABEA536FDA36 successfully disconnected from port .
13:19:51 Miniport NIC E2CB537E-DCAE-4094-A260-ABEA536FDA36 (Friendly Name: Default Switch) successfully initialized.
13:19:51 Miniport NIC E2CB537E-DCAE-4094-A260-ABEA536FDA36 (Friendly Name: ) successfully enabled

Um 13:04 traten die selben Meldungen auf, ebenfalls um 12:27:56.

Es tritt auch ganz oft die Meldung von Netwtw06 auf in der steht: 7023 - Intel proprietary
Welches vom Wifi Adapter ausgelöst wird, aber der Laptop ist via Dock per LAN verbunden, Wifi ist deaktiviert bzw. nicht verbunden.

Die Meldungen mit dem Inhalt, dass der Adapter erfolgreich getrennt wurde, sind meisten vorangeführt von Meldungen des Service Control Managers, bei dem entweder der Service "Gemeinsame Nutzung der Internetverbindung" oder "Intelligenter Hintergrundübertragungsdienst" von disabled auf demand start bzw. von auto start auf demand start geändert wird.

So einen richtigen Zusammenhang hat das ganze aber nicht, denn jetzt ist die IP config gerade wieder verloren gegangen, aber KEINE Logmeldungen von Hyper-V-VmSwitch sind aufgetreten, nur eben wieder die Meldungen des Service Control Managers und die Netwtw06 Meldung.
 
shawly schrieb:
Und nein ein zweiter externer vSwitch in Hyper-V ist keine Lösung, wenn ich schon Workarounds nutzen muss, dann steige ich lieber gleich auf VirtualBox um. Würde aber gerne das Problem mit Hyper-V lösen, statt auf VirtualBox zu wechseln.

Ich will das Problem nicht umgehen, ich will es Lösen. :)
Sonst kann ich Hyper-V auch gleich in die Tonne treten und VirtualBox verwenden.
 
shawly schrieb:
Welches vom Wifi Adapter ausgelöst wird, aber der Laptop ist via Dock per LAN verbunden,

Ist das ein USB Dock? Möglicherweise hat das dann mit USB Energiemanagement zu tun!
 
Ist eine Dell TB16 Thunderbolt Dock.
Wenn ich einen eigenen NAT Switch erzeuge, dann verliert dieser seine IP Konfiguration nicht, daher muss es irgendwie mit Hyper-V's Verwaltung des Default Switches zu tun haben.

Ich habe hier noch einen zweiten Dell Laptop rumliegen, ich könnte dort auch mal Hyper-V aufsetzen und überwachen, ob das Problem dort auch auftritt. Denn die neue Dell Kiste die ich hier habe, macht ohnehin bereits mehr Probleme als der alte Laptop.
 
Warum ersetzt du den Switch nicht einfach durch einen externen?
Dadurch befinden sich alle VMs und dein Host im gleichen Netz hinter deinem Router.
Oder versprichst dir von dem NAT etwas?
 
Weil mein Laptop in einem Firmennetzwerk hängt und dort MACs freigegeben werden müssen, weshalb ich meine VMs nicht einfach ins selbe Netz stecken kann.
 
OK.
Dann könntest als Workaround einen privaten Switch erstellen und, wenn die VMs ins Internet sollen, Internet mittels ICS über den physischen Netzwerkadapter des Notebooks auf den virtuellen Hostadaper, der am privaten Switch hängt, freigeben.

Löst zwar nicht den Fehler des NAT Switches sollte aber auch gehen.
 
Zurück
Oben