VMware Cloud Community
ltfields
Contributor
Contributor

Brain buster issue with Server 2008, NIC drivers, and ESX 3.02

Ok, I've got a brain buster for everyone, but I'd love to know if anyone has any thoughts on this. We have a Windows Server 2008 32bit file server that was created on an ESX 3.5 Update 3 host with the Intel vNICs. For reasons more complicated that I have space for, the host had a shared SAN LUN with an ESX 3.02 host and we had to bring the VM up on the 3.02 host. I set up the custom VM, attached the VMDK, and when the server came up, I set up the new AMD PCNET vNICs with the old IPs and Server 2008 auto-removed the static IPs from the old reg entries. The IPs came up fine (1 LAN, 1 Private SAN subnet), and I can ping the server with a few milliseconds latency, and RDP to the box just fine. My issue is:

Since we had to bring this system online with the AMD PCNET vNICs, the XP machines that connect to this file server are functioning normally using CIFS, however we have a handful of Windows Vista and Windows 7 systems that can connect to the CIFS shares on the server, but they're dropping and retransmiting a lot of the packets (such that it takes 3-5 minutes to pull up a UNC path or mapped drive, switch folders, or open a file). When I did a packet capture I saw a lot of retransmits, and I also spotted a couple TCP Offload errors.

I suspect the NIC Driver change for the problems, but I'm not sure what I can do about it. I can attempt to reinstall the older VMtools, but I suspect that might be worse because the drivers aren't for 2008 in ESX 3.02. I don't have the ESX 3.5 host anymore, so I can't move it back to that yet. I've confirmed on the Server 2008 host that TCP Offload is disabled on the PCNET adapters, but is there a setting in the VMtools?

Let me know if anyone has thoughts about this issue?

Reply
0 Kudos
3 Replies
siglert
Enthusiast
Enthusiast

It sounds to me like Jumbo frames might be enabled. That would cause the retransmits.

Reply
0 Kudos
ltfields
Contributor
Contributor

Its possible. I'll check first thing in the morning. We don't normally use Jumbo Frames anywhere in our environment, so we wouldn't have turned it on manually. Could the PCNET drivers have flipped it on somehow? And how would that explain normal operation from 75 XP systems?

Weird...

Reply
0 Kudos
ltfields
Contributor
Contributor

Nope, the MTU is still 1500 bytes, so Jumbo Frames are not the issue. There is a value in the driver called "TsoEnable" that's set to 1. I'm not sure what this value is...

Reply
0 Kudos