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?
I've had this issue occur a dozen or so times since upgrading to lion. Sometimes a 'killall Dock' would resolve the issue sometimes a reboot would. Definitely not 100% tied to VMware in my case but it did seem like there was some corilation there.
Thanks for posting the work around Steve, I always love to see developers engage the user comunity, espeically when intermittent and hard to reproduce problems occur.
kenross and everyone else, the fix in this post, earlier in this thread, is very likely to work. Just try it. It worked for me. Thank you, Steve.
My experience on this problem, I'm able to replicate this in this way:
- I have a virtual machine open with XP
- start to install something on the host
- when the installer starts optimizing the system the new Dock try to add the new application icon to the Launcher
- in this moment both processes mds and Dock starts eating CPU and memory
- if I kill Dock and mds, new Dock and mds opens and starts eating CPU and memory again
- if I close Fusion than kill Dock, new Dock and mds opens but this time with normal CPU and memory usage
- I can now reopen Fusion
Seams that the problem has something to do with the new Laucher function of the Dock
Maybe these informations are helpful
I think you hit on what I was having problems with. I have only see the Dock issue once and it seamed to happen the first time Lion checked for updates. I called Apple and they had me reboot and reset the PRAM. I need to understand this better. I had them connect me with a senior tech anyway because the first tech had no idea if it would fix the problem. The senior tech was not sure either but both of them were very nice to work with.
I hope I don't see this again but at least I have a temp solution that seams to work.
OK, so it's pretty clear to me that this an Apple issue. Initially I was thinking my issue was with Vmware Fusion, simply because it made sense to me but after closely monitoring the Dock process again, I've come to the realization that it's a Apple issue, whether it is with Lion or the Dock process. Although, I'm more inclined to believe that it is a Lion issue because this never happened before I upgraded my iMac to Lion, and I've had it for 3 years. THis morning I came in and my 'Dock' process was at 9.37GB of real memory. I noticed that the 'Inactive' memory in the 'Activity Monitor' was showng nearly 7GB. I started closing all of my applications, and I noticed the 'Free' (Activity Monitor - System Memory) counter started to climb gradually. I left my Vmware for last, but after I shut it down the 'Free' memory counter climbed by 2GB, which is what my vm had allocated, so shutting down my VM released the memory as it should. The Dock process climbed another GB in size instead of decreasing. It just appears that Lion won't let it chew up more than 10GB, although I've seen it at 11GB before. I didn't realize that I had the option of using a different Dock application so I give it a try, although I'm hesitant to do that. I sure hope Apple gets this issue resolved quickly because I'm getting flashbacks of my days as a Windows user when I had to reboot my PC several times a week just to get some work done, which is why I changed to Mac in the first place.
It's been about 2 hours here. VMX edit is holding, keeping the dock cpu % down.
I'm running 10.7.2
Mid 2009 Mackbook Pro 2.26MHz
2xSeagate Momentus XT 750GB HHHDs in RAID0.
Today I got around to looking into why in the world my Dock process was eating memory like a deranged beaver, sitting at over 3GB of real memory, and 17GB of Virtual Memory, and CPU usage was nuts. A few googles and I came to these sort of threads.
Rebooted. Made the change suggested by Marc (and others), started the VM, and VMware Tools automatically reconfigured back. I don't particular care to remove access to the host filesystem frankly. I went next to changing the settings of the VM, turned off the 3D acceleration (I don't need it anyways), turned the Application Menu to Never show, and turned off all of the application defaults. After several hours, memory for dock is sitting ~29MB and Virt of 36.2MB, but this problem takes time (days?) to kick-in.
Several threads have suggested switching to Parallels was the solution, and I tried that when Fusion 3 began acting up in Lion, but the latest Parallels caused excessive idle load compared to Fusion, enough to destroy battery life by at least 50%. Not good.
So, when is someone in VMware (or Apple) going to actually fix this?
Hi Shel007, and welcome to the VMware Communities!
If you added the line to the vmx file and it vanished later, it's likely that either your VM was suspended instead of being powered off, or VMware Fusion was still running while the change was made. If that is the case, can you try again, being certain to power off the VM and close Fusion before editing the file?
That vmx option should be sufficient to prevent VMware Fusion from triggering the runaway Dock, but it is still possible for other applications on your host to trigger the same problem -- I believe that DropBox is one possibility, so if you are using that on your host, you might wish to disable it until Apple fixes the underlying issue.
I'm certain I made the change after a full shutdown. Upon start of the VM, and login, the system complained about not being able to open the shared folders and then the VMtools said it needed to make changes and reboot (which turns back on the sharing setting). But like I said, I prefer it to be on anyways.
I forgot to mention that I turned off Dropbox also (saw those suggestions as well).
The option you should add to work around this issue (isolation.tools.hgfs.notify.enable = "FALSE") should not disable sharing. It should only mean that your host won't be immediately made aware of file changes made by the guest in your shared folders -- with the above option, a Finder window on the host will no longer automatically refresh its view of a shared folder when the guest makes a change to a file.
Could I ask you to go through the process of changing the vmx file again and powering on the VM (including Tools complaining and requesting a reboot of the guest), then shut the VM down and attach the resulting vmware.log from inside the VM bundle to your next reply? That might give us a hint as to what's going wrong.
As Darius suggested please follow the settings that he kindly restated for you and as many have already done in response to my suggested workaround to fix the issue. We know the fix works as many users have confirmed this already.
The setting looks very similar to other settings so please pay very careful attention to the string to set.
This should not result in any disabling of the VMware sharing feature of file access between the Windows VM and the OS X host, or any reboot of the Windows VM.
My guess from the description given, what may have happened is that you set a similar setting to false which disables the VMware sharing feature completely and with mirroring also enabled will prompt the tools to put a dialog to ask the user to log off. This is because registry changes are made when enabling or disabling the mirroring feature, and also occurs if you enable or disable the sharing feature as a whole. This is not quite a reboot but could be mistaken for such if you are not paying close attention and are doing other work.
So just make sure that you have powered off the Windows VM, closed Fusion, then edit the VM's VMX file with the stated setting which should not already exist in that file. Start everything back up and log on to Windows your mirroring and sharing should still be as before and files still accessible.
OK, well while we're all spamming this thread, I might as well ask again whether there's any kind of fix in the works from Apple (or VMware I guess?)
The change notification feature is really essential for my workflows within my Windows VM. I used to make it work by accessing the Mac host's files through samba rather than through the VMware shared folders, but Apple pretty comprehensively broke smb sharing in Lion (among other things, logins are weird and keep on breaking, and smb frequently stops the laptop from sleeping when the screen is closed), so I can't go back to that.
So unfortunately my preference is leave the setting on, and just restart VMware Fusion (and Dropbox) whenever the Dock starts going mad (every few days). Obviously this isn't a very good situation to be in.
Indeed there are three suggestions out there on the net:
isolation.tools.hgfs.enable = "FALSE"
isolation.tools.hgfs.disable = "TRUE"
(Is one of the above total an error, or are there really two ways to set this same feature?)
isolation.tools.hgfs.notify.enable = "FALSE"
Apologies for not being precise, I set:
isolation.tools.hgfs.enable = "FALSE"
and commented out
# isolation.tools.hgfs.disable = "FALSE"
I went ahead shutdown the VM again, commented out my new addition, uncommented the original, restart Fusion and the VM. The dialog box from VMware tools says roughly (shortened) "has modified settings to enable sharing data with the host. You must log off to apply these settings. Press OK to logoff now...."
I have also read some suggestions to not use Unity mode. That's a bummer of a suggestion, but I'll do anything to have my system memory back while this issue is sorted out. We're all sort of grasping at lots of suggestions until someone (preferrably VMware) definitively (preferrably officially) states what is going wrong and what the correct actions are in the interim.
I will give the isolation.tools.hgfs.notify.enable = "FALSE" a try next.
Also, the KB article http://kb.vmware.com/selfservice/microsites/microsite.do?cmd=displayKC&docType=kc&externalId=2011360... is not emcompassing enough if indeed it is fixing the same problem that has been plaguing many of us.
CPU at 100% isn't the only indicator nor is it constant. I have watch it run at 100% today for a bit of time, and see it turn around and drop back to normal again. Memory growth by the Dock does seem to be consistent, but admittedly that can be a side affect of other program too, like the Dropbox mentions we've seen. If anything, the CPU usage might be a direct relation to memory allocation or swapping, I just don't know what is happening to be more accurate.
At any rate, I'd suggest a revisit to give a few more indications. I've added the changes to my VMX and will watch my system for any troubles over the next several days and will slowly turn back on features to help any watching the thread.
isolation.tools.hgfs.enable = "FALSE" is bogus.
isolation.tools.hgfs.disable = "TRUE" will completely disable shared folders. You don't want to do this unless you really don't need to use shared folders at all.
isolation.tools.hgfs.notify.enable = "FALSE" will work around the problem by disabling the file-change notifications which are causing Dock to go insane. As long as you haven't disabled Shared Folders yourself, the Shared Folders themselves should continue to work as usual except for the lack of file change notiifcations being passed to the host operating system.
Both Steve Goddard and myself are VMware employees (we have the "vm" logo underneath our avatar icons on the left of these posts), and Steve is the guru of Shared Folders, so if he says that you can fix this specific issue with that option, it's a fairly sure bet that he's right. In fact, I am confident that if you were seeing Dock go crazy when you were running Fusion, and you've now added the required option to work around the problem, you can undo any and all other changes you made while trying to fix the problem, and you can then go back to using your virtual machine(s) as you normally would. I'm not aware of any relation between Unity and this problem.