10
Hyper-V Portmirror - Fehlende Pakete
Hallo zusammen,
ich habe eine Tracing (Wireshark bzw. dumpcap) Umgebung für unser Microsoft S2D Cluster erstellt.
Dafür habe ich auf jedem Knoten eine VM erstellt, welche keine HA Rolle hat. Nun nutze ich die Hyper-V Funktion "portmirroring" um den Traffic der Produktiven VM's auf die Trace VM zu bekommen und diese dann dort mittels Capture Filter zu trennen.
Das funktioniert auch soweit. Nun ist meinem Netzwerker aufgefallen, dass immer mal wieder Pakete (Die von der Produktiv VM gesendet werden) nicht auf der Trace VM auftauchen. Um das zu validieren haben wir zusätzlich eine dumpcap Instanz auf der Produktiv VM laufen lassen. Beim Vergleich der beiden dumpcap Dateien ist dieser Fehler gut sichtbar geworden.
Leider haben meine Google Suchen nicht viel ergeben. Deswegen wende ich mich an euch.
Habt ihr Ideen woran das liegen könnte?
Was braucht noch für Infos um eine Aussage treffen zu können?
Danke im voraus.
Viele Grüße
Patrick
ich habe eine Tracing (Wireshark bzw. dumpcap) Umgebung für unser Microsoft S2D Cluster erstellt.
Dafür habe ich auf jedem Knoten eine VM erstellt, welche keine HA Rolle hat. Nun nutze ich die Hyper-V Funktion "portmirroring" um den Traffic der Produktiven VM's auf die Trace VM zu bekommen und diese dann dort mittels Capture Filter zu trennen.
Das funktioniert auch soweit. Nun ist meinem Netzwerker aufgefallen, dass immer mal wieder Pakete (Die von der Produktiv VM gesendet werden) nicht auf der Trace VM auftauchen. Um das zu validieren haben wir zusätzlich eine dumpcap Instanz auf der Produktiv VM laufen lassen. Beim Vergleich der beiden dumpcap Dateien ist dieser Fehler gut sichtbar geworden.
Leider haben meine Google Suchen nicht viel ergeben. Deswegen wende ich mich an euch.
Habt ihr Ideen woran das liegen könnte?
Was braucht noch für Infos um eine Aussage treffen zu können?
Danke im voraus.
Viele Grüße
Patrick
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3135440186
Url: https://administrator.de/forum/hyper-v-portmirror-fehlende-pakete-3135440186.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
10 Kommentare
Neuester Kommentar
Moin Patrik,
ist das ein Hyper-V 2019?
Wenn ja, hast du auf dem entsprechenden vSwitch noch RSC aktiviert?
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.
Ist der Uplink auf dem vSwitch geteamt?
Wenn ja welches, LBFO oder SET?
Verwendest du SR-IOV oder VMQ?
Geht es eventuell um IPv6 Verkehr?
Beste Grüsse aus BaWü
Alex
ist das ein Hyper-V 2019?
Wenn ja, hast du auf dem entsprechenden vSwitch noch RSC aktiviert?
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.
Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $falseIst der Uplink auf dem vSwitch geteamt?
Wenn ja welches, LBFO oder SET?
Verwendest du SR-IOV oder VMQ?
Geht es eventuell um IPv6 Verkehr?
Beste Grüsse aus BaWü
Alex
Moin Alex,
ich setze Hyper-V 2016 als auch 2019 ein. Natürlich sind die Versionen innerhalb eines Clusters identisch.
Ja bei allen vSwitch ist RSC aktiv. Werde das mal abklären ob das RSC für S2D eine Rolle spielt.
Melde mich sobald ich weitere Infos habe
Ja und nein, wenn die geteamt sind dann so:
Hyper-V 2016: LBFO
Hyper-V 2019: SET
Aber ich hab auch NICs die nicht geteamt sind.
SR-IOV ist bei uns deaktiviert.
VMQ ist bei unseren Containern aktiviert.
Nein es geht ausschließlich um IPv4 Verkehr.
Ich habe bei einer Trace VM in der vNIC -> Advanced Features -> Protected network deaktiviert. Dadurch wurde der Packet "lost" weniger.
Danke schon mal für die Ideen
Gruß
Patrick
ich setze Hyper-V 2016 als auch 2019 ein. Natürlich sind die Versionen innerhalb eines Clusters identisch.
Wenn ja, hast du auf dem entsprechenden vSwitch noch RSC aktiviert?
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.
Ja bei allen vSwitch ist RSC aktiv. Werde das mal abklären ob das RSC für S2D eine Rolle spielt.
Melde mich sobald ich weitere Infos habe
Ist der Uplink auf dem vSwitch geteamt?
Wenn ja welches, LBFO oder SET?
Wenn ja welches, LBFO oder SET?
Ja und nein, wenn die geteamt sind dann so:
Hyper-V 2016: LBFO
Hyper-V 2019: SET
Aber ich hab auch NICs die nicht geteamt sind.
Verwendest du SR-IOV oder VMQ?
SR-IOV ist bei uns deaktiviert.
VMQ ist bei unseren Containern aktiviert.
Geht es eventuell um IPv6 Verkehr?
Nein es geht ausschließlich um IPv4 Verkehr.
Ich habe bei einer Trace VM in der vNIC -> Advanced Features -> Protected network deaktiviert. Dadurch wurde der Packet "lost" weniger.
Danke schon mal für die Ideen
Gruß
Patrick
Moin Patrick,
tritt dieses Problem etwa auf beiden Clustern 2016/2019 gleich auf?
Ja bei allen vSwitch ist RSC aktiv. Werde das mal abklären ob das RSC für S2D eine Rolle spielt.
Melde mich sobald ich weitere Infos habe
soweit ich weis nicht, aber ich bin ehrlich gesagt auch kein S2D Experte.
Ja und nein, wenn die geteamt sind dann so:
Hyper-V 2016: LBFO
Hyper-V 2019: SET
😬, Details siehe hier.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Hast du auf den Nodes des 2019er Cluster noch je eine Physikalische NIC zur freien Verwendung?
Beides sollte das Problem eigentlich nicht verursachen, ich wollte es vorerst nur der Vollständigkeit halber wissen.
Nein es geht ausschließlich um IPv4 Verkehr.
Sehr gut, dann läuft du schon mal nicht in den Prüfsummenabladungsbug.
Wie bitte, 😮 ... 😵.
Sehr interessant aber absolut schräg, da dieses Feature eigentlich nicht aktiv in den Datenverkehr eingreifen sollte.
Aber das SDN benötigt aufgrund der ständigen Überwachung der entsprechenden vNIC's dadurch auch etwas mehr Leistung. 🤔
Ich habe da eine Idee, benötige im Vorfeld aber noch ein paar Infos.
Kannst du mir bitte die Konfiguration des entsprechenden vSwitches posten, danke.
Und auch die Infos zu den betreffenden vNIC's.
Welche physikalischen NIC's (Hersteller/Typ) verwendest du eigentlich?
Beste Grüsse aus BaWü
Alex
ich setze Hyper-V 2016 als auch 2019 ein. Natürlich sind die Versionen innerhalb eines Clusters identisch.
tritt dieses Problem etwa auf beiden Clustern 2016/2019 gleich auf?
Wenn ja, hast du auf dem entsprechenden vSwitch noch RSC aktiviert?
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.
Ja bei allen vSwitch ist RSC aktiv. Werde das mal abklären ob das RSC für S2D eine Rolle spielt.
Melde mich sobald ich weitere Infos habe
soweit ich weis nicht, aber ich bin ehrlich gesagt auch kein S2D Experte.
Ist der Uplink auf dem vSwitch geteamt?
Wenn ja welches, LBFO oder SET?
Wenn ja welches, LBFO oder SET?
Ja und nein, wenn die geteamt sind dann so:
Hyper-V 2016: LBFO
Hyper-V 2019: SET
😬, Details siehe hier.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Aber ich hab auch NICs die nicht geteamt sind.
Hast du auf den Nodes des 2019er Cluster noch je eine Physikalische NIC zur freien Verwendung?
SR-IOV ist bei uns deaktiviert.
VMQ ist bei unseren Containern aktiviert.
VMQ ist bei unseren Containern aktiviert.
Beides sollte das Problem eigentlich nicht verursachen, ich wollte es vorerst nur der Vollständigkeit halber wissen.
Geht es eventuell um IPv6 Verkehr?
Nein es geht ausschließlich um IPv4 Verkehr.
Sehr gut, dann läuft du schon mal nicht in den Prüfsummenabladungsbug.
Ich habe bei einer Trace VM in der vNIC -> Advanced Features -> Protected network deaktiviert. Dadurch wurde der Packet "lost" weniger.
Wie bitte, 😮 ... 😵.
Sehr interessant aber absolut schräg, da dieses Feature eigentlich nicht aktiv in den Datenverkehr eingreifen sollte.
Aber das SDN benötigt aufgrund der ständigen Überwachung der entsprechenden vNIC's dadurch auch etwas mehr Leistung. 🤔
Ich habe da eine Idee, benötige im Vorfeld aber noch ein paar Infos.
Kannst du mir bitte die Konfiguration des entsprechenden vSwitches posten, danke.
Get-VMSwitch -Name "VSWITCHNAME" | FL Und auch die Infos zu den betreffenden vNIC's.
Get-VM -Name "VMNAME"| Get-VMNetworkAdapter | FL Welche physikalischen NIC's (Hersteller/Typ) verwendest du eigentlich?
Beste Grüsse aus BaWü
Alex
Moin Alex,
entschuldige die späte Antwort, ich hatte Kundentermine und konnte deswegen noch nicht weiter Testen.
tritt dieses Problem etwa auf beiden Clustern 2016/2019 gleich auf?
Das muss ich noch testen. Habe eben schon mal ein Trace gestartet. Also werde ich heute Nachmittag eine Info haben.
Ja bei allen vSwitch ist RSC aktiv. Werde das mal abklären ob das RSC für S2D eine Rolle spielt.
Melde mich sobald ich weitere Infos habe
soweit ich weis nicht, aber ich bin ehrlich gesagt auch kein S2D Experte.
Ich werde mich dazu noch einlesen und nochmal meine Consulting Dame Fragen
Ja und nein, wenn die geteamt sind dann so:
Hyper-V 2016: LBFO
Hyper-V 2019: SET
😬, Details siehe hier.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Den Artikel führe ich mir heute zu gemühte Danke schon mal
Hast du auf den Nodes des 2019er Cluster noch je eine Physikalische NIC zur freien Verwendung?
Auf dem 2019er Cluster leider nein. Aber auf den 2016er Cluster (Hier bleibt abzuwarten was mein Test ergibt)
Wie bitte, 😮 ... 😵.
Sehr interessant aber absolut schräg, da dieses Feature eigentlich nicht aktiv in den Datenverkehr eingreifen sollte.
Aber das SDN benötigt aufgrund der ständigen Überwachung der entsprechenden vNIC's dadurch auch etwas mehr Leistung. 🤔
Ich hatte am Anfang den verdacht das es auch ein Performancethema sein könnte. Da die Packets ca. 2 Sekunden später erst auf der Tracing VM eintreffen(Hatte ich initial leider nicht erwähnt).
NIC's 2019er Cluster
Intel(R) Ethernet Server Adapter I350
NIC's 2016er Cluster
Intel(R) Ethernet Connection X722 for 1 GbE
Melde mich später nochmal
Grüße aus NRW
Patrick
entschuldige die späte Antwort, ich hatte Kundentermine und konnte deswegen noch nicht weiter Testen.
ich setze Hyper-V 2016 als auch 2019 ein. Natürlich sind die Versionen innerhalb eines Clusters identisch.
tritt dieses Problem etwa auf beiden Clustern 2016/2019 gleich auf?
Das muss ich noch testen. Habe eben schon mal ein Trace gestartet. Also werde ich heute Nachmittag eine Info haben.
Wenn ja, hast du auf dem entsprechenden vSwitch noch RSC aktiviert?
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.
Ja bei allen vSwitch ist RSC aktiv. Werde das mal abklären ob das RSC für S2D eine Rolle spielt.
Melde mich sobald ich weitere Infos habe
soweit ich weis nicht, aber ich bin ehrlich gesagt auch kein S2D Experte.
Ich werde mich dazu noch einlesen und nochmal meine Consulting Dame Fragen
Ist der Uplink auf dem vSwitch geteamt?
Wenn ja welches, LBFO oder SET?
Wenn ja welches, LBFO oder SET?
Ja und nein, wenn die geteamt sind dann so:
Hyper-V 2016: LBFO
Hyper-V 2019: SET
😬, Details siehe hier.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...
Den Artikel führe ich mir heute zu gemühte
Danke schon mal Aber ich hab auch NICs die nicht geteamt sind.
Hast du auf den Nodes des 2019er Cluster noch je eine Physikalische NIC zur freien Verwendung?
Auf dem 2019er Cluster leider nein. Aber auf den 2016er Cluster (Hier bleibt abzuwarten was mein Test ergibt)
Ich habe bei einer Trace VM in der vNIC -> Advanced Features -> Protected network deaktiviert. Dadurch wurde der Packet "lost" weniger.
Wie bitte, 😮 ... 😵.
Sehr interessant aber absolut schräg, da dieses Feature eigentlich nicht aktiv in den Datenverkehr eingreifen sollte.
Aber das SDN benötigt aufgrund der ständigen Überwachung der entsprechenden vNIC's dadurch auch etwas mehr Leistung. 🤔
Ich hatte am Anfang den verdacht das es auch ein Performancethema sein könnte. Da die Packets ca. 2 Sekunden später erst auf der Tracing VM eintreffen(Hatte ich initial leider nicht erwähnt).
Ich habe da eine Idee, benötige im Vorfeld aber noch ein paar Infos.
Kannst du mir bitte die Konfiguration des entsprechenden vSwitches posten, danke.
Kannst du mir bitte die Konfiguration des entsprechenden vSwitches posten, danke.
Get-VMSwitch -Name "VSWITCHNAME" | FL Name : //"entfernt"//
Id : f74bf650-222e-4781-b906-8310539923b4
Notes :
Extensions : {Microsoft Windows Filtering Platform, Microsoft NDIS Capture}
BandwidthReservationMode : Absolute
PacketDirectEnabled : False
EmbeddedTeamingEnabled : True
IovEnabled : False
SwitchType : External
AllowManagementOS : True
NetAdapterInterfaceDescription : Teamed-Interface
NetAdapterInterfaceDescriptions : {Intel(R) Ethernet Server Adapter I350-T4 #3, Intel(R) Ethernet Server Adapter I350-T4}
NetAdapterInterfaceGuid : {7aa789dd-063a-4bf1-b7a3-34fe624eab5e, 0d4aaeb6-79b2-4c79-b215-dd62c9c361cf}
IovSupport : True
IovSupportReasons :
AvailableIPSecSA : 0
NumberIPSecSAAllocated : 0
AvailableVMQueues : 14
NumberVmqAllocated : 3
IovQueuePairCount : 0
IovQueuePairsInUse : 0
IovVirtualFunctionCount : 0
IovVirtualFunctionsInUse : 0
PacketDirectInUse : False
DefaultQueueVrssEnabledRequested : True
DefaultQueueVrssEnabled : True
DefaultQueueVmmqEnabledRequested : True
DefaultQueueVmmqEnabled : False
DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 8
DefaultQueueVrssMinQueuePairsRequested : 1
DefaultQueueVrssMinQueuePairs : 1
DefaultQueueVrssQueueSchedulingModeRequested : StaticVrss
DefaultQueueVrssQueueSchedulingMode : StaticVrss
DefaultQueueVrssExcludePrimaryProcessorRequested : False
DefaultQueueVrssExcludePrimaryProcessor : False
SoftwareRscEnabled : True
BandwidthPercentage : 10
DefaultFlowMinimumBandwidthAbsolute : 200000000
DefaultFlowMinimumBandwidthWeight : 0
CimSession : CimSession: .
ComputerName : //"entfernt"//
IsDeleted : False
DefaultQueueVmmqQueuePairs : 8
DefaultQueueVmmqQueuePairsRequested : 16Und auch die Infos zu den betreffenden vNIC's.
Get-VM -Name "VMNAME"| Get-VMNetworkAdapter | FL Name : //"entfernt"//
Id : Microsoft:7E2103D7-8B13-47ED-983E-40906542EED3\AFD70BD6-5FE0-407F-8011-2523A7B7AF01
IsLegacy : False
IsManagementOs : False
ComputerName : //"entfernt"//
VMName : //"entfernt"// - Tracing
VMId : 7e2103d7-8b13-47ed-983e-40906542eed3
SwitchName : //"entfernt"//
SwitchId : f74bf650-222e-4781-b906-8310539923b4
Connected : True
PoolName :
MacAddress : 00155D01613D
DynamicMacAddressEnabled : True
AllowPacketDirect : False
NumaAwarePlacement : False
MacAddressSpoofing : Off
AllowTeaming : Off
RouterGuard : Off
DhcpGuard : Off
StormLimit : 0
PortMirroringMode : Destination
IeeePriorityTag : Off
VirtualSubnetId : 0
DynamicIPAddressLimit : 0
DeviceNaming : Off
VMQWeight : 0
VMQUsage : 0
IOVWeight : 0
IOVUsage : 0
IovQueuePairsRequested : 1
IovQueuePairsAssigned : 0
IOVInterruptModeration : Default
PacketDirectNumProcs : 0
PacketDirectModerationCount : 64
PacketDirectModerationInterval : 1000000
VrssEnabledRequested : True
VrssEnabled : False
VmmqEnabledRequested : True
VmmqEnabled : False
VrssMaxQueuePairsRequested : 16
VrssMaxQueuePairs : 1
VrssMinQueuePairsRequested : 1
VrssMinQueuePairs : 1
VrssQueueSchedulingModeRequested : Dynamic
VrssQueueSchedulingMode : Dynamic
VrssExcludePrimaryProcessorRequested : False
VrssExcludePrimaryProcessor : False
VrssIndependentHostSpreadingRequested : False
VrssIndependentHostSpreading : False
VrssVmbusChannelAffinityPolicyRequested : Strong
VrssVmbusChannelAffinityPolicy : Strong
IPsecOffloadMaxSA : 512
IPsecOffloadSAUsage : 0
VFDataPathActive : False
MaximumBandwidth :
MinimumBandwidthAbsolute :
MinimumBandwidthWeight :
BandwidthPercentage : 0%
MandatoryFeatureId : {}
MandatoryFeatureName : {}
Status : {Ok}
IPAddresses : {}Welche physikalischen NIC's (Hersteller/Typ) verwendest du eigentlich?
NIC's 2019er Cluster
Intel(R) Ethernet Server Adapter I350
NIC's 2016er Cluster
Intel(R) Ethernet Connection X722 for 1 GbE
Melde mich später nochmal
Grüße aus NRW
Patrick
Moin Alex,
Auf dem 2016 Cluster tritt das Problem nicht auf. Dort verwenden wir ein LBFO Teaming.
Gruß
Patrick
tritt dieses Problem etwa auf beiden Clustern 2016/2019 gleich auf?
Auf dem 2016 Cluster tritt das Problem nicht auf. Dort verwenden wir ein LBFO Teaming.
Gruß
Patrick
Moin Patrick,
Auf dem 2016 Cluster tritt das Problem nicht auf. Dort verwenden wir ein LBFO Teaming.
ich sehe dein Problem schon an dem vorherigen Post. 😀
Geb mir noch etwas Zeit um wieder fit zu werden (habe gerade Corona 🤮),
dann schreibe ich dir ausführlich woran das liegt und was zu machen ist.
Beste Grüsse aus BaWü
Alex
tritt dieses Problem etwa auf beiden Clustern 2016/2019 gleich auf?
Auf dem 2016 Cluster tritt das Problem nicht auf. Dort verwenden wir ein LBFO Teaming.
ich sehe dein Problem schon an dem vorherigen Post. 😀
Geb mir noch etwas Zeit um wieder fit zu werden (habe gerade Corona 🤮),
dann schreibe ich dir ausführlich woran das liegt und was zu machen ist.
Beste Grüsse aus BaWü
Alex
Moin Patrick,
sehr gut, Intel, meine Lieblinge. 😀
Egal was die sagt, schalt das bescheuerte RSC aus, das bringt nur Probleme und wird von deinen NIC's eh nicht unterstützt, weil Intel den RSC Support bei den Treibern für Server 2019, schon vor über einem Jahr, vollständig entfernt hat.
Das ist eigentlich nur einer der kleinen Brüder von diesem hier. 🤪
https://community.spiceworks.com/topic/post/9486432
Und der Letzte Post in diesem, betrifft +- auch dich.
Mal abgesehen vom RSC ist RSS dein zweites Problem.
Die Lastverteilungstechnologie ist erst ab 10G NIC's wichtig und dann muss diese
bei allen NIC auch noch richtig konfiguriert werden. Mit den Standardeinstellungen der Hersteller kannst du diese meistens mehr als nur knicken.
Für dich ist das ganze aber eh egal, weil du nur 1G NIC's hast und somit auf RSS vollkommen pfeifen kannst, da ein modernen Kern alleine schon locker 5-10G wuppen kann.
Sprich, als erstes solltest du RSS (Empfangsseitige Skalierung) auf den physikalischen NIC's und auch auf den vNIC's innerhalb der VM's deaktivieren.
danach sollten diese beiden Werte des vSwitches eigentlich auf 1 gehen.
DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 8
DefaultQueueVmmqQueuePairs : 8
DefaultQueueVmmqQueuePairsRequested : 16
Wenn nicht, dann musst du von Hand etwas nachhelfen.
Bei der vNIC sieht von aussen gar nicht so schlecht aus.
VrssMaxQueuePairs : 1
Das einzige was mir hier nicht gefällt ist der "VrssQueueSchedulingMode",
hier sollte eigentlich nicht "Dynamic" stehen, was die gleichzeitige Verwendung von RSS und VMQ ermöglicht sondern "StaticVrss".
Danach sollten deine Datenpakete wieder ohne Verlust durchflutschen.
Beste Grüsse aus BaWü
Alex
NIC's 2019er Cluster
Intel(R) Ethernet Server Adapter I350
NIC's 2016er Cluster
Intel(R) Ethernet Connection X722 for 1 GbE
Intel(R) Ethernet Server Adapter I350
NIC's 2016er Cluster
Intel(R) Ethernet Connection X722 for 1 GbE
sehr gut, Intel, meine Lieblinge. 😀
Ich werde mich dazu noch einlesen und nochmal meine Consulting Dame Fragen
Egal was die sagt, schalt das bescheuerte RSC aus, das bringt nur Probleme und wird von deinen NIC's eh nicht unterstützt, weil Intel den RSC Support bei den Treibern für Server 2019, schon vor über einem Jahr, vollständig entfernt hat.
Den Artikel führe ich mir heute zu gemühte Danke schon mal
Danke schon mal Das ist eigentlich nur einer der kleinen Brüder von diesem hier. 🤪
https://community.spiceworks.com/topic/post/9486432
Und der Letzte Post in diesem, betrifft +- auch dich.
Mal abgesehen vom RSC ist RSS dein zweites Problem.
Die Lastverteilungstechnologie ist erst ab 10G NIC's wichtig und dann muss diese
bei allen NIC auch noch richtig konfiguriert werden. Mit den Standardeinstellungen der Hersteller kannst du diese meistens mehr als nur knicken.
Für dich ist das ganze aber eh egal, weil du nur 1G NIC's hast und somit auf RSS vollkommen pfeifen kannst, da ein modernen Kern alleine schon locker 5-10G wuppen kann.
Sprich, als erstes solltest du RSS (Empfangsseitige Skalierung) auf den physikalischen NIC's und auch auf den vNIC's innerhalb der VM's deaktivieren.
Disable-NetAdapterRss -Name "NICNAME" Get-VMSwitch -Name "VSWITCHNAME" | FL Name : //"entfernt"//
Id : f74bf650-222e-4781-b906-8310539923b4
Notes :
Extensions : {Microsoft Windows Filtering Platform, Microsoft NDIS Capture}
BandwidthReservationMode : Absolute
PacketDirectEnabled : False
EmbeddedTeamingEnabled : True
IovEnabled : False
SwitchType : External
AllowManagementOS : True
NetAdapterInterfaceDescription : Teamed-Interface
NetAdapterInterfaceDescriptions : {Intel(R) Ethernet Server Adapter I350-T4 #3, Intel(R) Ethernet Server Adapter I350-T4}
NetAdapterInterfaceGuid : {7aa789dd-063a-4bf1-b7a3-34fe624eab5e, 0d4aaeb6-79b2-4c79-b215-dd62c9c361cf}
IovSupport : True
IovSupportReasons :
AvailableIPSecSA : 0
NumberIPSecSAAllocated : 0
AvailableVMQueues : 14
NumberVmqAllocated : 3
IovQueuePairCount : 0
IovQueuePairsInUse : 0
IovVirtualFunctionCount : 0
IovVirtualFunctionsInUse : 0
PacketDirectInUse : False
DefaultQueueVrssEnabledRequested : True
DefaultQueueVrssEnabled : True
DefaultQueueVmmqEnabledRequested : True
DefaultQueueVmmqEnabled : False
DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 8
DefaultQueueVrssMinQueuePairsRequested : 1
DefaultQueueVrssMinQueuePairs : 1
DefaultQueueVrssQueueSchedulingModeRequested : StaticVrss
DefaultQueueVrssQueueSchedulingMode : StaticVrss
DefaultQueueVrssExcludePrimaryProcessorRequested : False
DefaultQueueVrssExcludePrimaryProcessor : False
SoftwareRscEnabled : True
BandwidthPercentage : 10
DefaultFlowMinimumBandwidthAbsolute : 200000000
DefaultFlowMinimumBandwidthWeight : 0
CimSession : CimSession: .
ComputerName : //"entfernt"//
IsDeleted : False
DefaultQueueVmmqQueuePairs : 8
DefaultQueueVmmqQueuePairsRequested : 16danach sollten diese beiden Werte des vSwitches eigentlich auf 1 gehen.
DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 8
DefaultQueueVmmqQueuePairs : 8
DefaultQueueVmmqQueuePairsRequested : 16
Wenn nicht, dann musst du von Hand etwas nachhelfen.
Set-VMSwitch -Name "VSWITCHNAME" -DefaultQueueVrssEnabled $false -DefaultQueueVmmqEnabled $false -DefaultQueueVrssMaxQueuePairs 1 -EnableSoftwareRsc $false Und auch die Infos zu den betreffenden vNIC's.
Get-VM -Name "VMNAME"| Get-VMNetworkAdapter | FL Name : //"entfernt"//
Id : Microsoft:7E2103D7-8B13-47ED-983E-40906542EED3\AFD70BD6-5FE0-407F-8011-2523A7B7AF01
IsLegacy : False
IsManagementOs : False
ComputerName : //"entfernt"//
VMName : //"entfernt"// - Tracing
VMId : 7e2103d7-8b13-47ed-983e-40906542eed3
SwitchName : //"entfernt"//
SwitchId : f74bf650-222e-4781-b906-8310539923b4
Connected : True
PoolName :
MacAddress : 00155D01613D
DynamicMacAddressEnabled : True
AllowPacketDirect : False
NumaAwarePlacement : False
MacAddressSpoofing : Off
AllowTeaming : Off
RouterGuard : Off
DhcpGuard : Off
StormLimit : 0
PortMirroringMode : Destination
IeeePriorityTag : Off
VirtualSubnetId : 0
DynamicIPAddressLimit : 0
DeviceNaming : Off
VMQWeight : 0
VMQUsage : 0
IOVWeight : 0
IOVUsage : 0
IovQueuePairsRequested : 1
IovQueuePairsAssigned : 0
IOVInterruptModeration : Default
PacketDirectNumProcs : 0
PacketDirectModerationCount : 64
PacketDirectModerationInterval : 1000000
VrssEnabledRequested : True
VrssEnabled : False
VmmqEnabledRequested : True
VmmqEnabled : False
VrssMaxQueuePairsRequested : 16
VrssMaxQueuePairs : 1
VrssMinQueuePairsRequested : 1
VrssMinQueuePairs : 1
VrssQueueSchedulingModeRequested : Dynamic
VrssQueueSchedulingMode : Dynamic
VrssExcludePrimaryProcessorRequested : False
VrssExcludePrimaryProcessor : False
VrssIndependentHostSpreadingRequested : False
VrssIndependentHostSpreading : False
VrssVmbusChannelAffinityPolicyRequested : Strong
VrssVmbusChannelAffinityPolicy : Strong
IPsecOffloadMaxSA : 512
IPsecOffloadSAUsage : 0
VFDataPathActive : False
MaximumBandwidth :
MinimumBandwidthAbsolute :
MinimumBandwidthWeight :
BandwidthPercentage : 0%
MandatoryFeatureId : {}
MandatoryFeatureName : {}
Status : {Ok}
IPAddresses : {}Bei der vNIC sieht von aussen gar nicht so schlecht aus.
VrssMaxQueuePairs : 1
Das einzige was mir hier nicht gefällt ist der "VrssQueueSchedulingMode",
hier sollte eigentlich nicht "Dynamic" stehen, was die gleichzeitige Verwendung von RSS und VMQ ermöglicht sondern "StaticVrss".
Get-VM -Name "VMNAME"| Set-VMNetworkAdapter -VrssQueueSchedulingMode StaticVrss Danach sollten deine Datenpakete wieder ohne Verlust durchflutschen.
Beste Grüsse aus BaWü
Alex
1
Moin Alex,
jetzt hat es mich auch die letzten 10 Tage niedergerissen. Drecks Corona.
Ich teste das ganze mal in meinem Labor und melde mich nochmal
Gruß
Patrick
jetzt hat es mich auch die letzten 10 Tage niedergerissen. Drecks Corona.
Ich teste das ganze mal in meinem Labor und melde mich nochmal
Gruß
Patrick
Moin Alex,
Hast du Corona gut überstanden?
Gruß
Patrick
ich sehe dein Problem schon an dem vorherigen Post. 😀
Geb mir noch etwas Zeit um wieder fit zu werden (habe gerade Corona 🤮),
dann schreibe ich dir ausführlich woran das liegt und was zu machen ist.
Geb mir noch etwas Zeit um wieder fit zu werden (habe gerade Corona 🤮),
dann schreibe ich dir ausführlich woran das liegt und was zu machen ist.
Hast du Corona gut überstanden?
Gruß
Patrick
Moin Patrick,
leider nein, bin immer noch am zurück kämpfen.
Gruss Alex
Hast du Corona gut überstanden?
leider nein, bin immer noch am zurück kämpfen.
Gruss Alex
