VM's not resuming past 50% in progress bar, then maxing cpu

D

doctor46

Bit poster
Using Parallels Desktop 4.0.3540 build.

After the disaster of the issues from vm's not upgrading in the first release, build 3540 fixed that finally but now they are useless as they will not resume anymore.

Fedora and XP both fail to get past 50% in the remusing progress bar, basically locks up and then prl_vm_app takes 100% and will not quit/force quit etc forcing a restart of the computer, a mbp in this case.

What can I possibly do to make the vm's useable again, some help would be nice because this is rubbish. Thanks.
 
I would like to suggest that perhaps doctor46 is seeing the problem when a VM resumes from a suspended state.

If he is seeing that behaviour, then I am seeing the same thing.

I am not able to generate a problem report, as if I try to generate one my system becomes unresonsive and I am then required to hold down the power button until the system restarts.

This has happened to me every time I try to unstandby my RHEL vm and my XP Sp2 VM while running build 3540 when I do the following:

1) start a VM
2) while VM is running, close the lid of my macbook pro (without pressing the standby button on the VM's GUI)
3) resume the macbook pro
4) standby the VM (press standby button on VM's GUI)
5) resume the VM
7) VM gets stuck at 50% of resuming prl_vm_app now uses 100% CPU

At step 7, if I `kill -9 <pid of prl_vm_app>` then my system hard crashes (instant poweroff, no error message or log entried on reboot).

If I try to generate an error report at step 7 my system becomes unresponsive. (mouse keeps working but the GUI stops working on all apps). It never gives me an ID for the error report, so I'm not sure if they got sent.

This issue does not happen with previous builds.


EDIT: I want to specifically point out that I'm usually running into this issue on my *Linux* virtual machine (RHEL listed below) The KB article does not address Linux machines. Also: I've never seen any specific GUI action to "upgrade" a Linux VM. Is there such a thing?
 
Last edited:
unused_user_name said:
I would like to suggest that perhaps doctor46 is seeing the problem when a VM resumes from a suspended state.

If he is seeing that behaviour, then I am seeing the same thing.

I am not able to generate a problem report, as if I try to generate one my system becomes unresonsive and I am then required to hold down the power button until the system restarts.

This has happened to me every time I try to unstandby my RHEL vm and my XP Sp2 VM while running build 3540 when I do the following:

.....

5) resume the VM (from a previously working state-my emphasis)
7) VM gets stuck at 50% of resuming prl_vm_app now uses 100% CPU

At step 7, if I `kill -9 <pid of prl_vm_app>` then my system hard crashes (instant poweroff, no error message or log entried on reboot).

...
Click to expand...

Thanks UUN, that is exactly it, same symptoms, same end result in a hard restart required.
 
I was able to post a problem ticket while a fresh install VM (repeatable) is "stuck". This is a fresh install of XP (SP2 integrated) with no additional patches. Nothing is installed except the tools.

Ticket #17936.

To create the machine:

Install XP with Sp2 integrated. Reboot VM.
Install parallels tools. Reboot VM.
Follow steps 1-7 above.
 
Ditto

I have the exact same issue - any attempt to restore a VM hoses my MacBook Pro (early 2008).

Its extremely fustrating - I assume that PD4 installs some kernel extensions to do its VM magic and these are misbehaving because there is no reason a user-mode only software program should be able to bring a XNU kernel down.
 
Update - I am now able to restore a VM from suspend state. I removed and re-installed PD4 (for the 3rd time) including doing a 'find / -name "*Parallels*"' to track down any stray files and I changed the VM from 2 processors to 1 processor. Now restore from suspend seems to work.
 
tvaida said:
Update - I am now able to restore a VM from suspend state. I removed and re-installed PD4 (for the 3rd time) including doing a 'find / -name "*Parallels*"' to track down any stray files and I changed the VM from 2 processors to 1 processor. Now restore from suspend seems to work.
Click to expand...


I followed this advice, mostly (just used the un-install, both options ticked), reinstalled again, added the VM's again and changed them back to 1 processor and they are back working again. Maybe this will be the end of dramas for a while. Hopefully. ...


Thanks tvaida :)
 
I have the same problem. I'm stuck at about 50% resuming an XPSP3 VM that has been working fine forever. I did increase the CPU's for the vm from 1 to 2 a few days ago in an attempt to get video to play better. (4 core MacPro) I'll see if I can get to the point I can change the CPU number without reinstalling PD4 (build 3540). Problem report submitted # 24425.
 
I had to force shutdown of the mac by holding the power button down. When it rebooted I ran parallels and selected the stuck VM then clicked on "Configure". It warned me I would lose any unsaved data, but I went ahead and did it anyway. I then changed the number of CPU's to 1. I was then able to start the vm successfully and subsequently suspend/resume without problems. Hopefully that works for others as it is a lot easier than an uninstall/reinstall. I still need the multiple CPU's for my video to play without jerking. Hopefully this bug will be fixed soon.
 
You must log in or register to reply here.
Back
Top