Nutzung eines Teams in Hyper-V 2025

Hallo,

ja, das ist vollständig. Es gibt beim SET kein Team in der Parent-Partition, daher kann das Hyper-V-GUI nichts anzeigen.
Auf dem Hardware-Switch wird nichts konfiguriert (außer z.B. VLANs auf allen Members natürlich).

Dynamisches Balancing ist für manche Anwendungsfälle ungeignet (VoIP, Routing-Bypass z.B. bei LANCOM-Verwaltungsschnittstellen).

Grüße
Richard

Nabend,
im Netzwerk und Freigabe Center taucht der VMSwitch nur auf, wenn er für das Management auch genutzt werden darf. Ein reiner External oder Internal Switch taucht hier nicht auf.
Gruß

Moin @DiWiDiWi:


das geht mit dem richtigen Power-Shell Befehl, also ein LBFO-Team einem vSwitch als Uplink unterzujubeln, meines Wissens nach auch noch bei einem Server 2025, das sollte man jedoch seit Server 2016 nicht mehr machen, vor allem mit >= 10G NIC’s, da LBFO kein VM(M)Q oder SR-IOV unterstützt und ohne VM(M)Q oder SR-IOV, kannste VM-Seitig >= 10G eh knicken.


Das sollte eher so …

Set-VMSwitchTeam -Name "vSwitch_Network_External" -LoadBalancingAlgorithm HyperVPort

… aussehen, denn bei NIC’s >= 10G sollte nicht „Dynamic“ verwendet werden.

Siehe …


Quelle:
https://learn.microsoft.com/en-us/azure/azure-local/concepts/host-networ ...

Und das mit „For best performance“ ist zudem auch geschwindelt. 🙃

Denn mit der Performance selber, hat das Ganze nichts zu tun, sondern eher mit der Tatsache, dass bei „Dynamic“ die Ressourcen aller NIC’s und insbesondere auch deren VMQ und SQ-IOV VF’s, quasi summiert dem vSwitch/VM’s zur Verfügung gestellt werden. Sprich, wenn eine pNIC sagen wir mal 64 SR-IOV VF’s unterstützt und du packst 2 davon per SET und „Dynamic“ in einem vSwitch zusammen, dann stellt dieser vSwitch den VM’s in Summe 128 SR-IOV VF’s zur Verfügung, was sich im ersten Augenblick eigentlich ganz gut anhört.

Aber wenn man von diesen 128 VF’s, über 64 VF’s verbraucht, dann hat man schlichtweg keine HA-Kapazitäten mehr. Sprich wenn bei einer solchen Konfiguration und einer Belegung von >64 VF’s, nun einer der pNIC Ports ausfallen sollte, dann kann der andere Port nur max. 64 SR-IOV VF’s übernehmen und alle anderen VF’s(vNIC‘s) darüber, verlieren in dem Fall die Verbindung, respektive, im schlimmsten Fall bekommt der entsprechende HV-Node dann auch noch einen Blue-Screen. 😔😭

Das Traurige ist nun, dass das mit der Kalkulation der richtigen Ressourcen auch beim LoadBalancingAlgorithm "HyperVPort" nicht wirklich funktioniert, weshalb wir bei NIC's >= 10G, seit Server 2019 überhaupt kein Teaming mehr machen. 😔


Jup, mit dem oberen Befehl hast du lediglich einen vSwitch erstellt, von dem aus keine vNIC in die Management-VM gemountet wird, da …


… diese Option beim erstellen des Switches gesetzt war. 😉



Auch noch eine Broadcom P210p … 😱 … ähm, da habe ich dir leider schlechte Nachrichten, das mit VM(M)Q und SR-IOV, ist insbesondere auf diesen NIC’s alles andere als einfach. 😭

Sprich, wenn du in den VM’s wirklich 10G benötigst, dann solltest du dir lieber Mellanox CX-6 NIC’s holen, die machen mit VMQ oder SR-IOV, meiner bisherigen Erfahrung nach am wenigsten Stress.


Auf gar kein Fall solltest du auf dem Switch irgend ein Teaming einrichten, denn das benötigt das ein SET-Team schlichtweg nicht und es unterstützt auch absolut kein LACP & Co.!

Gruss Alex

Moin @aqui,


wie ich schon oben geschrieben habe, benötigt ein SET vSwitch, Switchseitig überhaupt kein Teaming.

Das mit LACP geht nur bei LBFO und LBFO gilt in Verbindung mit einen vSwitch, seit Server 2016 als veraltet.

Gruss Alex

Die Parent-Partition ist die Windows-Installation des Hosts. Stelle dir den vSwitch wirklich als Switch vor: Das SET ist ein Team zwischen dem vSwitch und dem physischen Switch. LBFO ist ein Team zwischen der Parent-Partition und dem physischen Switch, auf dessen Teaming-Adapter der vSwitch dann sitzt.
Das SET hingegen liegt nicht als Adapter in der Parent-Partition vor. Der ausgegraute Adapter im GUI des vSwitch hat keinerlei Bedeutung. Er ist sozusagen das, was für einen vSwitch im GUI auswählbar wäre, wenn gerade kein SET konfiguriert wäre.

Moin @DiWiDiWi,


du hast vollkommen Recht ...


... bei Server 2025 ist das tatsächlich nicht mehr möglich.

Lustig, seit Server 2016 prädigt Microsoft, dass LBFO bei einem vSwitch als veraltet gilt und erst bei Server 2025 fliegt es wirklich raus. 🙃

Gruss Alex

Moin @DiWiDiWi,


das hat nichts mit der Anzahl der VM's zu tun.
Wenn dein vSwitch bei einem >= 10G Uplink, VMMQ oder SR-IOV technisch nicht korrekt konfiguriert ist,
dann läuft dieser noch grottiger als ein 1G vSwitch. 😔


Für ein SET-Switch, musste man seitens der HW-Uplink-Switche noch nie einen Trunk (Loadbalancing/Failover) konfigurieren, sondern höchstens V-LAN's.

Oh ja stimmt, Cisco ... 😬 ... dort heisst ein Port auf dem mehrere V-LAN's anliegen, ja auch Trunk-Port. 🙃

Gruss Alex

Dann entfällt sehr wahrscheinlich auch der LACP LAG auf der Cisco Seite denn der Hypervisor benutzt dann kein dynamischen LAG nach 802.3ad Standard sondern einen Algorithmus der auch auf nicht managebaren Switches funktioniert, sprich also keinerlei Konfig auf der Switchseite benötigt.

Die Kunden sollen halt die Chance haben ihre Infrastruktur anzupassen, aber für Microsoft ist das sogar relativ schnell. Der MSI Installer ist seit so 20 Jahren deprecated und immer noch dabei.

Nein!
Port Channel ist ja immer ein LAG mit LACP nach 802.3ad Standard oder Ciscos proprietärem PaGP. Das ist bei "-LoadBalancingAlgorithm HyperVPort" dann definitiv ausgeschlossen da kein LAG. Ansonsten würde sich ein LAG nicht mehr mit dem Gegenüber verstehen wenn dort auch kein LAG definiert ist.

Nein, das SET-Balancing bestimmt nur die Verteilung des Outbound-Traffic auf die Links. Wenn du da viel hin und her stellst, kann es eine Weile dauern, bis es wie erwartet funktioniert. Oder Host neu starten.