Shirt Pocket Discussions

Shirt Pocket Discussions (http://www.shirt-pocket.com/forums/index.php)
-   General (http://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   Parallels & Memory Allocation Issue (http://www.shirt-pocket.com/forums/showthread.php?t=4412)

grmlaw 08-06-2008 03:19 PM

Parallels & Memory Allocation Issue
 
Dave,

I too have been unable to open the Parallels virtual machine after doing a SuperDuper restore. This is a recent development as SuperDuper has saved me many times over the last year, including successfully restoring my entire system with Parallels on it and subsequently being able to open the VM without any problem.

Like the others who have reported the problem to you, when I go to open the VM on a recent restored system I receive the improper memory allocation notification and the suggestion to go into Parallel's Preferences and make sure I've set the memory allocation settings properly. Like the others, I have followed the instruction precisely, and the like the others it cured nothing - I'm left, like all the others, with being unable to open the VM.

I realize this is not a SuperDuper problem. It's a Parallels problem which they may or may not be working on. Their suggestion is to reduce the amount of allocated memory to 1GB or less. I don't want to try that.

In the meantime, I continue to religiously make SuperDuper backups in which I have no faith I can open the Parallels' VM.

My practice is to make a different SuperDuper backup on three different external drives on a revolving basis. I hope my most recent need to restore is illuminating. First, I restored by system using my most recently dated backup. I had the same memory problem opening the VM. I then restored my system using my next most recently dated backup. I had the same memory problem opening the VM. I then restored my last and oldest backup (dated 7/4/08) and that restore allows me to open the VM.

I don't know what the difference is between the three backups that explains why the two most recent backups won't permit the VM to open but the oldest one does. At the moment I'm just happy (very) that I was able to get one of them to work although I then had to perform about a month's worth of updating various programs including the 10.5.4 update, new iPhone installation, MobileMe, etc. A lot of updating.

My concern is what do I do in the meantime until the issue is fixed, i.e., should I continue to make backups that I don't confidently believe will allow the VM to open and no way to test the backups I do make without jeopardizing the current system that is working properly (the one from 7/4/08 that required all the updating). Any suggestions would be sincerely appreciated.

Nevertheless, I thought reporting my experiences might be illuminating to someone like you whose program has saved me several times, including your assistance with the recent VirusBarrier work around that stops SuperDuper cold.

The Parallels people seem to think the 10.5.4 OS X update that was released on or about 7/4/08 in anticipation of the iPhone release is the ultimate culprit. That may be true because the one backup of mine that worked was done on 7/4/08 right before and in anticipation of doing the new OS X update (I always do a SuperDuper backup before doing an OS update or other significant update). But, once I restored the 7/4/08 backup, I then updated all my programs needing updating and I am able to open the VM which seems contradictory to the notion the OS X update is the culprit. Does that shed any light on it?

In the meantime, I use two of my three external drives to make current backups from which I can boot but can't open the VM while booted from the external backup drive. On my third external drive I have kept the old 7/4/08 backup that allowed me to restore back to a place where I could open the VM, but I'd be looking at a significant amount of updating if I have to restore back to my 7/4/08 backup - and I will someday have to.

The whole thing is bewildering and completely submarining the security I used to feel knowing SuperDuper would save my bacon when I needed it. Thanks for listening and I hope I've not wasted your time, but this issue tangentially affects my confidence in using SuperDuper so I though you ought to know.

dnanian 08-06-2008 03:42 PM

This really seems to be something Parallels is going to have to fix. We're just copying the files as they are on the drive. I'm not quite sure how, if you know this is a Parallels problem, it affects your confidence in SuperDuper, though.

You're sure you're not running Parallels when you're backing up?

grmlaw 08-06-2008 10:06 PM

Dave,

What I meant about affecting my confidence in SuperDuper obviously wasn't clear. It wasn't meant as a slam to SuperDuper. On the contrary, I know it's not a SuperDuper-caused problem. SuperDuper makes an exact bootable clone of my hard drive/system. and until recently it worked flawlessly and I could open the VM on a restored system.

But, now the fall out from this Parallels' problem is I am making SuperDuper backups in which I have no confidence that if I must ever use them to restore my system I won't be able to access the Parallels' VM in the restored system. Being able to access the Windows' programs and data in my Parallels' VM is vital to my everyday work.

What could be happening in the backup/restore process to persuade Parallels that the memory in my restored system is not properly allocated? How can that be with the same system, the same memory, the same settings, and the same files? It's crazy, but nevertheless its very unsettling to me since I've come to rely heavily on the security SuperDuper has given me for over a year. I feel like a trapeze artist working without a safety net.

dnanian 08-06-2008 10:10 PM

I don't know what might be happening here, unfortunately. One would hope Parallels would know... it's their diagnostic, and they should be able to determine what's going on... are you sure you aren't running Parallels when you back up?

grmlaw 08-09-2008 01:10 AM

Yes. I'm sure I'm not running Parallels when I run the SuperDuper backup and I have the VM stopped too.


All times are GMT -4. The time now is 01:52 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.