Hyper-V: Probleme mit der virtuellen Netzwerkverbindung lösen

Immer beklagen sich Leser, dass es bei einem virtuelle System in Hyper-V mit der Netzwerkverbindung nicht klappen will. Die folgenden Lösung hilft in den meisten Fällen.

Die in Windows (nur x64-Versionen und ab der Pro-Edition) integrierte Virtualisierungskomponente Hyper-V lässt sich zum Erstellen und Nutzen virtueller Systeme verwenden und genügt selbst professionellen Ansprüchen. Allerdings ist der Umgang damit im Vergleich zu Mitbewerbern wie VirtualBox oder VMWare teilweise etwas spröder. So stellt die Konfiguration der virtuellen Netzwerkverbindung viele Anwender immer wieder vor Probleme. Die enden damit, dass das virtuelle System zwar problemlos läuft, aber keinerlei Verbindung zu Netzwerk und Internet herstellen kann. Zwei wesentliche Punkte lassen sich in der Regel als Fehlerquelle ausmachen.

Einen virtuellen Netzwerkadapter einrichten

Soll das virtuelle System Zugang zu Netzwerk und Internet haben, müssen Sie einen virtuellen Netzwerkadapter einrichten. Während das bei andere Virtualisierungslösungen einfach als Teil des Einrichtens einer virtuellen Maschine erfolgt, ist es bei Hyper-V ein separater Schritt, der vor dem Einrichten der virtuellen Maschine durchgeführt werden muss. Dafür kann ein einmal erstellter virtueller Netzwerkadapter von verschiedenen virtuellen Maschinen genutzt werden. Der virtuelle Adapter kann in verschiedenen Modi betrieben werden, was wichtige Auswirkungen auf die Sicherheit von realem und virtuellem System hat.

  1. Wählen Sie im Hyper-V-Manager die Menüfunktion Aktion/Manager für virtuelle Switches, um einen virtuellen Netzwerkadapter einzurichten.
  2. Wählen Sie dann aus, was für eine Art von Adapter Sie verwenden möchten, und klicken Sie auf Create Virtual Switch:
  • hypv01Extern: Der virtuelle Netzwerkadapter wird direkt mit dem physikalischen Netzwerkadapter des Wirtssystems verbunden. Das virtuelle System hat somit genau dieselben Zugriffsmöglichkeiten (und bietet dieselben Angriffspunkte) wie der reale PC.
  • Intern: Der virtuelle Netzwerkadapter wird nur mit dem realen PC sowie gegebenenfalls anderen virtuellen Maschinen auf diesem PC verknüpft und kann mit diesem Daten in einem eigenen lokalen Netzwerk austauschen. Er erhält aber keine Verbindung zum Netzwerk des realen PCs.
  • Privat: Der virtuelle Netzwerkadapter wird nur mit anderen virtuellen Netzwerkadaptern auf demselben PC verbunden. Die virtuellen Systeme können also untereinander Daten austauschen, aber keinesfalls auf reale PCs oder Netzwerke zugreifen.
  1. Legen Sie dann einen Namen für diesen virtuellen Netzwerkadapter fest. Sollten mehrere reale Netzwerkadapter vorhanden sein und Sie einen Adapter vom Typ Extern einrichten, können Sie außerdem wählen, mit welchem der realen Adapter dieser verbunden werden soll. Klicken Sie dann unten auf OK.

Beim Einrichten der virtuellen Maschine wählen Sie bei den Netzwerkeinstellungen den zuvor erstellen virtuellen Netzwerkadapter als Verbindung. In den meisten Fällen, sollte die Netzwerkverbindung dann nach dem Installieren des virtuellen Systems direkt funktionieren. Falls nicht, beachten Sie bitte den nachfolgenden Abschnitt.

Fussball-EM 24-PlanerIhr lustiger Begleiter durch das Fussball-EM-Turnier 2024 in Deutschland

Fussball-EM24 - Der Witzeplaner

  • Alle Spiele, alle Termine und die besten Fussballwitze in einem kompakten Taschenbuch vereint.
  • Alle Stadien, alle Gruppen, alle Spieltage. Ihr kompetenter Begleiter vom Eröffnungsspiel bis zum Finale.
  • Mit Ergebnisfeldern und Tabellen zum Ausfüllen, damit Sie immer auf dem aktuellen Stand sind.
  • Und wenn es mal nicht so rund läuft, heitern Sie sich und Ihre Freunde mit echten Brüllern und den witzigsten Zitaten von Spielern und Trainern rund um den Rasenballsport im Handumdrehen wieder auf.
