Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

gelöst Hyper V Server 2019, Gast Server 2016, Intel X722, langsame ext. Netzwerkanbindung

Mitglied: bonbastler

bonbastler (Level 1) - Jetzt verbinden

26.12.2018 um 13:02 Uhr, 9142 Aufrufe, 110 Kommentare, 4 Danke

Hallo Community,
ich habe hier ein Problem mit extrem langsamen Netzwerkanbindungen von mehreren VM. Hardware sind zwei fast identische neue Maschinen (MB Supermicro X11SPM-F mit 2x 1 GB Intel X722 onBoard NIC und sep. IPMI, Intel Xeon Silver 4110, 96 GB RAM, lokales SSD Storage, soweit schön) auf denen je Windows Server 2019 Std. mit aktivierter Hyper V Rolle als Host installiert ist. Treiber sind erstmal alle original vom Hersteller was Supermicro halt so bereit stellt (Intel MB Chipsatz, Intel Pro 23.2 u.a.). Die Maschinen haben eine sep. IPMI NIC, die erste X722 NIC von dem Server verwende ich für das Hyper V Verwaltungsinterface, die zweite als HV Switch für die ext. Anbindung aller VM. Wenn ich Windows Server 2019 Std. in einer VM installiere ist alles gut, alles läuft wie es laufen soll. Wenn ich Windows Server 2016 Std. oder Server 2008R2 Std. in einer VM auf dem Host installiere haben diese VM nur je eine sehr sehr langsame Anbindung an die Aussenwelt. Ich hab das alles mal mit iperf getestet. Zwischen den VM ist die Transferrate wie gewünscht (iperf. knapp 10 GBit/s), von den VM zum Host auch (da das extern über einen Switch geht nur rd. 1 GBit/s, wenn ich einen HV Switch an das Verwaltungsinterface binde dann auch schneller), zu physischen Computern nach aussen hin im realen Netzwerk komme ich bei der einen Maschine aber nur auf 5-10 MBit/s und bei der anderen auf 20-120 MBit/s mit stark schwankender Tendenz - je nachdem. Der verwendete HW Switch ist entweder mal ein D-Link DGS 1210-28 oder ein HP 2510G-24, blank und nahezu unkonfiguriert, was halt grad so rumliegt. Mir geht ein klein wenig die Zeit aus weil beide Maschinen produktiv gehen sollen. Die erste steht schon vor Ort und dort ist mir das erst aufgefallen als ich von einem vorh. Server Daten migrieren wollte, das dauert ewig. Die andere noch bei mir im Labor und mit der habe ich nun schon einiges probiert: mehrfach Windows Server 2019 und 2016 auf dem Host installiert (meist wirklich neu von null an), div. VM installiert (Gen 1 und Gen 2), div. Intel Netzwerkkartentreiberversionen für die X722 installiert (23.0, 23.2, 23.4, aktuell 23.5), deren physische Zuordnungen hin und her geändert und auch an deren Parametern rumgespielt (Stichworte Flusssteuerung, VMQ, Lange send Offload v2 u.a. auf dem Host und in den VM), Hyper V Rolle deaktiviert und aktiviert. Ich habe die letzten Tage schon einige umfangreiche Installationsorgien hinter mir um das Problem einzukreisen - insbes. da das ändern der Intel NIC Treiber immer mit dem Löschen des HV Switches und Neustart des Hosts verbunden ist. Nur das BIOS des MB habe ich derzeit noch in Ruhe gelassen da dort meiner Meinung nach nichts für dieses Problem relevante einzustellen ist. Dabei kommt u.a. auf dem 2019 Host immer mal wieder das Problem auf dass ich keinen virt. Switch mit ext. Anbindung erstellen kann (Stichwort Hyper V Rolle deinstallieren, netcfg -d, Neustart, Hyper V Rolle aktivieren, alles neu einrichten ...) - aber das nur am Rande.

Letztendlich hat das alles mehr oder weniger nichts gebracht. Derzeitiges Fazit: sobald auf dem Host ein Server 2019 als Hyper V läuft auf dem in einer VM kein Server 2019 läuft (habe es mit Server 2016 und 2008R2 probiert) dann ist die Netzwerkanbindung dieser VM nach aussen über die Intel X722 extrem langsam. CPU Leistung steigt nicht, keine Fehlerpakete am Hardware Switch, es kommt halt einfach zu wenig an. Ich weiss auch spontan nicht wonach ich weiter suchen sollte und wo da der Flaschenhals ist (Paketgrößen?, Jumbo Pakete sind aber überall deaktiviert). Läuft auf dem Host Server 2016 als Hyper V funktioniert alles wie gewünscht. Das Problem habe ich z.Z. temporär gelöst indem ich eine weitere separate physische PCIe NIC (eine einfache Intel i210) eingebaut habe, an diese einen eigenen HV Switch gebunden und alle VM über diesen laufen lasse. Sobald ich die 2016er VM über einen HV Switch wieder über die onBoard NIC Intel X722 nach aussen anbinde haben externe PC die o.g. schlechte Netzwerkanbindung. Mit dem HV Switch der i210 geht das schnell wie gewünscht.

Meine Fragen: kennt jemand dieses Problem in dieser Konstellation (HV 2019, Intel NIC X722, HV Gast 2016)? Gibt es eine Lösung oder hat jemand weitere Ansätze zur Suche?
110 Antworten
Mitglied: certifiedit.net
26.12.2018, aktualisiert um 15:54 Uhr
Hallo,

Firmware aktuell?
Systeme auf aktuellem systemstand?

Was sagt der Hersteller? (Gut über Weihnachten ist das natürlich problematisch)

Was ergibt eine Googlesuche?
Ereignisanzeige?

VG
Bitte warten ..
Mitglied: maxblank
26.12.2018, aktualisiert um 15:14 Uhr
Moin,

da du schon vieles versucht hast, würde ich mich hier direkt an den Hersteller oder den Lieferanten wenden.
Da diese Server anscheinend neu und für den produktiven Einsatz vorgesehen sind, gehe ich davon aus, dass du diese unter einem Wartungsvertrag hast. Wie lange ist dort die Reaktionszeit?

Gruß
maxblank
Bitte warten ..
Mitglied: bonbastler
26.12.2018 um 16:12 Uhr
Firmware ist an allen Teilen aktuell. Systeme auch. Ich vermute es ist ein Treiber- oder Einstellungsproblem irgendwo. Wir assemblieren selber, d.h. sind selber der Hersteller - sind eh nur kleine Systeme aus Standardkomponenten welche lt. Herstellerangaben dafür und in dieser Konstellation vorgesehen sind.

Google 2 Tage gesucht: bis auf VMQ nichts gefunden was annähernd dem Problem entspricht. Auf jeden Fall nichst spezifisches zum Problem HV 2019 Gast 2016 oder 2008R2 (2012R2 wäre sicher ebenso betroffen, könnte ich testen, fehlt mir grad die Zeit).
Ereignisanzeige sieht total schick aus - nix.

Problem ist derzeit exakt diese Kombination: X722 + HV 2019 + Gast 2016. Andere NIC, anderer Host, 2019 als Gast dann geht es.
Bitte warten ..
Mitglied: certifiedit.net
26.12.2018 um 16:18 Uhr
Dann solltest du dich an den mobo Hersteller wenden. Sehe soweit kein Problem auf den Konstellationen (dell basiert)
Bitte warten ..
Mitglied: bonbastler
26.12.2018 um 16:28 Uhr
Hat dein Dell Server die gleiche NIC? Woanders (andere onBoard NIC) habe ich das Problem ja auch nicht.
Bitte warten ..
Mitglied: 137846
26.12.2018, aktualisiert um 17:20 Uhr
Hmm.
Hier steht das Teil [X11SPM-F] hätte zwei 1GbE Marvel Controller, keine Intel.
https://www.supermicro.com/products/motherboard/Xeon/C620/X11SPM-F.cfm
Dual LAN with 1GbE with Marvell® 88E1512

Gruß A.

Btw. Server 2019 produktiv nutzen? Da würde ich das Ding erst mal noch mind. ein Jahr reifen lassen bis zumindest die gröbsten Schnitzer behoben sind, denn davon gibt es nach meiner Evaluation der letzten Build noch einige.
Bitte warten ..
Mitglied: Vision2015
26.12.2018 um 18:47 Uhr
Moin...

jo, der 2019er ist sehr buggy... lass das beser mal.

nutze deinen server richtig, mache es mit ESXI 6.5... die 6.7er würde ich noch nicht nehmen wollen!

Frank
Bitte warten ..
Mitglied: bonbastler
26.12.2018 um 19:52 Uhr
Sind Intel NIC:
x11spm-f1-nic - Klicke auf das Bild, um es zu vergrößern

Ich weiss nicht wieso das auf der Supermicro Site und auch im Handbuch so steht (vielleicht ist nur der physische Endteil Marvell? kann grad kein Bild machen weil ncht mehr vor Ort), aber die Treiber Downloads und auch die OUI Herstellerkennung sind da recht eindeutig ;)

Hyper V ist schon nicht schlecht, ist glaub mein vierter produktiver Einsatz seit div. Tests und der MS Freigabe (nicht nur als Hyper V). Aber so ein Problem allein schon beim Hyper V finde ich nicht lustig.
Bitte warten ..
Mitglied: 137846
26.12.2018, aktualisiert um 20:35 Uhr
OK, da hat Supermicro tatsächlich etwas in der Doku geschlampt, siehe
https://vmware-forum.de/viewtopic.php?t=32808
Aber so ein Problem allein schon beim Hyper V finde ich nicht lustig.
Gerade bei der Hyper-V Rolle machen sich die meisten Unzulänglichkeiten beim 2019er bemerkbar.
Das OS reift beim Kunden, nicht anders wie bei den Client OS.. Deswegen bei Virtualisierung besser gleich zur Bewährtem greifen.
Bitte warten ..
Mitglied: certifiedit.net
26.12.2018 um 20:36 Uhr
Zitat von 137846:

OK, da hat Supermicro tatsächlich etwas in der Doku geschlampt, siehe
https://vmware-forum.de/viewtopic.php?t=32808
Aber so ein Problem allein schon beim Hyper V finde ich nicht lustig.
Gerade bei der Hyper-V Rolle machen sich die meisten Unzulänglichkeiten beim 2019er bemerkbar.
Das OS reift beim Kunden, nicht anders wie bei den Client OS..

Findest du? Seit dem letzten Update läuft das auf meinen Testsystemen sehr gut. Mittlerweile 5 Systeme 24/7 aktiv.

Welche Probleme siehst du da?

Aber: Anscheinend wird von VMware 6.7 auch (noch) abgeraten ;) also nicht besser.
Bitte warten ..
Mitglied: Xaero1982
26.12.2018 um 21:40 Uhr
Ähnliche Probleme schien es schon mit den alten Treiberversionen gegeben haben in Verbindung mit dem 2019er. Scheinbar funktioniert dann der 23.5er auch nicht richtig mit 2019 trotz Freigabe für die 1809 von Intel.

Hier hilft nur Kontakt mit Intel aufnehmen und ggf. Microsoft.
Bitte warten ..
Mitglied: bonbastler
27.12.2018 um 11:58 Uhr
So ähnlich habe ich das inzwischen auch aus den Errata bei Intel rausgelesen. Es waren Probleme in dieser Richtung bekannt, die 23.5 sollte diese beheben, tut sie aber nicht.

Der Vollständigkeit halber:
x11spm-f1-nic2 - Klicke auf das Bild, um es zu vergrößern

Es sind Marvell Phy Transceiver für die Konnektoren. Die NIC sind intern und Intel.
Bitte warten ..
Mitglied: GrueneSosseMitSpeck
27.12.2018, aktualisiert um 17:23 Uhr
kurz zusammengefaßt einer der 30 Parameter der Netzwerkkarte (die Detaileinstellungen im Gerätemanager) im Gast paßt wohl nicht zu den physischen Fähigkeiten des Intel NIC X722

2016 hat nen Bug der in 2019 vielleicht auch drin ist - es aktiviert einige Features an der Netzwerkkarte wie z.B. das RSS oder noch ein paar weitere "Offloading" Optionen, die auf physischen Karten dann Teile des TCP-IP Protokolls in Hardware umsetzen wie z.B. Checksum Prüfungen oder Hashberechnungen. Ich hatte gerad nen Kunden am Rohr, der auf 2016 Terminalserver eine Roundtrip Latency von sage und schreibe 2000 ms hatte, dabei waren Client und Server keine 2 km voneinander entfernt. Bei 2008R2 lag er bei 17 ms.

ICh hatte neulich auch mal ein 2016 auf ESX installiert, und mit Defaulteinstellungen war das Netz langsam bis unbenutzbar, dann VMware Tools installiert aber nicht viel besser geworden... Unter 2012 R2 auf demselben Host gingen dann Downloads bei MS so wusch mit Maximalbandbreite des CDN von Microsoft (ca. 120 Mbit) ... ich hab sogar die Ports getauscht konnte aber keinen finden der daran schuld war. Und stellt man aber auf 2012 R2 und dem E1000E Treiber das RSS ein, dann bricht der Download dramatisch ein und acuh die VMware Tools halfen zunächst nicht.... das ist aber in aktuellen VMware Tools dann gefixt.
Bitte warten ..
Mitglied: bonbastler
27.12.2018 um 21:40 Uhr
Meine stille Hoffnung ist immer noch dass es ein solcher Fehler ist der sich durch entspr. Einstellungen beheben lässt, so auch meine ursprüngliche Frage: kennt das jemand.

