Hard Disk image file corrupted

M

MG_work

Member
When starting my Ubuntu VM, I suddenly got the message that the VM "seems to be not a valid Parallels virtual machine." I got that message for both my Windows and my Ubuntu guest OS's.

I read through the Windows thread, http://forum.parallels.com/showthread.php?t=19187
and created a new "Custom" virtual machine that used my existing Windows hard disk file. That worked, and I have my installation of Windows back. (Note: I did not uninstall and reinstall Parallels)

I did the same for Ubuntu, but I got this message:
Parallels Desktop is unable to access the virtual hard disk image file /Users/Shared/Parallels/Ubuntu Linux/ubuntu.hdd. The file is corrupted.
Click to expand...

The forementioned thread suggests that one has to uninstall and reinstall Parallels and then create the new Custom VM using the old hard drive. Is this true?

I just wanted to check b/c it's a pain to reinstall Parallels; I have to involve my Tech Services crew to type in the registration number.

Background

Mac OS 10.4.11 on a Mac Pro 2x2.66 Dual Core Intel Xeon
Parallels 3.0 build 5608
Running Windows XP in one VM and Ubuntu (Heron?) in another

As I remember, I installed some Mac updates, spent a day finishing my work, shut down both VMs nicely, rebotted the Mac, and suddenly was seeing weird failed boots on Ubuntu (didn't try Windows). Then started getting "...seems to be not a valid...". Tried Windows, and got the same error there.

And yes, Ubuntu had the data I actually wanted to get back. And no, I hadn't figured out yet how to back it up yet (priority problem!).

Attached: most recent crash info

thanks for any and all help!
 
Thank you, John. I did that, but when I started the virtual machine it required me to reinstall Ubuntu. After that, I had a working Ubuntu installation but none of the data from my original installation.

The HDS file was too small to contain everything from my original installation. I assume that my data is spread out throughout the 14 hds files there. Is that correct?

So... am I doing something wrong that I'm being prompted to reinstall Ubuntu? Or is this a symptom of this hard drive being corrupted?
 
John, I think you misunderstood. I'm discussing corrupted hard disk, not snapshots, and because the hard disk is corrupted (or because Parallels reports that it's corrupted), I cannot open it either in Parallels Desktop or in Image Tool to merge the snapshots, and I can't open it in Parallels Explorer.

And as I said before, I don't have a backup of the working VM. Earlier, I didn't have anything I could copy 30 GB onto. I did have snapshots, but obviously those aren't useful when the hard disk itself isn't useful. So I can't simply "restore the backed up VM."

To recap:

1. My Ubuntu Linux VM suddenly wouldn't open within Parallels, reporting that the VM "seems to be not a valid Parallels virtual machine."

2. I created a new VM using the existing Ubuntu hard disk. I created the new VM using the "Custom" option for the type of VM. (This was suggested in the Windows guest OS forum that I mentioned.)

Now Parallels would open the VM, but gave me the error msg that the hard disk file was corrupted.

3. Then I followed your directions (from post #2 in this thread) to backup my corrupted VM (already done) and to follow the directions in this Knowledge Base post: http://kb.parallels.com/en/4680. I did:
3a. I showed the package contents of ubuntu.hdd. It contained 12 .hds files.
3b. I copied the most recent .hds file and followed the directions that make it into a new .hdd file.
3c. I made my new Ubuntu VM use the new .hdd file.

But when I run this VM, Parallels insists that I must install an OS.

At no time am I able to open the snapshot manager. And I haven't copied over the snapshots, anyway. That sounds like a red herring.

I think the problem may be that my original, corrupted hard disk contained 12 .hds files, and I'm trying to make a new hard disk out of the most recent of them. I know that this hard disk can't possibly contain all of my data; it behaves like it also doesn't contain an installation of Linux.

So, to try again-- what is it I can do with this 'corrupted' hard disk to either bring it back to life or get the data off of it?

thank you in advance!
 
Last edited:
let me describe
hdd file is actually bundle (folder) where those hds file with actual data are located.
there should be DiskDescriptor.xml file (by the way check is that file empty?)
if somehow it is empty. it is very hard but but may be possible to restore data from that files using R-Studio software
It is Windows software and can read from disk images and read ext2 file systems
You can try this later

So for now check DiskDescriptor.xml
 
Recreated DiskDescriptor.xml

You gave me a couple ideas.

I did my best to recreate the DiskDescriptor.xml file. Now I can boot the Ubuntu VM; it gets as far as the Ubuntu Cylon startup window but then, after the light bounces once, it freezes.

I can now run the Snapshot Manager, but I haven't done anything to the snapshots yet (um, I believe I have to do that in the Image Tool anyway, right?)

I can open the hard disk in Parallels Explorer now, but I can't open my user Documents folder (gee, would that be due to user permissions?)

It would be nice to be able to start this VM and export the data normally. Any suggestions?

====================

If it helps anyone, here's how I remade the DiskDescriptor file. Keep in mind, of course, my VM still doesn't actually work. :-)

