Thanks Adriel - yes, like you mentioned, that works but takes me back to the Virtual Box days of sharing.
This seamless integration is extremely important to me, so I just went ahead and bought parallels last night (they have a $30 price for VMWare fusion owners :-) ). I think I am going to keep both - if one bombs I'll use the other. I've now moved to parallels and haven't noticed any such issues (yet) and its blazing fast (so far).
For anyone who can reproduce this,
I am a developer on the VMware Shared Folders feature, and sorry for the slow response in getting to this.
Please could someone enable the Shared Folders sharing again for the Windows VM and then suspend or shutdown the VM.
Quit Fusion and then edit the vmx file for the VM and add the following line if does not already exist (which it should not):
isolation.tools.hgfs.notify.enable = "FALSE"
(The file resides in the same folder along with all the files for the VM, is the same name as the name of the VM and ends with the extension ".vmx".)
Restart Fusion, restart the VM, ensuring that it has had a reboot if you suspened and didn't shut the VM down.
See if the problem reappears again.
From the descriptions that I have read, and system log events that occured, it seems that the directory change notification feature may be the cause of the issue. This feature monitors file system events on the host and notifies applications running in the VM, such as Windows Explorer so they can refresh their cached information of directory contents automatically. We poll the fsevents for this and Apple may have changed this and caused the feature to break.
Since it has not been reproduced in house so far from what I can tell, disabling this feature would help us narrow down the cause and maybe discover what Apple have changed.
The line you have listed:
> My vmx file has this line: isolation.tools.hgfs.disable = "TRUE"
is for the shared folders feature and since the disable is set to true means that for your VM it is disabled. Changing it to FALSE would enable the VMware Shared Folders feature again. However, it must be done while the VM is not loaded or running. Really it is simpler to just use the Fusion UI to enable and disable the feature.
As Nick already stated that does not apply to the particular file system feature for notification to of updates to folder contents which I am wondering if is the issue here.
I followed your directions and applied your requested change but within an hour the Dock was running amuck again. Just checked to make sure my .vmx file changes held, and it looks like they did, here's a snapshot of my .vmx file:.encoding = "UTF-8"displayName = "Windows 7 x64"roamingVM.enabled = "FALSE"isolation.tools.hgfs.notify.enable = "FALSE"roamingVM.useBackgroundSync = "FALSE"
Note: There are two other nodes for encryption (which I won't post here).
Over the last two days, with folder sharing turned off, there have been no issues with the dock. Interestingly, in this case where the dock was going wild again, it tamed right back down as soon as the VM started the process of suspending - there isn't even a need to restart the dock. During the suspension is there a hook being withdrawn from the dock?
If it helps, this is running on a "MacBookPro6,2" with 8GB ram under system 10.7.2.
I'll give it another go, but it doens't look like this is the Holy Grail.
After an hour or so of running my Win7 VM today my Dock started running wild again. I suspended and made the requested change. Unlike AdrielH, I had to kill my Dock after suspending my VM. The memory and CPU usage stayed abnormally high.
I will post again after I've had some time to observe the Dock process.
Thanks for trying. It is good to know either way. It all helps trying to narrow things down.
Another thing we can try, is to watch the file IO going on. We can try from the Windows guest and maybe even on the OS X host.
Maybe something is repeatedly changing a file from the VM side over the VMware shared folder on the host which is causing the issue.
So you can download process monitor from http://technet.microsoft.com/en-us/sysinternals/bb896645 here and run it in the guest.
It is straight forward to install and run it as administrator and set it to monitor file IO. You can even filter for path names that contain vmware-host.
Anyway, when the issue occurs, if you can run it in the guest, monitor the file IO for a short while, then save it to a log file and send it to me or let me know where you put it and I can take a look. You won't need to monitor the registry, network or process activity for this. That should keep the quantity of data down.
If there isn't any file IO going on from the guest, I would be surprised but that might mean then the issue is contained with our server side talking to host file system. Again, though it is narrowing things down.
You could try the standard troubleshooting suggestions: http://www.macosxhints.com/article.php?story=2004011205473937 http://forums.osxfaq.com/viewtopic.php?t=7269 In particular, you should remove all startup items from the list under your user account in the Accounts preferences. Note that to stop these apps from starting up at login, you need to remove them completely from the list in the Accounts preferences
I was also going to suggest fs_usage and/or dtruss to see if that helps and monitor the vmware-vmx process and the dock process.
Maybe able to give us some hints if it is really a file IO issue here.
See man pages for these