Auf dem (neu installierten) Host habe ich nur noch die 23.5 Intel Treiber und kein Pro Set mehr installiert. Im Gerätemanager habe ich bei den Karten die Flusssteuerung, IPv4 Prüfsummen Abladung, Large-Send-Offload v2 (IPv4 und v6), NS-Abladung, TCP-Prüfsummen abladen (IPv4 und v6) und UDP-Prüfsummen abladen (IPv4 und v6) deaktiviert. Per Registry auch mal VMQ explizit deaktiviert. Soweit möglich das auch in den VM NIC Einstellungen eingestellt. Das alles immer Stückweise mit zwischenzeitlichem testen und tlw. Neustarts. RSS Einstellungen habe ich belassen, wenn überhaupt dann könnte man die vergrößern für mehr Last. An weiteren Parametern habe ich hier und da probiert (u.a. Recv.-Segment-Coalescing IPv4 und v6). Fazit - hat alles nichts gebracht. Ich habe keinen kleinsten gemeinsamen Nenner gefunden bei dem ich auf mehr Geschwindigkeit komme. Da gibt es aber eben immer noch einige Einstellungen und Kombinationen die ich sicher nicht getestet habe und ein Teil der Einstellungen lässt sich nur per Registry anpassen. Das wurde mir dann zu viel und der Hickhack zu groß. Eine beliebte Einstellung früher war halt Flusssteuerung, Prüfsummenabladung und Large-Send-Offload v2 - aber das hat's hier auch nicht gebracht. Ebenso Interrupt Drosselung usw. . Die CPU und IRQ dümpeln dennoch rum und das Netz ist nach extern langsam. Das alles war bisher keine Lösung bei mir.
Bitte warten ..
Mitglied: 137846
27.12.2018, aktualisiert um 22:03 Uhr
Ich bekomme morgen eine X722 in die Finger, dann mach ich hier auch mal ein paar Tests um das nachzustellen.

Gruß A.
Bitte warten ..
Mitglied: 137846
29.12.2018, aktualisiert um 10:52 Uhr
Also, ich habe das ganze hier mal mit einem SM Board mit X722 NIC nachgestellt (hatten wir hier noch auf Ersatz-Lager liegen):
  • Server 2019 Datacenter mit allen verfügbaren Updates (nur Hyper-V als Rolle)
  • Gast jeweils mit fest zugewiesenen 4GB RAM und 2 vCPUs
  • Sowohl beim Gast mit Server 2016 Datacenter (alle Updates), als auch Server 2008R2 (mit allen Updates) laufen die NICs sehr nah am theroetischen Max. durchschn. 950MBit/s (netio) über einen CISCO SG350-52 Switch auf einen Windows 10 1809 Client mit 1GB Intel-NIC. VM Gen 1. oder 2. machten dabei keinen Unterschied.
  • Treiber von Intel ist der letzte verfügbare 23.5, Anpassungen an den NICs sowohl am Hosts als auch am Gast waren nicht nötig.

Also k.A. was da bei dir dazwischen funkt und du beim Aufsetzen anders machst.

Gruß A.
Bitte warten ..
Mitglied: bonbastler
02.01.2019 um 16:33 Uhr
Danke, schön zu wissen dass es auch anders geht. Hilft mir halt nicht weiter. Ich hab das von MS freigegebene 2019er ISO SW_DVD9_Win_Server_STD_CORE_2019_64Bit_German_DC_STD_MLF_X21-96583.ISO aus dem MS Partner Portal genommen. Mehrfach von Null an neu installiert, zuletzt nahezu nichts mehr auf dem Host und in den VM eingerichtet. Problem war reproduzierbar immer wieder da.
Bitte warten ..
Mitglied: certifiedit.net
02.01.2019 um 16:39 Uhr
Und genau an dem Punkt (oder ggf davor) hilft ein Forum wohl nicht mehr weiter.
Bitte warten ..
Mitglied: bonbastler
02.01.2019 um 16:56 Uhr
Es hat mir geholfen - zumindest in der Beziehung dass andere das Problem so nicht haben. Es ist wie immer: suche den Fehler bei dir selbst, hilf dir selbst.
Bitte warten ..
Mitglied: 137846
02.01.2019, aktualisiert um 16:58 Uhr
hilf dir selbst.
Und ab und zu auch anderen .
Bitte warten ..
Mitglied: certifiedit.net
02.01.2019 um 17:29 Uhr
Zitat von bonbastler:

hilf dir selbst.

Darf man das zurück geben, wie gesagt, genau an dem Punkt - hilf dir selbst.
Bitte warten ..
Mitglied: Vision2015
02.01.2019 um 18:05 Uhr
Moin...
Zitat von bonbastler:

Danke, schön zu wissen dass es auch anders geht. Hilft mir halt nicht weiter. Ich hab das von MS freigegebene 2019er ISO SW_DVD9_Win_Server_STD_CORE_2019_64Bit_German_DC_STD_MLF_X21-96583.ISO aus dem MS Partner Portal genommen.
und welche Build version hast du nach der Installation genau....
Updates ?
allerdings finde ich dein Unterfangen, einen Hyper-V auf basis des 2019er nutzen zu wollen, doch sehr gewagt... ich traue dem braten nicht....

Mehrfach von Null an neu installiert, zuletzt nahezu nichts mehr auf dem Host und in den VM eingerichtet. Problem war reproduzierbar immer wieder da.

hast du auch die VM´s neu installiert?

Frank
Bitte warten ..
Mitglied: bonbastler
02.01.2019 um 18:35 Uhr
Die 2019 waren und sind immer die 1809 Build 17763.195.

Ja, auch die VM wurden oft neu installiert, aber ich gebe zu: nur bei jeder 2. Neuinstallation des Host, abhängig von den Spielereien die ich an den NIC in den VM durchgeführt habe.

Das ist selbstverständlich. Ich gebe wenn ich kann immer zurück. Vor allem dann wenn ich wirklich mal irgendwo frage und - wie so oft - keine Lösung kurzfristig gefunden wird dann schreibe ich zumindest wenn ich eine finde diese nachträglich noch dazu. Falls andere vor dem Problem stehen hilft das denen - ist die Hoffnung.
Bitte warten ..
Mitglied: Vision2015
02.01.2019 um 18:48 Uhr
Moin...
Zitat von bonbastler:

Die 2019 waren und sind immer die 1809 Build 17763.195.
hm...
warum solle es ein 2019er Hyper-V Host werden?
nutze doch den ESXI 6.5.... mach es besser gleich richtig!

Ja, auch die VM wurden oft neu installiert, aber ich gebe zu: nur bei jeder 2. Neuinstallation des Host, abhängig von den Spielereien die ich an den NIC in den VM durchgeführt habe.
na ja... das sollte schon mit den grundeinstellungen klappen....
hast du mal eine ander NIC in dein Blech geklemmt?
hast du den Server bestellt für 2019.. was sagt der Hersteller dazu? support?

Das ist selbstverständlich. Ich gebe wenn ich kann immer zurück. Vor allem dann wenn ich wirklich mal irgendwo frage und - wie so oft - keine Lösung kurzfristig gefunden wird dann schreibe ich zumindest wenn ich eine finde diese nachträglich noch dazu. Falls andere vor dem Problem stehen hilft das denen - ist die Hoffnung.
....

Frank
Bitte warten ..
Mitglied: certifiedit.net
02.01.2019 um 19:00 Uhr
Frank, an Server 2019 per SE liegt es nicht. S.o das Problem könnte auch an der Konfektion liegen. Der wird selbst durch den to zusammen geschraubt.

VG
Bitte warten ..
Mitglied: bonbastler
02.01.2019 um 19:07 Uhr
So klein sind wir nun nicht. Assemblieren ist kein Hexenwerk. Wir können dieses Blech exakt so auch von einem der Großen bauen lassen, das sind Standardkomponenten, die sind auch bei denen in dieser Kombination zertifiziert (weiss ich), das wird dann halt ein BTO System - kein Problem. Dann bieten dieser Hersteller des BTO Systems den Support und ich würde tagelang und irgendwann auch kostenpflichtig mit denen telefonieren. Könnten wir machen. Ist grad nicht. Die beiden Systeme sind schon da.
Bitte warten ..
Mitglied: certifiedit.net
02.01.2019 um 19:21 Uhr
Naja dann wurde ich mal sagen, entweder ihr schaut was ihr mit den Systemen macht oder ihr ordert bei den grossen ein entsprechendes system. Da du hier nun schon tagelang und zog Installationen durch hast dürfte es so langsam billiger sein sich nach einer alternative um zuschauen.

Vielleicht geht es momentan einfach nicht aufgrund eines anderen problems, dass gerade gar nicht mit der nicht zusammenhängt, aber die Leistung frisst.
Bitte warten ..
Mitglied: bonbastler
02.01.2019, aktualisiert um 19:43 Uhr
Spätestens für das zweite System was ich zu dem Zeitpunkt noch nicht ausgeliefert hatte kann ich das zum Großteil ausschließen.

Die pragmatische Lösung sieht aktuell so aus dass die Systeme je eine weitere NIC drin haben über welche die VM nach aussen kommunizieren.

Zusätzlich habe ich noch die problematisch funktionierenden onBoard NICs extern angebunden und kann so remote in Ruhe weiter nach Ursachen forschen wenn es die Zeit mal wieder hergibt - dank IPMI, ext. gelagerten Backups und Installationsmedien ist das möglich. Demnächst kommt noch so ein drittes System an und vielleicht lasse ich mir gar mal das Gleiche von anderen bauen um die dann mit dem evtl. noch auftretenden Problem zu nerven. Mal schauen was die Zeit so mit sich bringt. Wenn ich eine Ursache und praktikable Lösung finde kommt das hier rein.
Bitte warten ..
Mitglied: Vision2015
02.01.2019, aktualisiert um 20:05 Uhr
Moin...

Zitat von bonbastler:

So klein sind wir nun nicht. Assemblieren ist kein Hexenwerk.
nun sag das mal nicht... wir machen das schon über 25 Jahre....
Wir können dieses Blech exakt so auch von einem der Großen bauen lassen, das sind Standardkomponenten, die sind auch bei denen in dieser Kombination zertifiziert (weiss ich), das wird dann halt ein BTO System - kein Problem.
und für was zertifiziert? Server 2019.. ESXI? mit welcher Firmware / Bios Version... mit welchen einstellungen?
also doch ein problem....
natürlich kann jerder Hans und Franz einen Server zusammenschustern, darum geht es nicht- es geht darum zu wissen wie, mit was der Server rennt... und vor allem warum!
das wissen fehlt leider bei den meisten....
Dann bieten dieser Hersteller des BTO Systems den Support und ich würde tagelang und irgendwann auch kostenpflichtig mit denen telefonieren. Könnten wir machen. Ist grad nicht. Die beiden Systeme sind schon da.
tja.. etwas support wäre nicht schlecht...
nutze in zukunft lieber das Server Board Intel S2600BPS...
witzig finde ich auch, das du bei der 2019er Hyper-V kiste bleiben willst, obwohl dir fast jeder davon abraten würde...


Frank
Bitte warten ..
Mitglied: bonbastler
02.01.2019, aktualisiert um 22:06 Uhr
Zitat von Vision2015:

Moin...
Nabend...

Zitat von bonbastler:

So klein sind wir nun nicht. Assemblieren ist kein Hexenwerk.
nun sag das mal nicht... wir machen das schon über 25 Jahre....
Wir auch.

Wir können dieses Blech exakt so auch von einem der Großen bauen lassen, das sind Standardkomponenten, die sind auch bei denen in dieser Kombination zertifiziert (weiss ich), das wird dann halt ein BTO System - kein Problem.
und für was zertifiziert? Server 2019.. ESXI? mit welcher Firmware / Bios Version... mit welchen einstellungen?
also doch ein problem....
natürlich kann jerder Hans und Franz einen Server zusammenschustern, darum geht es nicht- es geht darum zu wissen wie, mit was der Server rennt... und vor allem warum!
das wissen fehlt leider bei den meisten....
Generell 2019 zertifiziert, die sind noch dabei. Firmware soweit ich seit heute weiss auch gleich. Das mit den Einstellungen wäre interessant. Der Abteilung welche die Hardware beim Hersteller zertifiziert war recht überrascht von dem Problem und stellen das gerade (tlw. erfolgreich) nach. Demnächst weiss ich da mehr. Soviel auch zum Thema Support. Wir reden noch mit anderen und können das auch.
Dann bieten dieser Hersteller des BTO Systems den Support und ich würde tagelang und irgendwann auch kostenpflichtig mit denen telefonieren. Könnten wir machen. Ist grad nicht. Die beiden Systeme sind schon da.
tja.. etwas support wäre nicht schlecht...
nutze in zukunft lieber das Server Board Intel S2600BPS...
witzig finde ich auch, das du bei der 2019er Hyper-V kiste bleiben willst, obwohl dir fast jeder davon abraten würde...


Frank
Tja Frank, ich finde das nicht witzig, das gleitet ab. Das Fazit für mich: dein Beitrag war in keiner Weise hilfreich oder konstruktiv. Ich finde auch du ziehst das Niveau des Beitrages und mich hier runter. Mag sein dass du das öfters machst, ich brauche das nicht. Es geht um das Thema, nicht um die Personen. Deine Mainboard Empfehlung ist am Thema vorbei, Thema Formfaktor, das ist dir vielleicht entgangen. Solche Kommentare brauche ich und vmtl. auch andere in diesem Thread nicht. Weiter gehe ich nicht darauf ein. Du musst das auch nicht kommentieren.

Bei Answer möchte ich mich nochmal bedanken sich den Aufwand gegeben und kurzfristig negativ nachgestellt zu haben.
Bitte warten ..
Mitglied: Vision2015
02.01.2019 um 22:42 Uhr
moin..
Generell 2019 zertifiziert, die sind noch dabei.
sagt ja schon alles....es könnte sein, oder vieleicht!
du solltest aber schon wissen, das die Intel S2600 Serie euch für dein Formfaktor zu erwerben ist!
Tja Frank, ich finde das nicht witzig, das gleitet ab
das glaube ich dir gerne, den du verkaufst nicht supportete systeme, selbst für dein MB gibbet keine Server 2019 Treiber... aber gut, windows 10 ist ja schon mal ein anfang.

