I have posted several times about having a VM go poof i.e. drop back to "Stopped" state without warning, reason, or message. Most recently I posted Poof! the Movie to show it happening.
All this was on my MacPro, and presumptively an issue with the Xeon CPUs. But this morning I had a brainstorm: I connected the MacPro by a Firewire cable to a MacBook and booted the MacPro in Target mode, so its disks showed up on the laptop as mounted volumes.
Then I installed a Parallels Desktop trial on the laptop and used it to open the winxp.pvs VM off of the MacPro's disk. The exact, identical .pvs and .hdd files that you can see in "the movie" but executing in the MacBook Core Duo CPU. And... IT POOFED just like in the movie!!!
Conclusions: The "poof" failure is not related to Macpro hardware.
To review, this failure (which makes Parallels Desktop useless to me) affects good, working VMs which suddenly begin to "poof" and once they begin to do it, they keep doing it. It isn't the MacPro hardware as such. I earlier posted how I had compared the .pvs files of working and non-working VMs and they were the same. What does that leave?
Some particular VM use of the virtualized CPU or (my guess) the virtualized BIOS. What makes it repeatable? Probably, some content of the VM's memory that is stable from one boot to the next. The VM can go a long time (hours for me, apparently weeks for others) with no problem, but once it has the magic contents at the magic location, some otherwise-normal operation is interpreted by Parallels as shutting the VM down. Poof, back to "stopped" state.
Attention Parallels Support:
This failure is inherent in the .hdd file. I am burning the .pvs and .hdd to a DVD right now. If you have it you will be able to repeat the failure and debug it!. Just give me a name and a shipping address and it will be there tomorrow!
All this was on my MacPro, and presumptively an issue with the Xeon CPUs. But this morning I had a brainstorm: I connected the MacPro by a Firewire cable to a MacBook and booted the MacPro in Target mode, so its disks showed up on the laptop as mounted volumes.
Then I installed a Parallels Desktop trial on the laptop and used it to open the winxp.pvs VM off of the MacPro's disk. The exact, identical .pvs and .hdd files that you can see in "the movie" but executing in the MacBook Core Duo CPU. And... IT POOFED just like in the movie!!!
Conclusions: The "poof" failure is not related to Macpro hardware.
To review, this failure (which makes Parallels Desktop useless to me) affects good, working VMs which suddenly begin to "poof" and once they begin to do it, they keep doing it. It isn't the MacPro hardware as such. I earlier posted how I had compared the .pvs files of working and non-working VMs and they were the same. What does that leave?
Some particular VM use of the virtualized CPU or (my guess) the virtualized BIOS. What makes it repeatable? Probably, some content of the VM's memory that is stable from one boot to the next. The VM can go a long time (hours for me, apparently weeks for others) with no problem, but once it has the magic contents at the magic location, some otherwise-normal operation is interpreted by Parallels as shutting the VM down. Poof, back to "stopped" state.
Attention Parallels Support:
This failure is inherent in the .hdd file. I am burning the .pvs and .hdd to a DVD right now. If you have it you will be able to repeat the failure and debug it!. Just give me a name and a shipping address and it will be there tomorrow!