Nutzung eines Teams in Hyper-V 2025
Hallo zusammen,
wir haben in Windows Server 2025 ein Team (2x 1GBits/s NICs) mit dem Server Manager für den Host erstellt. Für Hyper-V kann diese Art von Teams ja nicht mehr genutzt werden.
Also haben wir folgende Powershell-Kommandos verwendet, um zusätzliche 2x 10GBit/s NICs zu einem Team zu verschmelzen:
New-VMSwitch -Name "vSwitch_Network_External" -NetAdapterName "LAN-Adapter 5 (PCIe - V1)","LAN-Adapter 6 (PCIe - V2)" -AllowManagementOS $false -EnableEmbeddedTeaming $true
Set-VMSwitchTeam -Name "vSwitch_Network_External" -LoadBalancingAlgorithm Dynamic
In der Network Connections Liste erscheint das Teamed-Interface 'vSwitch_Network_External' nicht. Nur der mit Server Manager erstellte Adapter für den Host erscheint dort. Ist das so vorgesehen?
Nutzen wir => Get-VMSwitchTeam -Name "vSwitch_Network_External" | FL
dann erhalten wir eine Info darüber, daß beide 10GBit/s NICs im Team enthalten sind.
TeamingMode => SwitchIndependent
LoadBalancingAlgorithm => Dynamic
Im Virtual Switch Manager in Hyper-V sehen wir jetzt unter dem ausgegrauten External network: => Broadcom P210p NetXtreme-E Dual-port 10Gb Ethernet PCIe Adapter (die NIC mit #2 sehen wir dort nicht).
Ist die Konfiguration damit wirklich vollständig?
SET steht ja für Switch Embedded Teaming => das bedingt aber trotzdem noch eine Link Aggregation (LAG) auf z.B. einem Cisco Switch, richtig?
Falls wir etwas vergessen haben zu erwähnen, bitte einfach antworten.
Danke im voraus für eine Antwort.
wir haben in Windows Server 2025 ein Team (2x 1GBits/s NICs) mit dem Server Manager für den Host erstellt. Für Hyper-V kann diese Art von Teams ja nicht mehr genutzt werden.
Also haben wir folgende Powershell-Kommandos verwendet, um zusätzliche 2x 10GBit/s NICs zu einem Team zu verschmelzen:
New-VMSwitch -Name "vSwitch_Network_External" -NetAdapterName "LAN-Adapter 5 (PCIe - V1)","LAN-Adapter 6 (PCIe - V2)" -AllowManagementOS $false -EnableEmbeddedTeaming $true
Set-VMSwitchTeam -Name "vSwitch_Network_External" -LoadBalancingAlgorithm Dynamic
In der Network Connections Liste erscheint das Teamed-Interface 'vSwitch_Network_External' nicht. Nur der mit Server Manager erstellte Adapter für den Host erscheint dort. Ist das so vorgesehen?
Nutzen wir => Get-VMSwitchTeam -Name "vSwitch_Network_External" | FL
dann erhalten wir eine Info darüber, daß beide 10GBit/s NICs im Team enthalten sind.
TeamingMode => SwitchIndependent
LoadBalancingAlgorithm => Dynamic
Im Virtual Switch Manager in Hyper-V sehen wir jetzt unter dem ausgegrauten External network: => Broadcom P210p NetXtreme-E Dual-port 10Gb Ethernet PCIe Adapter (die NIC mit #2 sehen wir dort nicht).
Ist die Konfiguration damit wirklich vollständig?
SET steht ja für Switch Embedded Teaming => das bedingt aber trotzdem noch eine Link Aggregation (LAG) auf z.B. einem Cisco Switch, richtig?
Falls wir etwas vergessen haben zu erwähnen, bitte einfach antworten.
Danke im voraus für eine Antwort.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672865
Url: https://administrator.de/forum/nutzung-eines-teams-in-hyper-v-2025-672865.html
Ausgedruckt am: 04.06.2025 um 19:06 Uhr
71 Kommentare
Neuester Kommentar
das bedingt aber trotzdem noch eine Link Aggregation (LAG) auf z.B. einem Cisco Switch, richtig?
Das kommt ganz drauf an was Microsoft beim -LoadBalancingAlgorithm Dynamic unter "Dynamic" versteht?!Wenn sich dahinter ein 802.3ad bzw. 802.1AX kompatibles LAG Verfahren verbirgt, sprich ein im Netzwerk Bereich klassischer LACP LAG dann ja. Dann ist eine entsprechende Konfig auf der Switch Seite zwingend dazu erforderlich.
Zu mindestens bei Server 2012 war dem noch so.
https://www.firewall.cx/operating-systems/microsoft/windows-servers/wind ...
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
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
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
wir haben in Windows Server 2025 ein Team (2x 1GBits/s NICs) mit dem Server Manager für den Host erstellt. Für Hyper-V kann diese Art von Teams ja nicht mehr genutzt werden.
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.
Set-VMSwitchTeam -Name "vSwitch_Network_External" -LoadBalancingAlgorithm Dynamic
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. 😔
In der Network Connections Liste erscheint das Teamed-Interface 'vSwitch_Network_External' nicht. Nur der mit Server Manager erstellte Adapter für den Host erscheint dort. Ist das so vorgesehen?
Jup, mit dem oberen Befehl hast du lediglich einen vSwitch erstellt, von dem aus keine vNIC in die Management-VM gemountet wird, da …
-AllowManagementOS $false
… diese Option beim erstellen des Switches gesetzt war. 😉
Im Virtual Switch Manager in Hyper-V sehen wir jetzt unter dem ausgegrauten External network: => Broadcom P210p NetXtreme-E Dual-port 10Gb Ethernet PCIe Adapter (die NIC mit #2 sehen wir dort nicht).
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.
SET steht ja für Switch Embedded Teaming => das bedingt aber trotzdem noch eine Link Aggregation (LAG) auf z.B. einem Cisco Switch, richtig?
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,
Wenn sich dahinter ein 802.3ad bzw. 802.1AX kompatibles LAG Verfahren verbirgt, sprich ein im Netzwerk Bereich klassischer LACP LAG dann ja. Dann ist eine entsprechende Konfig auf der Switch Seite zwingend dazu erforderlich.
Zu mindestens bei Server 2012 war dem noch so.
https://www.firewall.cx/operating-systems/microsoft/windows-servers/wind ...
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
das bedingt aber trotzdem noch eine Link Aggregation (LAG) auf z.B. einem Cisco Switch, richtig?
Das kommt ganz drauf an was Microsoft beim -LoadBalancingAlgorithm Dynamic unter "Dynamic" versteht?!Wenn sich dahinter ein 802.3ad bzw. 802.1AX kompatibles LAG Verfahren verbirgt, sprich ein im Netzwerk Bereich klassischer LACP LAG dann ja. Dann ist eine entsprechende Konfig auf der Switch Seite zwingend dazu erforderlich.
Zu mindestens bei Server 2012 war dem noch so.
https://www.firewall.cx/operating-systems/microsoft/windows-servers/wind ...
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
Mit Parent-Partition meinst Du vermutlich den fehlenden "Microsoft Network Adapter Multiplexor Driver #2", da ja nur der 'Microsoft Network Adapter Multiplexor Driver" aus dem mit Server Manager erstellten LAN-Team existiert? Und deshalb wird nur der erste physikalische Adapter aus dem Team in der Hyper-V GUI sichtbar. Ehrlich gesagt, ich finde das sehr unübersichtlich und hätte mir gewünscht, daß das Teaming weiterhin über den Server Manager geht und der entsprechende Teaming-Adapter Name aus dem Server Manager erscheint, aber wenn es nun so ist, dann ist es so.
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
Soweit ich weiß nicht, auch Parameter-technisch hat sich wieder Einiges geändert, die Anzahl an YT-Videos zu dem Thema (WS2025) ist auch spärlich, deshalb hier halt das Forum.
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
Keine Sorge, das ist nur ein kleines System, auf dem ein paar ressourcenschonende VMs laufen ;)
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. 😔
Und unter Windows Server 2012 R2 mit den beiden Teams aus dem Server Manager hatte ich immer ein LAG ohne LACP für beide Teams und jetzt soll es für SET weggelassen werden ... irgendwie auch verwirrend.
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
-LoadBalancingAlgorithm HyperVPort… aussehen, denn bei NIC’s >= 10G sollte nicht „Dynamic“ verwendet werden.
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.Zitat von @MysticFoxDE:
Lustig, seit Server 2016 prädigt Microsoft, dass LBFO bei einem vSwitch als veraltet gilt und erst bei Server 2025 fliegt es wirklich raus. 🙃
Lustig, seit Server 2016 prädigt Microsoft, dass LBFO bei einem vSwitch als veraltet gilt und erst bei Server 2025 fliegt es wirklich raus. 🙃
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.
Muß vielleicht doch ein PortChannel auf dem Cisco-Switch konfiguriert werden?
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.
Moin @DiWiDiWi,
ja, das kann bei SET schon passieren, vor allem wenn man >= 10G NIC's verwendet, weil sich hier ein vSwitch ganz anders verhält wie bei einem SET-Team mit z.B. mehreren 1G NIC's, weil bei ab 10G schlichtweg Dinge wie VM(M)Q noch dazu kommen, die jedoch auf den meisten Systemen per Default nicht wirklich korrekt konfiguriert sind und daher auch nicht wirklich sauber funktionieren, wenn überhaupt. 😔
Kannst du mal bitte die vollständige Ausgabe von ...
... hier mal reinposten, danke.
Warum?
Sind die Server denn auch wirklich über zwei getrennte Switche angebunden?
Jain ... man kann es schon besser zum Laufen bekommen, dafür muss man jedoch eventuell das BIOS der Server optimieren und auch auf jeden Fall das BIOS deiner Broadcom NIC's, auch die Treiber der NIC's müssen vor allem RSS technisch korrekt eingestellt werden und noch einige andere Dinge. Erst dann kannst du den vSwitch erstellen, weil er z.B. nachträgliche Änderungen an den Treibern der NIC's nicht so gerne mag, dieser muss dann auch korrekt konfiguriert werden und auch die vNIC's der VM's, müssen auch entsprechend angepasst werden. Und wenn das alles was ich oben lediglich angeschitten habe sauber gemacht wurde und die NIC's auch keinen BUG hat, was z.B. bei den Intel NIC's der Fall ist, dann kann das was du vorhast, tatsächlich funktionieren. 😔
Jup und es war auch wesetlich einfacher ... aber ... bei Server 2012R2, haben die Meisten auch noch kein >= 10G verwendet. 🙃
Gruss Alex
Hmm, also LoadBalancing weiterhin => HyperVPort, auf Switch kein PortChannel und wenn ein Adapter ausfällt => Host neu starten? Ich kopiere Daten rein in die VMs und da friert es ein.
ja, das kann bei SET schon passieren, vor allem wenn man >= 10G NIC's verwendet, weil sich hier ein vSwitch ganz anders verhält wie bei einem SET-Team mit z.B. mehreren 1G NIC's, weil bei ab 10G schlichtweg Dinge wie VM(M)Q noch dazu kommen, die jedoch auf den meisten Systemen per Default nicht wirklich korrekt konfiguriert sind und daher auch nicht wirklich sauber funktionieren, wenn überhaupt. 😔
Kannst du mal bitte die vollständige Ausgabe von ...
Get-VMSwitch -Name 'vSwitch_Network_External' | FL
... hier mal reinposten, danke.
Teaming-Verzicht ist für uns nicht wirklich die Lösung!
Warum?
Sind die Server denn auch wirklich über zwei getrennte Switche angebunden?
Ist das SET unbrauchbar für solche Zwecke?
Jain ... man kann es schon besser zum Laufen bekommen, dafür muss man jedoch eventuell das BIOS der Server optimieren und auch auf jeden Fall das BIOS deiner Broadcom NIC's, auch die Treiber der NIC's müssen vor allem RSS technisch korrekt eingestellt werden und noch einige andere Dinge. Erst dann kannst du den vSwitch erstellen, weil er z.B. nachträgliche Änderungen an den Treibern der NIC's nicht so gerne mag, dieser muss dann auch korrekt konfiguriert werden und auch die vNIC's der VM's, müssen auch entsprechend angepasst werden. Und wenn das alles was ich oben lediglich angeschitten habe sauber gemacht wurde und die NIC's auch keinen BUG hat, was z.B. bei den Intel NIC's der Fall ist, dann kann das was du vorhast, tatsächlich funktionieren. 😔
Öhm, die Lösung ist k.cke! Ich meine unter Windows Server 2012 R2 hat das besser funktioniert 
Jup und es war auch wesetlich einfacher ... aber ... bei Server 2012R2, haben die Meisten auch noch kein >= 10G verwendet. 🙃
Gruss Alex
Moin Zusammen,
den folgende Artikel ...
https://www.altaro.com/hyper-v/erratic-behavior-hyper-v-network-load-bal ...
... vom Eric Siron der sich in dieses Thema auch schon sehr tief reingefuchst hat, kann ich an dieser Stelle nur empfehlen. 😉
Gruss Alex
den folgende Artikel ...
https://www.altaro.com/hyper-v/erratic-behavior-hyper-v-network-load-bal ...
... vom Eric Siron der sich in dieses Thema auch schon sehr tief reingefuchst hat, kann ich an dieser Stelle nur empfehlen. 😉
Gruss Alex
Moin @DiWiDiWi,
das habe ich so fast schon befürchtet. 😬
Ja ... OK ... in so einer Situation macht das Teaming schon auch Sinn, wird aber dadurch leider auch nicht einfacher. 😔
Gruss Alex
Yes sir, gestackter Cisco-Switch bestehend aus 2 Modulen.
das habe ich so fast schon befürchtet. 😬
Ja ... OK ... in so einer Situation macht das Teaming schon auch Sinn, wird aber dadurch leider auch nicht einfacher. 😔
Gruss Alex
Moin @DiWiDiWi,
es ist leider genau so wie ich befürchtet habe, sprich, so kann das nicht wirklich gut funktionieren. 😔
Ähm, ja, das wird jetzt etwas komplizierter. 😬
Ich schicke dir gleich per PN meine Kontaktdaten zu und wir können das Ganze ja mal telefonisch kurz grob durchsprechen und danach kannst du selber entscheiden, welchen Lösungs-Weg du danach beschreiten möchtest. 🙃
Gruss Alex
Name : vSwitch_Network_External
Id : 65dcd574-1358-49b0-b497-6271a7941a82
Notes :
Extensions : {Microsoft Windows Filtering Platform, Microsoft NDIS
Capture}
BandwidthReservationMode : Absolute
PacketDirectEnabled : False
EmbeddedTeamingEnabled : True
AllowNetLbfoTeams : False
IovEnabled : False
SwitchType : External
AllowManagementOS : False
NetAdapterInterfaceDescription : Teamed-Interface
NetAdapterInterfaceDescriptions : {Broadcom P210p NetXtreme-E Dual-port 10Gb Ethernet PCIe
Adapter, Broadcom P210p NetXtreme-E Dual-port 10Gb
Ethernet PCIe Adapter #2}
NetAdapterInterfaceGuid : {50484866-da8b-45d3-a23c-a2695f51e34a,
ce77210f-3bf8-4815-8d51-02fb6bc2a50a}
IovSupport : False
IovSupportReasons : {This network adapter does not support SR-IOV.}
AvailableIPSecSA : 0
NumberIPSecSAAllocated : 0
AvailableVMQueues : 516096
NumberVmqAllocated : 3
IovQueuePairCount : 142
IovQueuePairsInUse : 28
IovVirtualFunctionCount : 0
IovVirtualFunctionsInUse : 0
PacketDirectInUse : False
DefaultQueueVrssEnabledRequested : True
DefaultQueueVrssEnabled : True
DefaultQueueVmmqEnabledRequested : True
DefaultQueueVmmqEnabled : True
DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 8
DefaultQueueVrssMinQueuePairsRequested : 1
DefaultQueueVrssMinQueuePairs : 1
DefaultQueueVrssQueueSchedulingModeRequested : StaticVrss
DefaultQueueVrssQueueSchedulingMode : StaticVrss
DefaultQueueVrssExcludePrimaryProcessorRequested : False
DefaultQueueVrssExcludePrimaryProcessor : False
SoftwareRscEnabled : True
RscOffloadEnabled : False
BandwidthPercentage : 10
DefaultFlowMinimumBandwidthAbsolute : 1000000000
DefaultFlowMinimumBandwidthWeight : 0
CimSession : CimSession: .
ComputerName : XXXXXXXX
IsDeleted : False
DefaultQueueVmmqQueuePairs : 8
DefaultQueueVmmqQueuePairsRequested : 16
es ist leider genau so wie ich befürchtet habe, sprich, so kann das nicht wirklich gut funktionieren. 😔
Ähm, ja, das wird jetzt etwas komplizierter. 😬
Ich schicke dir gleich per PN meine Kontaktdaten zu und wir können das Ganze ja mal telefonisch kurz grob durchsprechen und danach kannst du selber entscheiden, welchen Lösungs-Weg du danach beschreiten möchtest. 🙃
Gruss Alex
Moin @DiWiDiWi,
im Folgenden möchte ich nur kurz auf diese Parameter ...
... deines vSwitches eingehen eingehen und erklären, warum alleine diese, von vorne bis hinten nicht stimmen. 😔
Aber keine Sorge, ist nicht deine Schuld, sondern die von MS, weil die diesen BUG seit Server 2016, also seit es SET gibt, nicht wirklich beseitigt bekommen. 😭
Denn, wenn du einen vSwitch mit nur einem Port dieser NIC's ...
... erstellst, dann sieht dessen Konfiguration +- folgend ...
... aus und ja, wir haben in unserem Test-LAB rein zufällig eine ähnliche Broadcom-NIC und ja unseren NIC . 🙃
Auf jeden Fall stellt der entsprechende Port bei der aktuellen Konfiguration der pNIC, die so jedoch nicht optimiert ist, daher auch nicht als Beispiel nehmen ...
AvailableVMQueues = 79
IovQueuePairCount = 167
... VMQ Ressourcen für max. 79 vNIC's (VF's) mit in Summe max. 167 QueuePairs (QP's) bereit.
Und nun kommt das Wesentliche, zumindest was diese(n) BUG(s) betrifft.
Denn wenn man nun hergeht und ein SET-Switch aus zwei solcher Ports baut ...
... und vor allem mit LoadBalancingAlgorithm = HyperVPort, dann darf der vSwitch nicht wirklich hergehen und die von beiden pNIC's (PF's) bereitgestellten AvailableVMQueues & IovQueuePairCount einfach zusammenadieren, sondern er darf nur das benutzen, was auch ein Port maximal an entsprechenden Ressourcen bereitstellt, sonst hat man nicht wirklich HA.
Aber, genau das bekommt Microsoft nicht wirklich auf die Kette und zwar wie schon oben angesprochen, seit fast 10 Jahren. Denn wenn man einen SET-Switch aus dem beiden Ports mit LoadBalancingAlgorithm = HyperVPort erstellt, ...
... dann weden sehr wohl die "IovQueuePairs" zusammengezählt (BUG Nr. 1) und diesen absoluten Blödsinn mit AvailableVMQueues = 516096 (BUG Nr. 2), konnte mir bisher auch noch keiner erklären. 😭
Sprich, eigentlich müsste laut der Theorie mit SET und der Verwendung von nur VM(M)Q, die Konfig des vSwitches was "IovQueuePairCount", "AvailableVMQueues" angeht, eigentlich genau so ausschauen wie auch ohne SET, was jedoch in der Praxis leider definitiv nicht der Fall ist. 🤢🤮
Das oben angesprochene Problem hat übrigens auch nichts mit den Broadcom NIC's zu tun, sonder tritt bei allen NIC-Herstellern auf, sprich, ist somit durch Microsoft selbst verursacht.
Ich suche bei Gelegenheit noch die Doku von Microsoft heraus, also die wo drin steht wie es eigentlich sein sollte. 🙃
Und das ist jetzt nur einer der duzenden Stulpersteine, die man bei diesem Thema berücksichtigen muss.
So, jetzt muss ich aber weiterflitzen.
Gruss Alex
im Folgenden möchte ich nur kurz auf diese Parameter ...
AvailableVMQueues : 516096
IovQueuePairCount : 142
... deines vSwitches eingehen eingehen und erklären, warum alleine diese, von vorne bis hinten nicht stimmen. 😔
Aber keine Sorge, ist nicht deine Schuld, sondern die von MS, weil die diesen BUG seit Server 2016, also seit es SET gibt, nicht wirklich beseitigt bekommen. 😭
Denn, wenn du einen vSwitch mit nur einem Port dieser NIC's ...
New-VMSwitch -Name "P210TEP" -NetAdapterName "P210TEP-1" -AllowManagementOS $false
... erstellst, dann sieht dessen Konfiguration +- folgend ...
Name : P210TEP
Id : 725713e9-900c-4399-a10f-7f0eae175ca0
Notes :
Extensions : {Microsoft Windows-Filterplattform, Microsoft-NDIS-Aufzeichnung}
BandwidthReservationMode : Absolute
PacketDirectEnabled : False
EmbeddedTeamingEnabled : False
AllowNetLbfoTeams : False
IovEnabled : False
SwitchType : External
AllowManagementOS : False
NetAdapterInterfaceDescription : Broadcom P210tep NetXtreme-E Dual-port 10GBASE-T Ethernet PCIe Adapter #2
NetAdapterInterfaceDescriptions : {Broadcom P210tep NetXtreme-E Dual-port 10GBASE-T Ethernet PCIe Adapter #2}
NetAdapterInterfaceGuid : {66b494fb-3077-4af8-bdff-ccc7641e8c6d}
IovSupport : True
IovSupportReasons :
AvailableIPSecSA : 0
NumberIPSecSAAllocated : 0
AvailableVMQueues : 79
NumberVmqAllocated : 0
IovQueuePairCount : 167
IovQueuePairsInUse : 16
IovVirtualFunctionCount : 0
IovVirtualFunctionsInUse : 0
PacketDirectInUse : False
DefaultQueueVrssEnabledRequested : True
DefaultQueueVrssEnabled : True
DefaultQueueVmmqEnabledRequested : True
DefaultQueueVmmqEnabled : True
DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 16
DefaultQueueVrssMinQueuePairsRequested : 1
DefaultQueueVrssMinQueuePairs : 1
DefaultQueueVrssQueueSchedulingModeRequested : StaticVrss
DefaultQueueVrssQueueSchedulingMode : StaticVrss
DefaultQueueVrssExcludePrimaryProcessorRequested : False
DefaultQueueVrssExcludePrimaryProcessor : False
SoftwareRscEnabled : True
RscOffloadEnabled : False
BandwidthPercentage : 10
DefaultFlowMinimumBandwidthAbsolute : 1000000000
DefaultFlowMinimumBandwidthWeight : 0
CimSession : CimSession: .
ComputerName : LABWS25-1
IsDeleted : False
DefaultQueueVmmqQueuePairs : 16
DefaultQueueVmmqQueuePairsRequested : 16
... aus und ja, wir haben in unserem Test-LAB rein zufällig eine ähnliche Broadcom-NIC und ja unseren NIC . 🙃
Auf jeden Fall stellt der entsprechende Port bei der aktuellen Konfiguration der pNIC, die so jedoch nicht optimiert ist, daher auch nicht als Beispiel nehmen ...
AvailableVMQueues = 79
IovQueuePairCount = 167
... VMQ Ressourcen für max. 79 vNIC's (VF's) mit in Summe max. 167 QueuePairs (QP's) bereit.
Und nun kommt das Wesentliche, zumindest was diese(n) BUG(s) betrifft.
Denn wenn man nun hergeht und ein SET-Switch aus zwei solcher Ports baut ...
New-VMSwitch -Name "P210TEP-SET" -EnableEmbeddedTeaming $true -NetAdapterName "P210TEP-1", "P210TEP-2" -AllowManagementOS $false
... und vor allem mit LoadBalancingAlgorithm = HyperVPort, dann darf der vSwitch nicht wirklich hergehen und die von beiden pNIC's (PF's) bereitgestellten AvailableVMQueues & IovQueuePairCount einfach zusammenadieren, sondern er darf nur das benutzen, was auch ein Port maximal an entsprechenden Ressourcen bereitstellt, sonst hat man nicht wirklich HA.
Aber, genau das bekommt Microsoft nicht wirklich auf die Kette und zwar wie schon oben angesprochen, seit fast 10 Jahren. Denn wenn man einen SET-Switch aus dem beiden Ports mit LoadBalancingAlgorithm = HyperVPort erstellt, ...
Name : P210TEP-SET
Id : 704cb7e0-4e01-42a4-a344-7f4534c59b8b
Notes :
Extensions : {Microsoft Windows-Filterplattform, Microsoft-NDIS-Aufzeichnung}
BandwidthReservationMode : Absolute
PacketDirectEnabled : False
EmbeddedTeamingEnabled : True
AllowNetLbfoTeams : False
IovEnabled : False
SwitchType : External
AllowManagementOS : False
NetAdapterInterfaceDescription : Teamschnittstelle
NetAdapterInterfaceDescriptions : {Broadcom P210tep NetXtreme-E Dual-port 10GBASE-T Ethernet PCIe Adapter #2, Broadcom P210tep NetXtreme-E Dual-port 10GBASE-T Ethernet PCIe Adapter}
NetAdapterInterfaceGuid : {66b494fb-3077-4af8-bdff-ccc7641e8c6d, af4c94cb-c15f-4741-8ef0-8250f3373dd3}
IovSupport : True
IovSupportReasons :
AvailableIPSecSA : 0
NumberIPSecSAAllocated : 0
AvailableVMQueues : 516096
NumberVmqAllocated : 0
IovQueuePairCount : 334
IovQueuePairsInUse : 32
IovVirtualFunctionCount : 0
IovVirtualFunctionsInUse : 0
PacketDirectInUse : False
DefaultQueueVrssEnabledRequested : True
DefaultQueueVrssEnabled : True
DefaultQueueVmmqEnabledRequested : True
DefaultQueueVmmqEnabled : True
DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 16
DefaultQueueVrssMinQueuePairsRequested : 1
DefaultQueueVrssMinQueuePairs : 1
DefaultQueueVrssQueueSchedulingModeRequested : StaticVrss
DefaultQueueVrssQueueSchedulingMode : StaticVrss
DefaultQueueVrssExcludePrimaryProcessorRequested : False
DefaultQueueVrssExcludePrimaryProcessor : False
SoftwareRscEnabled : True
RscOffloadEnabled : False
BandwidthPercentage : 10
DefaultFlowMinimumBandwidthAbsolute : 1000000000
DefaultFlowMinimumBandwidthWeight : 0
CimSession : CimSession: .
ComputerName : LABWS25-1
IsDeleted : False
DefaultQueueVmmqQueuePairs : 16
DefaultQueueVmmqQueuePairsRequested : 16
... dann weden sehr wohl die "IovQueuePairs" zusammengezählt (BUG Nr. 1) und diesen absoluten Blödsinn mit AvailableVMQueues = 516096 (BUG Nr. 2), konnte mir bisher auch noch keiner erklären. 😭
Sprich, eigentlich müsste laut der Theorie mit SET und der Verwendung von nur VM(M)Q, die Konfig des vSwitches was "IovQueuePairCount", "AvailableVMQueues" angeht, eigentlich genau so ausschauen wie auch ohne SET, was jedoch in der Praxis leider definitiv nicht der Fall ist. 🤢🤮
Das oben angesprochene Problem hat übrigens auch nichts mit den Broadcom NIC's zu tun, sonder tritt bei allen NIC-Herstellern auf, sprich, ist somit durch Microsoft selbst verursacht.
Ich suche bei Gelegenheit noch die Doku von Microsoft heraus, also die wo drin steht wie es eigentlich sein sollte. 🙃
Und das ist jetzt nur einer der duzenden Stulpersteine, die man bei diesem Thema berücksichtigen muss.
So, jetzt muss ich aber weiterflitzen.
Gruss Alex
gestackter Cisco-Switch bestehend aus 2 Modulen.
Module?? 🤔Du meinst bei dieser recht pauschalen Antwort wohl eher Switches (Units), oder?
Und da dann die Frage ob Hardware Stacking oder virtuell (Stackwise Virtual) beim Stacking??
Alternativ bestünde ja auch noch die Möglichkeit eines MLAG Setups. (Nexus etc.)
Über deine Switch Infrastruktur machst du ja leider nur wenig konkrete Angaben...
ist auch nicht mein Hauptbetätigungsfeld.
Aber der Netzwerk Kollege gegenüber sollte es ja genau wissen?! 9300er supporten weder MLAG (Cisco vPC) noch Stackwise Virtual (nur 9k4, 9k5, 9k6). Die können nur Hardware Stacking per extra Stack Modul, was ja in deinem o.a. Setup aber auch völlig reicht.
https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9300 ...
https://video.cisco.com/detail/video/6355253434112
Moin @DiWiDiWi,
Moment, hier muss ich etwas intervenieren. Denn der Kollege "Famous-Egg-4157" verwendet in seinem System warum auch immer honkalte "QLogic 57xxx" NIC’s, die maximal bis Server 2019 freigegeben sind …
https://www.windowsservercatalog.com/product/0a02f9d9-52c8-9af7-a638-6f1 ...
… und die auch kein VMMQ und auch kein vRSS unterstützen. 😔
Sprich, das kann mit Server 2025 und vor allem per Default, so überhaupt nicht gut gehen und selbst mit viel Optimierung, könnte ich diesen NIC’s, selbst unter einem Server 2019 nicht wirklich deren volle Leistung entlocken, zumindest nicht in eine virtualisierten Umgebung, weil diese dafür schlichtweg nicht die entsprechenden Features haben.
Und auch bei den von dir verwendeten Broadcom NIC’s, gibt es eine ganze Menge zu beachten und zwar alleine nur Broadcom-Seitig, sprich, BIOS- und Treiber-Technisch.
Schreibe später noch etwas mehr dazu.
Gruss Alex
Geil, ich lese mir gerade das durch (hat auch Windows Server 2025 und muß nun SET anstatt LBFO nutzen) und hat folgendes Phänomen ...
Critical Hyper-V SET Bug/Issue
Ich freu mich schon darauf *würg*
Critical Hyper-V SET Bug/Issue
Ich freu mich schon darauf *würg*
Moment, hier muss ich etwas intervenieren. Denn der Kollege "Famous-Egg-4157" verwendet in seinem System warum auch immer honkalte "QLogic 57xxx" NIC’s, die maximal bis Server 2019 freigegeben sind …
https://www.windowsservercatalog.com/product/0a02f9d9-52c8-9af7-a638-6f1 ...
… und die auch kein VMMQ und auch kein vRSS unterstützen. 😔
Sprich, das kann mit Server 2025 und vor allem per Default, so überhaupt nicht gut gehen und selbst mit viel Optimierung, könnte ich diesen NIC’s, selbst unter einem Server 2019 nicht wirklich deren volle Leistung entlocken, zumindest nicht in eine virtualisierten Umgebung, weil diese dafür schlichtweg nicht die entsprechenden Features haben.
Und auch bei den von dir verwendeten Broadcom NIC’s, gibt es eine ganze Menge zu beachten und zwar alleine nur Broadcom-Seitig, sprich, BIOS- und Treiber-Technisch.
Schreibe später noch etwas mehr dazu.
Gruss Alex
Moin @DiWiDiWi,
🤔 ja, der kommt mir auch irgendwie bekannt vor. 🤪
Wie du siehst, beschäftigt sich dieser 🦊 schon etwas länger mit diesem Thema/Krampf.
Gruss Alex
Hmm, irgendwie kommt mir das Avatar aus dem Artikel bekannt vor ;) Ich schwöre, ich wußte es vorher nicht!
🤔 ja, der kommt mir auch irgendwie bekannt vor. 🤪
Wie du siehst, beschäftigt sich dieser 🦊 schon etwas länger mit diesem Thema/Krampf.
Gruss Alex
Mit VMware ESXi wäre das jetzt kein Problem.
Mit Proxmox auch nicht! Nach dem ganzen VmWare Drama mit Broadcom ist es eine sehr gewagte Behauptung zu sagen es wäre nicht weit vertreten. Sogar Veeam supportet es mittlerweile auch mit der Community Edition. Sollte also mal einen Test wert sein bei dir! Schlimmer als Hyper V kann es ja nicht werden.
Moin @DiWiDiWi,
der DL20 Gen11 ist ein "Mini-Server", der für Hochleistungsvirtualisierung nicht wirklich gedacht ist. 🙃
Ja, mit VMware oder Proxmox hättest du jetzt wahrscheinlich viel weniger Stress.
Aber, das liegt nicht wirklich daran, dass VMware oder Proxmox das Thema viel besser umgesetzt haben,
sondern schlichtweg an der Tatsache, dass sie viel Features wie z.B. auch VM(M)Q, per Default überhaupt nicht benutzen. Und wenn du diese dort benutzen möchtest, dann bekommst du dort meist noch einen grösseren Krampf als beim Hyper-V. 😔
Und ohne VM(M)Q/SR-IOV, kann man die Performance spättestens bei >=10G knicken, weil das ganze SDN-Geraffel (vSwitche & vNIC's) in dem Fall komplett in Software läuft und dadurch vor alem CPU-technisch, einen extremen Overhead verursacht. Das gilt übrigens für alle Hypervisoren und nicht nur Hyper-V.
Zwischen 2012R2 und 2025 liegen Welten, vor allem was das SDN angeht.
Das mit SET hat schon berechtigte Gründe, weil LBFO schlichtweg kein VM(M)Q oder SR-IOV oder RDMA unterstützt und ohne diese "Features", macht eine >= 10G NIC, zumindest wenn diese als Uplink für einen vSwitch dient, nicht wirklich viel Sinn. Und dass man dafür quasi einen "Doktor-Abschluß" benötigt, ist auch nicht nur Microsoft geschuldet, sondern auch so gut wie allen NIC-Herstellern, weil z.B. deren Default-Werte, oft schlichtweg für den Hintern sind. 😔😭
https://community.spiceworks.com/t/server-2019-network-performance/72496 ...
🙃
In Server 2025 versucht MS mit Network-ATC ja genau das hinzubekommen, das macht jedoch bei weiten auch nicht das was wirklich nötig ist. 😔
👍👍👍 ... das mache ich jetzt auch, sprich, ab in den Garten ... muss noch ein paar brennende Esel rupfen. 🤪
Gruss Alex
Ganz ehrlich, ich habe hier eine nigelnagelneues HPE-Billigsystem DL20 Gen11 mit neustem BIOS und neuster Firmware und Windows Server 2025 auf dem neusten Stand und mit den neusten Treibern von HPE hochgezogen.
der DL20 Gen11 ist ein "Mini-Server", der für Hochleistungsvirtualisierung nicht wirklich gedacht ist. 🙃
Da erwarte ich einfach, daß das läuft, ohne einen deep dive auf Parameter-Ebene für die NICs zu machen. Mit VMware ESXi wäre das jetzt kein Problem und das System schon längst in Betrieb.
Ja, mit VMware oder Proxmox hättest du jetzt wahrscheinlich viel weniger Stress.
Aber, das liegt nicht wirklich daran, dass VMware oder Proxmox das Thema viel besser umgesetzt haben,
sondern schlichtweg an der Tatsache, dass sie viel Features wie z.B. auch VM(M)Q, per Default überhaupt nicht benutzen. Und wenn du diese dort benutzen möchtest, dann bekommst du dort meist noch einen grösseren Krampf als beim Hyper-V. 😔
Und ohne VM(M)Q/SR-IOV, kann man die Performance spättestens bei >=10G knicken, weil das ganze SDN-Geraffel (vSwitche & vNIC's) in dem Fall komplett in Software läuft und dadurch vor alem CPU-technisch, einen extremen Overhead verursacht. Das gilt übrigens für alle Hypervisoren und nicht nur Hyper-V.
Leider habe ich mich auf diesem Einzelsystem für Hyper-V entschieden, weil ich mit Windows Server 2012 R2 gute Erfahrungen gesammelt habe, was die Einfachheit der Bedienung anbetrifft.
Zwischen 2012R2 und 2025 liegen Welten, vor allem was das SDN angeht.
Wenn Microsoft meint, ein mit Windows Server 2016 funktionierendes LBFO-Team abzukündigen und stattdessen dieses Schrott SET zu empfehlen, welches ja bis heute nicht zufriedenstellend läuft, ohne bestimmte NICs einzusetzen oder die Parametrierung zu automatisieren, daß das auch ohne einen Doktor-Abschluß an der Uni funktioniert, dann ist das der größte Müll aller Zeiten, aber Du hast ja nicht umsonst diesen ellenlangen Artikel auf Spiceworks geschrieben.
Das mit SET hat schon berechtigte Gründe, weil LBFO schlichtweg kein VM(M)Q oder SR-IOV oder RDMA unterstützt und ohne diese "Features", macht eine >= 10G NIC, zumindest wenn diese als Uplink für einen vSwitch dient, nicht wirklich viel Sinn. Und dass man dafür quasi einen "Doktor-Abschluß" benötigt, ist auch nicht nur Microsoft geschuldet, sondern auch so gut wie allen NIC-Herstellern, weil z.B. deren Default-Werte, oft schlichtweg für den Hintern sind. 😔😭
Ich war zur Hälfte mit dem Artikel durch oder noch ein bißchen mehr, dann wurde ich müde ;)
https://community.spiceworks.com/t/server-2019-network-performance/72496 ...
🙃
Also, ich bin jetzt schon über 30 Jahre in der IT tätig und für Alles gibt es eine Lösung irgendwann, fragt sich nur, wann Microsoft sich bequemt, etwas Stabiles auf den Markt zu bringen, was mit Windows Server 2016 eingeführt wurde und bis heute nicht richtig funktioniert.
In Server 2025 versucht MS mit Network-ATC ja genau das hinzubekommen, das macht jedoch bei weiten auch nicht das was wirklich nötig ist. 😔
So, trink jetzt meinen Kaffee auf und dann erstmal Wochenendaktivitäten.
👍👍👍 ... das mache ich jetzt auch, sprich, ab in den Garten ... muss noch ein paar brennende Esel rupfen. 🤪
Gruss Alex
Moin @DiWiDiWi,
die haben sich durchaus was dabei gedacht, die Umsetzung ist bisher jedoch etwas suboptimal verlaufen. 😔
Aber, wenn du dieselben Features die beim Hyper-V per Default an sind, auch bei VMware oder Proxmox verwenden möchtest, dann brichst du dir dort zum Teil noch mehr die Finger. Wie ich schon weiter oben angesprochen habe, sehe ich bei Windows/Hyper-V das grösste Problem darin, dass so gut wie alle Feautures per Default an sind und zwar unabhängig davon, ob diese Hardwaretechnisch überhaupt korrekt bereitgestellt oder überhaupt benötigt werden und oder ob diese untereinander überhaupt kompatibel sind. 😭
Daher muss man beim Hyper-V auch sehr viel zurückdrehen respektive zurechtoptimieren, vor allem wenn man auch Performance/Effizienz haben möchte.
Auf der anderen Seite kann MS schon seit Jahren z.B. iWARP.
VMware spricht zwar theoretisch auch schon seit Jahren darüber, praktisch können die das bis heute jedoch nicht wirklich. 🙃
Stimmt nicht so ganz, denn mit einem WAC, kannst du den SET-Switch auch per GUI anlegen. 😉
Mir wäre es auch lieber, wenn dieses Thema etwas einfacher wäre, denn selbst die meisten Systemintegratoren die ich kennen, sind damit vollkommen überfordert. 😔
Gruss Alex
Aber mit SET einfach nur Schrott. Was denkt sich Microsaft dabei?
die haben sich durchaus was dabei gedacht, die Umsetzung ist bisher jedoch etwas suboptimal verlaufen. 😔
Aber, wenn du dieselben Features die beim Hyper-V per Default an sind, auch bei VMware oder Proxmox verwenden möchtest, dann brichst du dir dort zum Teil noch mehr die Finger. Wie ich schon weiter oben angesprochen habe, sehe ich bei Windows/Hyper-V das grösste Problem darin, dass so gut wie alle Feautures per Default an sind und zwar unabhängig davon, ob diese Hardwaretechnisch überhaupt korrekt bereitgestellt oder überhaupt benötigt werden und oder ob diese untereinander überhaupt kompatibel sind. 😭
Daher muss man beim Hyper-V auch sehr viel zurückdrehen respektive zurechtoptimieren, vor allem wenn man auch Performance/Effizienz haben möchte.
Auf der anderen Seite kann MS schon seit Jahren z.B. iWARP.
VMware spricht zwar theoretisch auch schon seit Jahren darüber, praktisch können die das bis heute jedoch nicht wirklich. 🙃
abgesehen von SET, wo schon Powershell notwendig ist.
Stimmt nicht so ganz, denn mit einem WAC, kannst du den SET-Switch auch per GUI anlegen. 😉
da ist es sehr müßig sich mit Parametrierung von NICs auseinanderzusetzen, wegen einem Popels-NIC-Team
Mir wäre es auch lieber, wenn dieses Thema etwas einfacher wäre, denn selbst die meisten Systemintegratoren die ich kennen, sind damit vollkommen überfordert. 😔
Gruss Alex
Moin @DiWiDiWi,
🤔 ... OK ... eins nach dem anderen.
Also, zuerst zu dem Komplizierten.
iWARP ist quasi einer der Geschwister der RDMA-Familie. Meiner Ansicht nach ist dieser auch der ausgereiftere Sprössling, weil er/sie/es viel schlichter aufgebaut ist und insbesondere auch keine besonderen "lossless" Switche benötigt. 😁
Nun zu den einfacheren Dingen.
Also, gemäss der einsteinschen Relativitätstheorie, ist ein WARP-Antrieb schlichtweg ein Unfug. 😔
Aber, gemäss der fuchsischen Relativitätstheorie …
Eine alternative Erklärung des Doppler-Effekts durch variable Lichtgeschwindigkeit
… sollte dieser kein Problem sein. 🤪
iWARP: Ja, in manchen Umgebungen macht das schon Sinn.
WARP-Antrieb: Definitiv, denn irgendwann geht auch mal unserer Sonne die Puste aus. 😉
Ich fürchte jedoch, dass wir uns lange davor schon selbst ausgelöscht haben. 😔
Installiere das Ding am besten in einer VM mit einem englischen OS und den WAC am besten auch auf Englisch installieren, dann läuft dieser auch etwas fehlerfreier.
Denn Tipp habe ich übrigens erst dem Letzt von einem MVP bekommen. 🙃
Ähm, ja, ich fürchte, das Thema GPU-P ist mindestens genau so ausgereift wie auch VM(M)Q oder SR-IOV. 😔
Ja, du möchtest mit dem SET lediglich ein NIC-Team abbilden, so wie die meisten anderen auch.
Aber, hinter SET steckt eine sehr komplexe Technologie, die so auch durchaus eine Berechtigung hat!
Leider haben es die Hersteller und damit meine ich nicht nur Microsoft, sondern auch Broadcom und auch Intel, bisher nicht wirklich geschafft, diese Technologie auch wirklich „einfach“ nutzbar zu machen, obwohl deren Marketing, genau das schon seit >10 Jahren bewirbt. 😭
Gruss Alex
Sorry, ich kenne nur WARP-Antrieb, aber das war glaube ich in der Enterprise!
🤔 ... OK ... eins nach dem anderen.
Also, zuerst zu dem Komplizierten.
iWARP ist quasi einer der Geschwister der RDMA-Familie. Meiner Ansicht nach ist dieser auch der ausgereiftere Sprössling, weil er/sie/es viel schlichter aufgebaut ist und insbesondere auch keine besonderen "lossless" Switche benötigt. 😁
Nun zu den einfacheren Dingen.
Also, gemäss der einsteinschen Relativitätstheorie, ist ein WARP-Antrieb schlichtweg ein Unfug. 😔
Aber, gemäss der fuchsischen Relativitätstheorie …
Eine alternative Erklärung des Doppler-Effekts durch variable Lichtgeschwindigkeit
… sollte dieser kein Problem sein. 🤪
Braucht man das? ;)
iWARP: Ja, in manchen Umgebungen macht das schon Sinn.
WARP-Antrieb: Definitiv, denn irgendwann geht auch mal unserer Sonne die Puste aus. 😉
Ich fürchte jedoch, dass wir uns lange davor schon selbst ausgelöscht haben. 😔
Jipp, habe ich im Thomas Krenn Video gesehen und wollte es dann installieren und stellte fest, daß man dafür dann ein Zertifikat braucht. Habe ich nicht und so ne 60 oder 90 Tage Version wollte ich auch nicht, also mal bei Google geschaut, wie man Eins erstellt, was länger hält, aber dann die Lust verloren, also WAC doch nicht installiert.
Installiere das Ding am besten in einer VM mit einem englischen OS und den WAC am besten auch auf Englisch installieren, dann läuft dieser auch etwas fehlerfreier.
Denn Tipp habe ich übrigens erst dem Letzt von einem MVP bekommen. 🙃
Werde ich aber irgendwann auf dem Host machen, auf dem dann auch GPU-P zum Einsatz kommen wird ;)
Ähm, ja, ich fürchte, das Thema GPU-P ist mindestens genau so ausgereift wie auch VM(M)Q oder SR-IOV. 😔
Wir reden hier von einem NIC-Team.
Ja, du möchtest mit dem SET lediglich ein NIC-Team abbilden, so wie die meisten anderen auch.
Aber, hinter SET steckt eine sehr komplexe Technologie, die so auch durchaus eine Berechtigung hat!
Leider haben es die Hersteller und damit meine ich nicht nur Microsoft, sondern auch Broadcom und auch Intel, bisher nicht wirklich geschafft, diese Technologie auch wirklich „einfach“ nutzbar zu machen, obwohl deren Marketing, genau das schon seit >10 Jahren bewirbt. 😭
Gruss Alex
Moin @DiWiDiWi,
ja, damit bist du schon mal nicht auf dem falschen Dampfer gelandet. 🙃
Ich habe dir kurz mal was erstellt ...
... .😉
Damit kannst du quasi einen nackten SET-Switch ohne die in den letzten 15 Jahren dazugekommenen Features wie Harwarebeschleunigung (VRSS, VM(M)Q, SR-IOV) erstellen, der dann aber zu 100% softwarebasiert läuft, wodurch nur eine bestimmte Performance (2-4 GB/s) zurverfügung steht und auch dessen Latenz nicht wirklich "low" ist.
Zudem erzeugt in einem solchen Fall, der Netzwerkverkehr auch deulich mehr CPU Leistung, weil die vSwitche und vNIC's nur per Software emmuliert werden, was wiederum, im Vergleich zu einem Bare-Metale oder einem HV System mit funktionierendem RSS, VRSS, VM(M)Q, SR-IOV & Co, sprich, im Vergleich zu hardwarebeschleunigten Systemen, deutlichst mehr und vor allem CPU Ressourcen frisst. 😔
Aber, Proxmox kann stand heute eh nur softwarebasierte vSwitche, sprich ist was das angeht noch nicht mal auf Stand vom Server 2012R2 und VMware erstellt per Default auch nur softwarebasierte vSwitche, sprich ohne VMQ oder SR-IOV. 🙃
Gruss Alex
Hab ein bißchen was zur Deaktivierung von RSS und VMQ gefunden. Werd da mal mit rumtesten und sehen, ob die VMs dann stabil laufen und Ihre Verbindung behalten, wenn die Adapter einzeln abgeschaltet werden und dann geschwenkt wird. Wie gesagt, NIC-Performance für die paar VMs hat da nicht die höchste Prio, da läuft ja keine SAP HANA oder Sonstiges drauf ;)
ja, damit bist du schon mal nicht auf dem falschen Dampfer gelandet. 🙃
Ich habe dir kurz mal was erstellt ...
$NIC1 = "P210TEP-1"
$NIC2 = "P210TEP-2"
$SETSWITCHNAME = "SET-SWITCH"
netsh int tcp set global RSC=Disabled
Disable-NetAdapterRsc -Name $NIC1, $NIC2 -IPv4 -IPv6 -NoRestart
Disable-NetAdapterRss -Name $NIC1, $NIC2 -NoRestart
Disable-NetAdapterVmq -Name $NIC1, $NIC2 -NoRestart
Disable-NetAdapterSriov -Name $NIC1, $NIC2 -NoRestart
Disable-NetAdapterRdma -Name $NIC1, $NIC2 -NoRestart
Get-NetAdapterAdvancedProperty -Name $NIC1 -IncludeHidden -AllProperties | FT -AutoSize
Set-NetAdapterAdvancedProperty -Name $NIC1, $NIC2 -RegistryKeyword "*LSOv2IPv4" -RegistryValue 0 -NoRestart
Set-NetAdapterAdvancedProperty -Name $NIC1, $NIC2 -RegistryKeyword "*UsoIPv4" -RegistryValue 0 -NoRestart
Set-NetAdapterAdvancedProperty -Name $NIC1, $NIC2 -RegistryKeyword "*UsoIPv6" -RegistryValue 0 -NoRestart
Set-NetAdapterAdvancedProperty -Name $NIC1, $NIC2 -RegistryKeyword "*RssOnHostVPorts" -RegistryValue 0 -NoRestart
Restart-NetAdapter -Name $NIC1, $NIC2
New-VMSwitch -Name $SETSWITCHNAME -EnableEmbeddedTeaming $true -NetAdapterName $NIC1, $NIC2 -AllowManagementOS $false
Set-VMSwitch -Name $SETSWITCHNAME -DefaultQueueVrssEnabled $false -DefaultQueueVmmqEnabled $false -EnableSoftwareRsc $false -EnableRscOffload $false
... .😉
Damit kannst du quasi einen nackten SET-Switch ohne die in den letzten 15 Jahren dazugekommenen Features wie Harwarebeschleunigung (VRSS, VM(M)Q, SR-IOV) erstellen, der dann aber zu 100% softwarebasiert läuft, wodurch nur eine bestimmte Performance (2-4 GB/s) zurverfügung steht und auch dessen Latenz nicht wirklich "low" ist.
Zudem erzeugt in einem solchen Fall, der Netzwerkverkehr auch deulich mehr CPU Leistung, weil die vSwitche und vNIC's nur per Software emmuliert werden, was wiederum, im Vergleich zu einem Bare-Metale oder einem HV System mit funktionierendem RSS, VRSS, VM(M)Q, SR-IOV & Co, sprich, im Vergleich zu hardwarebeschleunigten Systemen, deutlichst mehr und vor allem CPU Ressourcen frisst. 😔
Aber, Proxmox kann stand heute eh nur softwarebasierte vSwitche, sprich ist was das angeht noch nicht mal auf Stand vom Server 2012R2 und VMware erstellt per Default auch nur softwarebasierte vSwitche, sprich ohne VMQ oder SR-IOV. 🙃
Gruss Alex
Moin @aqui,
wenn man SR-IOV verwendet, dann ist das quasi so.
Denn in diesem Fall, wird die pNIC in diverse logische Teile aufgeteilt und diese kannst man dann direkt den VM's zuordnen, ähnlich wie bei GPU-P. Der Paketfluss zwischen SR-IOV beschleunigten vNIC und von diesen nach aussen, erfolgt dann auch grösstenteils hardwarebeschleunigt über die pNIC ASIC, was immens die CPU(s) entlastet.
Gruss Alex
Das die vSwitches in VmWare und Hyper V Hardware basiert sind war mir auch neu...
wenn man SR-IOV verwendet, dann ist das quasi so.
Denn in diesem Fall, wird die pNIC in diverse logische Teile aufgeteilt und diese kannst man dann direkt den VM's zuordnen, ähnlich wie bei GPU-P. Der Paketfluss zwischen SR-IOV beschleunigten vNIC und von diesen nach aussen, erfolgt dann auch grösstenteils hardwarebeschleunigt über die pNIC ASIC, was immens die CPU(s) entlastet.
Gruss Alex
Moin @DiWiDiWi,
ja, ich würde es sicherheitshalber jedoch trotzdem deaktivieren.
😁👍 ... siehst du, so übel ist SET ja gar nicht, zumindest wenn es korrekt konfiguriert ist. 🙃
Wenn du VMQ wieder aktivieren möchtest, dann sollte es vorher auch korrekt konfiguriert werden und zwar nicht nur VMQ, sondern auch SR-IOV und auch RSS, sprich, das ist eine ganz ganz andere Geburt wie die jetzige. 😔
Gruss Alex
Auf allen VMs ist 'Enable virtual machine queue' noch aktiviert, aber das wird ja auch nur genutzt, wenn der physische Netzadapter dies unterstützt.
ja, ich würde es sicherheitshalber jedoch trotzdem deaktivieren.
Get-VM | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 0 -VmmqEnabled $false
Dann habe ich wieder meine 2 Kopiervorgänge in 2 unterschiedlichen VMs gestartet und mit den Adaptern aus dem SET experimentiert (also Abschaltung und Anschaltung) und bisher keine Abbrüche mehr.
😁👍 ... siehst du, so übel ist SET ja gar nicht, zumindest wenn es korrekt konfiguriert ist. 🙃
Werde das wieder aktivieren und gegenchecken und wenn das stabil läuft, dann könnte man damit LIVE gehen oder gibt es Einwände, daß VMQ alleine nicht reicht?
Wenn du VMQ wieder aktivieren möchtest, dann sollte es vorher auch korrekt konfiguriert werden und zwar nicht nur VMQ, sondern auch SR-IOV und auch RSS, sprich, das ist eine ganz ganz andere Geburt wie die jetzige. 😔
Gruss Alex
Moin @DiWiDiWi,
ja, aber du hast es vorher auch nicht richtig konfiguriert gehabt, respektive, du hast vorher nicht die vermurkste Default-Konfiguration optimiert und auch das SR-IOV ist überhaupt nicht betriebsbereit, siehe Meldung im vSwitch.
Damit jedoch VMQ oder SR-IOV korrekt funktioniert, muss das System-BIOS, als auch das NIC-BIOS noch angepasst werden, zudem muss man RSS und VMQ, auf den entsprechenden pNIC auch korrekt konfigurieren und erst dann kann/sollte man VMQ oder SR-IOV verwenden.
Gruss Alex
Ich habe SR-IOV und RSS nicht deaktiviert.
ja, aber du hast es vorher auch nicht richtig konfiguriert gehabt, respektive, du hast vorher nicht die vermurkste Default-Konfiguration optimiert und auch das SR-IOV ist überhaupt nicht betriebsbereit, siehe Meldung im vSwitch.
Damit jedoch VMQ oder SR-IOV korrekt funktioniert, muss das System-BIOS, als auch das NIC-BIOS noch angepasst werden, zudem muss man RSS und VMQ, auf den entsprechenden pNIC auch korrekt konfigurieren und erst dann kann/sollte man VMQ oder SR-IOV verwenden.
Gruss Alex
Moin @DiWiDiWi,
die NIC kann schon SR-IOV. 😉
Damit das jedoch auch wirklich funktioniert, musst du wie ich schon geschrieben habe, sowohl am System-BIOS als auch am NIC-BIOS, noch einige Einstellungen anpassen.
Gruss Alex
Ich glaube das mit SR-IOV hat sich erledigt, siehe IovSupportReasons ...
die NIC kann schon SR-IOV. 😉
Damit das jedoch auch wirklich funktioniert, musst du wie ich schon geschrieben habe, sowohl am System-BIOS als auch am NIC-BIOS, noch einige Einstellungen anpassen.
Gruss Alex
Das "does not" meint das sie es kann ist sicher für viele eine neue Erkenntnis!
Ja, geht Dir das auch so? Jeden Tag neue Erkenntnisse :p
Na ja, die korrektere Beschreibung müsste eigentlich auch eher ...
"Unfortunately, this network adapter does not support SR-IOV, at least in its or the systems current configuration."
... heissen. 🙃
"THE NEXT LEVEL"...
ich meine gelesen zu haben (Broadcom & Intel) in den Readme's, daß Sie das aktuell "noch nicht" supporten..
Ein Austausch der NIC's von 10 auf 25GB brachte mir bis Dato nichts...
Ich werde dies beim nächsten Wechsel auf den neuen Cluster ZUVOR mit @MysticFoxDE testen...
Gruss Globe!
ich meine gelesen zu haben (Broadcom & Intel) in den Readme's, daß Sie das aktuell "noch nicht" supporten..
Ein Austausch der NIC's von 10 auf 25GB brachte mir bis Dato nichts...
Ich werde dies beim nächsten Wechsel auf den neuen Cluster ZUVOR mit @MysticFoxDE testen...
Gruss Globe!
Wenn es das als Lösung war bitte deinen Thead dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?