ich verstehe nicht, warum sich die "assemblierer" aufregen, wenn ihnen gesagt wird, das ist Bockmist, was du da machst...
was ist für dich am Intel S2600
MB so schlecht als Empfehlung? weil du dann den Supermicro Schrott auf halde liegen hast?
Der Abteilung welche die Hardware beim Hersteller zertifiziert war recht überrascht von dem Problem und stellen....(tlw. erfolgreich) nach.
aha... dann sollte "Der Abteilung" dir besser mal vorschlagen, ein MB zu verbauen, was für deine zwecke auch 100% geeignet ist...
Wir reden noch mit anderen und können das auch.
anscheinend nicht beim Bestellen....

Frank
Bitte warten ..
Mitglied: bonbastler
03.01.2019, aktualisiert um 08:24 Uhr
Frank, du kannst es nicht sein lassen, was? Ich hatte darum gebeten aber du musst unbedingt noch eins drauf setzen. Wie ich schon mal schrieb: das was du schreibst ist nicht mehr konstruktiv, das ist nicht hilfreif, trägt nicht zum Thema bei und wenn ich mir die ersten Posts anschaue und dann das was du schreibst und in welche Richtung du diesen Thread bewegst dann heisst das für mich du trollst hier rum. Hör doch bitte einfach auf. Das liest keiner mehr. Du lenkst vom Thema ab. Ich würde das so stehenlassen bis ich mehr über das Thema weiss.
Bitte warten ..
Mitglied: certifiedit.net
03.01.2019 um 09:46 Uhr
LIeber bonbastler,

wenn du von uns nichts hören willst, dann musst du hier nicht verweilen und auch keine Kommentare oder Fragen abgeben. So Unrecht hat Frank mit seinen Statements nicht. Gut, bzgl. Vmware und Hyper-V da is' er halt einfach ein Kind von VMware, soll er sein, ist OK. Aber grundsätzlich hockst du(!) auf dem Problem, nicht wir. Wie immer gilt: Bist du mit dem Service im Forum nicht zufrieden, kaufe dir direkten Service (per Geldbetrag X) ein. Dem kannst du dann auch (bedingt) Vorschreiben, wie und was er zu melden hat.

Viele Grüße,

Christian
Bitte warten ..
Mitglied: mbplg19
02.03.2019 um 00:14 Uhr
Hallo zusammen,

gibt es hier mittlerweile eine Lösung?

Wir stehen aktuell vor exakt dem gleichen Problem, jedoch in einer Server 2016-Umgebung (Supermicro X11-Board mit 2x Intel X722 10G SFP+).

Ich freue mich auf eine (kostruktive!) Rückmeldung.

Grüße, Stephan
Bitte warten ..
Mitglied: certifiedit.net
02.03.2019 um 21:19 Uhr
Hallo Stephan,

nein, offensichtlich nicht, oder der TO hat sich ohne Lösungsmitteilung verabschiedet - dann kommt diese i.d.R auch nicht mehr. Ist leider das um sich greifende"Hilfe abgreifen, aber nichts zum Forum beitragen".

VG
Bitte warten ..
Mitglied: bonbastler
04.03.2019 um 14:02 Uhr
Certified: dem ist nicht so, zumindest nicht bei mir und nicht hier. Ich kann deine negative Einstellung diesbzgl. verstehen aber indem du einer möglichen Antwort vorgreifst wird hier wohl keine mehr kommen, nicht von mir, nicht hier, nicht nach so einer fruchtlosen Diskussion - s.o., du weisst - am Thema vorbei.

Ich hatte den Thread als gelöst markiert weil ich mir mit gewissem Aufwand mehrere Lösungen für das Problem erarbeitet habe. Ich werde die dem Frager direkt mitteilen dann wird das hier nicht wieder breitgetreten und zerredet. Ich finde das ist in zielführender.

mbplg19: du bekommst heute noch Post, ich brauche ein klein wenig Zeit zum Antworten.
Bitte warten ..
Mitglied: certifiedit.net
04.03.2019, aktualisiert um 14:05 Uhr
Hallo Bonbastler,

wenn du wirklich eine Lösung (oder gar mehrere) hast, dann pack diese hier ins Forum, denn auch wenn man die Lösung nun selbst erarbeitet hat, gehört das zum guten Ton, diese zu publizieren. Anders sieht es ggf. nur aus, wenn man dritte dafür bezahlt hat eine Lösung zu erarbeiten, das negierst du aber indirekt.

Viele Grüße.

PS: Bitte certifiedit.net
Bitte warten ..
Mitglied: bonbastler
04.03.2019 um 14:11 Uhr
Ich werde das mit dem Frager zusammen abarbeiten und wenn sich eine repoduzierbare Lösung für andere ergibt werden wir die ggf. hier publizieren.
Bitte warten ..
Mitglied: manuelm2
18.03.2019 um 20:05 Uhr
Hallo bonbastler

Habe ähnliche Probleme, biiiitte um eine Lösung.
Produktivserver beim Kunden sehr langsam.

Vielen Dank
Bitte warten ..
Mitglied: bonbastler
18.03.2019, aktualisiert um 23:16 Uhr
Hallo manuelm2,

was für ein Mainboard und was für Betriebssysteme (Hyper V Host und Gast)? Ausserdem: was genau meinst du mit 'sehr langsam'?
Bitte warten ..
Mitglied: manuelm2
19.03.2019 um 09:24 Uhr
Hallo bonbastler

Besten Dank für deine Antwort.

Mainboard ist X10SRH-CF mit Intel i350 Dual NIC, Host und VM sind mit Windows Server 2019 installiert.
Netzwerk von VM aus max. 34MBit!

Bereits gemacht, Switch, Kabel, Treiber, MS Updates, neue VM zum testen inst., etc.
Bitte warten ..
Mitglied: bonbastler
19.03.2019 um 09:49 Uhr
Das ist gänzlich andere Hardware, die Vorgängerversion sozusagen. Mit diesen NIC habe ich noch nirgends Probleme.

Dann die Frage: hast du dir den gesamten Thread - insbes. die von mir durchgeführten Dinge der Eigenschaften der Netzwerkkarten - durchgelesen, hoffentlich verstanden (ist tlw. etwas spärlich geschildert) und auch bei dir angewandt? Inzwischen gibt es neuere Treiber von Intel auch für diese Karten die im Prinzip so ein Problem tangieren, ist die 23.5.2 (Treiber Intel), dort insbes. auch mal die readme durcharbeiten.
Bitte warten ..
Mitglied: manuelm2
20.03.2019 um 12:12 Uhr
Neuste Treiber habe ich installiert (23.5.2) keine Änderung.
Habe Testhalber SMB2/3 deaktiviert und via SMB1 laufen lassen, viel besser, zwischen 200MBit und 500MBit, schwankt sehr.
Ist aber keine Lösung, ich vermute es liegt an Windows Server 2019.
Bitte warten ..
Mitglied: bonbastler
20.03.2019 um 14:34 Uhr
Ich hatte das immer mit iperf getestet weil das Problem schon tiefer lag wie SMB. Würde ich dir auch empfehlen weiter unten anzusetzen und zu klären ob die Probleme auch dort auftreten. SMB ist dann schon wieder eine andere Geschichte.

Ich nehme an du hast bei dem Hyper V Server eine separate NIC ausschließlich für den Hyper V zur Verwaltung und das ist auch eine der 350er Intel NIC. Wie verhält es sich mit der, auch diese Probleme? Der erste Punkt ist doch: gibt es wesentliche Unterschiede in den Übertragungsraten zwischen ext. Maschinen und dem Hyper V (über einen ext. Switch), ext. Maschinen und den HV Gästen (über einen ext. Switch) und zwischen dem Hyper V und seinen Gästen (einmal über ext. Switch und einmal intern wenn die HV Verwaltung auf der NIC eines HV Switches aktiviert wurde) und das halt alles mal auf einer niedrigeren Ebene gemessen, iperf bietet sich da an.

Abschließende Frage: ist irgendwo Teaming oder ein sonstige NIC Gruppierung aktiv oder war es mal?

Wie ich dir schon schrieb: einfach nur die Treiber zu installieren nutzt u.U. nicht. In der readme zu den Treibern stehen einige wesentliche zu beachtende Punkte drin. Bei Änderungen an der NIC (in den erweiterten Einstellungen im Gerätemanager oder in der Registry) oder dem HV Switch auch mal den HV neu starten. Steht explizit da drin, Thema VMQ z.B.. Ich hab auch extra - leider mehrfach - ab und an netcfg -d gebrauchen müssen inkl. anschl. Neustart und kompletter Neukonfiguration der NICs und der HV Switche am HV.

Generell sieht es erst einmal nicht so aus als wären deine Probleme mit meinen ehem. Problemen vergleichbar.
Bitte warten ..
Mitglied: manuelm2
20.03.2019, aktualisiert um 18:35 Uhr
Hab einen virtuellen 2016 installiert, läuft einwandfrei!
Wieso habe ich nur 2019 installiert?!!!
Bitte warten ..
Mitglied: bonbastler
20.03.2019 um 18:48 Uhr
Ich habe alle 16 sinnvollen Kombinationen an Betriebssystemen mit einer gewissen Geduld ausprobiert (Host + Gast je 2008R2, 2016 und 2019, nachträglich auch noch 2012R2) und meist auch alles von null an installiert: das Problem trat ausschließlich auf wenn der Host ein 2019 war und der Gast nicht.
Bitte warten ..
Mitglied: MysticFoxDE
03.04.2019 um 20:01 Uhr
Moin @ alle Mitleidenden,

habe die letzte und diese Woche einige Tage in das selbe Problem ungeplant investieren müssen. 😰
Kurz vor der Verzweiflung habe ich vor einigen Stunden dann aber einen Durchbruch gehabt. 😌

Zusammenfassung:
Das Problem tritt nur in Verbindung mit X722 & 1G UPLINK & HV2019 & VM < WIN 2019 auf.

Nun zur Lösung / Workaround:
Ich habe nun in jeden Server für 1G Uplinks eine zusätzliche, dualport I350 basierte Netzwerkkarte für je ~ 150,- verbaut
und siehe da die VMs bringen per SMB wieder 112 - 113 MBs. 🙏😃🤪
Mit aktiviertem SR-IOV & VMQ.

https://www.intel.de/content/www/de/de/ethernet-products/gigabit-server- ...

Es liegt somit definitiv am X722, der im Kern ein 10-40G Chipsatz ist, 1G kann dieser nur aus Kompatibilitätsgründen.

Ob das Problem auch mit einem 10G Uplink passiert, kann ich noch nicht sagen, aber in spätestens 2-3 Wochen,
da bekommt einer der Besitzer einen neuen ARUBA-Core mit 10G.

Werde auch den Intel Support noch stressen, wird aber erst nächste Woche was werden.

Ich bin jetzt erst mal glücklich, dass ich den neuen HV-Cluster, welcher am Freitag beim Kunden mit 1G Uplinks in Betrieb gehen wird,
nicht in einer Nacht und Nebelaktion, auf 2016 downgraden muss. Die 300,- für die beiden Adapter sind bei einem Systempreis von 50K (incl. SAN) für mich persönlich erst einmal vollkommen irrelevant.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: Vision2015
04.04.2019 um 06:23 Uhr
Moin...

bei 10G würde ich SFP+ nutzen wollen, Kupfer wird deutlich zu heiß....

Frank
Bitte warten ..
Mitglied: MysticFoxDE
04.04.2019, aktualisiert um 08:03 Uhr
Moin Frank,

da muss ich dir widersprechen.
Wir verbinden die Server immer über 10G Kupfer zum Core.

Zum einen ist es eine Budgetfrage. Eine LWL Verbindung kostet bei DACs mind. 100,- mehr und bei GBICs + Kabel kommst man locker auf ~ 500,- mehr pro Verbindung.
(ich weis, dass es weit günstiger geht, aber nicht wenn mann auf Kompatibilität und Zertifizierung achtet)

Zum Anderen kommt der Faktor Kompatibilität hinzu, der bei LWL nicht zu unterschätzen ist, besonders beim Einsatz von DACs.
Bei Kupfer hingegen gibt es keine Kompatibilitätsprobleme, höchstens Qualitätsprobleme bei den Patchkabeln.

Core zum Verteiler (>25m) binden wir bei 10G wiederum immer über LWL ab.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: Vision2015
04.04.2019 um 11:54 Uhr
Zitat von MysticFoxDE:

Moin Frank,

Moin,
da muss ich dir widersprechen.
Wir verbinden die Server immer über 10G Kupfer zum Core.
ich sag ja nicht, das es nicht geht... sondern nur das es ziemlich warm wird...


Zum einen ist es eine Budgetfrage. Eine LWL Verbindung kostet bei DACs mind. 100,- mehr und bei GBICs + Kabel kommst man locker auf ~ 500,- mehr pro Verbindung.
(ich weis, dass es weit günstiger geht, aber nicht wenn mann auf Kompatibilität und Zertifizierung achtet)

Zum Anderen kommt der Faktor Kompatibilität hinzu, der bei LWL nicht zu unterschätzen ist, besonders beim Einsatz von DACs.
Bei Kupfer hingegen gibt es keine Kompatibilitätsprobleme, höchstens Qualitätsprobleme bei den Patchkabeln.

Core zum Verteiler (>25m) binden wir bei 10G wiederum immer über LWL ab.

Grüsse aus BaWü

Alex
Frank
Bitte warten ..
Mitglied: MysticFoxDE
01.05.2019 um 13:01 Uhr
Moin Bonbastler,

du solltest deinen Post im Bezug auf den X722 Adapter korrigieren, ich fürchte du bist hier auf denselben Irrtum reingefallen wie ich selber.
Deine Annahme, dass du ein Problem mit einem X722 NIC hast, stammt bestimmt daher, weil der Gerätemanager dir das vorgaukelt.
Leider gibt es bei Intel schon seit Längerem einen „BUG“ welcher bei der Installation der Treiber entweder den falschen Treiber installiert und oder den NIC falsch benennt. ☹

