[Hyper-V 2012 R2 / Microserver Gen8] Traag netwerk

[Der Rudi]

Ik heb een Microserver gen8 opgezet met het volgende:
Xeon E3-1260L
16GB udimm ecc
Smart Array P222 raid met FB en BBU
1x 128GB Crucial op de B210i (= std controller)
4x 4TB in raid 5 op de P222 (= in PCIe slot)

Op de Crucial heb ik Hyper-V 2012R2 core gezet als hypervisor en de raid5 voor de VM's.
Als test een 2012R2 Std eval opgezet en alle HP patches ed geinstalleerd en ook de Hyper-V en Standard 2012R2 zijn vwb updates/patches bijgewerkt.

Probleem is dat ik een zeer lage netwerksnelheid krijg van een ter test aangemaakte SMB share op de 2012R2 Std VM. CrystalDiskMark geeft nog geen 12MB/s voor seq read; op de 2012R2 Std is dat honderden MB/s. Dat geeft dan ook wel aan dat de fysieke harddisk/controller werken. De fysieke NICs connecten met 1GB naar het thuis netwerk. Lijkt alsof de virtuele switch in Hyper-V tot 100Mb beperkt is?

Iemand hier een idee in welke richting ik het moet zoeken of wat er verkeerd gaat, google geeft wat resultaten (oa updaten Broadcom NIC drivers die wel iets helpen) maar nog geen silver bullet.

Als er meer info nodig is dan hoor ik het graag. Ik loop nu even vast iig.

[Brahiewahiewa]

Der Rudi schreef op zaterdag 7 oktober 2017 @ 19:28:
... zeer lage netwerksnelheid krijg van een ter test aangemaakte SMB share op de 2012R2 Std VM. CrystalDiskMark geeft nog geen 12MB/s voor seq read; op de 2012R2 Std is dat honderden MB/s.

Da's geen eerlijke vergelijking, natuurlijk. CrystalDiskMark is bedoeld voor DAS, en idd retetraag over smb

alsof de virtuele switch in Hyper-V tot 100Mb beperkt is?

Nee hoor, die is minimaal 10 Gb/s

[RGAT]

Sowieso kan je niet zo even een bench op je storage doen aangezien er een cache module op zit, die resultaten zijn dus sowieso niet heel representatief...

[Der Rudi]

De snelheid van de virtuale switch is intern tussen VM's idd min 10Gb/s (in memory als ik het goed begrijp). Het gaat hier om de snelheid naar externe gebruikers, dus via de fysieke NIC in de server.

Heb nu een 'real world' test gedaan met het copieren van een 4GB ISO file van de Desktop naar de Share. Dat levert een 'snelheid' op van een 3MB/sec (dwz een 24Mbits/s). Dat lijkt me veel te weinig.



Dezelfde test naar een QNAP TS410 geeft een veel hogere snelheid en de TS410 is nu niet bepaald de snelste (vandaar ook (mede) deze nieuwe setup).



Bovenstaande is voor upload naar share resp TS410. Een download geeft soortgelijke resultaten:

Share


TS410

[ Voor 18% gewijzigd door Der Rudi op 08-10-2017 12:41 ]

[Brahiewahiewa]

Kwenie hoor; je bent nu ahw de snelheid van een trein die op de snelweg rijdt aan het vergelijken met de snelheid van een auto die over de spoorbaan rijdt. Die trein graaft z'n wielen lekker diep in het asfalt en de auto komt steeds bbbbbbbbbbielzen tegen. 't Schiet allebei totaal niet op.

ik haal van een virtuele 2008R2 SMB share een iso binnen met 133 MB/s. Daar is de bottleneck duidelijk de wire-speed die niet verder komt dan 1 Gb/s

[Der Rudi]

Dus als ik het goed begrijp is uitgaande van je snelheid van 133MB/s, mijn snelheid van een 11MB/s duidelijk te laag voor een download van virtuele SMB share naar desktop op een 1Gb/s netwerk.

Enig idee waar dat in te zoeken is?

[nelizmastr]

Mijn Gen8 trekt z'n gigabit link helemaal vol, zowel onder Server 2016 als via een VM in ESXi. Niets voor hoeven doen.

Ik heb wel eens dat mijn AP het leuk vindt om z'n switch op 100mbit te gooien dus heeft-ie een schop nodig af en toe.

[Dennism]

Wat zie je qua snelheden als je test van een client naar de Host zelf i.p.v. de VM en van de host naar een client?

Verder check je VMQ settings eens in Hyper-V, bij Broadcom wil je deze uit hebben als je issues hebt met trage transfers bij Hyper-V gebruik.

Hyper-V virtual machines (VMs) hosted on a Windows Server 2008 R2 or Windows Server 2012 (R2) server may exhibit slow network performance if Broadcom network adapters are installed in the host. This can happen if Virtual Machine Queue (VMQ) is enabled on the physical network adapter used by the VMs.

