we are currently evaluating ESX 3.5 and are using ESX 2 in our production system. We used our secondary ESX 2.5 host and upgraded it to ESX 3.5. After updating the virtual hardware and vmware tools on the images we thought we're done. Unfortunately we are now confronted with a very poor network performance on our Windows XP images. Others with a different operating system work perfectly. We also created a new Windows XP installation from scratch which had the same network issues.
In the following picture you see the network traffice while transfering an iso-image (~650MB) from a Windows 2003 Server Std. on our testing ESX to different machines:
First transfer was done to an external XP machine, which is connected via 100MBit Ethernet. It worked perfectly. The second one was to an Ubuntu virtual machine on the same host, which was acceptable although, in our opinion it should be much faster than the first one. For the third transfer we used a Windows 2003 Server Std. (same ESX host(!)) which took a little bit longer than the Linux transfer. Fourth and sixth transfer was to XP where you can see that it did not make any difference if it was a converted image or a newly created one.
Everything seems to be installed correctly. We haven't done any modifications to the virtual network settings. We also did a network test with ttcp, but the transfer rates were all normal (1,2 MByte/sec. on 100MBit Ethernet). ESX Logs do not show any error or warning messages.
Has somebody already encountered such a strange behaviour? We would very much appreciate some help, otherwise we would be forced to stay with ESX 2.5 which is also not an optimal situation.
Greetings and thanks in advance!
Yes of course. We've already thought that the problem could be in a conflict between the old vmware tools and the actualized ones. But as I said, we created a new Windows XP installation from scratch, where the new VMWare Tools were used from the beginning.
Strange. Are the vm's all on the same network? Let's take the physical network out of it. If this isn't being used, try removing the physical networks from the vSwitch to make it a host-only network, and then retry your copy.
All images are on the same network. Removing the vSwitch from the physical NIC would be a problem, since we are already running some production images on it. I will give it a try at the weekend.
We have a single vSwitch attached to the physical NIC and having two port groups named vmnic0 and VLAN48. All images are running within port group VLAN48. vSwitch is has its default values.
The fresh installation of Windows XP has as NIC an 1Gbps "VMWare Accelerated AMD PCNet Adapter". The converted one has a 10Mbps "AMD PCNet Family PCI Ethernet Adapter". According to Infrastructure Client both network adapters are flagged as "flexible".
As I said everything looks alright.
> The fresh installation of Windows XP has as NIC an 1Gbps "VMWare
Accelerated AMD PCNet Adapter". The converted one has a 10Mbps "AMD
PCNet Family PCI Ethernet Adapter". According to Infrastructure Client
both network adapters are
>flagged as "flexible".
Can you check what driver is loaded for the AMD PCNet adapter? Right-click the nic in Device Manager-> Properties -> Driver Details.
If, as you mentioned, you have tools installed, it should be pointing to a vmxnet driver.
With the tools properly installed and working, the converted vm should also be stating a vmware accelerated adapter, as opposed to the amd 10 Mbps, which is the default. Your tools in the converted vm do not look to be working properly. It doesn't explain the fresh install though, but it is one thing to look at.
You can also create a separate vSwitch with no adapters, move your testing vm's to a portgroup on that new vSwitch, and then test again without having to affect prod. That is, if you the vm you are using to test with is not your prod machine, of course.
I've just addressed a very similar issue on my XP VMs - althought the tools package looked to be installed fine, the NIC driver hadn't been updated so it was still running at a grotty 10Mb. I uninstalled the tools, reinstalled and now it's running the correct driver at a flashy 1Gbps.
I've not encountered many instances of this but it doesn seem to happen.
The install should have updated the drivers, which it did not. In this case, it would be more prudent to simply reinstall the tools, just in case.
OK, here's an update of our current situation. We did a complete new installation of ESX, created a virtual switch with no physical nic attached. Within that switch we installed two Windows XP machines with VMWare-Tools and configured their nics with 192.168.0.5/255.255.255.0 and 192.168.0.6/255.255.255.0 - same workgroup, different computer names. Everything left to default. Surprisingly we had the same network problems!!!
Thread moved to the Virtual Machine and Guest OS forum
If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points
VMware Communities User Moderator
That makes no sense....Have you got the ports set on the switch that the host is connected to?
Did you try it with just a private vswtich between 2 xp vm's? You should be averaging at least 26mb a sec that way.
You need to remove the old vmware nics from the device manager
In a CMD prompt type:
Choose View/Show hidden devices
Remove the old nic
attached you will find a screenshot of our configuration. I want to underline that we did not modify any settings. We left all to its default values and the ESX installation is also a fresh one - no upgrade.
We are using the german version. So sorry for the inconvenience but you should get the picture.
Definitely sounds like an OS piece is misconfigured. Using a private vSwitch, you're not even going out to the network. You should be at wirespeed, at this point. Add in that win2k3 image, and see what the throughput is there.
No inconvenience friend.
Can you post the xp guest ipconfig /all's for both guests?
Can you also do a file transfer, preferably to a linux guest (sorry to add that one in, but you can then do an ftp or something and get actual numbers, since XP tends to lie).