Auszug Readme

---

"Incorrect branding strings
Devices based on the Intel(R) Ethernet Controller X550 and Intel Ethernet
Controller X700 series may display incorrect branding strings in Windows Device Manager. This issue does not affect the functionality of the device. This issue only affects Microsoft* Windows Server* 2016."

---

In meinem Fall wurden die X557 Onboard-NICs ebenfalls als X722er erkannt.
Dein Board dürfte alleine schon aufgrund des Releasedatums (<2018) keine X722er NICs haben.
Der X722er Chipsatz wurde erst 2018 gelauncht.

Habe diesbezüglich vor einer Woche ein Supportcase bei Intel eröffnet, bisher gab es jedoch keine brauchbaren Neuigkeiten. ☹

Halte die Mannschaft auf dem laufenden sobald was Neues reinkommt.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: bonbastler
01.05.2019 um 21:01 Uhr
Hallo Alex,

das X11SPM-F hat wirklich X722 NIC onboard. Die Treiberdateien wurden auch ersetzt durch die aus dem jeweiligen Paket, hab das mehrfach penibel vor- und rückwärts kontrolliert. Das Problem tritt nur bei Server 2019 auf.

Grüße

der bon
Bitte warten ..
Mitglied: MysticFoxDE
01.05.2019 um 22:59 Uhr
Moin Bon,

ich widerspreche dir nur äusserst ungern, aber schau dir mal bitte den Anhang an.
Du hast exakt das gleiche Problem mit den NICs wie ich.

Gruss Alex

P.S. der Intel Support hat sich heute gemeldet, die sind an dem Problem dran.
x11spm-f - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: bonbastler
02.05.2019 um 11:22 Uhr
Hallo Alex,

ich bin nicht beratungsresistent. Wenn es zur Sache sinnvoll beiträgt dann widersprich mir gern ;)

Wir haben mehrere X11SPM-F verwendet. Der von dir rot eingerahmte NIC Chip ist die für die -TF Boards (10GB RJ45). Weder der Chip noch der zugehörige Konnektor (ein klein wenig weiter rechts) ist bei den -F Boards bestückt. Auf den -F Boards sind die LAN1/2 Konnektoren rechts daneben und die Marvell 88E1512 Phy Transceiver bestückt, siehe Handbuch S. 9 und 10.

Gruss bon
Bitte warten ..
Mitglied: MysticFoxDE
02.05.2019 um 22:05 Uhr
Moin Bon,

bin es auch nicht.

Habe die Marvell's entdeckt, siehe aktualisiertes Bild.
Bin kein SuperMicro Experte, wir arbeiten mit Intel Hardware.

Nun verstehe ich aber nicht wie du das mit "Hardware sind zwei fast identische neue Maschinen (MB Supermicro X11SPM-F mit 2x 1 GB Intel X722 onBoard NIC“ meinst, onBoard habe ich nichts von X722er entdeckt und deswegen geschrieben.

---

Ist aber auch zweitrangig, wenn du mit optionalen X722er NICs auch das Problem hast, dann hat der Treiber wahrscheinlich generell einen "Schuss" unabhängig ob mit falsch erkannten X557er oder mit richtigen X722er.

Interessant ...

Grüsse aus BaWü

Alex
x11spm-f - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: bonbastler
02.05.2019 um 23:05 Uhr
Hallo Frank,

zu deiner Information, das ist vielleicht ein Verständnisproblem: der Unterschied zwischen Netzwerkkarte, deren benötigten Treiber und dem Transceiver der die physische Verbindung zur Außenwelt / dem Anschluss herstellt.

Die onboard NIC auf diesen Mainboards (allen Mainboards der X11SPM Serie und vmtl. auch den von dir verwendeten Mainboards) sind Intel X722. Diese sind im Intel 'Lewisburg' PCH Chipsatz integriert und daher benötigen die auch Intel Treiber für X722. Die 1 GB Transceiver (real world connectoren für 1 GB per RJ45 / copper) von den X11SPM-F (die Mainboards welche das Problem haben, siehe 1. Post) sind von Marvel und das spielt treibertechnisch erstmal keine Rolle da diese hinter den NICs angesiedelt sind und keine eigenen Treiber haben oder benötigen. Siehe dazu auch Intel Supportmatrix S. 3 ff. mit der Unterstützung NIC und passendem Transceiver, z.B. auch wg. der X557 Transceiver für Copper 10 GbE welche ihr wohl verwendet habt.

Die temporär verwendeten NIC auf Einsteckkarten waren Intel i210 und i350. Damit gab und gibt es keine Probleme, hatte ich auch so geschrieben.

Gruß, der bon
Bitte warten ..
Mitglied: MysticFoxDE
03.05.2019 um 07:11 Uhr
Moin Bon,

Frank ist auch gut ... 🙃

OK, der Hinweis ist gut und ich habe auch schon was passendes in form eines Bildes dazu gefunden.
Verstanden habe ich es zwar noch nicht so ganz, es ist aber auch noch sehr früh am Morgen.

Man lernt eben nie aus ...

Grüsse aus BaWü

Alex
x11spm-f-diag - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: MysticFoxDE
03.05.2019 um 07:44 Uhr
Moin Bon,

der Groschen ist soeben glaube ich gefallen.
Bei den OnboardNICs steckt die Funktionalität/Logik im Chipsatz (C621/X722), die X557/Marvell's übernehmen hierbei lediglich die physikalische Verbindungsschicht.
Ähnlich wie bei einem SFP/SFP+ Switch, die Funktionalität/Logik sitzt im Switch, die Verbindungschicht übernimmt der jeweilige GBIC.

Richtig verstanden?

Gruss Alex
Bitte warten ..
Mitglied: bonbastler
03.05.2019 um 09:48 Uhr
Hallo Alex,

ganz genau so ist es. Schönes Bild, hätte ich nach einer guten Darstellung gesucht: das wär's, Handbuch S. 19.

Gruß

der bon
Bitte warten ..
Mitglied: MysticFoxDE
03.05.2019 um 10:11 Uhr
Moin Bon,

mein Hirn arbeitet besser mit visuellem Material. 😜

Gruss und Dank

Alex
Bitte warten ..
Mitglied: MysticFoxDE
03.05.2019 um 10:23 Uhr
Moin Bon,

zurück zu der Problematik.
Wenn ich nun alles zusammenlege, dann entsteht das Problem nur bei der folgenden Konstellation.

HV-OS: 2019
VM-OS: irrelevant (konnten das Problem mit 2012R2/2016/2019 nachstellen)
V-Switch nach extern über X722(LOGIK) und 1G Uplink.
Die verwendete physikalische Übertragungschicht (X557 oder Marvell) ist dabei irrelevant.

Bei Verwendung eines "eigenständigen" Adapters basierend auf I350, treten hingegen keine Probleme auf.

???

Gruss Alex
Bitte warten ..
Mitglied: bonbastler
03.05.2019 um 11:12 Uhr
So ähnlich, siehe Eröffnungspost.

Das Problem trat bei uns mehrfach reproduzierbar ausschließlich auf wenn der Hyper V ein 2019 und der Gast kein 2019 (2008R2, 2012R2, 2016) war. Mit Server 2016 oder Server 2012R2 als Hyper V und einem beliebigen Server als Gast (2008R2, 2012R2, 2016, 2019) trat das Problem nicht auf. Bei Verwendung eines eigenständigen NIC Adapters mit i210 oder i350 trat das Problem auch nicht auf. Ob die bei der X722 verwendeten phys. Transceiver (in dem von mir geschilderten Fall die Marvell 1GB Phy Transceiver) eine Rolle spielen konnte ich bisher mangels Technikverfügbarkeit bzw. mangelnder Zeit nicht weiter nachstellen. Der User 137846 hatte weiter oben am 29.12. gegen 10:52 geschrieben dass er diese Probleme nicht nachstellen konnte, keine Ahnung was für ein Board der genau benutzt hat.

Fakt ist: mit einer Standardinstallation, mehreren der damals verfügbaren originalen Treibern und den originalen Einstellungen dafür trat das Problem reproduzierbar auf. Wir haben an den Systemen derart viel rumgebastelt (im positiven Sinne) dass der (insbes. der einfachste / kürzeste) Weg zum Ziel nicht mehr komplett reproduzierbar ist. Das Ziel war irgendwann erreicht. Mangels weitere Zeit und alternativer HW zum Nachstellen und Testen habe ich das bei uns vor Monaten als vorläufig gelöst beiseite legen müssen. Einem anderen Benutzer hier im Forum (s.o.) welcher vmtl. das gleiche Problem hatte habe ich angeboten das mit ihm durchzuspielen aber er hat das Angebot nicht wahrgenommen, so blieb auch mir die einfache Möglichkeit verwehrt das Problem - sofern es aktuell noch besteht - genauer zu dokumentieren und einen effektiven Lösungsweg (auch hier) zu offerieren.
Bitte warten ..
Mitglied: MysticFoxDE
04.05.2019 um 12:05 Uhr
Moin Bon,

das mit HV 2019 & VM 219 kann ich nur zum Teil bestätigen.
VM 2019 --> HV 2019 --> 1G SWITCH --> Client W10 konnte ich keine Probleme feststellen.
Jedoch bei VM 2019 --> HV 2019 --> 1G SWITCH --> HV 2019 --> VM 2019 sehr wohl.
Die Lösung mit dem I350 setzen wir aktuell auch bei allen aktuellen Systemen mit 1G Switchen dahinter ein.

Ich habe vor 1,5 Wochen einen Supportcase bei Intel eröffnet und gebeten das ganze im Lab mal nachzustellen, siehe Anhang.

Bei allem was ich bisher gelesen habe, sollte die Lösung meines Problems auch deines beseitigen.

Bleibt nun abzuwarten.

Grüsse aus BaWü

Alex

P.S. Die Jungs vom Intel Support haben von mir auch den Link zu diesem Post hier bekommen.
intel-x557 - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: MysticFoxDE
24.05.2019 um 09:37 Uhr
Hi Bon,

habe Update, siehe Mail die ich gerade an den Intel Support geschickt habe.

---

Hi Christian,

it’s a little bit cracy.
We prepare these week a new system for a customer.
The hardware is the same like the systems before, the only differences are a bunch of microsoft updates for the MS server 2019 and
a new version of the chipset driver.

Now, we can’t reproduce the issue!?!

The last day’s we try some different configurations.

HV was always MS Server 2019
VMQ & SRIOV are both enabled (BIOS, NIC, V-SWITCH, VM).

VM: MS Server 2019  MS Server 2019 112 – 113 MB’s
VM: MS Server 2016  MS Server 2016 112 – 113 MB’s
VM: MS Server 2012R2  MS Server 2012R2 112 – 113 MB’s

At the moment we, check the whole configuration (BIOS/OS/HV), to make sure that everything corresponds to the previous system.
---

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: bonbastler
24.05.2019 um 11:14 Uhr
Hallo Alex,

danke erstmal für deine Bemühungen.

Das Problem tritt ja nicht in der Kommunikation der VM untereinander innerhalb des Host über den HV Switch auf sondern zu 'beliebigen' Clients (physisch und virtuell) nach außen über die NIC. Das geht aus deren Beschreibung nicht so eindeutig hervor ob die das Szenario auch so umgesetzt haben.

Gruß

der Bon
Bitte warten ..
Mitglied: MysticFoxDE
24.05.2019 um 14:57 Uhr
Moin Bon,

wenn ich etwas anfasse, dann richtig.

"Das Problem tritt ja nicht in der Kommunikation der VM untereinander innerhalb des Host über den HV Switch auf sondern zu 'beliebigen' Clients (physisch und virtuell) nach außen über die NIC."

Wir haben immer mit 2 HVs getestet.

HV01(2019) mit VM 2019 <--> Hardwareswitch <--> HV02(2019) mit VM 2019
HV01(2019) mit VM 2016 <--> Hardwareswitch <--> HV02(2019) mit VM 2016
HV01(2019) mit VM 2012R2 <--> Hardwareswitch <--> HV02(2019) mit VM 2012R2

Das müsste, wenn ich mich nicht täusche, auch dein Szenario abdecken.

Gruss Alex
Bitte warten ..
Mitglied: MysticFoxDE
24.05.2019 um 15:02 Uhr
Moin Bon,

kam gerade vom Intel Support rein.

---

Hello Alexander,
Thank you for the update in regards to the experience on your end.
We also noticed that the new updates from Microsoft have some impact on our current configurations but in some different scenarios.
We will still continue and try to replicate the issue and see what results we will get over the testing period.
When we get some details we will let you know for sure.
At the same time, if you find out some details on your side, we would be very tankful for additional feedback.
Once again thank you in advance.

---

Lag vielleicht doch nicht an Intel sondern an MS. 😀

Wünsche allen ein schönes Wochenende.

Ich tauche jetzt ab . 😎🤪🤘🏿

Gruss Alex
Bitte warten ..
Mitglied: MysticFoxDE
27.05.2019 um 09:38 Uhr
Moin Bon,

wir haben das System noch bin Anfang nächster Woche.
Wir testen noch das NIC-Teaming und wenn das gut geht dann ist der Fisch für uns geputzt.

Mit welchen Clients hattest du bis jetzt Probleme?

Wir testen unser Setup nochmals mit Win10 Workstation gegen HV2019 und VM2016 & VM2012R2.
Gebe dir Bescheid, sobald die Tests durch sind.

Gruss Alex
Bitte warten ..
Mitglied: MysticFoxDE
27.05.2019 um 11:56 Uhr
Moin Bon,

sind durch mit den Tests. 😀🤘🏿

(Anwortmail an Intel)
---
Hi Christian,

today we test the last part, NIC-Teaming (2 x 1Gbit/s), it works fine.

