Dies ist ein etwas schwieriges Problem, das ohne dieselben grundlegenden Hintergrundinformationen nicht zu erklären ist. Ich werde versuchen, die Frage später bei Bedarf zu verfeinern.
Ursprünglich habe ich einen einzelnen gehosteten Server (Win 2008R2) mit dem folgenden Bereich von 8 IP-Adressen.
- Single NIC ( IP: x.x.128.72 -> x.x.128.79 // Subnet: x.x.255.192 // GW: x.x.128.65 )
Nachdem ich Hyper-V installiert und einen einzelnen virtuellen Server auf derselben Box eingerichtet hatte, wollte ich dem virtuellen Server eine der IP-Adressen zuweisen und alles andere normal weiterlaufen lassen.
--
Zuerst habe ich versucht, das "Externe" Netzwerk zu verwenden, aber (auch nach dem Einstellen von IPs auf dem "Virtuellen Adapter" ähnlich wieHierhatte aber Probleme, das Netzwerk überhaupt zum Laufen zu bringen).
Ich musste den Server am Laufen halten (sonst hätte ich mehr Zeit mit diesem Ansatz verbracht)
F1 ... War das eine vernünftige Entscheidung? Hätte ich diesen Weg weiterverfolgen sollen?
--
Ich habe mich dann entschieden, einen anderen Ansatz auszuprobieren - das HyperV-Netzwerk auf „Intern“ einzustellen (für das Management-Betriebssystem sichtbar)
- Physical NIC ( IP: x.x.128.72 to .75 // Subnet: x.x.255.192 // GW: x.x.128.65 )
- Virtual NIC ( IP: x.x.128.78 // Subnet: x.x.255.252 // GW: x.x.128.72 )
- Gateway was the same as the IP of the physical NIC )
- Virtual OS-NIC ( IP: x.x.128.77 // Subnet: x.x.255.252 // GW: x.x.128.78 )
- Gateway was the same as the IP of the host virtual-NIC )
--
Überraschenderweise funktionierte dieser Ansatz tatsächlich und ich konnte von allen folgenden Punkten aus Verbindungen herstellen: - Internet zu/von physischer Netzwerkkarte (xx128.72) - physische Netzwerkkarte (xx128.72) zu virtueller Netzwerkkarte des Betriebssystems (xx128.77), z. B. Testen über Ping + FTP - Internet zu/von virtueller Netzwerkkarte des Betriebssystems (xx128.72)
--
Mein Problem ist, dass dieser Ansatz anscheinend nur für kurze Zeit (ein paar Stunden) anhält.
Nach dieser Zeit scheint es, als könnte ich keine Verbindung mehr von der Netzwerkkarte des virtuellen Betriebssystems zum/vom Internet herstellen (ich kann aber immer noch eine Verbindung vom Host-Betriebssystem zum virtuellen Betriebssystem und vom Host-Betriebssystem zum Internet herstellen).
Ich habe dies ein paar Mal erneut getestet, mit den gleichen Ergebnissen ... Ich lasse den Server einige Stunden lang eingeschaltet (z. B. über Nacht), und wenn ich morgens zurückkomme, verliert das virtuelle Betriebssystem die Fähigkeit, zum Internet zu routen
--
Ich bin nicht ganz sicher, was ich als nächstes anschauen soll (oder ob ich das völlig falsch angehe)
Ein „möglicherweise relevanter Punkt“ ist, dass das Host-Betriebssystem auch RRAS (Routing und Remote Access) ausführt, dies dient jedoch nur zum Ausführen eines einfachen VPN
--
F2 – Mit Weizen sollte ich als nächstes rechnen? (Gibt es gute Referenzen/Empfehlungen, was ich ausprobieren könnte)
Würde mich über alle Gedanken oder Kommentare freuen (auch wenn Sie mir sagen, dass ich die Sache falsch angehe)
--
*EDIT - Zweiter Versuch, „Extern“ zu verwenden *
Nachdem ich es mit dem „externen“ Ansatz erneut versucht hatte, erhielt ich erneut KEINEN Netzwerkzugriff …
Ich habe dann die Option „Virtuelle LAN-Identifizierung für Verwaltungsbetriebssystem aktivieren“ deaktiviert ... Simsalabim, erwachte alles zum Leben.
Die kritische Formulierung war im Link „Mehr zur Verwaltung virtueller Netzwerke“ versteckt, der besagt:
Gibt eine Identifikationsnummer an, mit der der Netzwerkverkehr vom Verwaltungsbetriebssystem isoliert werden kann.
Endgültiges Ergebnis ...ERFOLG(aber ohne Lösung, warum es für eine begrenzte Zeit TEILWEISE funktioniert hat)
Später fand ich den folgenden MSDN-Blog-Beitrag interessant ...Grundlegendes zu Hyper-V-VLANs
Antwort1
Hyper-V ist eigentlich gar kein Add-on für Windows, sondern ein vollwertiger Hypervisor, der die Kontrolle übernimmt. Das ursprünglich installierte Betriebssystem wird dann zu einer Hyper-V untergeordneten Root-Partition. Das Basisbetriebssystem ist also jetzt technisch gesehen eine spezielle VM. Insofern kann die „spezielle“ VM Hardware durchleiten (um den Anschein zu erwecken, immer noch ein normales Betriebssystem zu sein). Dies ist die Standardkonfiguration für fast alle Hardware, nachdem Hyper-V aktiviert wurde. Wenn Sie jedoch ein virtuelles Netzwerk für Hyper-V erstellen, das mit einer physischen Netzwerkkarte verbunden ist, übernimmt Hyper-V den Besitz der Netzwerkkarte und sie wird nicht mehr durchgeleitet.
Ihre NIC-Konfiguration sollte wie folgt aussehen:
Für die physische Netzwerkkarte sollte nur das Protokoll „Microsoft Virtual Network Switch“ aktiviert sein (die einzige Ausnahme besteht, wenn es sich nicht um eine tatsächliche physische Netzwerkkarte handelt, z. B. bei einem per Software konfigurierten Team. In diesem Fall ist normalerweise ein anderes Protokoll verfügbar, das nicht deaktiviert werden kann).
Erstellen Sie im Virtual Network Manager des Hyper-V-Managers ein „Netzwerk“. Dadurch wird ein virtueller Netzwerk-Switch in Hyper-V erstellt. Machen Sie ihn zu einem externen Switch, der an die physische Netzwerkkarte angeschlossen ist, und aktivieren Sie das Kontrollkästchen, um dem Management-Betriebssystem Zugriff zu gewähren. Dadurch wird eine neue vNIC für das Basis-Betriebssystem erstellt (denken Sie daran, dass es sich eigentlich um eine spezielle VM handelt, Sie fügen dieser VM also eine vNIC hinzu ...). Die neue Netzwerkkarte muss möglicherweise für die IPs konfiguriert werden, die von der alten physischen Netzwerkkarte übernommen wurden (hängt von der verwendeten Hyper-V-Version ab, ob dies automatisch geschieht oder nicht).
Erstellen Sie nach Wunsch VMs, fügen Sie ihnen vNICs hinzu und hängen Sie diese vNICs an das entsprechende virtuelle Netzwerk an.
Externe virtuelle Netzwerke sind an eine physische Netzwerkkarte angeschlossen. Sie ermöglichen VMs, eine Verbindung zu den physischen Netzwerkkarten herzustellen. Interne virtuelle Netzwerke erstellen immer eine neue vNIC für das Management-Betriebssystem (es gibt kein Kontrollkästchen, es wird einfach immer ausgeführt). Dadurch können VMs mit dem Basisbetriebssystem kommunizieren, jedoch nicht mit physischen Netzwerkkarten. Private virtuelle Netzwerke sind nur für VMs und werden in keiner Weise an das Management-Betriebssystem angeschlossen.
Sie haben auch Probleme erwähnt, die den Betrieb aufrechterhalten. Wenn Sie keine NIC-Chips für Server verwenden (insbesondere Intel, Broadcom, QLogic, Emulex, NexGen, Mellanox usw.), müssen Sie mit Problemen rechnen. Stellen Sie außerdem sicher, dass Sie die neueste Firmware haben. Wenn Sie Via- oder Realtek-Chips verwenden, können Sie Zeit sparen und die Idee zuverlässiger Level-1-Hypervisoren (Hyper-V, ESXi, KVM usw.) aufgeben.