Hyper-V Netzwerk-Tuning: LSO und RSC gezielt abschalten

Wer in einer Hyper-V-Umgebung Performance-Probleme bei Windows-Fileservern beobachtet, obwohl Hardware, Virenschutz und DNS unauffällig sind, sollte zwei Stellschrauben im Netzwerk-Subsystem prüfen: die Offload-Funktionen der Netzwerkkarte (Large Send Offload, Receive Segment Coalescing) und RSC im Hyper-V-vSwitch. In Hamburger Rechenzentren und Remote-Arbeitsplatz-Infrastrukturen begegnen wir diesem Problem regelmäßig.

Hintergrund: Warum Offload manchmal bremst

Large Send Offload (LSO) und Receive Segment Coalescing (RSC) verlagern TCP-Segmentierung vom CPU-Stack auf den Netzwerkkontroller. Auf Bare-Metal-Servern mit aktueller Hardware steigt der Durchsatz dadurch oft. In virtuellen Umgebungen führen diese Funktionen aber auch zu Inkompatibilitäten mit älteren Netzwerkkadern. Hyper-V muss die zusammengefassten Frames erst wieder zerlegen, bevor sie in der VM ankommen. Das kann CPU-Last senken, während Latenzen gleichzeitig steigen. Das Ergebnis sind träge SMB-Transfers und inkonsistente Reaktionszeiten.

Ausgangskontrolle vor Änderungen

Offload im Host abschalten

Physische Intel- oder Broadcom-NIC auf dem Hyper-V-Host

1. Geräte-Manager öffnen (devmgmt.msc)
2. Netzwerkadapter, physische Karte doppelklicken
3. Reiter “Erweitert” wählen
4. Diese Einträge auf “Deaktiviert” setzen:
   • Large Send Offload V2 (IPv4)
   • Large Send Offload V2 (IPv6)
5. Übernehmen, dann Ping und SMB-Copy messen

Messpunkt in Perfmon: Zähler \\Network Interface\\Bytes Total/sec und \\Processor(_Total)% Processor Time aufzeichnen.

Offload im Gast abschalten

Virtuellen NIC in der VM konfigurieren

1. VM anmelden (lokaler oder Domänen-Admin)
2. Geräte-Manager, Hyper-V Virtual Ethernet Adapter
3. Reiter “Erweitert”
4. Diese Optionen auf “Deaktiviert” setzen:
   • Large Send Offload V2 (IPv4)
   • Large Send Offload V2 (IPv6)
   • Recv Segment Coalescing (IPv4)
   • Recv Segment Coalescing (IPv6)
5. VM neu starten

PowerShell-Skript für Host und Gast

# Host: LSO deaktivieren
$props = @("LSOv2IPv4", "LSOv2IPv6")
Get-NetAdapter -Physical | ForEach-Object {
    foreach ($p in $props) {
        Set-NetAdapterAdvancedProperty -Name $_.Name -DisplayName $p -DisplayValue "Disabled"
    }
}

# Gast: LSO und RSC deaktivieren
$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"
    }
}

RSC im Hyper-V-vSwitch steuern

Microsoft aktiviert RSC im vSwitch ab Windows Server 2019 standardmäßig. In Hochlast-Szenarien kann das zu Jitter oder Timeouts führen.

Status prüfen:

Get-VMSwitch | Select-Object Name, EnableSoftwareRsc

RSC deaktivieren:

Set-VMSwitch -Name "Prod-vSwitch" -EnableSoftwareRsc $false

RSC wieder aktivieren:

Set-VMSwitch -Name "Prod-vSwitch" -EnableSoftwareRsc $true

Faustregel:

• 1-GBit-Anbindungen und ältere Netzwerkkarten: RSC ausschalten
• 10-GBit- und RDMA-fähige Adapter: RSC eingeschaltet lassen

Validierung nach Änderungen

Nach jeder Offload-Änderung mindestens zehn Minuten Dauerlast testen.

Weitere Troubleshooting-Schritte

1. Treiber-Rollback: Erst neuester OEM-Treiber, dann Windows-Inbox-Treiber testen
2. RSS und NUMA: Bei mehr als 8 vCPUs RSS aktivieren (Enable-NetAdapterRSS)
3. Jumbo Frames: Nur einsetzen, wenn alle Geräte im Pfad MTU 9000 unterstützen
4. SMB Multichannel: Ab 10 GBit lohnend
5. Storage-QoS: Nicht auf denselben vSwitch wie VM-Traffic pinnen

Fazit

Durch gezieltes Deaktivieren von LSO und RSC lassen sich typische Engpässe bei SMB-Last oder hochfrequenten Datenbankzugriffen beseitigen. Das Prinzip bleibt dabei immer gleich: messen, ändern, erneut messen. Jede Hardware-Konfiguration reagiert unterschiedlich, weshalb Annahmen ohne Messung zu falschen Schlüssen führen.