VMQ is designed to improve network performance on VMs by expediting the transfer of network data from the physical adapter to the appropriate VM, but it appears to have the opposite effect on certain Broadcom network adapters, resulting in significantly decreased network performance on all VMs that utilize a virtual switch bound to an affected adapter.

The known workaround is to disable VMQ on the affected network adapters or change the MAC addresses of the corresponding virtual switches. However, it is possible that Broadcom has released an update to fix the issue since this article was written. Therefore, the first step in troubleshooting the issue should be to ensure that the Broadcom adapter driver and firmware are up to date on the Hyper-V host.


If the adapter driver and firmware are up to date and the problem persists, virtual switches can be bound to an unaffected network adapter, if one exists on the host. If no such adapter exists, there are two possible workarounds:

Disable VMQ on affected virtual switches or physical network adapters.
Change the MAC address of all affected virtual switches.

Disable VMQ

To disable VMQ on a virtual switch, use the Set-VMNetworkAdapter PowerShell cmdlet as follows:

Set-VMNetworkAdapter –ManagementOS -Name <VirtualNetworkAdapterName> -VmqWeight 0

To disable VMQ on a physical network adapter, uncheck the appropriate box in the Advanced tab of the network adapter's properties page.

To change the MAC address of a virtual switch, either modify it in Hyper-V Manager or by using one of the following Set-VMNetworkAdapter PowerShell cmdlets:

Using a static MAC address:
Set-VMNetworkAdapter –ManagementOS -Name <VirtualNetworkAdapterName> -StaticMacAddress <MacAddress>

Using a dynamic MAC address:
Set-VMNetworkAdapter –ManagementOS -Name <VirtualNetworkAdapterName> -DynamicMacAddress

VMQ disablen op de fysieke netwerk adapter gaat nog wel eens mis via het vinkje, gebruik in dat geval dit commando: Disable-NetAdapterVMQ -Name NICname

[Der Rudi]

VMQ:
De laatste HP/Broadcom drivers hebben default vmq disabled staan. Maar om zeker te zijn eea nog handmatig gedaan op host nic (en via Manager op de virtual nic van de guest):


Helaas zonder verbetering in snelheid:


Snelheid gemeten na shutdown/start up van vm.

Een share aanmaken op de host zelf is een goeie. Helaas geeft dat dezelfde lage snelheid (na enabling van file sharing).

[ Voor 8% gewijzigd door Der Rudi op 09-10-2017 10:17 ]

[Tomba]

Der Rudi schreef op maandag 9 oktober 2017 @ 10:10:
VMQ:
De laatste HP/Broadcom drivers hebben default vmq disabled staan. Maar om zeker te zijn eea nog handmatig gedaan op host nic (en via Manager op de virtual nic van de guest):
[afbeelding]

Helaas zonder verbetering in snelheid:
[afbeelding]

Snelheid gemeten na shutdown/start up van vm.

Een share aanmaken op de host zelf is een goeie. Helaas geeft dat dezelfde lage snelheid (na enabling van file sharing).

Welke snelheid haal je lokaal op de machine? Wellicht is het je P222 die zo traag is, kan me van vruuger herinneren dat de P2xx serie geen cache had en een trage processor.

NB ik draai Windows 2012 R2 Essentials op mijn Gen8 met een i5-3470T processor en haal Linespeed (100+MB/s) via Gigabit netwerk (maar gebruik dan ook niet een SmartArray RAID controller maar de ingebouwde controller gewoon AHCI)

[ Voor 16% gewijzigd door Tomba op 09-10-2017 10:25 ]

[Der Rudi]

P222 heeft flash cache en BBU. Als ik op de VM een CrystalDiskMark test run geeft dat 100-en megabytes / sec (veelal uit cache).

De bovenstaande test op de host zelf gaat van de SSD/AHCI waar Hyper-V 2012R2 core is geinstalleerd. Dus niet via de P222. Dit geeft helaas dezelfde snelheid.

[jimbo123]

Je hebt non-HPE hardware in een HPE server geplaatst.
Dat wordt niet ondersteund.

Ik weet dat de supported disks erg duur zijn, maar het zou zomaar kunnen dat deze geen problemen geven.

[ Voor 5% gewijzigd door jimbo123 op 10-10-2017 11:15 ]

[Meekoh]

Loop ook even deze lijst door:
https://support.microsoft...utions-for-windows-server
Niet alle hotfixes uit deze lijst komen via Windows Update binnen.

[Der Rudi]

[schaam mode on]
Lag aan netwerk kabel.....
[schaam mode off]

Het bleek dat de netwerk kabel naar de kleine switch voor de microserver de boosdoener was. Vervangen en nu zo goed als line speed.

Dank iedereen voor het meedenken!