I have a powerful Windows 7 x64 Ultimate workstation. On it I have installed VMware Workstation 9. It's fully up to date.
Windows 8.1 Pro Preview and Windows 8.1 Enterprise Preview Guests can barely transfer groups of files to/from the host system or other VMs. Performance is dismal.
File transfers seem to start out being able to access a few files fairly quickly but almost immediately everything slows to a crawl, slowing the transfers down to near zero data throughput. It's trivial to reproduce - I just need to try to pull (copy) a folder with a few tens of megabytes of files from host to guest. There is almost no network load, as measured by Task Manager, Resource Monitor, etc., yet the VM and often the host both often seem bogged down.
All other Windows guests, including Windows XP, Windows Vista, Windows 7, and Windows 8 RTM work great - no problem. Network transfers run as fast as the drive array will support.
Networking is Bridged in all cases.
Observations that may be pertinent:
- The transfer may copy several files quickly, then almost immediately slows to a virtual crawl. I have occasionally seen it fail, but usually it struggles along at incredibly slow throughput speeds.
- There is no problem reaching the Internet (e.g., browsing) from the Windows 8.1 guests. It runs clean and fast. Only Windows networking - e.g., copying files between Windows systems - is affected.
- The problem seems to be symmetric; i.e., Windows Networking from the host to the guest, or between guest Windows VMs is also slow no matter who initiates the copies.
- The host system sometimes lags while the guest is accessing it, as though a common resource is tied up. Occasionally the fans will speed up, as though there's a heavy CPU load, though I haven't seen much of that in Task Manager.
- PING from the guest to the host is IPv6 and succeeds 100% of the time and time<1ms, with VERY occasional delays longer than that - even while a lagging transfer is taking place. The problem seems to be in the network stack somewhere above IP.
- Some file types seemed to transfer faster than others, leading me to initially wonder whether anti-malware software (I use Avast! on the host) could be involved, but it's not consistent. Disabling AV software doesn't help. I later thought this was probably just an issue where .exe and .dll files are generally larger.
- It doesn't matter whether using a mapped net drive or a UNC file name, the problem happens both ways.
- No obvious errors show up in the event logs to give a clue what's happening, though the event log is not clean (e.g., "The server {AB807329-7324-431B-8B36-DBD581F56E0B} did not register with DCOM within the required timeout."). However, these errors don't seem consistent with the laggy network operation.
- The problem happens with a bone stock, just installed Windows 8.1 guest, even without VMware tools installed.
- Host and VMs otherwise work flawlessly. This is a well-maintained, perfectly stable system.
This is typical:
Based on my double and triple checking, this is not a simple configuration issue, though I will be happy to verify settings on request.
My intuition tells me the virtual network adapter is somehow incompatible with Windows 8,1, but that's a guess.
Thanks in advance for any help you can offer. Please let me know if there is more information I can provide, especially if there is diagnostic information somewhere I'm neglecting.
-Noel
I don't mind trying things on it. It's a VM after all, and we do have this wonderful snapshot feature. 
I did netsh interface tcp set global autotuning=disabled, then rebooted (just for good measure).
There was no change to the symptom. Probably says the bug/glitch isn't in the autotuning feature.
My own personal thoughts are that maybe somehow the change in the Windows scheduler so that interrupts don't occur at regular 1/1000 second intervals but are now variable has somehow affected a driver or protocol implementation.
-Noel
Not sure whether VMware re-reads the .vmx file in entirety so I closed the tab and reopened it after making the above mod.
Ran the folder copy again. Iinitially I thought maybe it was better, because it started out fast, but it ran into a wall at about 10% complete, then was showing numbers as small as 0 bytes/s.
Probably just random happenstance that it looked a little different. Next time I tried it the symptoms were the same as in all prior tests.
-Noel
Okay, that was easy enough. There was only one of them.
That seems to have worked. The entire folder now copies in a few seconds. Bravo!
Now the $64 question. What did that change just do?
Edit: Removed incorrect statement about IPv6.
-Noel
