Windows 10 / Server 2019: Langsames Netzwerk– bei Hyper-V-Gästen und Bar-Metal-Clients

[English]Ein Blog-Leser hat mich auf ein Problem bei Windows 10 und Windows Server 2019 in Bezug auf eine schlechte Performance im Netzwerkbetrieb (geringer Durchsatz) in Verbindung mit Hyper-V-Gästen (aber auch auf Windows 10-Clients ohne Virtualisierung) hingewiesen. Grund ist eine Änderung Microsofts am TCP-Stack, der Probleme verursacht. Ich bereite das man in einem Beitrag auf, denn es gibt eine einfache Lösung in Form von PowerShell-Scripten.


Anzeige

Blog-Leser Flying Sorcerer schrieb mich die Tage per E-Mail an, um das Thema anzusprechen (danke dafür).

Da ich es bisher sonst nirgendwo gefunden habe, mal ein Hinweis dazu.
Ein Kollege hat mich am Wochenanfang auf Probleme mit Server 2019 und Hyper-Gästen im Bereich Netzwerk angesprochen.

Nach einer etwas längeren Suche bin ich auf  zwei Threads gestoßen.
Microsoft hat in Server 2019 und Windows 10 ab 1709 ziemlich Bockmist geschossen…

Der Blog-Leser hat mir dann verschiedene Links mit Fundstellen im Web zukommen lassen, die sich mit dem geringen Netzwerkdurchsatz bei Hyper-V-Gästen auf den genannten Betriebssystemplattformen beschäftigen.

Dieses Problem gibt es mit Hyper-V-Gästen

Wird ein Gast-Betriebssystem unter Microsofts Virtualisierungslösung Hyper-V auf einem Host mit Windows 10 (ab Version 1709) oder Windows Server 2019 aufgesetzt, ist der Netzwerkdurchsatz für die Hyper-V-Gäste arg bescheiden. Auf administrator.de hat jemand das bereits im Frühjahr 2019 mit folgender Beschreibung aufgegriffen. Ich bereite die Buchstabenwüste mal ein wenig auf:

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 Außenwelt.

Zwischen den VMs 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 […].

Zu den physischen Computern nach außen 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 Betroffene hat einiges im Labor getestet, und sein Fazit lautet: Sobald auf dem Host ein Server 2019 als Hyper V läuft, und in einer VM die Gäste kein Windows Server 2019 sind (er hat es mit Windows Server 2016 und Windows Server 2008 R2 getestet) ist die Netzwerkanbindung dieser VM über die onBoard NIC Intel X722 nach außen extrem langsam. Die CPU-Leistung steigt aber auch nicht an, es gibt keine Fehlerpakete am Hardware Switch, aber es kommt kein Netzwerkdurchsatz zustande.

Temporäre Lösung: Separate PCIe NIC

Der Betroffene hat dann das Problem temporär gelöst, indem er eine weitere separate physische PCIe NIC (eine einfache Intel i210) auf dem Host eingebaut hat. Diese Netzwerkkarte hat er an einen Hyper-V-Switch gebunden und lässt alle VMs mit ihren Gästen Netzwerk-mäßig über diesen Switch laufen. In diesem Szenario ist der Netzwerkdurchsatz wie gewünscht.

Ein zweiter Fall aufbereitet

Der Blog-Leser wies mich auf darauf hin, dass hat ein anderer Betroffener Mitte Januar 2020 diese Problematik mit grafisch aufbereiteten Netzwerkmessungen auf Spiceworks dokumentiert hat. Es wurde sehr viel getestet und dokumentiert. Nachfolgende Abbildung zeigt ein Protokoll des Netzwerkdurchsatzes.

Netzwerk-Durchsatz Hyper-V Gast
(Source: Spicework)

Dann ist der Betreffende auf die glorreiche Idee gekommen, auf dem Server und auf dem Client das Virtual Receive Side Scaling (vRSS) zu deaktivieren. Dann hat er auf dem Windows Server 202012 noch das Receive Segment Coalescing (RSC) deaktiviert. Und plötzlich kam er beim Netzwerkdurchsatz zwischen Hyper-V-Gästen und dem Host auf die erwarteten Werte.


Anzeige

