Host system is linux debian and the guest system is Winxp using vmplayer.
I am using the bridged networking option and everything works great except for one very annoying thing.
Network transfers moving files from host->guest over the network is incredibly slow something <1KB/s.
This is independant of protocol, I've tried scp, ftp, and samba.
Transfering files using the above protocols from the guest->host is fine getting something in the order of 4000-7000 KB/s
guest->Any other network host is fine
host->Any other network host is fine
Any other network host ->host is fine
Any other network host ->Guest is fine
So now I quite puzzled as to why as if it works fine in one direction but not the other I doubt its a problem with the disk being read and then writtened to straight away.
Any ideas ?
Thx in advance
Just wanted to jump in and say thank you as well -- I left a transfer running overnight between a guest (XP) and the host (Ubuntu) because it was getting late, and I didn't have time to find out the problem.
(BTW, this was definitely a case of 'sudo make me a sandwich' (http://xkcd.com/c149.html), where I first got the 'no can do' reply first
Problem is caused by TCP Segment OffLoading of the intel e1000 network card I'm using (although the problem occurs in other 1gig or 10gb cards). Even though the information I found suggests the relevant bugs were fixed in kernel 2.6.12 (I'm using 220.127.116.11) I got instant results turning it off.
unforunately this cannot be done in an OSX-host (vmware-fusion) because TSO apparently is not a supported feature in the OSX tcp/ip-stack.
but setting MTU to 8244 (don't ask why, it's a value I found googling for "optimal en0 mtu osx") everything worked great again.
\# ifconfig en0 mtu 8244
Great catch, Chris!
It was causing copies of large files from Linux to Win 2000 to fail, causing the Visual Studio
IDE to crawl, and so on.
Thanks for tracking it down, /and/ posting it.
I am having the same problem running on Mandriva Linux 2006 and 2007. I have tried both of these and tried all of the different fixes here but none have worked. I am not running nvnet. My primary network adapter on my laptop is an Intel wireless adapter running the ipw2200 drivers. Everything else seems to work fine but I cannot get VMware Workstation to work at any decent speed on Mandriva! I have tried a couple of different versions of Workstation as well (5.5.3 and 5.5.1).
Interestingly when I installed 5.5.3 on Mandriva 2007 and ran vmware-config.pl it found a compatible set of modules for the kernel version but on Mandriva 2006 it did not and it had to create a new set of modules. But both did not work anyway. I cannot use ethtool and when I tried to set things like mtu size in modules.conf (as per the ferdora forums link) this does not work either.
I just want to pipe in here and say 'omg, thanks!'. I have 2 fedora core systems @ home, and I had this exact same problem, and it was truly boggling my mind. I spent a couple days testing, reinstalled a second vm, reinstalled smb and was just baffled. ONe of the guys at work said google for "vmware guest slow net access go host os", and found this thread. amazing.
anyway, my systems are configured like this
>> achilles - fedora core 6 host, vmware 1.0.2, smb configured w/ shares, say one called "swraid5", and nfs exports that same volume to terra
>> terra - fedora core 6 host, nfs mounts shares "swraid5" from achilles, same shares that are smb exported from achilles
- terra ALSO smb exports the NFS mounted volumes from achilles
>> vger - my true windows xp desktop
>> pseudo - my vmware windows xp desktop
>> pseudo2 - second vmware windows xp desktop
from my desktop, vger, smb access to share 'swraid5' on both terra and achilles were fine
from vmwares pseudo and pseudo2, access to smb share on achilles, well, you know the storey from above. watching task manager, the explorer windows would go into 'not responding', consistently. browsing folder structures with no items in it them seemed ok, but as soon as I hit a folder with programs, that would need to be scanned for icons, instant lockup. I watched tcpdump on my interfaces too, to see what I could see, and I would see traffic slow to a crawl, about 20 packets per second - nuts.
At that point, upgraded smb, reinstalled a new vmware session (pseudo2), upgraded my kernel, etc. all the same behavior.
waht was even stranger, is that I could smb browse from pseudo to terra, which nfs mounts the volumes from achilles, which worked -fine-. boggled my mind, as i said.
in any case, as soon as I turned off the 'tso' on my network card on achilles intel pro 1000 card, (eth0 = e1000, eth1=3c59x, eth2=forcedeth) , everything was fine from my VM sessions
MANY, Many thanks guys.
oh, btw guys, does anyone know if I can add this to my
ETHTOOL_OPTS in /etc/sysconfig/network-scripts/ifcfg-ethN? I use it now to force "speed 1000 duplex full autoneg off", can i add "tso off" ? the previous options are used with -s, whereas this one uses -K
Just wondering, otherwise, i can add it to rc.local
I have two VM x64 Server Edition machines. 1 is a domain controller,dns,dhcp server. The other is exchange server.
What i have noticed is that the internet throughput has decrease since i moved over my dns server to a vm. i used to get an average of 10Mb on the download for all my domain computers when i did a speed test. Now i get 2-3Mb, which causes my media center internet content viewing to choke. My host machine is a dual core AMD 2.2ghz processor with 4 gigs of ram 1gig for each vm. the host machine is xp pro 32bit with a realtek 1gig nic. Everything seems fine on the host machines in terms of having enough ram an the processor not choking or overloaded. Has anyone else experienced this issue and/or have a solution to get back to speed? Is this a vm limitation? Sorry i have the latest vmworkstation 5.5 patches and updates.
I had a similar problem on a Fujitsu TX300 s4 server with Broadcom NetXtreme Gigabit Ethernet card
It has an option for LSO & Jumbo frames. I had to google if that was the same as what you talked about
An alternative to using jumbo frames is large send offload (LSO), also known as TCP. segmentation offload (TSO).
I disabled these options and since then data is flowing again.
Thanks for the tip, RichardFrank!
I don't have a TCP Segment OffLoading option on my Server 2008 Standard x64 system's Intel 82566DM gigabit card, but disabling Large Send Offload v2 seemed to work for me.
I was having the opposite issue here. Moving files from host to guest was fine, but transferring files from guest to anywhere else was very slow. All firewall settings looked good. I saw this and had some hope. I disabled Large Send Offload v2 on my host, but this did not improve anything. Eventually I disabled Large Send Offload v2 on the guest and speed improved immediately!