Hyper-V File Shares over Wide Ethernet Dramatically Slower

Question

We recently moved a file share machine that runs on 2008 hyper-v to our data center from our local network and now it is periodically extremely slow.

The networks are connected via wide ethernet. Pinging the server returns in less than 1ms and tracert shows only 1 hop again at less than 1ms. Other services provided from that location seem to be unaffected (DC, Active Directory, intranet, etc.)

1 1 ms <1 ms <1 ms 192.168.XX.XX

Other than the location, nothing else changed about the server, including IP address.

A simple excel sheet can take up to 2 minutes to download. Browsing the shares can also be slow.

Any ideas?

Answer 1

More things than simple TCP latency can slow down Windows server performance. If you're up to it, throw a sniffer like Wireshark on a client that experiences slow Excel sheet loading and see what it looks like on the wire. Perhaps you'll see suspicious timeouts between packets, like strange 200ms intervals between packets. Then compare similar traffic to an unaffected non-VMed machine to see what it should look like.

Network driver settings. When you moved to HyperV, you unavoidably changed your NIC driver. Settings here can affect traffic in ways that ping can't diagnose or expose. Stuff like this is best exposed by what you're doing: copying files off of the system, creating connections, browsing shares. Even if it moved from one point-rev of HyperV to another, driver versions may be slightly different.

But, the packet flows should shed more light on the problems.

Answer 2

A couple of things to check:

Determine if MTU is less than what we would expect for a normal Ethernet. From the client workstation:

ping -f -l 1472

If it returns "Packet needs to be fragmented but DF set" (or "request timed out"), keep reducing from 1472 until you determine what the maximum payload is. The MTU is max payload plus 28 bytes (8 bytes for ICMP header + 20 bytes for IP header, normal Ethernet MTU is 1500).

Next, in Wireshark and MS Network Monitor 3.3, you can add the column for "Frame Length". This will enable you to see if the server is sending oversize Ethernet frames. Create a display or capture filter for packets > 1514 bytes, however the server really should not be sending packets larger than the MTU.

If there are oversize frames, these are determined by the network adapter properties "Large Send Offload" and "Jumbo Packets" in your guest.

Answer 3

There are good suggestions already made that are worth looking into. Another common issue I've run into is with the TCP Chimney offloading, especially with Broadcom NICs. Try disabling it and testing to see if that's coming into play. http://support.microsoft.com/kb/951037