In weiteren Schritten kam er dann darauf, wie er in Windows Server 2019 (und Windows 10) als Hyper-V-Host den Netzwerkdurchsatz optimieren kann. Das Problem liegt an einer signifikanten Änderung des TCP-Stacks seitens Microsoft (Stichworte: CongestionProvider, CUBIC, siehe auch diesen Spiceworks-Post mit den PowerShell-Ausgaben).

Lösung per PowerShell Script

Nach vielen Tests hat der Betroffene ein Powershell-Script mit dem Titel “THE HOLY NGIS VM-WS2019 NETWORK BACK OPTIMIZATION SCRIPT V1.0” geschrieben und auf Spiceworks veröffentlicht (eine abgespeckte Fassung findet sich bei administrator.de).

Das Script ist über Als Administrator ausführen auf dem als Host fungierenden Windows Server 2019 zu starten. Es setzt diverse Einstellungen des Netzwerks zurück, so dass die Mechanismen Microsofts nicht mehr greifen. Der Netzwerkdurchsatz erreicht danach die gewünschte Geschwindigkeit.

Der Ersteller merkt an, dass man das nicht in laufenden Produktivumgebungen nutzen solle. Denn durch das PowerShell-Script wird der NIC neu gestartet. Daher ist ein Neustart des Servers erforderlich, um alle Änderungen wirksam werden zu lassen. Das möchte man aber in einer produktiven Windows Server-Umgebung eher nicht. Beachtet auch diesen Post eines Microsoft-Vertreters mit Zusatzhinweisen.

Es trifft auch Windows 10-Maschinen ohne Hyper-V

In einem Nachtrag merkt der Blog-Leser an, dass dieses Netzwerkdurchsatzproblem durch den ‘optimierten TCP-Stack auch einfache Windows 10-Clients ab Version 1709 betrifft. Er schreibt dazu:

Wir hatten hier den Fall das wir von Client zu Client mit 80 KB (!!!) Daten kopiert haben, nach Ausführung des PowerShell-Scriptss von Administrator.de (also die Windows 10 Fassung) mit 80 MB….

Das Script im englischen Forum ist für Server 2019 (Server, Hyper-V und Gäste), das im deutschen Forum für Windows 10.

Ein PowerShell-Script für Windows 10-Hosts, welches das Problem löst, wurde von Nutzer MysticFoxDE auf administrator.de veröffentlicht. Mein Dank an den Blog-Leser für den Hinweis. Vielleicht hilft er dem einen oder anderen Server-Administrator oder genervten Windows 10-Power-Nutzer weiter.

Ähnliche Artikel:
Patchday: Windows Server 2008 R2 bootet in Recovery
Windows Server 2012 geht in Update-Schleife
Pending Update Problem mit Windows Server 2012 Standard
Windows Server: Schwachstelle CVE-2020-0609 im Remote Desktop Gateway
Windows Server 2016: Chaos bei Freigaben, Ordnern und Berechtigungen?
Windows Server 2008/R2: In-place-Upgrade-Beschreibung aktualisiert (6.1.2020)
Windows Server 2016: Fehler in den Benutzerprofil-Sicherheitsberechtigungen
Windows Server 2019 Referenz-Abbild erstellen
Windows Server 2008 R2 und ein WSUS SHA-2-Problem
Windows Server 2008 R2: Update KB4503269 bringt Sync-Fehler bei TS-Profilen
Windows Server 2016: Lange Patch-Zeiten für Updates–Microsoft sieht keinen Handlungsbedarf


Anzeige


Dieser Beitrag wurde unter Netzwerk, Virtualisierung, Windows 10 abgelegt und mit , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