1. Work with a copy of your screwed up VM. Don't work on the original!!

2. Make another VM (probably should be the same OS) so you can get a similar DiskDescriptor.xml file from that VM. I already had another install of Ubuntu handy.

3. Copy that DiskDescriptor.xml and paste it in place of your empty, useless, 0-byte file.

4. Now you're going to edit the XML and paste in all your broken VM's data.

4a. In the XML file's StorageData section, there's a bunch of Image elements. These represent the .hds files in the .hdd package. So for each Image element, change the File and GUID elements to the filename and the code-like part of the filename (e.g. 5fbaabe3-6958-40ff-92a7-860e329aab41)

I assumed that order was important, but I dont' really know. I made the first Image element represent the most recently modified hds file. (I suspect this is the main or parent image, but I'm full of assumptions.) I made the next Image element represent the least recently modified hds file. (I'm assuming this was the next one to be made.) and so on.

4b. In the XML file's Snapshots section, there's a bunch of Shot elements, representing snapshots listed in, no surprise, your Snapshots.xml file. Open that file.

The relevent data is: what's the snapshot's code (again, something that looks like 5fbaabe3-6958-40ff-92a7-860e329aab41) and which snapshot is its parent. Maybe you can just look at the modification dates for the snapshot files, but I read the Snapshots.xml.

Again, I assumed that order matters, and that it goes from most recent to most distant.

So my first Shot element has the GUID of the most recently modified .hds file (Surprise! Yes, the most recent hds file) and its ParentGUID is the most recent snapshot.

The next Shot's GUID is the GUID of the most recent snapshot (the same as the parent of our most recent .hds file), and its ParentGUID is the next most recent snapshot. and so on.

Finally, the last Shot's ParentGUID is 00000000-0000-0000-0000-000000000000 , which you probably already knew by looking at the DiskDescriptor.xml file that you copied.

(By the way, A week ago i tried skipping writing out details for the snapshots; the disk will not work then. Maybe this is why John suddenly started talking about corrupted snapshots when I was still asking about corrupted hds files)

5. Your snapshots know which VM they were made with. Now you must change them to think they were made with this VM. It might be important that your VM be made exactly the same way. There's probably a smoother way to do this, but...

5a. Back up all of your snapshots, your Snapshots.xml file, and (just in case) your newly made DiskDescriptor.xml file. You're about to blow the snapshots away to get this new VM's ID number.

5b. Make a new, temporary snapshot. (Yes, I was able to do that by this point in the hack)

5c. Open the Snapshots folder; open the .PVC file in a text editor. Your VMID is in there. (once more, looks like ee868d17-6f67-4202-bbdb-f7d7581f3420). Copy that.

5d. Quit the VM. Close the Parallels window to make sure.

5e. Copy your snapshots & Snapshots.xml file back to your broken VM, deleting the temporary one.

5f. Change the VMID in all your Snapshots/something.PVC files to the new one you just copied.

and that's how I got the thing to work as much as it did. I must love this sort of nonsense. Hope that helps someone.
 
You must log in or register to reply here.
Back
Top