Parallels 10 on Mac OS X 10.10 DP6 - All Windows Guest VMs Slow

Christopher, thank you very much!
I added your file to our internal investigation.

 

@sergey

One question:

Don´t you think that the information that while moving the cursor around the screen ( even outside the virtual window !! ) does accelerate the speed of Parallels is important?

I believe this information must be important!


Best regards
Gregor

 

Hey guys,
I am having the same problem. CPU load on one core only remains between 100% and 250%.
System configuration: MacBook Pro (17" Early 2011), Yosemite 10.10, 2,3 GHz, i7 CPU, 8GB RAM 1333MHz DDR3.
Guest OS: Windows 8.1

So far I tried re-installing Parallels 10, checking for interrupt problems with trace_intr (none present) and trying an empty test machine (no OS, still over 100% on one CPU). I also tried several options using a nvram terminal command. No success.

I purchased Parallels 10, because I read several reviews that shows a significant performance advantage compared to VMWare. This is simply not usable, so for now it is wasted money.

I am expecting a quick fix, otherwise I will claim a refund!!

 

I just want to add my 2 cents here as I seem to be having the same problem as everyone else, and, like many, moving my mouse seems to speed up the VM. I've tried installing/re-installing both Yosemite and PD 10 in various orders, reducing the number of available cores to one, adding the debugging parameter, but to no avail. There was another poster in this thread that has the exact same setup as I do: Mid-2011 21.5 iMac, SSD Drive (after-market), 32 GB RAM, 2.5 GHz i5.

 

Your current solution/workaround is doing this from Terminal: sudo nvram boot-args="debug=0xd4e"
If your iMac has a busted internal DVD drive and you need to use a superdrive, you need to change the arguments accordingly.
Read more about this here: http://forum.parallels.com/threads/parallels-10-running-slow-on-yosemite.326205/

 

Thanks, Martin. I actually tried it, and it caused my machine to not start at all...got stuck during boot. Doing a PRAM reset fixed that problem.

 

Sorry to hear that didn't work for you. It's helped a bunch of people, including myself, solve the issue. Do let us know what else you find.
Some other temporary workarounds were using a single core for your VM, but that didn't work for me.

 

With regards to using a single core. I do believe that using a single core is the recommendation that Parallels make even if there is nothing wrong with your VM - this is simply standard protocol.

 

I had the following exchange with Marat Tuktarov who was very helpful:
This is a thread format so you need to read from the bottom up. I switched back to two cores but it seemed very slow and sluggish so I went back to four cores and its useable but still not like it was under Mavericks and Parallels 9. Hopefully an update will get everything working properly again!

Chris,

Sometimes, setting all the Mac cores can slow down the Mac but you win nothing in virtual machine performance. We always recommend using 1 or 2 virtual cores.

Best regards,
--
Marat Tuktarov
Customer Support Engineer
||Parallels

- Wed Oct 22 11:33:19 2014]:

Hi Marat,

I will make the changes as you suggest. I have always run 4 as I was figuring with hperthreading my i7 has 4 real cores and another 4 virtual cores but maybe my logic is wrong??

My machine has been running much hotter than normal but that seems to be a Yosemite thing just as much as a Parallels problem!

Best regards,

Chris

On Oct 22, 2014, at 12:27 AM, Marat Tuktarov, Parallels wrote:

Chris,

The fact that virtual machine takes more CPU than any other process is normal. You are running a separate operating system - this is tens and hundreds of processes inside it.

Moreover, from the problem report I see that virtual machine consumes 38.2% of CPU time, that is reasonable.

Also, I would like to recommend you to decrease the number of CPU assigned to virtual machine. From the problem report I see that you have 4. Change it to 2 (it is not good if virtual machine uses all the Mac CPUs): open virtual machine configuration (in Mac menu bar 'Actions' > 'Configure' > 'CPU & Memory').

From the attached Terminal output I see that original issue is resolved.

Should you have any additional questions, please feel free to reply during the next 14 days.


Best regards,
--
Marat Tuktarov
Customer Support Engineer
||Parallels

- Wed Oct 22 11:10:19 2014]:

Hi Marat,

I did the debug Terminal suggestion and it seems to be a lot better although not perfect as the %CPU usage is still much higher than any other process when doing anything in the VM.

I have attached a zip file with three output files created by following the KB you linked. This was done before I did the update.

 

@Christopher_Kessell WOW! You actually had an email exchange with someone at Parallels? I have logged a ticket, uploaded files etc. and not heard a thing. I don't see any formal acknowledgement of this issue from Parallels and that they are working on a possible workaround/patch until Apple/Parallels/WMWare come up with a proper solution. Did Marat acknowledge the issue and they are working on it? Do you know if they consider this a priority issue or not? Just curious.

 