HV01(2019) with VM 2019 <--> Hardwareswitch <--> HV02(2019) with VM 2019 112-113MB/s
HV01(2019) with VM 2016 <--> Hardwareswitch <--> HV02(2019) with VM 2016 112-113MB/s
HV01(2019) with VM 2012R2 <--> Hardwareswitch <--> HV02(2019) with VM 2012R2 112-113MB/s

HV01(2019) with VM 2019 <--> Hardwareswitch <--> Workstation W10 112-113MB/s
HV01(2019) with VM 2016 <--> Hardwareswitch <--> Workstation W10 112-113MB/s
HV01(2019) with VM 2012R2 <--> Hardwareswitch <--> Workstation W10 112-113MB/s

I think our problem is solved. 😀
MS Update ???

Best regards

Alex

---

Gruss Alex
Bitte warten ..
Mitglied: hub22019
27.05.2019, aktualisiert 29.05.2019
Hallo zusammen,

interessanter Post. So ähnlich habe ich es auch, aber mit einer ganz einfachen Konfiguration, keine VMs, kein „Schnickschnack“, simply Dateitransfer, kein Teaming:
- verschiedene Windows 10 Rechner
- Win2016 Server (Intel)
- Win2019 Server (AMD)
- Netgear 10G switch
- Alle Asus 10G Karte RJ45
- Alle Treibereinstellungen probiert, danach wieder auf Standard gestellt

Aufgabe: Einfach nur eine 24GB Datei vom Server laden.
Win2016 Server -> Windows 10 Rechner konstant 500MByte/sec
Windows 10 RechnerA -> Windows 10 RechnerB konstant 1,09GByte/sec (nvme)
Win2019 Server -> Windows 10 Rechner unberechenbar, startet teilweise bei 500MB/sec, dann drop auf 360KB/sec . Oder „startet“ gleich mit 360KB/Sec.

Bin mit meinem Latein am Ende. Problem scheint doch auf Server2019 fokussiert zu sein. Vielleicht im Zusammenspiel mit AMD.

Update: Es liegt nicht an der Asus Karte, Bei Verwendung einer Intel Karte dasselbe Problem...
Bitte warten ..
Mitglied: Badger
28.05.2019, aktualisiert um 09:31 Uhr
Ich habe/hatte auch das Problem, dass jegliche VM (wie von @MysticFoxDE beschrieben) einen schlechten Durchsatz hatte.

Nachdem ich auf den 2019er VMs den Panda Virenschutz deinstallierte, funktionierten diese zumindest ohne Probleme.
Problem bei den 2010R2er VMs bleibt jedoch bestehen.

Alles was ich bisher probierte, brachte nichts:
  • aktuellen Treiber installiert
  • aktuelle Firmware von Lenovo installiert
  • Panda Virenschutz deinstalliert
  • VMQ deaktiviert (ist bei 1GBit NICs ja sowieso nicht standardmäßig aktiviert)
  • Flußsteuerung und Puffergrößen auf die empfohlenen Einstellungen von Intel gesetzt (klick)
  • Direkt in den VM-Einstellungen die "Warteschlange für virtuelle Computer" deaktiviert
  • IPsec-Taskabladung deaktiviert
  • RSC deaktiviert (klick)
  • Large send offload deaktiviert
  • TCP- und UDP-Prüfsummenabladung deaktiviert (sowohl auf physischer als auch auf virtueller NIC)
  • Upgrade der VM von Gen1 auf Gen2 (klick)
  • ...

Habe dann Tests mit einer 14,99€ "teuren" Realtek USB GbE Family gemacht. Und voi­là: alles funktioniert.

Keine Ahnung ob es am Treiber oder an den Einstellungen hakt. Aber kann bestätigen, dass es hier definitiv Probleme gibt.


@MysticFoxDE:
was hat denn der Intel-Support dir nun geantwortet? Wie wollen die denn weiter vorgehen?

Grüße
Patrick
Bitte warten ..
Mitglied: MysticFoxDE
29.05.2019 um 18:56 Uhr
Hi Patrick,

wir können das Problem nicht mehr reproduzieren.
Nach mehrfacher Prüfung entspricht die Konfiguration des jetzigen "Labs" exakt der Konfiguration, der vorherigen Systeme.
Der einzige Unterschied ist der Patchlevel des 2019er Servers, die jetzige Lab ist auf dem allerneusten Stand gegen MS Updates, nicht WSUS.

---
VMQ deaktiviert (ist bei 1GBit NICs ja sowieso nicht standardmäßig aktiviert)
Flußsteuerung und Puffergrößen auf die empfohlenen Einstellungen von Intel gesetzt (klick)
Direkt in den VM-Einstellungen die "Warteschlange für virtuelle Computer" deaktiviert
IPsec-Taskabladung deaktiviert
RSC deaktiviert (klick)
Large send offload deaktiviert
TCP- und UDP-Prüfsummenabladung deaktiviert (sowohl auf physischer als auch auf virtueller NIC)
---

Hatten wir früher auch gemacht, ist aber nicht mehr notwendig, zumindest nicht bei unserem Szenario.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: Badger
29.05.2019 um 19:26 Uhr
Danke für deine Rückmeldung.

Zitat von MysticFoxDE:
Der einzige Unterschied ist der Patchlevel des 2019er Servers, die jetzige Lab ist auf dem allerneusten Stand gegen MS Updates, nicht WSUS.
Bei mir auch alles aktuell (ohne WSUS) und trotzdem genau die gleichen Symptome wie ihr sie hattet (und scheinbar nun bei euch behoben sind).
Das soll nun einer noch verstehen...

Grüße
Patrick
Bitte warten ..
Mitglied: MysticFoxDE
30.05.2019 um 08:00 Uhr
Moin Patrick,

bei uns sind die Probleme momentan in Verbindung mit einem NEUEN System nicht mehr nachvollziehbar.
Zumindest nicht, wenn unsere Adapter mit 1G laufen, mit 10G habe ich diese bisher nicht getestet, da keiner unserer Kuden 10G zum Client betreibt.
Die bisherigen 3 Systeme die wir auf 2019 ausgeliefert haben, sind alle mit i350 er nachgerüstet worden und laufen seit dem mit 1G reibungslos.

Versuch mal den folgenden Trick.
Gehe in den Gerätemanager und deinstalliere alle X722 Adapter, danach Hardwareerkennung (Nach geänderter Hardware suchen) ausführen und die Adapter anschliessend neu konfigurieren. Ist lästig, aber ich habe da so eine Vermutung die auf der folgenden jüngsten Erfahrung beruht.
Bei den Tests, die wir die letzten Tage gemacht haben, wurde unter anderem auch ein vierfach Teaming getestet.
Das Ergebnis war OK, aber als ich zwei der vier NICs wieder aus dem Team geschmissen habe, konnte ich dieselben nicht mehr in ein neues Team hinzufügen, die NICs waren über den Servermanager nicht mehr sichtbar (wir nutzen MS-Teaming (Modus --> Switchunabhängig), nicht Intel-Teaming). Die NICs waren erst nach der oben beschriebenen Prozedur über den Servermanager wieder konfigurierbar.
Ich schätze MS muss noch ein paar BUGs mehr beseitigen ... ☹

Wir deaktivieren ferner auf allen Adaptern IPv6, wollte ich nur der Vollständigkeit halber erwähnen.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: MysticFoxDE
30.05.2019 um 08:21 Uhr
Moin Hub22019,

welche Hardware benutzt du für die Server, Mainboard/CPU?
Welchen Storagetyp hat der Server HHD/SSD, SATA/SAS/NVME?

"Win2016 Server -> Windows 10 Rechner konstant 500MByte/sec"
"Win2019 Server -> Windows 10 Rechner unberechenbar, startet teilweise bei 500MB/sec, dann drop auf 360KB/sec . Oder „startet“ gleich mit 360KB/Sec"

???

Es ist etwas kurios, dass bei dir beide, sowohl der 2016er als auch der 2019er spacken ...
Hast du evtl. einseitig Jumboframe eingestellt?
VLAN, Routing dazwischen?

Je mehr Infos um so besser.

Gruss Alex
Bitte warten ..
Mitglied: hub22019
30.05.2019 um 17:57 Uhr
Hallo Alex,

hatte nun hier einen thread aufgemacht:
https://administrator.de/forum/10gbe-filetransfer-windows2019-server-fun ...

Server2016 Microserver gen8: Sata ssd 6g
Server2019 Microserver gen10: Sata ssd 6g
PCs: nvme
Jumbo überall eingestellt.

Auf dem folgenden Screenshot sieht man auf einen Blick das Problem. Dabei habe ich die beiden unteren Kopiervorgänge gestartet, als beim oberen schon seit 20 Sekunden bei 300kb/sec herumgedümpelt wird. WTF...

30-05-_2019_17-50-57 - Klicke auf das Bild, um es zu vergrößern

Am besten bitte im anderen Thread antworten
Bitte warten ..
Mitglied: Badger
30.05.2019 um 20:06 Uhr
Hallo Alex,

danke für deine Tips.

Hätte nun das entfernen und hinzufügen der Adapter probiert.
Auch das deaktivieren von IPv6.

Beides löst leider das Problem nicht

Grüße
Patrick
Bitte warten ..
Mitglied: MysticFoxDE
31.05.2019, aktualisiert 03.06.2019
Moin Patrick,
Moin Badger,

wenn Ihr auf dem 2019er Server noch etwas RAM übrig habt, so probiert bitte das folgende.
Generiert bitte mit dem folgenden Tool eine RAM-DISK.
https://sourceforge.net/projects/imdisk-toolkit/
Freigabe drauf und den Test wiederholen.

Ergebnis ???

---

Um bei einem MS Server die vollen Transferraten zu erreichen, sollte man ferner immer die Energieoptionen auf "Hochleistung" setzen!!!

Bei einem 2019er hätte ich euch noch den folgenden Trick.
CMD mit Adminrechten aufmachen und dann die folgenden beiden Befehle ausführen.
1. "powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61"
2. "powercfg.exe -setactive 9d69a0c6-32fb-4d7a-b235-e37b7d0111c0"
3. Unter Energieeinstellungen nachsehen. 😉🤪

Diese Einstellung muss sowohl auf dem HV als auch auf der VM gemacht werden.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: MysticFoxDE
03.06.2019 um 08:21 Uhr
Moin Hub22019,

ergänzend zu dem zuletzt geprosteten.
Du musst unbedingt sicherstellen, dass deine Storage-Hardware die 1GB/s bei einem "single thread / single task" auch packt.
Das bekommen im Normalfall nur PCIe/NVME SSDs hin oder ein leistungsfähiges SAN am Server.
Mit (6G)SATA SSDs wirst du das ohne einen RAID-Verbund 100% nicht hinbekommen.

Wir verwenden in unseren Servern P4800X von Intel als Bootlaufwerke und das angeschlossenen AllFlash-SAN ist auch sehr leistungsfähig,
beide packen bei "single thread" locker > 1000 MB/s.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: Badger
03.06.2019 um 14:30 Uhr
Danke allen - ganz besonders @MysticFoxDE - für eure Hilfe.

Ich konnte nun das Problem lösen. Im Lenovo Forum brachte mir ein User den entscheidenden Hinweis:

After trying different drivers, firmware, etc. the only solution I finally found was this:
In the Driver -> Advanced for the NIC:
Recv Segment Coalescing (IPv4) - set to Disabled
Recv Segment Coalescing (IPv6) - set to Disabled

Es muss dabei wirklich RSC auf der NIC abgeschaltet werden. Das deaktivieren von RSC am vSwitch löste bei mir das Problem nicht!

@bonbastler:
War dies evt. auch bei deinem Problem die Lösung?

Grüße
Patrick
Bitte warten ..
Mitglied: Badger
03.06.2019 um 15:06 Uhr
Auch diesbezüglich noch zur Info:
Wenn der Server 2019 ist, kam es bei mir prinzipiell nicht zu einem Problem. Außer Panda war installiert.

Seit ich RSC deaktiviert habe, funktioniert es auch mit installiertem Panda beträchtlich besser.

Patrick
Bitte warten ..
Mitglied: MysticFoxDE
03.06.2019 um 16:11 Uhr
Hi Patrick,

vielen Dank für diese sehr interessante Info, werde diese im Auge behalten.

Habe soeben das Lab-System welches morgen ausgeliefert wird nochmals hochgefahren und die Einstellungen geprüft,
bei uns sind die Optionen auf "Enabled" ohne Performanceeinbussen. ?!?
Aber dennoch sehr Cool, nun weis ich ja wo ich drehen muss, falls doch welche auftauchen. 👍

Nochmals herzlichen Dank für das Teilen der Lösung.

Gruss Alex
Bitte warten ..
Mitglied: mb1811
01.08.2019 um 21:17 Uhr
Hallo!

Ich möchte hier gerne Einsteigen und unsere Erfahrung teilen:

System: Fujitsu 2540M5 mit 2x X710 10G Karten.
Hyper-V Rolle installiert. Eine 10G Karte als Taggen Uplink für die VM's.

Wir haben angefangen VMs von einem 2012R2 zu migrieren. Das Ganze lief 2 Wochen einwandfrei.
Vor einigen Tagen fingen die Performance Probleme der VMs an:

Datendurchsatz meist unter 22MB/s - oftmals um die 3MB/s. Teilweise lassen sich Dateien nicht öffnen, oder Verbindungen zu einer Oracle DB brechen ab.

Was ich beobachten konnte: Das Kopieren einer ISO Datei mit 1GB hat auf die VM's (2008, 2008R2 und 2012R2) einen Durchsatz von 3MB/s.
2019er VM's bringen allerdings den vollen Durchsatz!

Wir haben dann die internen RJ45 als virtual Switch konfiguriert. Es handelt sich hier um X722 Karten.

Hier zeigt sich exakt das selbe Verhalten.

Kopiere ich nun aber über die 10G Karte, als auch über die 1G Karte direkt auf den Hyper-V Host, habe ich wieder vollen Durchsatz.