6 Antworten zu Windows 10 / Server 2019: Langsames Netzwerk– bei Hyper-V-Gästen und Bar-Metal-Clients


  1. Anzeige
  2. Michel Py sagt:

    Hatte kürzlich so ein Fall auf ein Windows Server 2012 R2 mit Hyper-V und Broadcom Netzwerkkarte.
    Physiche Server hatte ein gute Netzwerk Durchsatz. Alle VMs hatten katastrophale Durchsatz !
    Nach ein bisschen googeln war es klar das die Netzwerkkarten Treiber die mit Windows gekommen sind schuld waren. Entweder konnte man solche tiefe Einstellungen machen, oder einfach aktuelle Treiber vom Server Hersteller herunterladen. Es gab sogar ein Microsoft Artikel darüber.
    Eine Firma die sich mit Hyper-V sehr gut auskennt, mit blog und gratis Webinars auf Deutsch: https://www.hyper-v-server.de/

  3. oli sagt:

    Hm, wir haben ja auch einen Server 2019 als Hyper-V Host laufen und konnten keinerlei Probleme feststellen. Wir haben 2x I210 1Gb-NICs und 2x X710 10Gb-NICs laufen. Die 2x1Gb sind 1x fürs Management und 1x für einen normalen Hyper-V Switch, wo eine Linux-VM dran läuft. Die beiden 10Gb NICs sind per Switch Embedded Teaming (SET) zu einem weiteren Hyper-V Switch zusanmengeschlossen und da sind quasi alle restlichen VMs (Windows Server 2019, Windows Server 2012, Windows 10 LTSC 2019) dran angeschlossen. Alle Windows-Clients können problemlos mit full 1Gb-Speed ihre Daten per SMB übertragen. Sind SET-Switche evt. nicht betroffen?

    • Hi Oli,
      das Problem hat nichts mit SET-Switchen zu tun.

      Wir haben bei den meisten Kunden dieselbe Hardware verbaut, OK die CPU, RAM und SAN Bestückung variiert aber die Chassis und die darin verbauten NICs sind immer dieselben und auch die Konfiguration der HV Cluster ist bei den meisten sehr identisch. Nun haben wir Systeme, die ohne jegliche Optimierung absolut störungsfrei arbeiten und ein absolut gleiches System bei einem anderen Kunden kommt ohne Optimierung absolut nicht vorwärts. Ich habe selbst bei einer Installation eines neuen Systems eine ganz komische Erfahrung gemacht. Nach der ersten Installation lief der Server absolut bescheiden, 20-30 MB/s SMB Performance über X710 mit 1G Uplink. Dann habe ich den Server einfach erneut installiert und hatte danach keine Probleme mehr, obwohl ich 1:1 alles gleich gemacht habe, wie auch bei der ersten Installation.

      Ferner fällt das Problem anscheinend nicht allen (Admins) sofort auf. Ich hatte vor ein paar Wochen Kontakt zu einem Admin, der das Problem erst realisiert hat, nachdem er durch Zufall den Artikel bei Spiceworks gelesen hat und erst im Anschluss sein eigenes System durchgetestet hat. Dabei hat er festgestellt, dass auch sein System von den Problemen betroffen ist und auch die im Nachgang befragten User bestätigten, dass die Applikationen seit Monaten etwas langsamer laufen. Auf die Frage warum die das nicht gleich gemeldet haben, kam nur, “Jo, war zwar langsamer aber es lief ja noch alles”.
      Die Firma hat auf jeden Fall sehr entspannte User. 🙃

      Grüsse aus BaWü

      Alex

  4. Anzeige

  5. 1ST1 sagt:

    Das könnte auch mein Netzwerkproblem mit einer Thunderbold-Dockingstation erklären. Da dauerte auf einmal die Herstellung der LAN-Verbindung ewig (Status “Netzwerkerkennung” über 2-3 Minuten…). Treiberupdates (Realtek, Thunderbold) und Firmware-Updates (Thunderbold, Notebook-BIOS) halfen. Datendurchsatz ist jetzt auch wieder höher.

  6. Moin Günter,
    es ist mir eine grosse Freude, dass du diesen leidigen Punkt in deinem Blog auch thematisierst.

    Ich habe mittlerweile noch ein weiteres Problemkind gefunden, welches auf dem 2019er Server vermehrt zu Performanceproblemen führt, der Windows Defender. Das Problem lässt sich beim Server 2019 relativ einfach lösen.

    PowerShell als Admin starten und den folgenden Befehl reinklopfen.

    Remove-WindowsFeature -Name “windows-defender”

    Was das Windows 10 Thema angeht, so sind die bisherigen Optimierungsscripte alla „THE HOLLY WINDOWS 10 NO CUBIC SCRIPT“ eher rudimentär. Hier habe ich bei weitem noch nicht so viel zurückoptimiert wie bei den Scripten für den 2019er Server, habe aber aktuell auch keine Zeit dafür.
    Das Thema hat mich die letzten 12 Monate bereits > 80 Manntage an Forschung gekostet, die ich bisher auf eigenen Schultern tragen muss. Das ist für ein kleines Systemhaus wie wir es sind, schon ein ganz schöner Brocken. 😩

    Grüsse aus BaWü

    Alex
    (MysticFoxDE)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.