I am finding that sine I implemented the terminal vram fix, Parallels has improved with each useage. It is now working better than it did with PD8.

 

Hi Martin,

The only reply from Marat that I left out is the following which is pretty much what others have already posted. Apparently this is a known problem with the 2011 iMacs.

Hello Christopher,

Thanks for contacting Parallels Technical Support!

Most probably the issue is caused by the interrupt storm, which is the known Mac OS X 10.10 kernel issue that happens on the 2011 year iMacs. Please follow this article to confirm: (http://kb.parallels.com/en/117114 NOTE: do not follow _step 7_!).

Please set the boot argument on the Mac to workaround the issue:

1. Run **Terminal** (/Finder/Applications/Utilities/Terminal.app) and execute the command:

sudo nvram boot-args="debug=0xd4e"

You will need to type Mac Administrator password and hit **Enter (return)** (you will not see the symbols you type. That's OK.)

This command enables the debugging mode. It means that if Mac crashes it will attempt to collect the kernel dump. It will not affect the Mac performance.

2. Reboot your Mac

If it does not help:

1. Reboot your Mac again.
2. Start Parallels Desktop and run virtual machine.
3. Follow the instruction from http://kb.parallels.com/en/117114 NOTE: do not follow _step 7_!
4. Save the Terminal output in the text document.
5. Generate and send a problem report (http://kb.parallels.com/en/9058 ). After the report is sent you will see its unique 8-digit number in the pop-up window on your screen. Send us this ID number. NOTE: we will be unable to find your problem report without ID number.
6. Reply with the Terminal output and problem report id.

I mark this request as 'Pending Confirmation by Customer'. Should you have any additional questions, please feel free to reply during the next 14 days.

Best regards,
--
Marat Tuktarov
Customer Support Engineer
||Parallels

 

Sergey,
I am posting my files from the trace_intr script. There are three files: 1 file for the VM running with 2 cores (how I ran it under PD 9), 1 file for the VM running with 1 core, and 1 file for the iMac in an idle state. I have the mid-2011 iMac 21.5, 32 GB of RAM, and a quad-core i5 at 2.5.

My Report number is 52237467

Any help you could provide would be great. I'm having to bind my Mac to a Windows AD in the meantime, and it's causing both me and the network admins a lot of headaches.

Forgot to add: I've tried using the debugging command mentioned in this thread. All that does is lock up the device: I have to do a PRAM reset in order to get it to boot.

Thanks!

 

It seems that the topic is dying, and Developers are inactive! For what I paid my money? It is impossible to work with a virtual machine on Yosemite! The problem is clearly mass, and on the website of the developer still no instructions even for a temporary solution! Outrage! Parallels, Wake up, how can you pretend that nothing is happening?

 

I would agree. Although the vram fix has worked for me, there must be thousands of users who know nothing of this forum and are really struggling. It is very poor of Parallels that they have not made any kind of statement or come up with an update to fix this issue for their users.

 

The vram fix has worked for me too! Thank you for your help

 

I have the same trouble, last fix 10.1.0 (28600) did not change nothing. Unbelievably stupid situation.
I have two 27-inch iMacs:
1. iMac (27-inch, Mid 2011) 3,1 GHz Intel Core i5 16Gb RAM, OSX 10.10
2. iMac (27-inch, 2014) 3,1 GHz Intel Core i7, 1Tb Fusion drive. 32 Gb RAM OSX 10.10
The issue occurs only on 1st configuration!
It probably can be helpfull for those who have to fix it
Somebody from Parallels? Do you hear us?

 

This seems to be some problem with Apple, not with Parallels (though it does show up pretty much only when using Parallels). Even if you just reboot your Mac fresh and then run the trace_intr program, it shows more than 300k interrupts/second for the ACPIPlatform kext. I too have a mid-2011 iMac. Parallels probably can't do anything about it until Apple fixes this, though they could publicize the nvram fix as an interim fix.

 

You do have to wonder given the lack of action either by Apple or Parallels whether there is an intention to fix this issue. It could be that Apple take the view that this is a minor issue only affecting a comparatively small number of machines (which they now class as old) when using a particular programme. It could also be the case that Parallels simply haven't bothered to inform Apple there is an issue with some customers using their products.

Either way, it is disappointing from a customer view point. As said previously, the people I feel most sorry for are those that don't know about this forum and therefore don't have a fix. They must be absolutely desperate by now.

 

After trying anything I could find on the web so far, I contacted Parallels support and had a remote control session. A friendly technician called me, inspected my configuration and was finally able to help me.
There seem to be multiple issues causing this problem, so walking through all this with one of Parallels' guys is probably the quickest solution. It took only 2 hours to get a support time slot and 15 minutes of work to get it running.