Mir scheinen die NIC Treiber OK zu sein. Es scheint mir als gäbe es massive Probleme zwischen den VM's kleiner 2019 und dem virtual Switch.

Wir haben jetzt angefangen und migrieren zurück auf 2012R2 um die Firma am laufen zu halten.

Testweise haben wir das Oracle System und einen Fileserver auf einen 2012R2 Hyper-V zu schieben. Ebenfalls mit den 10G Karten: Voller Durchsatz. Die Maschinen laufen rund.

Matt
Bitte warten ..
Mitglied: MysticFoxDE
09.08.2019 um 07:37 Uhr
Moin Matt,

hast du auf dem 2019er alle MS-Updates installiert?

Falls WSUS vorhanden, so bitten den HV umkonfigurieren, dass dieser die Updates direkt aus dem Internet zieht.

Grüsse von einem der Seeen in Mecklenburg

Alex
Bitte warten ..
Mitglied: MysticFoxDE
09.09.2019, aktualisiert um 21:13 Uhr
!!! Heureka !!!

Moin Leidensgenossen,

habe das Problem gefunden und auch gleich gelöst, kein Witz.

Nun zur ganzen Geschichte.

Wir haben die letzten Monate diverse HV Systeme ohne Probleme von 2012R2 und 2016 auf 2019 umgestellt. Alle Upgrades sind ohne Probleme verlaufen, bis auf das Letzte.
Bei der letzten Umstellung hatten wir im Anschluss wieder massiv mit Performanceproblemen zu kämpfen. Zurückgerudert sind wir nicht, ich habe kurzerhand drei I350 Adapter aus dem Lager geholt und die drei HVs damit bestückt und schon konnte der Kunde auch mit 2019 ohne nennenswerte Einbussen weiter arbeiten. Keine Sorge das ist jetzt nicht die Lösung.

Nun begann eine längere Suchaktion. Ich verglich akribisch die Einstellungen der NICs und konnte absolut nichts finden, was das Problem erklären würde. Diverse Konfigurationen wurden ausprobiert, mal mit, mal ohne VMQ, SR-IOV, RSS, RSC & Co. KG. Alle Versuche das Problem über die Erweiterten Einstellungen der NICs zu lösen, brachten entweder keine Besserung oder verschlimmbesserten die Lage.

Das Licht ging mir auf, als ich letztes Wochenende mal wieder exzessiv getestet habe.
Ich verschob auf einen Kundensystem alle für eine bestimmte Applikation relevanten Server auf denselben HV incl. Terminalserver. Dann stellte ich alle VM-Netzwerkadapter vom dem funktionierenden vSwitch mit 1G Uplinks (vSwitch1G) auf den vSwitch mit den 10G Uplinks (vSwitch10G) um, und sofort brach die Applikationsperformace mehr als nur spürbar ein.
Moment, dachte ich mir, das kann doch jetzt doch gar nicht sein. Die gesamte Kommunikation läuft nun nur noch über den vSwitch der von der Host-CPU gehandelt wird, da haben die NICs doch noch gar nichts mit dem Traffic zu tun.

Schnell PowerShell geöffnet und die Konfig des vSwitches abgefragt.

Get-VMSwitch -Name „NAME_VSWITCH“ | format-list

Und dann dasselbe Spielchen auf ein paar anderen HV 2019er Kundensystem, wo uns keine Performanceprobleme bekannt sind und schon war das Übel ersichtlich. Der vSwitch wurde an ein paar Stellen, mit absolut falschen Parametern generiert.
Ich habe zur besseren Übersicht die Werte in eine Tabelle reingeklopft.

vswitch - Klicke auf das Bild, um es zu vergrößern

Ich sage nur "BandwidthReservationMode"

Wer mehr wissen möchte, einfach Google mit folgender Anfrage quälen "BandwidthReservationMode bug"
Gibt es anscheinend schon seit 2012, aber warum das jetzt ausgerechnet mit den INTEL >= X540er und HV 2019er vermehrt auftritt, habe ich noch nicht raus gefunden.

Nun war die Lösung nur noch einen Katzensprung entfernt.
Ich habe den vorherigen fehlerhaften vSwitch gelöscht und per PowerShell mit dem folgenden Befehl einen neuen angelegt.

New-VMSwitch -Name " NAME_VSWITCH " -MinimumBandwidthMode Absolute -NetAdapterName "NIC 1.1 - PROD 10G" -AllowManagementOS $false

Falls jemand Multilinks benutzt, dann muss er diese nicht mehr vorher im OS vorkonfigurieren, das klappt ab HV 2016 direkt auf dem vSwitch.

Dazu die folgende beiden Befehle ausführen.

New-VMSwitch -Name "NAME_VSWITCH" -MinimumBandwidthMode Absolute -NetAdapterName
"NAME_NIC_1", "NAME_NIC_2" -EnableEmbeddedTeaming $true -AllowManagementOS $false

Set-VMSwitchTeam -Name "DESIG-PROD-10G-BIUL" -LoadBalancingAlgorithm Dynamic

Und schon war der Fisch geputzt. 😊

Habe heute Nachmittag die Bestätigung von Kunden bekommen, dass die Änderungen gefruchtet haben. Es sind seit der Umstellung keine Performanceeinbussen auf dem vSwitch mit den X722er und X540er mehr aufgetreten. 🥳

Der Vollständigkeit halber, die jetzige Konfig läuft ohne VMQ, SR-IOV, RSS, wir werden die genannten Features nun kontrolliert nach und nach aktivieren und schauen was passiert.
Ich halte diesbezüglich auf dem Laufenden.

Ich bin mir aber 100% sicher, dass das Problem an dem vSwitch lag. Wir haben noch ein weiteres 2019er System, welches Ende 2018 mit X722er ausgeliefert wurde und im Nachgang mit 1G (I350) nachgerüstet wurde, da die Performance nicht passte. Auch dort ist der vSwitch vom OS bei der Konfiguration per GUI falsch generiert worden.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: mastersp
15.10.2019 um 09:30 Uhr
Hallo,

vielen Dank für deine Ausführliche Antwort.
Habe bei mir dasselbe Problem, die vSwitch Einstellungen sind allerdings korrekt.

3x HyperV Host(s), welche von 2016 auf 2019 upgegradet worden sind.
Geschwindigkeit bricht bei mir extrem bei kleineren Dateien ein. Einzelne große Dateien stellen kein Problem dar.
Weiße ich der VM die 1GB Nic zu, ist die Geschwindigkeit wie gewünscht...
Bei mir sind allerdings folgende 10GB NICs verbaut:
1x Intel 82599 10GB
1x Intel X520
1x Intel X710
VMQ = deaktiviert

Falls es noch weitere Ideen gibt, bitte ich darum

Danke
Bitte warten ..
Mitglied: MysticFoxDE
15.10.2019 um 10:45 Uhr
Moin Mastersp,

"Weiße ich der VM die 1GB Nic zu, ist die Geschwindigkeit wie gewünscht..."

Wie meinst du das genau?
Laut deinen Angaben sind im Server nur 10G NICs verbaut?
Hast du eine der NICs auf 1G "gedrosselt"?

Grüsse aus Murrhardt

Alex
Bitte warten ..
Mitglied: mastersp
15.10.2019 um 12:05 Uhr
Sorry falsch formuliert.
Die Server haben zusätzlich zu den 10GB NICs jeweils Broadcom GB (onboard).
Meine VMs haben nun einen vSwitch via den 1GB Karten, hier gibts keine Performance-Probleme.

Sobald ich die 10GB vSwitch verwende bricht die Geschwindigkeit ein.
Kann man sehr gut mit Kopiervorgängen testen.

liebe Grüße
Bitte warten ..
Mitglied: MysticFoxDE
15.10.2019 um 12:45 Uhr
Moin MasterSP,

ich habe die Vermutung, dass es entweder am RSS oder am RSC liegt, hatte Zuletzt aber absolut keine Zeit das Thema weiter zu verfolgen.

---

In der aktuellen Readme des 24.2 habe ich die folgenden interessanten Einträge gefunden.

Unexpected CPU utilization
You may see one CPU reaching 90%-100% utilization if the RSS Load Balancing
Profile is set to NUMAScalingStatic. Setting the RSS Load Balancing Profile to
ClosestProcessor should correctly balance the CPU load. This issue affects
devices based on the Intel(R) Ethernet Controller X722 in systems running
Microsoft* Windows Server* 2019.

RSS Load Balancing Profile Advanced Setting
Setting the "RSS load balancing profile" Advanced Setting to "ClosestProcessor"
may significantly reduce CPU utilization. However, in some system
configurations (such as a system with more Ethernet ports than processor
cores), the "ClosestProcessor" setting may cause transmit and receive failures.
Changing the setting to "NUMAScalingStatic" will resolve the issue.

Multicast routing table is not automatically set up
The multicast routing table for the Intel(R) Ethernet Virtual Function 700
Series driver is not automatically set up and the virtual machine will not
receive multicast traffic. Manually adding the multicast routing will resolve
the issue.

Reduced or erratic receive performance
Intel(R) 7500 chipset-based systems may experience degraded receive
performance. Increasing receive descriptors to 1024 will resolve the issue.
Disabling C-states in the system BIOS will also resolve the issue.

CPU utilization higher than expected
Setting RSS Queues to a value greater than 4 is only advisable for large web
servers with several processors. Values greater than 4 may increase CPU
utilization to unacceptable levels and have other negative impacts on system
performance.

VLANs are not supported on VMQ enabled adapters and teams
If you create a VLAN on a VMQ enabled adapter, the VMQ setting will
automatically be set to disabled. The same will happen if you create a VLAN on
a team whose member adapters have VMQ enabled.

Reduced Large Send Offload performance
Large Send Offload (LSO) and IPSec Offload are not compatible. LSO is
automatically disabled when IPSec Offload is enabled. This may reduce the
performance of non-IPSec traffic. Confining all of your IPSec traffic to one
port and enabling IPSec Offload only on that port may mitigate this issue. On
Microsoft Windows 8.1 and Server 2012 and later, devices based on the 82576,
82599, and X540 controllers are not affected by this issue.

Network stack will not enable RSC
If Intel Data Center Bridging (DCB) is installed (FCoE, iSCSi, or both), the
network stack will not enable Receive Segment Coalescing (RSC)

---

werde mich die Tage wieder dran klemmen (müssen).

Grüsse aus Murrhardt

Alex
Bitte warten ..
Mitglied: dneuhaeuser
15.11.2019 um 13:32 Uhr
Hallo Leidensgenossen,

wir haben aktuell genau das beschriebene Problem bei einem Kunden.
Neuer Server Supermicro X11 mit onboard NIC X722, HyperV 2019 und VM 2019 ist total träge im Dateizugriff.

Durchsatz vom Server zum Client oft nur 3-4 Mbit/s. Besonders beim Zugriff auf Dateien im MB-Bereich spürbar.
Geschwindigkeit nimmt nach 5-10 Sekunden dann Fahrt auf (bei Dateien mit einigen GB). Dann voller Gbit-Speed (ca. 113 MB/Sek).
In Gegenrichtung (Client zum Server) scheinbar kein Problem.

Leider hat bei uns bisher keine der diskutierten Lösungsmöglichkeiten geholfen.
Wir haben die aktuellsten NIC-Treiber (Intel 24.3), vSwitch neu erstellt (BandwithReservation=Absolut), RSC deaktiviert, RSS deaktiviert, sämtliche IP-/TCP-Offloading-Optionen deaktiviert, VMQ deaktiviert, SR-IOV deaktiviert.

Zuletzt haben wir eine i350 NIC eingebaut und auch keine Änderung festgestellt.
Kabel getauscht, Switch getauscht.

Clients sind W10 1903 mit Realtek Gbit onboard.
Testweise habe ich auch in einem Client eine andere (Intel) Gbit-Karte eingebaut. Keine Änderung.
Auch am Client probeweise alle Offloadings und RSS deaktiviert.

Dann haben wir rein zufällig den Linkspeed eines Clients von 1000 auf 100 Mbit/s reduziert.
Damit sind die Verzögerungen plötzlich nicht mehr vorhanden. Kleine Dateien öffnen mit 100 Mbit um ein Vielfaches schneller als mit 1000 Mbit Link. Das Verhalten lässt sich reproduzieren: 1000 Mbit Link -> sofort wieder langsam.
Es liegt aber definitiv nicht an Netzwerkkabel oder -dose. Das wurde durchgemessen und ist einwandfrei.
Außerdem lief über dasselbe Kabel schon früher eine Gbit-Verbindung und der Zugriff auf den alten Server (2008) war schnell.

Nun Frage ich mich:
Was macht der Server 2019 anders wenn ein Client mit einem 100 Mbit Link zugreift?
Sind dann vielleicht irgendwelche erweiterten Features nicht aktiv?

Hat noch jemand eine Idee?

Ich bin sonst kurz davor einen Server 2016 aufzusetzen.

Gruß
Dennis
Bitte warten ..
Mitglied: MysticFoxDE
16.11.2019 um 20:59 Uhr
Moin Dennis,

"Zuletzt haben wir eine i350 NIC eingebaut und auch keine Änderung festgestellt."

Was meinst du damit genau?
Bei allen unseren bisherigen X722 2019er Problemkindern hat der Einbau einer i350er die Problematik behoben.

Gruss Alex
Bitte warten ..
Mitglied: dneuhaeuser
16.11.2019 um 21:55 Uhr
Mit der i350-T2 ist es bei uns genauso langsam wie mit der X722.
Kein Unterschied: Geschwindigkeit von VM 2019 zu Clients weiterhin anfänglich nur 3-4 Mbit/s.
VM mit 2016 probeweise installiert: sofort volle Gigabit Geschwindigkeit ohne Verzögerungen.
Ich verstehe es nicht mehr.

Gruß Dennis
Bitte warten ..
Mitglied: dneuhaeuser
17.11.2019 um 00:28 Uhr
Total verrückt:
Ich kann auch einen Unterschied durch den Linkspeed am Server feststellen.

