Shared Folders in Fusion slower than in Parallels -- any advice?

[jimsold]

I was a mostly satisfied user of Parallels (version 2.5) but I bought the early bird special license for Fusion and have been trying it out the past few days.

One thing I was disappointed with in Parallels was the speed at which file reads and writes from a shared folder happened. I keep my subversion check-out for a company project on my Mac file system and some of the files are Windows-only binaries -- discrete event simulation files for the product Extend.

With Parallels, it was slow but usable to double click a file in a shared folder and have the Windows app open it. With Fusion I seem to have to wait 3 or 4 times as long for a double click to have the app open the file. The file is a 15 meg file so that is a factor. But Parallels could handle files of this size.

If I copy the file to my virtual disk, and double click the copy, things are very speedy but I want to keep my files where my Mac subversion client can access them.

Is this common experience -- really slow shared folders?

Any advice to speed things up? I tried to use Windows file sharing from my Mac rather than Fusion shared folders and it was no better -- might have even been worse. Mapping the share to a drive doesn't help.

Maybe this can be improved in the next Fusion release.

[jimsold]

As a follow up, I have a Dell PC on my company network from which I also share a drive.

I have a copy of the same subversion sandbox there. If I navigate to a folder with one of my huge binary files and double click it, the application opens it in seconds -- very acceptable performance!

But when the file is in a Mac folder, it remains very slow.

I am running Mac OS X 10.4.10 and Fusion is using bridged networking.

3 gig Core 2 Duo Macbook Pro. 512 megs allocated to the guest.

[jimsold]

Sorry to keep replying to my post, but I am discovering some more weirdness.

I un-installed and then re-installed VMware tools.

I should note that this VM was created from a Hardware Version 4 can from my corporate network, created I think with a PC Workstation instance. I upgraded it to Hardware Version 6 as documented in the help. I originally installed Fusion's VMware tools on top of whatever had been pre-installed in the can I copied.

I then re-tried my open the big file experiment. When the file is in the VMware virtual disk or on a real PC share, it is quite speedy to open.

I had un-set Fusion's shared drive option and accessed my Mac's home directory using Windows sharing on the Mac. I double clicked the file from its Mac location and the open process dragged on and on.

I had activity monitor open on the Mac and saw that for several minutes, the vmware-vmx process was using 100% cpu and the smbd process was using 25% cpu. After several minutes, the file finally opened and the smbd process shrunk to almost no cpu and the vmware-vmx process went way down as well.

I suspect this is not normal.

Can anyone offer some suggestions as to what to try?

[jimsold]

Once again, a self-reply.

It looks like the problem is not with Fusion but with samba/windows file sharing on the Mac.

I accessed my Mac's shared home folder from my Dell PC. I went to the folder with the big data file that I am double clicking to open with a Windows app. When I double clicked, in the Mac's activity monitor, I see an smbd process start up and consistently claim 25% cpu utilization. This goes on for MINUTES!. Finally, the PC app is able to open the file after a very long delay.

So there is some gross inefficiency going on.

If this is the case, why can't Fusion's shared folder mechanism by-pass samba and somehow get more efficient access to my files. Drag-copying files to the Fusion VM desktop is very fast. Once the file is there, using the PC app works very well.

I have noticed that copying files from Fusion back to a shared folder (or to a samba mounted Mac file share) is also unexpectedly slow.

I guess I can hope that Leopard will do a better job of Windows file sharing.

[shshjun]

i wouldn't think samba being in picture in general. i've never heard of samba as dependency for fusion and vmware workstations. i am not at my mac so not able to check my copy until tonight.

could you please disable your samba setting and run another test?

[jimsold]

I turned off samba (Windows File Sharing), re-enabled Fusion shared folders, and repeated my test -- double clicking a file on the share that opens in a PC application.

The delay to get the file to open was noticibly less than when using Windows File Sharing (not Fusion shared folders). But the vmware-vmx process still climbed to 100% cpu in activity monitor and the time until the file was fully open was still much longer than opening the file copied to the VMware virtual disk, or opening the file from a real Windows shared drive.

I read in these forums that using Windows shares was supposed to be faster than Fusion shared folders.

But that is not my experience unless the Windows share is on a real PC.

And as my last post before this documents, when accessing my Mac's shared folder (using OS X Tiger's Windows Sharing) from a real PC, performance is equally horrendous.

So for me at least, something is amiss at a deeper level than Fusion's shared folder concept.

[shshjun]

i had a few tests myself with notepad being the application to open a sample 15M text file.

to open inside windows VM itself takes 26s; to open from shared folders takes 27s, or equal time.

however, i did notice that sometimes the time to start gaining access to the file in shared folder itself can take longer time - indicated by cpu usage: being accessed with cpu usage around 40%; to gain access with no significant cpu usage increase.

but above only happens when using windows explorer. above being case I.

test case II: from command line: both takes about the same time

notepad c:\15mtest.txt

notepad
.host\shared folders\myshare\15mtest.txt

test case III: use file-->open from notepad, but do not browse to it, paste the path/filename to open the file: both took about the same amount of time, again

