Slow file copy/open between Windows Server 2008 R2 on ESXi 4 - Fixed!

[msoerensen]

Hi

We have setup our first Windows Server 2008 R2 Terminal Server (sorry Remote Desktop) environment and we had some problems with initial slow file copying and opening of files in Excel/Word. First an overview of our environment:

Server 1:

1 x IBM x3655 with 2 x 300 GB SAS 15K, 20 GB RAM, 2 x AMD Opteron 2216 CPU's

VMWare ESXi 4 Build 171294

2 x Windows Server 2008 R2 Virtual servers (TS01 & FILE01)

Server 2:

1 x IBM x3550 with 2 x 300 GB SAS 15K, 12 GB RAM, 2 x Intel Xeon 2.4 Ghz CPU's

VMWare ESXi 4 Build 171294

1 x Windows Server 2008 R2 Virtual server (TS02)

We also have a test environment based on XenServer:

Test Server:

1 x IBM x3550 with 2 x 300 GB SAS 15K, 12 GB RAM, 2 x Intel Xeon 2.4 Ghz CPU's

XenServer 5.5

3 x Windows Server 2008 R2 Virtual servers (TestTS01, TestTS02 & TestFile02)

Problem:

When the users tried to open a word document or an excel spreadsheet from a fileshare it hang in "Downloading" for about 20-40 sec. before actually opening it.

When the users copy/pasted the file from the fileshare to the local server, it started by "Calculating" in approximately 20-30 sec. before actually starting copying the file. When the copying started it was very fast and if the users then tried to copy a new file from the same fileshare there where no "calculation".

This only occurs on fileshares that are located on one of the Windows Server 2008 R2 servers running on VMWare ESXi 4, we did not see this problem if we tried coping from one of the Windows Server 2008 R2 servers running on XenServer 5.5.

So the problem did only occur when the user was logged on to TS01 or TS02 and was copying/opening files from either TSFILE01, TS01 or TS02. If the user tried opening files from TestTS01, TestTS02 or TestFile01 there where no problems at all.

Solution:

We tried using E1000, VMXNET2 & VMXNET3 and we tried changing GLOBAL AUTOTUNINGLEVEL, GLOBAL RSS. CHIMNEY and AUTOTUNINGLEVEL, plus a bunch of other fixes etc. but nothing seemed to work. So the last resort was using Network Monitor 3.3 from Microsoft, to try locating the initial network traffic and see what was going on. We know it was not our network that was causing the problem, because it worked from the XenServer virtual servers, so we just needed to see if there where any indication on what the problem could be.

What we saw was a lot of SMB2 traffic going on and I had somewhere read something about SMB2 and initial negotiation could slow thinks down. So the first think we did was to find an article that describe how to disable SMB2 on Windows Server 2008 () - Thanks Petri. After adding this registry value and a reboot of all the servers, THE PROBLEM WAS GONE!!!

To sum up, the only think we did was disabling SMB2 so it know uses SMB and our theorie is that somewhere in ESX SMB2 traffic is not supported, but if anyone know or has an idea of where in ESX the problem lies, please replay so we can test it in the future.

Thanks

/Mads

[J1mbo]

I wonder if this is a sympton of an underlying network issue. Did you try this hotfix:

Perhaps there is some loss & retransmit going on only on the ESX hosts, making the problem much worse?

- How are your speed & duplex configured in ESX and the attached switch?

- Similarly for the test client?

- How is the test client connected to the server (i.e. same switch, same stack, different switch, different site... etc)?

Please award points to any useful answer.

[msoerensen]

Hi J1mbo

I have not tried the hotfix, but when we don't see the problem on the servers running on XenServer, I don't think it's an direct Windows issue. But it may be worth trying.

- Everything is set to "Auto Negotiate", but the "funny" think is that's it's only a 1 Gbit network, but in the Windows Servers it says 10 Gbit - I think is is only when using VMXNET3, but not 100% sure.

- Same for all servers (TS01, TS02 & TSFILE01)

- The test servers is connected to the same network. The only think I can see that is different between the Windows server 2008 R2 servers running on XenServer vs. the Windows Server 2008 R2 servers running on VMWare ESXi4, is that the servers running on XenServer are using a RealTek network driver provided by Microsoft and the servers running on VMWare is using a vmxnet3 driver provided by VMWare.

/Mads

[J1mbo]

Do you have a test client running as a VM on the same host? I wondered if the issue is present entirely within the ESX host.

Please award points to any useful answer.

[msoerensen]

Yes, it's only when accessing a filshare from a server running in the ESX envoriment.

[J1mbo]

So if the fileserver AND the client are VMs on the same ESX host (and on the same vSwitch), the problem prevails?

Please award points to any useful answer.

[msoerensen]

Yes.

ESX host 1 (Server 1):

TS01

TSFILE01

ESX host 2 (Server 2):

TS02

XenServer host (Test Server)

TestFile01

TestTS01

TestTS02

The problem occurs when you are on any server inside or outside of the ESX environment and you are trying to:

Transferring/opening files from a fileshare located on TSFILE01

Transferring/opening files from a fileshare located on TS01

Transferring/opening files from a fileshare located on TS02

The problem does NOT occur if you are on any server inside or outside the environment and you are trying to:

Transferring/opening files from a fileshare located on TestFile01

Transferring/opening files from a fileshare located on TestTS01

Transferring/opening files from a fileshare located on TestTS02

/Mads