i350 im HyperV 2019 mit 1000 Mbit Link:
VM 2019 -> Client = verzögerter Dateizugriff (3-4 Mbit/s)
VM 2016 -> Client = keine Verzögerung (sofort übliche Durchsatzraten)

gleicher Server, gleiche NIC, aber auf _100_ Mbit Link runtergedreht:
VM 2019 -> Client = keine Verzögerungen mehr (sofort Durchsatz 90 Mbit/s)

Aktuell laufen die Anwendungen auf der 2019er VM damit um ein Vielfaches schneller als zuvor mit dem 1000er Link.

Kann sich jemand einen Reim darauf machen?
Bitte warten ..
Mitglied: MysticFoxDE
18.11.2019 um 07:45 Uhr
Moin Dennis,

"Kann sich jemand einen Reim darauf machen?"

+-, das riecht für mich nach RSS oder RSC, beim Letzteren, hat MS beim 2019er besonders kräftig rumgefummelt.

Siehe auch
https://www.computerweekly.com/de/tipp/Windows-Server-2019-Diese-SDN-Fun ...

Gib mal in einer CMD auf dem HV den folgenden Befehl ein. 😉

„netsh interface tcp show global“

Der Mist ist ganz schön tief auf der TCP Ebene verankert.

In dem folgenden Artikel werden die meisten Optionen ganz gut beschrieben und passt auch auf den Hyper-V obwohl der Artikel ursprünglich für VMware geschrieben wurde.

https://www.flatbox.org/vmware-vmxnet3-performance-fuer-windows-server-2 ...

An den TCP Stack Parameter habe ich bisher aus Zeitmangel noch nicht rumgespielt.
Aber ich denke, dass hier der Hund begraben sein könnte. Die Optionen haben sich zwischen 2016er und 2019er auf jeden Fall verändert, es sind neue dazugekommen aber auch welche wieder verschwunden.

Jetzt muss ich aber weiterflitzen.

Wünsche allen eine angenehme und erfolgreiche Woche.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: dneuhaeuser
18.11.2019 um 23:06 Uhr
Hallo Alex,

Danke für den Ansatz.

Ich habe mir die TCP-Optionen der Reihe nach vorgenommen.
Sowohl auf dem HyperV als auch in der Test-VM 2019 letztlich alle deaktiviert.

Aber leider keine Besserung der Performance...

Irgendwas muss bei uns noch anders sein...

Gruß
Dennis
Bitte warten ..
Mitglied: MysticFoxDE
21.11.2019 um 07:18 Uhr
Moin Dennis,

wir haben diverseste Kundensysteme mit 2019 und i350er ohne Probleme am Laufen.

Ich würde dir gerne das folgende Angebot unterbreiten.
Wir machen für nächste Woche einen Termin aus und gleichen dein i350 Problemkind per Teamviewer mit einem System von uns ab, wo es keine Probleme gibt.

???

Schreib mich bei Interesse einfach per Mail an.
alexander.fuchs"at"n-g-i-s.com

Grüsse aus Murrhardt

Alex
Bitte warten ..
Mitglied: MysticFoxDE
14.01.2020, aktualisiert 28.01.2020
Moin Zusammen,

kleines Update zu unserem Problemchen, aber ich muss mich kurz fassen, hatte gestern schon 18 Stunden auf dem Tacho und heute sind es wieder nicht weniger ... 😩🥱

Aber zurück zum Thema, ich habe gestern zu 99,9% den waren Grund für das ganze Schlamassel gefunden.
Zusammenfassend, es liegt nicht an Intel, sondern an einer signifikanten Änderung des TCP-Stacks seitens Microsoft.
Stichworte: CongestionProvider, CUBIC ...

Mehr Details siehe auch ...
Server 2019 network performance
etwa in der Mitte, siehe 5 blaue Screenshots.

Nun habe ich auf die Kürze eine gute und eine schlechte Nachricht.

Die gute Nachricht zuerst:
Bei einem 2019er Server lässt sich das Problem sehr einfach beheben.
Einfach das folgende in PowerShell reinklopfen, 2019er Server durchbooten und schon ist die Netzwerkperformance genau so gut wie beim 2016er. 😀



Habe gestern das erste 2019er System von CUBIC auf CTCP zurückgestellt.
Das heutige Feedback des Kunden: Heute lief alles wieder genau so schnell wie vor der Umstellung auf 2019. 😊

Das zweite 2019er System bei einem anderen Kunden wird noch diese Woche umgestellt, bei aller Euphorie möchte ich dennoch vorsichtig vorgehen.

Bitte um weitere Unterstützung um den Lösungsansatz zu untermauern, danke.

Nun kommen ich zu der schlechten Nachricht.
Den Gleichen Bockmist hat Microsoft auch beim Windows 10 ab Version 1709 geschossen.
Dort lässt sich das Ganze stand jetzt jedoch nicht rückgängig machen. 😡

So nun muss ich aber dringend die Schaffe zählen gehen ...

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: Assassin
28.01.2020 um 15:54 Uhr
Servus Alex, muss man diese Befehle für jede VM einzeln setzen, oder muss das nur auf dem HyperV Host selber gemacht werden?
Bitte warten ..
Mitglied: MysticFoxDE
28.01.2020, aktualisiert um 19:11 Uhr
Moin Assassin,

das Skript kannst du auf JEDEM Server 2019 aufführen, die sind alle egal ob mit oder ohne Hyper-V mit CUBIC verseucht. 🤪

Gruss Alex
Bitte warten ..
Mitglied: MysticFoxDE
28.01.2020 um 19:18 Uhr
Moin Zusammen,

bevor ich es vergesse, habe auch bei Windows 10 einen Weg gefunden den CUBIC Zahn zu ziehen. 😁

THE HOLLY WINDOWS 10 NO CUBIC SCRIPT
(mit Adminrechten ausführen)

Und der Vollständigkeit halber noch das retour Script

WINDOWS 10 CUBIC BACK SCRIPT 😱
(mit Adminrechten ausführen)
Würde mich über ein Feedback freuen.

Grüsse aus Sigmaringen

Alex
Bitte warten ..
Mitglied: Assassin
27.02.2020 um 14:08 Uhr
Servus, ich nochmal :D
Du hast bei Spiceworks in deinem Script das hier mit drin:
#NATIVE2019, HV2019, VM2019
#netsh int tcp show global
netsh int tcp set global RSS=Disabled
netsh int tcp set global RSC=Disabled


bei RSC gehe ich ja noch mit, das ist die allgemeine Empfehlung von Intel das auszuschalten...aber RSS bei einer 10G Karte? Dann würde ja alles nur noch über eine CPU Core gehen und das ganze auf 4Gbs eindampfen (cpu limit) oder hat das nichts mit dem RSS was man im Karten-Treiber einstzellen kan, zutun?
Bitte warten ..
Mitglied: MysticFoxDE
01.03.2020, aktualisiert um 08:54 Uhr
Moin Assassin,

sorry fürs Delay, war die letzten Wochen etwas Land unter.

bei RSC gehe ich ja noch mit, das ist die allgemeine Empfehlung von Intel das auszuschalten...aber RSS bei einer 10G Karte? Dann würde ja alles nur noch über eine CPU Core gehen und das ganze auf 4Gbs eindampfen (cpu limit) oder hat das nichts mit dem RSS was man im Karten-Treiber einstzellen kan, zutun?

Wir kommen gleich zur Sache, aber generell eines vorweg. Ja die ganzen Optimierungsfeatures alla RSC, RSS, SR-IOV, VMQ & Co. KG sollten laut der Theorie und vielleicht auch einigen Laborumgebungen eine bessere Performance bringen. Nur ist das mit der Theorie halt so eine Theorie und die Praxis ist eben die Praxis. In dieser bring der vorher erwähnte Mist, überwiegend nur Probleme mit sich, da so gut wie kein Normalsterblicher ein Labor betreibt. Die Meisten haben eher eine historisch gewachsene Umgebung.

So jetzt aber genug Philosophiepallaber ... 🤪

Ja, ich habe auch von dieser Einschränkung gehört, kann diese jedoch nicht ganz nachvollziehen.

Ich spiel das mal auf einem 2019er HV-Cluster eines unserer Kunden durch und verwende dazu einen der Clusterlinks, die über 10G laufen.
Dieses HV Cluster ist bereits mit allem optimiert was ich kenne, NO RSS, NO RSC, NO CUBIC, NO SR-IOV, VO VMQ, u.s.w. ...

10g - Klicke auf das Bild, um es zu vergrößern

Wie du siehst, kann ich den 10G Link auch ohne RSS und selbst mit einem "Singletask", fast zu 100% auslasten. 😉

---

Ich finde RSS generell nicht schlecht, jedoch ist vielen gar nicht bewusst, dass dieses gar nicht so einfach in Betrieb zu nehmen ist.
RSS ist zwar per default mittlerweile auf jeder NIC aktiviert, jedoch ist es mit den Standardeinstellungen, auf so gut wie jedem System mit mehr als einer NIC, störend bis unbrauchbar. Je mehr NICs man in einem System betreibt, umso granularer muss auch das RSS konfigurieren werden.
Die richtige Konfiguration hängt aber nicht nur von der Anzahl der NICs ab, sondern auch von der Anzahl, der auf diesem System verfügbaren CPU Kerne, der NUMA's, u.s.w.. Auf die Feinheiten kann ich aus Zeitmangel jetzt aber nicht eingehen, später vielleicht.

Unter dem Strich kann man sagen, umso grösser das System, umso komplexer ist auch die richtige RSS Konfiguration.
Hat man sich einmal die Mühe gemacht alles richtig einzustellen, so ist das keineswegs ein Grund zur langfristigen Freude.
Die Konfiguration fliegt schon mal gerne bei dem eine oder anderen MS oder NIC-Driver Update um die Ohren und man muss ales wieder neu einrichten. Kann da Bände dazu schreiben ... 😞

Ich habe bei aktiviertem und richtig konfiguriertem RSS, noch nie einen positiven Effekt beim Enduser erzielen können, das Gegenteilige jedoch schon oft genug. Bei deaktiviertem RSS hatte ich hingegen noch nie Stress und wie du oben siehst auch nicht wirklich einen Performancenachteil dadurch.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: Assassin
08.03.2020 um 08:07 Uhr
Welche NIC hattest du da aber im einsatz? eventuell eine mit RDMA /iWARP technik?

Wir haben hier ein paar Intel X550-T2 10G karten, die haben kein iWARP...wenn ich da RSS deaktiviere, läuft der gesammte Trafic über einen Kern der beiden 16 Core CPUs, und das capt bei 400MB/s.
RSS arbeitet richtig bei mir, da ich es - wie du schon sagtest - konfiguriert habe, also jeden adapter der über RSS arbeitet entsprechende Cores zugeordnet habe, dem nächsten adapter auch Cores aber andere,...


Wie gesagt, ich denke bei einer 10G karte sollte man das RSS nicht deaktivieren, aber ja, es sollte konfiguriert werden. Eigentlich sollte Server2019 das automatisch und dynamisch machen, also die Cores zuordnen...naja
Wenn die karte aber RDMA hat, und die Server worauf man kopiert oder wovon man was zieht ebenfalls, dann kann man RSS deaktivieren...
Bitte warten ..
Mitglied: MysticFoxDE
08.03.2020 um 08:58 Uhr
Moin Assassin,

Welche NIC hattest du da aber im einsatz? eventuell eine mit RDMA /iWARP technik?

Ohne jetzt nachgeschaut zu haben, es sind glaube ich 4x2xX722. RDMA ist deaktiviert.

Wir haben hier ein paar Intel X550-T2 10G karten, die haben kein iWARP...wenn ich da RSS deaktiviere, läuft der gesammte Trafic über einen Kern der beiden 16 Core CPUs, und das capt bei 400MB/s.

🤔, bei dem letzten System an dem ich das getestet habe, konnte ich mich nicht so richtig austoben, weil ich nur ein relativ kurzes Wartungsfenster hatte und dieses eigentlich nicht für Performancetests vorgesehen war.
Wir assemblieren in 1-2 Wochen ein neues, sehr potentes HV-Cluster (4 Nodes, je 2 x Xeon Gold 6254 & 1TB RAM & 4x10G).
Sobald dieses fertig ist, werde ich das Thema RSS mit diesem penibelst durchtesten und berichten.


RSS arbeitet richtig bei mir, da ich es - wie du schon sagtest - konfiguriert habe, also jeden adapter der über RSS arbeitet entsprechende Cores zugeordnet habe, dem nächsten adapter auch Cores aber andere,...

das verstehen und machen nur wenige, 👍👍👍, Kompliment und Anerkennung.

---

Generell ist mir der Maximaldurchsatz aber nicht ganz so wichtig wie eine konstant niedrige Latenz, davon haben die User meistens mehr als vom Durchsatz.

Gruss Alex
Bitte warten ..
Mitglied: Assassin
10.03.2020 um 15:41 Uhr
Ich bevorzuge beides :D


wegen der RSS und VMQ einstellung habe ich mir das hier erabeitet :

Set-NetAdapterVmq -Name "10G LAN Slot 03 Port 1 - VM NicTeam" -BaseProcessorNumber 2 -MaxProcessors 4 -MaxProcessorNumber 8 -NumaNode 0
Set-NetAdapterVmq -Name "10G LAN Slot 07 Port 1 - VM NicTeam" -BaseProcessorNumber 34 -MaxProcessors 4 -MaxProcessorNumber 40 -NumaNode 1

Set-NetAdapterVmq -Name "Onboard LAN Port 1 - andere Netze NicTeam" -BaseProcessorNumber 18 -MaxProcessors 1 -MaxProcessorNumber 18 -NumaNode 0
Set-NetAdapterVmq -Name "Onboard LAN Port 2 - andere Netze NicTeam" -BaseProcessorNumber 20 -MaxProcessors 1 -MaxProcessorNumber 20 -NumaNode 0