conclusion: shared folder in windows explorer (WE) caused your problem (because it's via entire network blah blah). WE takes time to locate the file sometimes. your application loads the file as if natively, that is, no difference.

this is rather a windows problem - windows explorer with network folders, be it mapped to a local driver or not.

hope this helps and please try to see if you can validate above test results.

[jimsold]

Thanks for the investigation and observations.

I also did some more testing. I went back to Parallels and tried to duplicate my double click of a file located on a Mac shared folder.

When I use Parallels built-in shared folder implementation, opening the 15 meg file from Windows explorer was almost as fast as when I opened a file within the VM hard disk image. In fact, I couldn't tell the difference in speed -- in each case the application opens the file in a few seconds.

However, if I access the folder as a Windows Shared folder using its network address, I get the same poor performance I observed earlier. Both the Parallels process and an smbd process are consuming loads of cpu and it takes several minutes for the application to complete opening the file.

So I conclude that something is wrong speed wise with the Mac's own support for Windows shared files. The bad behavior happens when I use Parallels, Fusion or even a real PC to access the folder via Windows file sharing.

But the bottom line is that Parallels somehow gets the double click behavior right when I use Parallels own shared folder feature.

For me, this is a strong reason to stick with Parallels for my day-to-day Windows work on my Mac. I have grown to rely on files in a shared folder being treated as if they were ordinary PC files when operating in Parallels. I thought I could get the same experience with Fusion and right now I do not.

I am still using Parallels 2.5 -- there are many negative reports still about misbehaviors with Parallels 3.0.

Perhaps the next releases of Parallels and Fusion will bring more feature parity.

Message was edited by: jimsold -- corrected spelling

jimsold

[ch2day]

Hi Jim -

I was experiencing the same slow access you are describing, but it seemed to be fixed by disabling Avast! (antivirus) on-access protection. At least in my case, that was the issue. I hope this helps.

Carlos

[Jayne_Cobb]

Nice. That was it for me. Coincidentally, by adding the shared folder to the exclusions list I was able to get around the problem and leave my on access protection on.

[nextech]

JimSold,

I had a similar problem with extremely slow shared folders, I have an Apple Mac Pro (2008/2009) and from my experience the problem seems to be

related to "Large Send Offload" being enabled on the host network

adapter. This seems to be very common among machines with an

Intel-based gigabit ethernet adapter in the host machine. It seems to

be common on Windows, Apple Mac OS X, and Linux users that all seem to

have a Gigabit Ethernet adapter (usually an Intel 1000 based adapter)

or they have a network adapter that supports Large Send Offload, and

for some reason this seems to be enabled by default, and it seems to

cause problems with VMWare products. I posted the correct solution to

this problem with detailed instructions here:

http://communities.vmware.com/message/1191790#1191790

I hope this helps, I believe this should solve your problem. Please

close this thread out, and mark it as "Answered" and If you find

this answer helpful, please do take the time to award me the "Correct Answer" points.

Thank-you!

Mark

[onomatopej]

Same here on my side, just testing Parallels 4 and the large Visual Studio project build places on Shared Folders is about 2.5x faster with Parallels in comparison to VMWare.... huh

[Kadu123]

This has annoyed me for ages and I have finally found the proper cause/solution:

This  slow performance, specially the 5-10 seconds delay between clicking on a  folder/file and actually getting it opened, happens because Widnows is  trying to access the share via NetBIOS protocol. Once the NBT attempt  fails windows reverts back to TCP, which then works OK.

So the solution is to disable netbios over TCP/IP on all network interfaces inside the Windows client.

Hope this helps more people out there.

For Windows XP, Windows Server 2003, and Windows 2000

1. On the desktop, right-click My Network Places, and then click Properties.
2. Right-click Local Area Connection, and  then click Properties
3. In the Components checked are used by this connection list, double-click Internet Protocol (TCP/IP), click Advanced, and then click the WINS tab.
   
   Note In Windows XP and in Windows Server 2003, you must double-click Internet Protocol (TCP/IP) in the This connection uses the following items list.
4. Click Disable NetBIOS over TCP/IP and then click OK three times.

For Windows Vista

1. On the desktop, right-click Network, and then click Properties.
2. Under Tasks, click Manage network connections.
3. Right-click Local Area Connection, and  then click Properties
4. In the This connection uses the following items list, double-click Internet Protocol Version 4 (TCP/IPv4), click Advanced, and then click the WINS tab.
5. Click Disable NetBIOS over TCP/IP, and then click OK three times.

For Windows 7

1. Click Start, and then click Control Panel.
2. Under Network and Internet, click View network status and tasks.
3. Click Change adapter settings.
4. Right-click Local Area Connection, and then click Properties.
5. In the This connection uses the following items list, double-click Internet Protocol Version 4 (TCP/IPv4), click           Advanced, and then click the WINS tab.
6. Click Disable NetBIOS over TCP/IP, and then click OK three times.

[danatkorg]

Perfect! That did the trick for me (on Windows 8.1).

[carlospuk]

Unfortunately, this solution did absolutely nothing to help me, on Windows 8.1, running VMWare Fusion 6 and Visual Studio 2013 RC3.

If anything, my build times were longer!

[vslavik]

Same here. That's because the Visual Studio issue is a different one — even if Shared Folders perform "well" (i.e. aren't as extremely slow as in the OP in general use), Visual Studio's filesystem usage pattern in particular is something that VMware's hgfs (shared folders) driver can't handle well and it shows in these significant performance degradations.

I reported it to VMware in detail, with logs and everything, several years(!) ago. VMware is aware of the problem, they asked for logs, confirmed it, said they would look into it and add VS to their performance testing, just not for the next year's release - that was a few releases back. Rinse and repeat annually. By the time of Fusion 6, I gave up and switched to Parallels (it isn't particularly pleasant to use, but boy, is VS2013 fast!).

With today's release of Fusion 7, I did my annual performance testing with VS2013 and a solution I use daily, on a 2013 iMac (i.e. modern HW) and with the same VM freshly migrated to Fusion:

Last year's Parallels Desktop 9:    7m36s

Just-released Fusion 7:    17m32s

Yes, that's right, still exactly as bad as before.