I upgraded to 3.0 a few days ago, converted my windows 2003 OS that has 2 hard drives. It worked great all day. The next morning when I launch my machine, I get prompted with "Parallels Desktop is unable to access the virtual hard disk image file [the drive's filename]. The file is missing, corrupted, or used by other application." When I go into the Configuration editor and select the drives, it gives me the same error for both drives. The new Parallels Explorer also gives me this same error when I try to view the drives. The file is definitely not missing or being used... so what could have happened? I've tried re-installing Parallels, but get the same thing. I've had to go back to Parallels 2 with a backup I took prior to converting, but I lost all my day's work. Is there anything I can do to try to recover the drive images?
I fixed my problem, I'll post what I did here in case it might help someone else. I converted a backup disk image to 3.0 to see if I could see any obvious differences between the corrupt and non-corrupt images. I noticed the DiskDescriptor.xml inside the .hdd directory was text .XML in the newly converted non-corrupt image, but binary gibberish in the corrupt images (I originally thought it was supposed to have been a binary encoded XML file when I looked at it earlier). So I copied the non-corrupt DiskDescriptor.xml into the corrupt disk images, edited the disk parameters and file names to be appropriate, and presto! Parallels recognizes the drives now, windows boots, data is safe, and all seems to be well.
I was hoping you could tell me! I have no idea what would corrupt those files (I'm assuming Parallels did it somehow, since no other files on that volume have any problems), but I'm glad it was just that and not the actual hds image files. I'm running a fully patched/current Macbook Pro, the Parallels drives are contained in an encrypted .sparseimage (been running them like that since the first Parallels version came out with no issues). If there is other specific information you'd like me to give to see if you can track down this potential bug, please let me know. I thought I was the only one with this issue on this forum, but I found another post in the Windows/Linux forum with the same issue, so I don't think it's just me anymore.
bgt, you've just saved my life! I have been running Parallels without issue for some time, and recently upgraded to 3 without issue. I have a WinXP VM with two hard drives. Without any reason at all when I started Parallels last night it came up with the HDD corrupt error for the second HDD. Based on what you said here I tried to open the XML file within that HDD's package. Couldn't - it said the XML file was corrupt. By this time I had already backed up the corrupt XML over the previous good copy, so instead replaced the bad XML file with the one from the first HDD, edited the name of the disk in the XML file and to my surprise and delight it then mounted again okay and all seems well. I too have no idea what caused the corruption; I am an IT professional, never close down inappropriately, have had no crashes etc. I'm hopeful this is a one off but seems odd that more than one of us would get this corruption. Anyway, great tip about the XML file. David
Unfortunately, I do not have either the expertise or the tools, or both for this recommended solution. I seem to have the same problem, is there an easier fix or explanation?
I'll try and help, but please proceed at your own risk. Locate the folder where the Parallels files are. This should be ~/library/Parallels. In there will be folders for your virtual machines. If you have just one, that will be it (in my case it's called 'winxp'). Inside that folder you should see various Parallels items including your hard disks. In mine I have 'winxp.hdd' and 'disk2.hdd'. Whilst these appear to be single files, they are, in fact, folders. If you right click (or control click) on them you can select 'Show Package Contents' and this will open like any other folder. There may be one or more items in here, one of which will be a file called 'DiskDescriptor.xml'. In my case, it was a corrupt one of these that was preventing the hard drive mounting. Move (move, not copy) the xml file for the non-working disk to somewhere else (desktop). This is purely for if this all goes wrong and you need it later (although if this is the cause of the trouble then it's no good to you anyway). Then copy (copy, not move) the xml file from the good disk, into the package for the bad one. You now have packages for the two disks, each of which contain the same DiskDescriptor.xml file. Unfortunately, that isn't the end of it as the file needs to be edited slightly. Right (or control) click the xml file for the non working disk and select 'Open With' 'Other' and chose Text Edit. This will open the file in a sort of tree structure. You need to look for an reference to the name of the original good disk and change this to the bad one. So, in my example the good disk appeared twice in the file as 'winxp.hdd.0.' and I changed this to 'disk2.hdd.0.0'. It's a small file and finding the references didn't take long. Once I saved the file and started Parallels again, all seemed well. Here are the caveats: 1. It worked for me, but that may not be the cause of your troubles, so may not work for you. 2. I don't know if the xml file also describes any other disk attributes, such as size etc. In my case, the good disk was larger than the bad one – by doing this I may have increased the size of the bad one without realising it. I have no idea. So, this may or may not be a permanent fix. As it happens, I will soon have the need to delete this virtual machine and start again so I am less concerned about long term impact. One thing I will do once it is up and runnning is make sure I have backup xml files outside of my usual backups. Hope this helps. David
torchydt: Glad it worked for you as well! I hope Parallels can track down this problem, corruption that renders virtual disks unusable is a huge problem. I don't have much choice at the moment, but I'm very nervous about continuing to use Parallels 3 on vital data until they respond that they have a grip on this. bgraff: torchydt's instructions are as simple as I'd be able to describe. Pay attention to his caveat's... that error could be caused by many other problems, this fix only applies if the issue is a corrupt DiskDescriptor.xml file in your virtual drive's package. Also, the disk parameters in that file must be important, and I have no idea what will happen if they are incorrect for your particular disk... you may not run into problems until later down the road if they are not right.
count me in, I now have a corrupt drive also Hi all, I successfully migrated from 3188 to 4124. Like everyone else it worked fine for the first couple of days. Today I attempted to upgrade to 4128 and now have a corrupt drive image. The problem is that I may not be as fortunate as some of the other people here as I do not have a backup of the xml file. If anyone has any suggestions as to how to fix this I am all ears. Thanks, dave
yes I've got the same.. but in my case fusion beta 4 VM was running in the background, so I thought, Parallels is having problems with that. I took an earlier saved version of the .hdd from an extern drive and everything works again. But I want to know the reason for this problem, too !!
fdm225: Before proceeding, please confirm your problem is actually a corrupt xml file! The DiskDescriptor.xml file inside your disk image package will be gibberish, rather than human readable xml text. I also recommend you backup your whole corrupted disk before proceeding, it's always possible it'll get screwed up worse than it already is by proceeding. 1. Do you have a backup of the disk file from anytime prior to upgrading to 4124? If you do, you can use Parallels to convert that up to the 3.0 format, and then get the xml file from that and copy it into your corrupted one. This would be the safest/optimal method. 2. If you have no backup whatsoever: use Parallels 3 to create a new disk that is the same size and parameters as your corrupt one. Use the DiskDescriptor.xml file from the new disk to replace your corrupted one (you will need to edit the GUID and disk file name fields appropriately!) Please let us know if either method works for you.
bgt- I had the same issue today. I fired up parallels, and what do you know, first time ever for me, a kernel panic! After a reboot, the exact same issue, and the image is corrupt. Or at least the diskdescriptor.xml file.. I followed idea#1, and copied over the pre 3.0 converted drive, extracted the xml file, changed the drivename in there (the GUID was the same, i assume since i converted from the pre-3.0 source image). Repointed the drive name in parallels back to the previously "corrupted" disk, and it boots again... wow, serious bug here, but it seems to be working again!
Hi again. Seems subscription to the thread works in very strange manner. I received only the last message from elf. Seems that i found what can be happened here, and i'll fix it soon. FYI, update with lot of fixes will be available in 2-3 weeks.
For what it's worth I saw the same thing happen to my 3.0 disk images after trying to use the "Parallels Explorer" application to browse my HDDs - it seemed to crash and afterward all images that I tried to view were corrupt. The HDDs were a mix of linux and NTFS windows formats.
I don't think the Window XP HDD was suspended but I'm pretty sure the linux HDD was... I fixed both, by the way, by creating a new one of the same size, going into the package and copying the .XML file to the old package (as someone described above).
Example XML file? My DiskDescriptor.xml file is totally truncated -- zero length. Can somebody post an example DiskDescriptor.xml? I hope I can re-create one for mine (as I don't have a backup.)
YNOT, do we deduce from your question that for now we should not be suspending VMs until a fix is out?
StorageData empty Hi, I do have the same corrupt message. In my case, the XML is syntaxically valid but is missing the StorageData information. My XML looks like this: <Parallels_disk_image Version="1.0" > <Disk_Parameters> ... snip what seems valid ... </Disk_Parameters> <StorageData> <Storage/> </StorageData> <Snapshots> ... snip what seems valid ... </Snapshots> </Parallels_disk_image> don't know what cause the issue. mb the issue was that I removed the only snapshot I had for the drive (at compressor's request). I did not have my backup image handy and went for creating a new disk of same size. I copied the XML and editted the storage area with the correct filename. So far so good, windows boots again. Bernard
Interesting... There are situations when this file can be accessed improperly. And its contents is truncated or corrupted in the manner you described above. This issue will be fixed in the nearest update.