Set-NetAdapterRss -Name "10G LAN Slot 03 Port 2 - LiveMigration1 + FE" -BaseProcessorNumber 10 -MaxProcessors 4 -MaxProcessorNumber 16 -NumaNode 0
Set-NetAdapterRss -Name "10G LAN Slot 07 Port 2 - LiveMigration2 + FE" -BaseProcessorNumber 42 -MaxProcessors 4 -MaxProcessorNumber 48 -NumaNode 1

Set-NetAdapterRss -Name "Onboard QuadLAN Port 1 - Management NicTeam" -BaseProcessorNumber 22 -MaxProcessors 1 -MaxProcessorNumber 22 -NumaNode 0
Set-NetAdapterRss -Name "Onboard QuadLAN Port 2 - Backup NicTeam" -BaseProcessorNumber 24 -MaxProcessors 1 -MaxProcessorNumber 24 -NumaNode 0
Set-NetAdapterRss -Name "Onboard QuadLAN Port 3 - Cluster Communication" -BaseProcessorNumber 26 -MaxProcessors 1 -MaxProcessorNumber 26 -NumaNode 0
Set-NetAdapterRss -Name "Onboard QuadLAN Port 4 - Management NicTeam" -BaseProcessorNumber 28 -MaxProcessors 1 -MaxProcessorNumber 28 -NumaNode 0

Disable-NetAdapterRsc "Onboard QuadLAN Port 2 - Backup Netz" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard QuadLAN Port 1 - Management NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard QuadLAN Port 4 - Management NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard QuadLAN Port 3 - Cluster Communication" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 03 Port 1 - VM NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 07 Port 2 - LiveMigration2 + FE" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 07 Port 1 - VM NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "10G LAN Slot 03 Port 2 - LiveMigration1 + FE" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard LAN Port 1 - andere Netze NicTeam" -IPv4 -IPv6
Disable-NetAdapterRsc "Onboard LAN Port 2 - andere Netze NicTeam" -IPv4 -IPv6

Set-VMSwitch -Name "VM NicTeam (extern)" -EnableSoftwareRsc $false
Set-VMSwitch -Name "andere Netze (extern)" -EnableSoftwareRsc $false


das RSC zu deaktivieren, wird ja von Intel empfohlen wenn man VMQ nutzt (also das RSS für VMs sozusagen)
quelle: https://downloadmirror.intel.com/28396/eng/readme.txt
erster punkt bei Known Issues



Die wenigstens scheinen aber zwei 10G Ports zu Teamen für um den Potenten vSwitch dann an die VMs weiterzugeben...aber warum? Ich meine, unser Cluster hat 18 VMs im einsatz, ich kann mir nicht vorstellen, das alle VMs nur mit einer einzelnen Netzwerkkarte mit dem gesammten Netzwerk agieren sollen. Loadbalancing ist da schon nicht schlecht denke ich. Klar wird da nicht ständig mit 10G daten umhergeschaufelt - wobei das manchmal schon vorkommt, da einige Poweruser die große zeichnungen haben oder Videos - auch mit 10G angebunden sind am 10G Switch.
Bitte warten ..
Mitglied: MysticFoxDE
10.03.2020 um 20:08 Uhr
Moin Assassin,

dein Script ist auch sehr interessant, vielen Dank dafür.

Die wenigstens scheinen aber zwei 10G Ports zu Teamen für um den Potenten vSwitch dann an die VMs weiterzugeben...aber warum?

Gute Frage ...

40gb - Klicke auf das Bild, um es zu vergrößern


40gb_2 - Klicke auf das Bild, um es zu vergrößern

🙃

Gruss Alex
Bitte warten ..
Mitglied: Assassin
11.03.2020 um 07:07 Uhr
so lob ich mir das, kann nie schnell genug sein :D


Was hälst du von SET Teaming im vergleich zum LBFO Teaming? Wird ja hier und da empfohlen das Team als SET einzurichten über die Powershell...ich vermisse da aber die LACP möglichkeit damit auch eingehend ein loadbalancing möglich ist...
Bitte warten ..
Mitglied: MysticFoxDE
22.03.2020, aktualisiert um 10:19 Uhr
Moin Assassin,

Was hälst du von SET Teaming im vergleich zum LBFO Teaming?

ist grundsätzlich sehr interessant, habe mich aber in der Tiefe noch nicht zu sehr damit beschäftigt.
Ich habe vor ein paar Monaten, bei einem der Systeme die von dem Netzwerk-Performanceproblem betroffen waren, mal das Teaming testweise auf SET umgestellt, jedoch keinerlei Veränderung damit erzielt.

Wird ja hier und da empfohlen das Team als SET einzurichten über die Powershell...ich vermisse da aber die LACP möglichkeit damit auch eingehend ein loadbalancing möglich ist...

Wenn ich die Materie auch nur halbwegs richtig verstanden habe, dann ist das durchaus möglich.
Du musst dafür aber den LoadBalancer des SET's auf "Dynamic" stellen.


Aber wie gesagt, so tief stecke ich da noch nicht in der Materie.
Die genaue Erforschung dieser, steht auf der ToDo Liste beim nächsten System drauf. 😉

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: MysticFoxDE
04.04.2020, aktualisiert um 09:41 Uhr
Moin Assassin,

Wir haben hier ein paar Intel X550-T2 10G karten, die haben kein iWARP...wenn ich da RSS deaktiviere, läuft der gesammte Trafic über einen Kern der beiden 16 Core CPUs, und das capt bei 400MB/s.
RSS arbeitet richtig bei mir, da ich es - wie du schon sagtest - konfiguriert habe, also jeden adapter der über RSS arbeitet entsprechende Cores zugeordnet habe, dem nächsten adapter auch Cores aber andere,...

habe dir ja versprochen das RSS Thema im Auge zu behalten und das habe ich nicht vergessen.

Ich bin gerade dabei eine Review für ein sehr flitziges Infortrend NAS vorzubereiten und bin dabei auf eine Kuriosität gestossen, die ich absolut nicht erklären kann.

https://community.spiceworks.com/topic/2265556-mystical-loadbalancing-by ...

Auch der 2nd Level des Herstellers ist bisher ratlos.
Noch ein paar wichtige Details zu der Workstation. In dieser sind zwei unterschiedliche 10G NIC’s verbaut. Onboard sitzt eine Aquantia NIC zusätzlich ist noch eine Intel X711-T4 verbaut.

OS: Windows 10 Enterprise 1909 (Build 18363.752)
Treiberversion Aquantia: 2.1.018.0
Treiberversion Intel: 25.0.0.0

Nun zu meinen bisherigen Feststellungen:

RSC:

Bei der Aquantia NIC lässt sich RSC wie gewohnt über GUI oder Power-Shell abschalten.

aquantia rsc - Klicke auf das Bild, um es zu vergrößern

Wohingegen bei der Intel NIC unter Windows 10 von RSC weit und breit absolut nichts zu sehen ist.

x710 no rsc - Klicke auf das Bild, um es zu vergrößern

Warum ist bei der Intel NIC unter Windows 10 kein RSC verfügbar?

Die Aquantia NIC unterstützt RSC und der TCP-Stack von Windows 10 per Default (leider 🤢) auch.
Beiden habe ich bei meinem jetzigen Aufbau sicherheitshalber nach der Installation sofort den RSC-Milchzahn 🙃 gezogen.

RSS:
Hier wird es noch lustiger oder trauriger, je nach Betrachtungswinkel.

Bei der Aquantia NIC kann ich noch am meisten einstellen.

aquantia rss - Klicke auf das Bild, um es zu vergrößern

Genau zwei Optionen RSS ein oder aus und die Queues.

Bei der Intel NIC gibt’s nur eine Einstellmöglichkeit …

x710 rss - Klicke auf das Bild, um es zu vergrößern

RSS ein oder RSS aus, that‘s it. 😮

Ich kann das Limit mit den 400 MB/s auf der W10 Maschine übrigens 1A nachvollziehen.
Wenn ich RSS deaktiviere so kommen die NICs nicht über ~4GBit/s hinaus.
Ich werde die Tage den Test auf dem Server auf jeden Fall wiederholen, dort hatte ich trotz deaktiviertem RSS wie schon geschrieben keine derartige Limitierung feststellen können. 🤔

Auf jeden Fall läuft RSS auf meiner Workstation trotz der wenigen Einstellmöglichkeiten bisher absolut ohne Probleme.

Nun drängt sich mir die folgende Frage auf.

Warum funktioniert auf Windows 10 RSS mit fünf 10G NICs und nur wenigen Einstellmöglichkeiten per Default bestens, während dieses auf den Servern, selbst bei einer Bestückung mit nur einer 10G NIC nur durch komplexe Konfiguration von diversen Parametern möglich ist?

@ Microsoft, Moin, die geht hauptsächlich an Euch. 😉
Kleiner Tipp an dieser Stelle, Weniger ist manchmal eben doch Mehr.

Grüsse aus BaWü

Alex
Bitte warten ..
Mitglied: Assassin
06.04.2020 um 20:24 Uhr
Ja ohne RSS wird man bei 400MB/s gecapt sozusagen - wegen der CPU. Warum es bei deinem Server trotzdem mit 10Gb/s übertragen hat kann ich dir nicht sagen - entweder RSS war nicht wirklich aus, oder es lief über SMB Multichannel was du ja jetzt auch entdeckt hast...doch auch das SMB3.0 Feature (Multichannel, gibts ein Windows 8) hat auch so seine tücken musste ich feststellen
https://www.mcseboard.de/topic/217424-smb-multichannel-nutze-nur-2-von-4 ...

egal wieschnell welche Netzwerkkarte angebunden ist, es werden immer die mit RDMA bevorzugt behandelt - da muss MS dringend nachbessern und vieleicht auch mal prüfen wieschnell die RDMA fähige karte angebunden ist, und ob es nicht doch andere NICs gibt, die deutlich schneller angebunden sind. Ich weiß zwar trotzdem noch nicht warum es bei mir diese einbrüche gibt, aber gut, das könnte was mit dem Raidcontroller zutun haben...auch wenn der in der zeit wo er schnell kopiert deutlich mehr daten transferriert hat, als in den Controller cache passen würde...
Bitte warten ..
Ähnliche Inhalte
Hyper-V

Hyper-V 2016 auf Datacenter 2019 aktualisieren

gelöst Frage von KnorkatorHyper-V4 Kommentare

Hallo zusammen, bisher haben wir hier auf 2 Servern den kostenfreien Hyper-V Server 2016 eingesetzt. Wir haben uns nun ...

Windows Server

Hyper-V 2016 - CPU auf Gast-Betriebssystem optimieren

Frage von hijacker99Windows Server6 Kommentare

Hallo zusammen Ich habe hier einen Hyper V Server, wo ich ein Gast-OS habe, deren DB-Applikation nur begrenzt Hyperthreading-tauglich ...

Netzwerke

Hyper-V Gast Netzwerkverlust

gelöst Frage von Florian961988Netzwerke8 Kommentare

Hallo ich habe einen Windows 2012 R2 Server mit installierter Hyper-V - Rolle, dort habe ich einen FileServer angelegt ...

Hyper-V

Grafikkartenzuweisung zu einer Hyper-V-VM 2016 vs 2019

Frage von DerWoWussteHyper-V19 Kommentare

Moin. Ich hoffe hier Leute zu finden, die Direct Device Assignment erfolgreich durchgeführt haben und derzeit nutzen. Wenn Ihr ...

Neue Wissensbeiträge
E-Books

Ausgewählte Rheinwerk-Bücher jetzt online lesen! Kostenfrei

Information von Maxima2005 vor 7 StundenE-Books1 Kommentar

Vielleicht hat ja jemand Interesse sein Wissen zu erweitern. Ausgewählte Rheinwerk-Bücher jetzt online lesen! Grüße Max

Instant Messaging
Jitsi Meet - April Update verfügbar
Information von Frank vor 9 StundenInstant Messaging3 Kommentare

Im Rahmen des April-Updates erhält Jitsi Meet mehrere interessante Features. Anwender können nun nicht mehr nur ihren Bildschirm, sondern ...

Rechtliche Fragen

Rechtliche Grundlagen: Datenschutz und Datensicherheit im Homeoffice

Information von AnkhMorpork vor 1 TagRechtliche Fragen

Sollte bekannt sein, aber

Router & Routing
"Upgrade" Fritte 7520 zu Fritte 7530 :-)
Information von Lochkartenstanzer vor 1 TagRouter & Routing6 Kommentare

Moin, wie sich herausgestellt hat, ist die 7520 eine per Software kastrierte Version der 7530. Per "Chiptuning", um es ...

Heiß diskutierte Inhalte
Rechtliche Fragen
Nachweispflicht für Status-Emails?
Frage von VincentGdGRechtliche Fragen36 Kommentare

Moin. Mein Kollege und Datenschutzbeauftragter erfreut mich täglich mit neuen Auslegungen. Heute erklärt er mir, wir müssen die Status-Emails, ...

Server-Hardware
Wie viel Speicher braucht eine Wissensdatenbank für bis zu 50 User?
Frage von Mrhallo19981Server-Hardware36 Kommentare

Hallo, könnt ihr mir sagen wieviel Speicherplatz eine Wissensdatenbank braucht (die physikalisch speichert, also nicht mit einer Datenbank zusammen) ...

Festplatten, SSD, Raid
Festplatten Datenvernichtung Server
Frage von survial555Festplatten, SSD, Raid29 Kommentare

Hallo, ich habe noch ein paar alte Server, wo ich die verbauten Festplatten gerne datentechnisch "sicher" löschen möchte. Leider ...

Linux
Internetprobleme mit Wine für Linux um .exe Dateien auszuführen
Frage von WinLiCLILinux22 Kommentare

Hallo zusammen, ich möchte auf meinem debian 10 einen client für cloud-telefonie (cloud pbx) installieren, den es nur für ...