Bill Bosacker

This is just my normal user blog for things that don't fit in the other blogs, but are tailored for the open source C/C++/C# and .NET communities.

Hyper-V: Slow network connections

UPDATE 03/30/2009:  The slow network issues came back and progressively became so bad that I was experiencing permanent data loss due to connections timing out.  I rebuilt the server last weekend w/o Hyper-V and everything is functioning normally.  I came across another post about this issue which refers to the Using Registry Values to Enable and Disable Task Offloading MSDN Library article.  Once I'm sure that everything is fine I'll perform a full backup of the system partition and give Hyper-V another try with this new information.

I've been using and/or testing Microsoft's Virtual Server technology (the current version is dubbed Hyper-V) for several years, as I was on the technical beta team.  The very first stable version was Virtual Server 2005 R2 with patches that later became available around October/November of 2006.  Prior to that the host operating system could lockup or the network connectivity of the virtual instances could completely fail, but once it was working it was a great way to create a virtual DMZ.

Today is the first time that I had a chance to try Hyper-V, as it does not work on any machine with an older processor.  Pretty much any system with a processor purchased prior to 2007 is out, and even some of the processors from 2007 won't work.  The processor must be a 64 bit processor, and it must support both Hardware Data Execution Protection (DEP) and Hardware Virtualization.  All new processors have this support.  Gibson Research Corporation offers a free application to test your machine named SecurAble.

If your machine passes the test, you are in for a real treat.  Hyper-V is several times better than Virtual Server ever was, but it does have one carry over issue from previous versions that got missed.   The issue not only affects virtual machines like the original issue in Virtual Server did, it also affects the host operating system; however, there is a work-around.  On the host operating system, you need to Disable all of the TCP Large Send Offload properties of all the virtual network adapters in the Device Manager.  If you don't disable this property, all large TCP transactions will burst at an incredibly slow rate (i.e. 1KB/sec).

Fortunately for me, I found the Very slow network performance with Intel NIC when TCP Large Send Offload is enabled post in Microsoft's TechNet forums which discusses the issue.  This will most likely be fixed down the road, but this adresses the issue and stops the burst transaction bottleneck.  I've only been using it for a couple hours, but I immediately observed a tremendous performance increase when I moved my virtual TFS instance from a host machine running Virtual Server 2005 R2 to a host machine running Hyper-V with 1/3 the resources.

Comments

Pierre Daubresse said:

Hi, thanks a lot for the trick. It saved me from white nights and nightmares. Disabling the property instantly resolves the problem.

# January 25, 2012 8:43 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)