Network traffic slow/times out to ESXi4 host from a different subnet but guests are fine

[wheelz311]

I setup a test ESXi4 server and am running various Windows 2003/XP guests and a Vyatta VC5 guest as my core router. This has been a strange problem as all traffic to the guests and elsewhere are fine, however I can only manage the host with the VI client on the same subnet. If I manage the host on a different subnet (even if I leave the cable plugged into the same port and vlan), it then becomes unusable. Many things time out including just trying to download the VI client from the https page of the host. Has anyone seen this before?

I have 2 vSwitches configured, one on an isolated vlan for my iSCSI traffic to my storage and the other as a trunk with the management network and guest vm vlans on it. My management network is in the same vlan as one of my guest vlans.

Thanks in advance.

[TAMW]

Your problems look like a problem i had with vsphere in 3.5 u4 it worked fine.

Doe jou have vmware tools installed in your Vyatta VC5 router?

If yes change your network adaptor type for that vm to e1000 en check if your problem is gone.

If no then you have not the problem like me.

[wheelz311]

I am running VC5 so it has open-vm-tools loaded by default so yes it is of sorts... however I do notice that the host shows the tools status as Unmanaged. I'm not sure what that means as usually it says not running if they are not loaded. I checked the vyatta vm and it is detecting the network adapters as vmxnet3 and using that driver. I assumed that meant it was working as it should. I can try changing the NIC type to e1000 if you still think that might help given that information. Is that the case?

[TAMW · Accepted solution]

yes try changing the nic to e1000,

[wheelz311]

That was it... I'm a little disappointed that vyatta's drivers aren't working. Anybody know what the implications of the Unmanaged state of the VM Tools are?

[DSTAVERT]

I would check with vyatta's forums.

[TAMW]

ist not a vyatta's bug but a Vmware Vsphere bug that occurs with all type's of linux vmxnet drivers.

I had it with RHEL 5 with the latests vmware tools. Its al bug in the vmxnet in combination with ESX(i) 4

In ESX 3.5u4 I had no problem (same VM/Hardware/configuration)

[DSTAVERT]

I wasn't suggesting that it was anyone's bug. If anyone would know a workaround to an issue regarding a vyatta vmware image/install it might be vyatta hence my suggestion.

As for the tools have a look at http://communities.vmware.com/community/vmtn/general/tools-os-pkg

[Virtuali3ed]

Apology about bring an old post to life. Any ideas when this bug will be fixed. Is vmware even aware of this issue about vmxnet3?

Thanks,

[MichaelW007]

I've experienced the same problem and have raised the awareness of it within some of the people I know at VMware. The best suggestion at this point is to raise SR's if you have specific issues. It appears to only happen on host isolated network traffic, i.e. traffic that doesn't exist the host to the physical network. If you put the Vyatta VA on an isolated vswitch by itself so that all VM's / systems have to talk to it through the physical network then you shouldn't experience the problem with the vmxnet3 drivers. e1000 works fine though and I've successfully pushed 1.4gb/s through the VA using e1000 with only 30% cpu load on the single vCPU. I've also seen this issue on Open SUSE 11 using the open VMware Tools. I was unable to install normal VMware tools on the guest to see if the native VMware tools makes any difference at all. But I'd suggest just using e1000, which will work just fine for 99% of workloads.

[vmaxx]

I had the same problem with esxi 4.1 and vyatta6. It was incredibibly slow, ftp with hash turned on would be about 1 # per second, and I am completly on gigabit. It was completly worthless. I changed to e1000 and everything on both subnets is just as fast as any of my physical machines...Thank you for posting that suggestion. I can't tell you how much that was annoying me. I have my systems back and can even term svc to machines on the other subnet.

Thank you Thank you Thank you

vm