I updated to OSX 10.7.2 yesterday. Since then, if I launch two VM at the same time, and ONLY then, the Dock will start eating CPU and memory. The memory usage will keep climbing until it takes every last available amount of memory. The system will come to a complete crawl. Killing Dock causes it to relaunch of course and then it starts all over. It does give me a temporary reprieve however until it can reach max available memory. I'm running on a MBP with 8 GB of RAM, a hybrid SSD main HD, and my VM's off of a secondary HD in the optibay. I'm wondering if anyone else is seeing this issue or has a solution?
Disabling Shared folders seems to have helped me, no problems today.
Hello,
here some support logs. I have only one VM, it was running since at least one hour, probably 2. I can’t tell exactly when the Dock process started running crazy.
I observed that the mds process is also eating up a lot of CPU at the same time, every time. But not as much.
Cheers
Turned off shared folders yesterday, and haven't had a runaway dock since!
It sounds like this is the cause...heopfully they can fix the issue, I for one, depend on shared folders.
Oh boy, I'm glad I found this thread.
The dock has reguarly been taking up close to 6GB of memory pretty much every day making my computer completely unusable.
I thought the OS was bonked. You are correct, upon not using VMware Fusion, I don't have that problem at all.
Not using Shared folders is not an option for me at all. I need it to share my desktop as well as folders with windows - my work environment is split between both platforms, so disabling it will make it useless for me. I have temporarily switched to VirtualBox till VMWare fixes this.
VMWare support: please do fix this urgently!
thx
I have the same problem, I have 16GB ram, 2011 MBP, but it maxes out CPU up to a point, that after 48 hours it crashes the VMs!
VMware, please fix ASAP! - thanks
arjunrc, it's not quite as convenient, but you can turn on File Sharing on the mac and mount the share from inside Windows, or turn sharing on in Windows and mount the share from the Mac. Works like a charm.
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).
regds
arjun
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.
Steve -
My vmx file has this line: isolation.tools.hgfs.disable = "TRUE"
This is pretty similar to the line you asked to add, so wasn't sure if it mattered.
To others: please note that the vmx file is inside the virtual machine package; you have to right-click "show package contents" to reveal it.
I have the dock problem too and am using shared folder. I will add the line in my vmx file as soon as I can shut down the VM.
Arlo, your line is related but not the same thing. The line that was given applies to notification.
Nick
Is it possible to test this out if you're using your bootcamp partition?
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.
It should be fine to use a boot camp partition running as a VM with the line I suggested added to the vmx file for it.
Steve,
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:
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
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/dtruss.1m.html
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/fs_usage.1.html
Thanks.
Something the Apple devs have pointed out with the file system events, is that DropBox has been known to cause issues and slow downs like this.
So if that happens to be installed, it could be worth temporarily disabling/removing too.