Einleitung
Dieser Leitfaden richtet sich an Fachinformatiker Systemintegration, die bei virtuellen oder physischen Windows-Fileservern wiederkehrende Performance-Engpässe sehen, obwohl Hardware, Virenschutz, DNS und Storage bereits überprüft wurden. Im Fokus stehen zwei Stellschrauben der Netzwerk-Subsysteme:
- Auslagerungs- und Offload-Funktionen der Netzwerkkarten (Large Send Offload, RSC usw.)
- Receive Segment Coalescing (RSC) im Hyper-V-vSwitch
Die folgenden Schritte helfen, Bandbreite und Latenz zu optimieren und gleichzeitig CPU-Last und Paketverluste im Griff zu behalten.
1 Ausgangskontrolle
| Prüfschritt | Befehl / Werkzeug | Erwartung |
|---|---|---|
| Aktuelle Netzwerktreiber | devmgmt.msc → Netzwerkkarte → Treiberdatum | nicht älter als 12 Monate |
| Offload-Status | Get-NetAdapterAdvancedProperty |
Übersicht aller Offload Flags |
| Hyper-V-vSwitch-Status | Get-VMSwitch |
Spalte EnableSoftwareRsc |
Wenn schon hier Unstimmigkeiten auftauchen, zuerst Treiber aktualisieren oder Firmware anheben.
2 Hintergrund: Warum Offload manchmal bremst
Large Send Offload (LSO) und Receive Segment Coalescing (RSC) verlagern Teile der TCP-Segmentierung vom CPU-Stack auf den Netzwerkkontroller. Auf Bare-Metal-Servern mit neuer Hardware steigert das oft den Durchsatz. In virtuellen Umgebungen addiert sich jedoch eine zweite Virtualisierungs-Schicht: Hyper-V muss die Jumbo-Frames erst wieder zerlegen, bevor sie in der VM ankommen. Dadurch kann die CPU-Last sinken, während Latenzen steigen. Microsoft beschreibt diese Zusammenhänge ausführlich im Performance-Tuning-Leitfaden für Netzwerkkarten (learn.microsoft.com).
3 Schritt für Schritt: Offload im Gast und Host abschalten
3.1 Physische Intel- oder Broadcom-NIC auf dem Hyper-V-Host
- Gerätemanager öffnen (
devmgmt.msc). - Zugriff auf Netzwerkadapter und physische Karte doppelklicken.
- Reiter Erweitert wählen.
- Folgende Einträge auf Deaktiviert setzen:
- Large Send Offload V2 (IPv4)
- Large Send Offload V2 (IPv6)
- Übernehmen, kurz testen (Ping und SMB-Copy).
Messpunkt: In Perfmon Zähler \Network Interface\Bytes Total/sec und \Processor(_Total)% Processor Time aufzeichnen. Steigt die CPU-Last moderat (< 10 %), sinkt aber die Dauer eines 5-GB-SMB-Transfers, war die Umstellung erfolgreich.
3.2 Virtuellen NIC in der VM konfigurieren
- VM anmelden (lokaler oder domänenbasierter Admin).
- Gerätemanager → Hyper-V Virtual Ethernet Adapter.
- Reiter Erweitert.
- Diese Optionen auf Deaktiviert stellen:
- Large Send Offload V2 (IPv4)
- Large Send Offload V2 (IPv6)
- Recv Segment Coalescing (IPv4)
- Recv Segment Coalescing (IPv6)
- Neustart der VM.
3.3 Offload per PowerShell scripten (Host + Guest)
# Host
$props = @("LSOv2IPv4", "LSOv2IPv6")
Get-NetAdapter -Physical | ForEach-Object {
foreach ($p in $props) {
Set-NetAdapterAdvancedProperty -Name $_.Name -DisplayName $p -DisplayValue "Disabled"
}
}
# Guest
$guestProps = @("Large Send Offload V2 (IPv4)",
"Large Send Offload V2 (IPv6)",
"Recv Segment Coalescing (IPv4)",
"Recv Segment Coalescing (IPv6)")
Get-NetAdapter | Where-Object {$_.Name -like "*Hyper-V*"} | ForEach-Object {
foreach ($p in $guestProps) {
Set-NetAdapterAdvancedProperty -Name $_.Name -DisplayName $p -DisplayValue "Disabled"
}
}
4 Hyper-V-vSwitch: RSC gezielt steuern
Microsoft führt Receive Segment Coalescing im vSwitch ab Windows Server 2019 standardmäßig als aktiv. In Hochlast-Szenarien kann das in Kombination mit Storage-Overhead oder älteren Treibern zu Jitter oder paketbasierten Timeouts führen. Das Abschalten erfolgt unkompliziert per PowerShell (learn.microsoft.com).
4.1 aktuellen Status prüfen
Get-VMSwitch | Select Name, EnableSoftwareRsc
4.2 RSC deaktivieren
Set-VMSwitch -Name "Prod-vSwitch" -EnableSoftwareRsc $false
4.3 RSC wieder aktivieren
Set-VMSwitch -Name "Prod-vSwitch" -EnableSoftwareRsc $true
Praxisregel:
- 1 GBit-Anbindungen und ältere Netzwerkkarten → häufig RSC ausschalten.
- 10 GBit / RDMA-fähige Adapter → RSC eingeschaltet lassen und nur nach Metrik-Analyse deaktivieren.
5 Validierung und Monitoring
| Tool | Was prüfen | Schwellenwert |
|---|---|---|
| iPerf3 (Host ↔ VM) | Netto-Durchsatz | nahe Leitungsmaximum |
| SMB-Copy (5 GB Testfile) | Transferdauer | < 70 % der ursprünglichen Zeit |
| Perfmon | CPU vs. Netzwerklast | CPU-Anstieg < 10 % erlaubt |
| Event Viewer | Warnungen im System-/Hyper-V-Log | Keine 106, 12389 usw. |
Nach jeder Offload-Änderung mindestens einen 10-Minuten-Dauertest durchführen und Ergebnis protokollieren.
6 Troubleshooting-Checkliste
- Treiber-Rollback: Neue Karte? Erst neuester OEM-Treiber, dann Windows-Inbox.
- RSS & NUMA: Bei > 8 vCPUs RSS aktivieren (
Enable-NetAdapterRSS). - Jumbo Frames: Nur einsetzen, wenn alle Geräte im Pfad MTU 9000 unterstützen.
- SMB-Multichannel: Ab 10 GBit lohnend, auf VMs mit mehreren vNICs prüfen.
- Storage-QoS: Hyper-V-QoS nicht auf denselben vSwitch pinnen.
7 Fazit
Durch das gezielte Deaktivieren bestimmter Offload-Funktionen in physischer und virtueller Netzwerkkarte sowie das bedarfsgerechte Schalten von RSC im Hyper-V-Switch beseitigen Sie typische Engpässe bei SMB-Last oder hochfrequenten Datenbanken. Messen – ändern – erneut messen bleibt der Leitgedanke, denn jedes Hardware-Team agiert anders.
Netzleiter unterstützt Sie dabei mit Managed Performance Monitoring, automatisierten PowerShell-Rollouts und herstellerübergreifendem Firmware-Lifecycle-Management. Sprechen Sie uns an und holen Sie das Maximum aus Ihrer Infrastruktur.
