Hyper-V unter Windows 10 - Wie einen Externen Switch konfigurieren?

Bewertung:  / 0

Details

Veröffentlicht am Sonntag, 23. Juni 2019 09:08

Zugriffe: 17106

Seit Windows 10 stellt Microsoft seine Virtualisierungslösung Hyper-V auch auf Client-Betriebssystemen zur Verfügung und ermöglicht so auf leistungsstarker Client-Hardware den Einsatz virtueller Computer beispielsweise für Testzwecke. Leider wird seit dem Windows 10 Upgrade 1709 im Netzwerk-Setup standardmäßig nur ein interner Default-Switch konfiguriert, der auch nicht deaktiviert oder konfiguriert werden kann. Der folgende Artikel beschreibt, wie ich dennoch wieder einen externen Switch unter Windows 10 konfigurieren konnte.

Das Problem trat unmittelbar nach dem Windows Upgrade 1709 auf: Nicht nur früher erfolgreich, konfigurierte virtuelle Testsysteme funktionierten nämlich danach plötzlich unter Windows 10 nicht mehr, sondern auch der Host-Rechner hatte fortan keinen Netzwerk-Zugang mehr. Aber ich würde das Problem eher aus der heutigen Perspektive beschreiben, denn das Problem kann auch heute noch bei Neuinstallationen von Windows 10 auftreten und wurde von Microsoft bis dato (Upgrade 1903) nicht gelöst.

Nehmen wir mal an, auf einem PC mit aktueller Hardware wird ein frisches Windows10Pro-System installiert und via Windows Update auf den neuesten Stand gepatcht. Das wäre in meinem Beispiel Windows 10 Upgrade 1903.
Anschließend füge ich den Windows10-Client als Domänen-Mitglied einem Domänen-Netzwerk hinzu. Wenn das geschehen ist, würde das Netzwerk-Setup üblicherweise so aussehen:

Bei diesem Netzwerk-Setup handelt es sich um eine 0815-Konfiguration: Der Client erhält per DHCP seine IP-Adresse, meldet sich im DNS sowie anschließend in der Domäne an: Also nix Besonderes.

Nun wird im nächsten Schritt das Windows-Feature "Hyper-V" unter Windows 10 aktiviert:

Nach der Installation von Hyper-V inklusive Zusatz-Tools sowie dem obligatorischen Neustart des PCs erscheint nun - anders als auf Server- oder früheren Windows10-Client-Installationen - kein Netzwerk-Setup mehr:

Das ist ein sehr hässlicher Fehler: Ein normal konfigurierter Windows-Client kann nach dem Aktivieren eines Windows-Features plötzlich keinerlei Netzwerk-Verbindungen mehr herstellen und ist auch nicht mehr im LAN-Netz erreichbar.

Die Ursache ist dann schnell gefunden: Mit der Hyper-V-Installation wurde zusätzlich zum physischen Netzwerk-Adapter ein Hyper-V Virtual Ethernet Adapter mit dem Name "Default Switch" installiert:

Das alleine ist noch nicht ungewöhnlich, denn schließlich muss die Hyper-V-Virtualisierungs-Software zwischen den Netzwerk-Paketen unterscheiden können, welche von aussen an das Host-Betriebssystem oder an einen der virtuellen Computer gerichtet sind und hat sich dafür in das Netzwerk-Setup des Host-Betriebssystems eingeklinkt.

Ungewöhnlich ist dagegen, dass der mit dem Adapter verbundene Netzwerk-Switch "Default Switch" im Manager für virtuelle Switches des Hyper-V-Managers nun standardmäßig auf "Internes Netzwerk" konfiguriert wurde und dennoch mit dem physischen Netzwerk-Adapter des externen Netzwerkes verknüpft bleibt:

In einem internen Netzwerk können die einzelnen virtuellen Computer (VMs) nur untereinander und mit dem Host kommunizieren. Eine Domänen-Anmeldung an einem externen Domänen-Controller aber wäre demnach unmöglich. Nur bei Verwendung eines Switches für externe Netzwerke sind die Testmaschinen wirklich eigenständig (beispielsweise mit einer eigenen IP-Adresse) im LAN-Netz vertreten.

Nun als Erstes wollte ich die Fehlkonfiguration beseitigen. Aber wie das Bild oben zeigt können die Einstellungen des Default Switch nicht geändert werden und auch der Button "Entfernen" hat keine Funktion. Microsoft möchte offenbar den Nutzer daran hindern an den Einstellungen des Default Switch irgend etwas zu ändern oder diesen zu löschen.