*Kommt über diesen Affiliate Link ein Kauf zustande, erhalte ich eine Provision. Für Käufer entstehen dadurch keinerlei Mehrkosten.

Wenn im installierten virtuellen System die Netzwerkkarte fehlt

Auch wenn man sich exakt an die vorangehend beschriebene Vorgehensweise hält, ist der Erfolg leider nicht garantiert. Auf manchen PCs findet das installierte virtuelle System bei dieser Konfiguration keine (virtuelle) Netzwerkkomponente vor, installiert dementsprechend keine Treiber und kann dann auch nicht auf das Netzwerk zugreifen. Wenn diese Situation vorliegt, obwohl der virtuelle Switch ordnungsgemäß eingerichtet wurde, hat sich folgende Vorgehensweise bewährt, die selbstverständlich auch bei einem bereits installierten virtuellen System nachträglich angewendet werden kann:

  1. hypv02Entfernen Sie in den Einstellungen des (heruntergefahrenen) virtuellen Systems zunächst die vorhandene Netzwerkkarte vollständig.
  2. Wählen Sie dann in den Einstellungen ganz oben Hardware/Hardware hinzufügen/Ältere Netzwerkkarte und klicken Sie dann auf Hinzufügen.
  3. hypv03Wählen Sie nun bei virtueller Switch den eingerichteten virtuellen Switch aus und klicken Sie unten auf OK.

Starten Sie dann das virtuelle System. Dieses wird nun beim Start neue Netzwerkhardware erkennen und einrichten. Danach sollte die Netzwerkverbindung endlich problemlos funktionieren.

