Man, als je VM’s ’s ochtends nog helemaal normaal werken, maar dan beginnen te haperen, pakketten verliezen of de doorvoer keldert zodra het druk wordt, is het een enorme hoofdpijn om dat uit te zoeken. Meestal ligt het probleem niet bij Hyper-V zelf, maar bij de onderliggende infrastructuur – met name de netwerkkaart en hoe die al dat verkeer verwerkt. Het oplossen van dit soort problemen vereist een paar kleine aanpassingen, meestal het uitschakelen van vervelende offload-functies of het bijwerken van stuurprogramma’s. Als je het goed doet, is het alsof je een schakelaar omzet – alles stabiliseert zich. Dus, hier is een overzicht van wat in het verleden heeft gewerkt en waar je naar moet kijken.
Hoe je netwerkproblemen met NIC’s en Hyper-V tijdens piekbelastingen kunt oplossen
Waarom dit gebeurt
Kort gezegd proberen netwerkkaarten (NIC’s) tijdens piekuren slim te zijn. Ze besteden bepaalde checksums, pakketsplitsing en wachtrijtaken uit om CPU-cycli te besparen. Klinkt goed, toch? Maar in de praktijk, vooral met oude of generieke drivers (ja, Windows Update installeert vaak de trage en buggy versie), raken deze offload-paden soms in de war bij de virtuele switch. Checksums raken beschadigd, data komt beschadigd of corrupt aan en plotseling wordt je VM-netwerk erg instabiel. De belangrijkste boosdoener is VMQ, de Virtual Machine Queue-technologie die de belasting over de cores verdeelt. Als de driver of hardware instabiel is, kan dit pakketcorruptie veroorzaken, maar alleen onder zware belasting wanneer al die offload-taken worden uitgevoerd.
De oplossing is dus om deze offloads uit te schakelen of bij te werken. Dat is wat ik in de meeste gevallen heb zien werken.
Oplossing 1 – Update het stuurprogramma van uw netwerkkaart via de website van de fabrikant.
Dit is eigenlijk een open deur, maar wordt vaak over het hoofd gezien. Verouderde stuurprogramma’s zijn meestal de oorzaak van al deze opgepoetste offload-bugs. Vertrouw niet alleen op Windows Update; ga direct naar de website van de hardwarefabrikant. Zij hebben vaak een recenter, geoptimaliseerd stuurprogramma dat bekende problemen oplost.
- Open Apparaatbeheer en zoek je netwerkkaart op. Kijk naar het exacte model om het juiste stuurprogramma te downloaden.
- Ga naar de website van de fabrikant — Intel, Broadcom, Realtek, wie uw netwerkkaart ook heeft gemaakt.
- Download het nieuwste stuurprogramma voor uw specifieke model en Windows-versie. Soms vindt u het nieuwste stuurprogramma onder ‘Nieuwste ondersteuningsdownloads’.
- Voer het installatieprogramma uit en herstart de computer. Ja, het kan zijn dat er om een herstart wordt gevraagd, maar geloof me, generieke Windows-stuurprogramma’s zijn vaak verouderd of missen een essentiële functie.
Bij sommige configuraties heb ik gemerkt dat Windows Update een oudere driver installeert die de situatie juist verergert. Het gebruik van de nieuwste driver van de fabrikant lost dit meestal op, of verbetert de situatie in ieder geval.
Oplossing 2 – Schakel VMQ uit op de fysieke netwerkkaart
Als die driverupdate het probleem niet oplost, is de volgende stap het uitschakelen van VMQ. Voor een configuratie met één host heeft dit weinig impact, maar het kan pakketcorruptie tijdens piekbelasting aanzienlijk verminderen.
- Open PowerShell als beheerder ( Windows + Xkies vervolgens Terminal (Admin) ).
- Controleer de VMQ-status met:
Get-NetAdapterVmq - Identificeer uw fysieke netwerkkaart (NIC), deze is meestal aangeduid met “Ethernet” of iets dergelijks.
- Schakel VMQ voor die netwerkkaart uit met:
Disable-NetAdapterVmq -Name "Ethernet"
U kunt hetzelfde ook via de grafische gebruikersinterface doen: open Apparaatbeheer, zoek uw netwerkkaart, ga naar het tabblad Geavanceerd en schakel de wachtrijen voor virtuele machines uit. Dit heeft hetzelfde effect. Houd er rekening mee dat sommige netwerkkaarten of stuurprogramma’s dit anders verwerken en dat in sommige gevallen een herstart nodig kan zijn om de wijzigingen door te voeren.
Deze stap heeft in talloze gevallen geholpen, vooral bij oudere Intel- of Broadcom-netwerkkaarten. Het is een simpele actie om “de onbetrouwbare offload uit te schakelen” die de situatie kan redden.
Oplossing 3 – Schakel TCP-offloadfuncties uit
Als VMQ niet de held was, dan zijn het misschien de TCP-offload-engines die de problemen veroorzaken. Deze functies, zoals Large Send Offload en Checksum Offload, zijn ontworpen om de snelheid te verhogen, maar onder belasting kunnen ze leiden tot beschadigde pakketten.
- Vouw in Apparaatbeheer de optie Netwerkadapters uit. Zoek uw netwerkkaart, klik er met de rechtermuisknop op en selecteer Eigenschappen.
- Ga naar het tabblad ‘Geavanceerd’.
- Zet de volgende instellingen op Uitgeschakeld :
- Large Send Offload V2 (IPv4)
- Large Send Offload V2 (IPv6)
- TCP-checksum-offload
- UDP-checksum-offload
Deze aanpassing ruilt een klein beetje CPU-efficiëntie in voor een veel betrouwbaardere pakketverwerking onder belasting. Voor de meeste configuraties is het absoluut de moeite waard, en je zult merken dat je doorvoer stabiel blijft tijdens de drukste uren. Je schakelt een aantal offloading-paden uit die de netwerkkaart gebruikt om te frauderen, maar die fraude werkt vaak averechts met beschadigde frames.
Oplossing 4 – Schakel RSC (Receive Segment Coalescing) uit op de virtuele switch.
RSC zou de CPU-prestaties moeten verbeteren door pakketten te bundelen, maar het veroorzaakt al een tijdje problemen met de doorvoer en pakketintegriteit op Hyper-V. Vreemd genoeg zou het uitschakelen ervan de corruptiegolf tijdens piekbelastingen mogelijk kunnen verhelpen.
- Open PowerShell als beheerder.
- Controleer de huidige instelling met:
Get-VMSwitch | Select Name, SoftwareRscEnabled - Als het is ingeschakeld, schakel het dan uit:
Set-VMSwitch -Name "YourSwitchName" -EnableSoftwareRsc $false
Voer vervolgens een aantal belastingstests uit. Als de pakketcorruptie bij hoge belasting stopt, was dat de oorzaak. Opmerking: Vervang YourSwitchName door de daadwerkelijke naam van uw switch, die u kunt vinden met Get-VMSwitch. In veel configuraties blijft het netwerk stabiel als RSC is uitgeschakeld.
Oplossing 5 – MTU en Jumbo Frames volledig op elkaar afstemmen
Dit is een verraderlijk probleem: als de MTU of Jumbo Frames niet overeenkomen tussen uw apparaten, beginnen er fragmenten rond te vliegen, en dat wordt vaak aangezien voor pakketverlies of -corruptie. Bij veel verkeer is deze mismatch het eerste dat vertragingen of vreemd gedrag veroorzaakt.
- Ga in Apparaatbeheer naar het tabblad ‘Geavanceerd ‘ van uw netwerkkaart en zoek naar ‘Jumbo Packet’.
- Als jumbo frames zijn ingeschakeld op de host, maar niet op je switch of router, worden frames afgekapt of gedropt. De beste oplossing? Stel overal dezelfde MTU in: schakel jumbo frames overal in (als je netwerk dit ondersteunt) of schakel het volledig uit en blijf bij 1500 bytes.
Om de MTU via de commandoregel te controleren of te wijzigen:
netsh interface ipv4 show subinterfacesnetsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistentHetzelfde geldt voor IPv6 indien nodig. Door alle apparaatinstellingen consistent te houden, wordt fragmentatiechaos voorkomen die onder belasting verergert, met name tijdens verkeerspieken.
Hoe houd je alles stabiel?
- Download netwerkstuurprogramma’s altijd rechtstreeks van de leverancier, niet via Windows Update. Verouderde stuurprogramma’s zijn vaak de stiekeme oorzaak van deze problemen.
- Schakel VMQ direct uit als de netwerkkaarten oud zijn of de drivers niet in orde zijn. Dat is beter dan later problemen te moeten oplossen.
- Zorg ervoor dat de MTU- en jumbo frame-instellingen op alle switches, routers en VM’s overeenkomen om dat te voorkomen.
- Test je netwerk vóór de implementatie om deze problemen vroegtijdig op te sporen. Een switch kan bijvoorbeeld probleemloos werken wanneer hij niet in gebruik is, maar een ramp worden wanneer hij zwaar belast wordt.
Mensen vragen ook vaak
Waarom laat Hyper-V pakketten vallen onder zware belasting?
Meestal ligt het probleem bij de offload-functies van de netwerkkaart. VMQ, Large Send Offload of checksum-offloading, die de snelheid verhogen bij weinig verkeer, werken vaak niet meer of raken beschadigd zodra het verkeer kritieke niveaus bereikt. Het uitschakelen van deze functies verhelpt meestal de pakketchaos.
Moet ik VMQ uitschakelen in Hyper-V?
Als je een enkele host gebruikt of problemen ondervindt, ja — vooral met oudere netwerkkaarten of drivers. Hoewel VMQ helpt bij servers met meerdere netwerkkaarten door de belasting te verdelen, kan het bij een eenvoudige configuratie meer problemen veroorzaken dan het waard is. Het uitschakelen van VMQ verhelpt vaak willekeurige pakketverlies of corruptie bij hoge belasting, zonder dat de prestaties noemenswaardig afnemen.
Vertraagt het uitschakelen van TCP-offload de boel?
Ja, een beetje wel. Het verplaatst een deel van de CPU-belasting terug naar de processor, maar bij moderne CPU’s is dat een klein verlies. Meestal wegen stabiliteit en veilig dataverkeer op tegen dat kleine prestatieverlies. De meeste systemen zullen het verschil niet eens merken, maar beschadigde datapakketten? Dat is een ander verhaal.
Hopelijk helpen deze tips iemand om te voorkomen dat hij of zij urenlang bezig is met het oplossen van onverklaarbare netwerkproblemen tijdens piekuren. Soms lost een simpele driverupdate of een snelle aanpassing het probleem sneller op dan verwacht. Succes!