Dann versuchte ich ersatzweise einen eigenen zusätzlichen neuen virtuellen Switch für externe Netzwerke hinzuzufügen und wollte diesen dann anstelle des Default-Switches in den Einstellungen der einzelnen VMs verwenden. Allerdings funktioniert das nicht, denn der einzige zur Verfügung stehende Ethernet-Adapter ist bereits mit dem Default Switch verknüpft und kann folglich nicht für einen weiteren Switch genutzt werden. Der Hyper-V-Manager verhindert das dann auch mittels einer eindeutigen Fehlermeldung.

Deshalb kursieren im Internet bereits einige Anleitungen um Abhilfe für dieses Problem zu schaffen:

Zusätzliche Hardware

Glücklich können sich diejenigen PC-Besitzer schätzen, dessen Mainboards über zwei Ethernet-Schnittstellen verfügen oder die eine zweite Hardware-Ethernet-Schnittstelle beispielsweise als Einsteckkarte besitzen. Die können dann nämlich einfach den zusätzlichen virtuellen Switch für externe Netzwerke hinzufügen und diesen mit dem zweiten Ethernet-Adapter verknüpfen. Allerdings müssen Sie dann alle Ethernet-Verbindungen auch über diesen Netzwerk-Adapter laufen lassen.

Loopback-Adapter

Eine andere Anleitung beschreibt, wie man sich im Geräte-Manager einen neuen virtuellen Microsoft Loopback-Adapter hinzufügen kann. Das klappt zwar wunderbar und der Default-Switch nutzt nun plötzlich den neuen virtuellen Microsoft-Loopback-Adapter anstelle des physischen Ethernet-Adapters. Allerdings tut der Default Switch das nur, weil der physische Ethernet-Adapter nun nicht mehr zur Verfügung steht, denn dieser ist nun seinerseits mit dem virtuellen Microsoft Loopback-Adapter anstelle des Default Switches verknüpft.
Folglich wird auch bei Konfiguration des Microsoft Loopback-Adapters die Verknüpfung mit den Default Switch nicht aufgehoben, weshalb auch weiterhin die Erstellung eines neuen externen Switches nicht möglich ist.

Registry-Hacks

Noch andere Anleitungen beschreiben sehr üble Registry-Hacks um den von Microsoft während der Hyper-V-Installation konfigurierten Default Switch einfach zu löschen. Spätestens nach einem Neustart des PCs sind die gelöschten Konfigurationseinträge jedoch wieder vorhanden, woran man erkennen kann, welchen Aufwand Microsoft betrieben hatte um sicherzustellen, das das Setup für diesen Default Switch weder deaktiviert noch verändert werden kann.

Wenn es also nach Microsoft geht, kann auf Windows10-Clients die Hyper-V-Virtualisierungslösung nur für interne Netzwerke genutzt werden. Soll eine Domäne aufgebaut werden müssen alle Mitglieder dieser Domäne als virtuelle Computer in dem internen Netzwerk aufgebaut werden, also auch der Domänen-Controller sowie alle anderen Server-Systeme der Domäne.

Das wollte ich aber nicht, denn ich möchte die Client-Maschinen testen; nicht die ganze Domäne! Meine Lösung bestand deshalb dann schlicht darin, zunächst die Einstellungen des Ethernet-Adapters zu öffnen und dort die Verbindung zum virtuellen Hyper-V-Switch zu kappen:

Damit wird nur die Verbindung deaktiviert. Die Deinstallation wird von Microsoft verhindert und ist auch nicht notwendig. Anschließend ist es nämlich möglich den gewünschten zusätzlichen virtuellen Switch für externe Netzwerke im Manager für virtuelle Switsches des Hyper-V-Managers nun doch hinzuzufügen.
In meinem Beispiel hatte ich das unter dem Name "Extern Switch" erfolgreich machen können:

 Nun muss noch in den Einstellungen jedes einzelnen virtuellen Computers (VM) der neue externe Switch eingestellt werden:

Bei diesem bereits früher eingerichteten virtuellen Computer zeigt der Hyper-V-Manager bereits einen "Konfigurationsfehler" an. Dass muss aber nicht zwingend der Fall sein. Wichtig ist, dass der neue Switch "Extern Switch" eingestellt wird.

Abschließend wäre noch erwähnenswert, dass einige meiner virtuellen Testmaschinen nicht sofort wieder eine Netzwerk-Verbindung aufbauen konnten. Hier half nur in den Einstellungen des virtuellen Computers ein Reparieren des gesamten Netzwerk-Setups:

1. In den Einstellungen der VM ändern des Switches von "Extern Switch" auf "Nicht verbunden"
2. Die VM hochfahren und mit lokalen Administrator-Account anmelden
3. Alle Hyper-V-Ethernet-Adapter im Geräte Manager der VM löschen
4. Die VM herunterfahren
5. In den Einstellungen der VM ändern des Switches von "Nicht verbunden" auf "Extern Switch"
6. Die VM hochfahren

Die VMs waren anschließend wieder normal in der Windows-Domäne angemeldet und im LAN-Netz erreichbar.