16 Antworten

  1. Michael Schreiter sagt:

    DANKE für diesen Tipp !

  2. Tim Salmutter sagt:

    Habe mehrfach versucht eine Centos 8 Virtual Machine einzurichten – aber jedes mal wenn alle Einstellungen und Installationen vorgenommen sind und es heißt ich solle rebooten um die Centos 8 VM zu verwenden beginnt es wieder von neuem zu installieren…

  3. Tobias sagt:

    Vielen Dank. Das hat tatsächlich funktioniert.
    Eine Ergänzung noch. Bei der Installation der VM muss man zwingend Generation 1 auswählen. Andernfalls ist der Punkt „ältere Netzwerkkarte“ nicht gelistet.

  4. User123 sagt:

    Hat mir weitergeholfen – Danke

  5. Andy sagt:

    Danke für deine hilfreiche Antwort, nachdem ich nichts gefunden hatte habe ich mir das Programm kurzerhand gedownloadet und nach 40 Minuten warten auf das Beenden des Restarts hat es einwandfrei geklappt 😀

    Vielen Dank 🙂

  6. Wolfram sagt:

    @Andy:
    Dann sollte man rausfinden, woran das Ändern der Systemeinstellungen scheitert.
    Die Dateien in C:WindowslogsCBS, C:WindowsWinSxSpoqexec.log und C:WindowsInfsetupapi.dev.log geben dazu Hinweise.

    Ansonsten könnte man noch das hier probieren:
    http://unclassified.software/de/apps/hypervswitch

  7. Andy sagt:

    Danke für die schnelle Antwort, aber wie ich bereits sagte ich habe alles mögliche versucht nach dem drücken von deaktivieren wollte er einen neustart, bei 99% blieb er dann stehen und meinte: die Systemeinstellungen konnten nicht erfolgreich verändert werden sie werden nun zurück gesetzt.

  8. Wolfram sagt:

    @Andy:
    Hyper-V muss als Windows-Feature deinstalliert werden (Systemsteuerung unter „Programme und Features|Windows-Features aktivieren oder deaktivieren“).
    Anschließend läuft VirtualBox wieder (und vermutlich auch VMware).

  9. Andy sagt:

    Ich habe ein ganz anderes Problem:
    Beim einrichten eines virtuellen Switches steht nach dem Klicken auf „OK“:
    „Änderungen werden übernommen“
    doch auch nach 12 Stunden warten war es nicht fertig, egal ob Externes, Internes oder Privaten Switch.
    und beim Externen Netz kam mein Wlan Stick nicht zur Auswahl…ich muss dazu sagen mit Hyper V habe ich noch nie etwas gemacht und hätte ich auch nicht wenn VMware funktionieren würde aber Hyper V blockiert das und lässt sich auch nicht deaktivieren oder ähnliches.
    Und auch VirtualBox geht nicht da bekomme ich jedesmal einen BlueScreen, ich habe bereits bei VirtualBox und VMware wochenlang im Internet nach Lösungen gesucht aber keine half mir weiter also muss ich jetzt wohl doch zu Hyper V greifen.

    Ich würde mich über hilfreiche Antworten sehr freuen 😀

  10. Catnes sagt:

    Hallo,

    es ist vielleicht ein ganz blöde Frage.

    Mit VMware ist die Einrichtung des Netzwerkes so schön einfach.

    Ich benötige wegen Notebook & vieler Reisen wahrscheinlich die folgende Kombinationen aus 3 Netzwerkkarten.

    Die 1. Netzwerkkarte ist Extern mit der Netzwerkkarte für Netzwerkkabel verbunden. Home
    Die 2. Netzwerkkarte ist Extern mit der Netzwerkkarte für kabelloses Netzwerk verbunden. Hotel
    Die 3. Netzwerkkarte ist Intern. Diese soll es mir ermöglichen immer mit RDP über die selbe IP zuzugreifen. Die Verbindung über den Hyper-V Manager finde ich von den Funktionen her nicht so toll.

    Ich habe immer wieder das Problem, wenn sich ein paar Windows updates angesammelt hatten, dass ich über die Interne Netzwerkkarte nicht mehr auf den Windows 7 Client kam.
    Seit den letzten Updates bekommt der Client statt der festen IP eine APIPA.

    Anbei die Konfig für Intern vom Host:
    Ethernet-Adapter vEthernet (Intern):

    Verbindungsspezifisches DNS-Suffix:
    Beschreibung. . . . . . . . . . . : Hyper-V-Adapter – virtuelles Ethernet #4
    Physische Adresse . . . . . . . . : 00-15-5D-B2-07-04
    DHCP aktiviert. . . . . . . . . . : Nein
    Autokonfiguration aktiviert . . . : Ja
    IPv4-Adresse . . . . . . . . . . : 192.168.137.1(Bevorzugt)
    Subnetzmaske . . . . . . . . . . : 255.255.255.0
    Standardgateway . . . . . . . . . : 0.0.0.0
    DNS-Server . . . . . . . . . . . : 192.168.137.1
    192.168.178.1
    NetBIOS über TCP/IP . . . . . . . : Aktiviert

    ping -a 192.168.137.132

    Ping wird ausgeführt für atlas.workgroup [192.168.137.132] mit 32 Bytes Daten:
    Antwort von 62.155.240.94: Zielhost nicht erreichbar.
    Antwort von 62.155.240.94: Zielhost nicht erreichbar.
    Antwort von 62.155.240.94: Zielhost nicht erreichbar.
    Antwort von 62.155.240.94: Zielhost nicht erreichbar.

    Ping-Statistik für 192.168.137.132:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),

    Client:
    Ethernet-Adapter INTERN:

    Verbindungsspezifisches DNS-Suffix:
    Beschreibung. . . . . . . . . . . : Microsoft Hyper-V-Netzwerkadapter
    Physikalische Adresse . . . . . . : 00-15-5D-B2-07-27
    DHCP aktiviert. . . . . . . . . . : Nein
    Autokonfiguration aktiviert . . . : Ja
    IPv4-Adresse (Auto. Konfiguration): 169.254.169.218(Bevorzugt)
    Subnetzmaske . . . . . . . . . . : 255.255.0.0
    Standardgateway . . . . . . . . . : 192.168.137.1
    DNS-Server . . . . . . . . . . . : 192.168.137.1
    192.168.178.1
    NetBIOS über TCP/IP . . . . . . . : Deaktiviert

    C:Windowssystem32>hostname
    Atlas

    C:Windowssystem32>ping -a 192.168.137.132

    Ping wird ausgeführt für 192.168.137.132 mit 32 Bytes Daten:
    Antwort von 62.155.240.94: Zielhost nicht erreichbar.
    Antwort von 62.155.240.94: Zielhost nicht erreichbar.
    Antwort von 62.155.240.94: Zielhost nicht erreichbar.
    Antwort von 62.155.240.94: Zielhost nicht erreichbar.

    Ping-Statistik für 192.168.137.132:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),

    Mir ist durchaus bewusst, dass dieses Bild ein Hinweis auf doppelte IP-Vergabe ist.
    Vorallem noch, dass Ergebnis, wenn ich die IP auf 192.168.137.133 ändere. Auf einmal klappt es wieder. Ich habe allerdings nur diesen einen Client in dem Netzwerk.

    C:Windowssystem32>ping -a 192.168.137.132

    Ping wird ausgeführt für 192.168.137.132 mit 32 Bytes Daten:
    Antwort von 192.168.137.133: Zielhost nicht erreichbar.
    Antwort von 62.155.240.94: Zielhost nicht erreichbar.
    Antwort von 62.155.240.94: Zielhost nicht erreichbar.
    Antwort von 62.155.240.94: Zielhost nicht erreichbar.

    Ping-Statistik für 192.168.137.132:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),

    C:Windowssystem32>ping -a 192.168.137.133

    Ping wird ausgeführt für Atlas [192.168.137.133] mit 32 Bytes Daten:
    Antwort von 192.168.137.133: Bytes=32 Zeit<1ms TTL=128
    Antwort von 192.168.137.133: Bytes=32 Zeit<1ms TTL=128
    Antwort von 192.168.137.133: Bytes=32 Zeit<1ms TTL=128
    Antwort von 192.168.137.133: Bytes=32 Zeit<1ms TTL=128

    Ping-Statistik für 192.168.137.133:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
    Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

    Wie bekomme ich den falschen Eintrag wieder raus?
    Kein Erfolg mit den folgenden Befehlen.
    ipconfig /flushdns
    ipconfig /release
    ipconfig /renew
    ipconfig /registerdns

    Vielen Dank Catnes

  11. Wolfram sagt:

    @Alexander:
    Was spricht denn gegen eine eigene IP-Adresse?
    Wenn Deine VM ins Netz soll (externer VSwitch), dann braucht sie auch eine eigene IP-Adresse. Wenn nicht, hast Du den falschen Adaptertyp gewählt.

    Im Übrigen: Wenn die VM dieselbe IP-Adresse wie der Host hätte, dann hättest Du zwei Systeme mit derselben IP-Adresse im selben Netzwerk.
    An welche Maschine sollen die ankommenden Datenpakete denn dann zugestellt werden? Die, die lauter „ich“ schreit? 😉

  12. Alexander sagt:

    Hallo,

    kann man bei HyperV irgendwie einstellen, dass die VM keine eigene IP-Adresse bekommt sondern einfach die komplette Verbindung des Host nutzt?
    Bei meiner Testumgebung auf Win10 bekomme ich das nicht hin. Die VM bekommt, wenn ich den vSwitch als externes Netzwerk konfiguriere immer eine eigene IP, was ich aber nicht möchte.

    Wäre super, wenn mir hier evtl. jemand helfen könnte.

  13. Stephan sagt:

    Ich habe ein größeres Problem. Wenn ich den Switch einrichte dann verabschiedet sich die Internetverbindung und kommt auch nicht wieder. Auch ein Reboot hilft nicht.

    Ich muss dann die Netzwerkkarte im Geräte-Manager entfernen und neu booten. Dann kommt der Rechner wieder in’s Netz, Hyper-V bleibt autistisch.

    Es hat mal funktioniert, ist wohl bei irgendeinem Update über‘n Jordan.

    Leider setzt der VS-Emulator für Android auf Hyper-V und das ist der einzige der hier performant läuft (AMD CPU). Sonst würde ich den Hyper-V Rotz einfach meiden.

    Schönes Wochenende,
    Stephan

  14. Torsten sagt:

    Vielen Dank für die ausführliche und hilfreiche Anleitung.
    Kannte bislang nur VMware und hatte arge Probleme mit dem Netz unter Hyper-V.

  15. Sebastian sagt:

    Super, das war die Lösung.

  16. Bitboss sagt:

    Danke ich habe schon ziemlich lange gesucht.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Schließen