Parallels Desktop 7 Performance Under Mountain Lion

I

IdMGuy

Bit poster
I am running a brand new Retina Macbook, 2.6ghz, 8GB RAM. Parallels 7 was running very smoothly under Lion (WinXP x86 and Win7 Ultimate x86/x64). After the upgrade to Mountain Lion, I initially ran into issues with these VMs not wanting to perform shutdown and log off once in the Guest OS. This does not seem to be an issue 'if' you rebuild the guest under Mountain Lion.

In addition, all guest OS's seem to take longer to boot up and their GUI is not as responsive as under Lion. When enabling fullscreen mode, they change fairly quickly, but the screen conversion is not as smooth as under Lion. When issuing the command to exit fullscreen, either from the keyboard or the Parallels menu bar, there's at least a 3 second delay before the window reacts. This was not the case under Lion.

Has anyone else on the new Retina Macbook or other Macbook experienced this?
 
Are you running the latest version of Parallels 7 (15104)?

Try to uninstall and reinstall Parallels Tools in each VM.
 
I made sure parallels was fully updated. The issue experienced occurs even if a brand new virtual is created under Mountain Lion, but I did initially try un-installing and re-installing parallels tools. I'm going back to Lion for now. I haven't seen anyone specifically complaining about this issue on the retina and parallels 7 yet.

I should also note that I had not loaded any additional software. Base OS, loaded updates, installed Mountain Lion, installed parallels 7, searched for a parallels update (software up to date).
 
Last edited:
Yes, slow bootup.

Reason seems to be Parallels is updating/"touching" the file prl_usb_connect.kext (located in /System/Library/Extensions) *every* *single* *time* you reboot!!! You'll notice the timestamp on that file changes constantly during each reboot.

If you right-click and select Show Package contents, there's a symlink file there that gets a new timestamp during each reboot. This file points to the real prl_usb_connect.kext located under a Parallels 10.6 directory.

Why it's referencing a 10.6 kext when we're running 10.8 ML I don't know.
Why it needs on touching that file I don't know.
I've tried recreating my kextcache but it's useless because of this Parallels behavior.
Because of this always new timestamp, the kernel boot cache in OSX is not being used and thus always get recreated each time you boot... thus the long bootup times.
 
Ruevoq said:
Yes, slow bootup.

Reason seems to be Parallels is updating/"touching" the file prl_usb_connect.kext (located in /System/Library/Extensions) *every* *single* *time* you reboot!!! You'll notice the timestamp on that file changes constantly during each reboot.

If you right-click and select Show Package contents, there's a symlink file there that gets a new timestamp during each reboot. This file points to the real prl_usb_connect.kext located under a Parallels 10.6 directory.

Why it's referencing a 10.6 kext when we're running 10.8 ML I don't know.
Why it needs on touching that file I don't know.
I've tried recreating my kextcache but it's useless because of this Parallels behavior.
Because of this always new timestamp, the kernel boot cache in OSX is not being used and thus always get recreated each time you boot... thus the long bootup times.
Click to expand...

These are red herrings:
- "Referencing a 10.6 kext": The 10.6 doesn't mean it's a 10.6 only kext, likely means that's the lowest version of OS X it supports.
- All the Parallels kexts are little more than 1 MB this takes a fragment of a second to load them into memory.
- Finally whatever is happening here that you described also does under Lion.
 
Thanks for your response.
But that doesn't answer the question.

I'm not talking about the size of the kext slowing thing down by "fragments of a second" as you say.
And also they're not more than 1MB.
prl_usb_connect.kext is only 264KB

I'm talking about why the timestamp on this file always changes on every reboot, which forces OSX to throw out it's previous cache, and rebuild the whole cache again during bootup, contributing to slower bootup times.

See man pages for Kextcache.
- "The kextcache program creates kext caches, which speed up kext loading
operations. It is invoked automatically as needed to rebuild system
caches."

If OSX doesn't have to rebuild the cache *EVERY TIME*, it will speedup boot considerably.

Now, It's okay to rebuild the cache if something new gets added to the S/L/E directory.
But this file prl_usb_connect is messing up the whole caching process because of it's updated timestamp.
OSX thinks it's always a new kext, forcing a rebuild.

My real question is: Why is this file prl_usb_connect.kext always get a new timestamp during every OSX reboot.
Why does Parallels always need to "touch" the timestamp on this file.
 
I'm just saying that is red herring, that the slow boot is unlikely related to the file being touched.
Also when I mentioned 1 MB I was referring to all Parallels related kexts.

What evidence do you have the cache is being rebuilt every time OSX (Host, not guest) boots up?

When you mention slow boots are you talking about VMs (guests) or the Host?

Because if there is a issue with rebuilding the kextcache this problem would only affect the Host booting up and not the VMs which is the topic of this thread.
If you still want to pursue the question about that particular kext I suggest you open a different thread.
 
Last edited by a moderator:
What evidence do you have the cache is being rebuilt every time OSX (Host, not guest) boots up?
You can check for the date/time under System/Library/Caches/com.apple.kext.caches/Startup/


When you mention slow boots are you talking about VMs (guests) or the Host?
I was talking about OSX, the host. (not the VM)


Never mind, I found a FIX.

Mulling on this problem, it is the date/time of the symbolic link file inside prl_usb_connect that is changing which forces the rebuild.
So what I did is I copied the kext it is pointing to (i.e. right-click, select Show Original, it points to the kext in the Parallels 10.6 directory), deleted the original symbolic link, and replaced that with the actual kext from the 10.6 directory.

Repair permissions, then rebuild kext cache using the command.
sudo kextcache -v 1 -a x86_64 -m /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext /System/Library/Extensions

Boot time is now in the 30-50 second range, instead of almost 2 minutes.

Checked operation of USB devices inside VM guests and they're still working no problem.

Problem resolved.
 
I am experiencing the exact same problems, stuff that used to boot in seconds takes forever. I just switched to Mac two months ago to get away from just this sort of thing. I might as well have stayed with Microsoft.
 
I have the same symptoms with mountain lion (and more). Guests that booted up and ran smoothly now take ages to boot and my host also seems to be struggling at the same time which it never did before. I cant ge any guests to read my dvd drive either. Not for new or existing guests.

So far I have to say I dont agree with parallels claim that there software will always run properly on new version of OSX at all... its been nothing but trouble since my upgrade. (I have tried uninstalling and re-installing parallels and paralleles tool. no dice).
 
You must log in or register to reply here.
Back
Top