Recently, I had Parallels (3.0 5584) for Mac present an error when I attempted to create a new snapshot. "An error occurred during reverting to snapshot. Return code 419502468. From that point on, I could no longer restore to any snapshot, nor could I boot up the virtual machine. "Parallels Desktop is unable to access the virtual disk image file <blah>" Upon further investigation, I found that the DiskDescriptor.xml file in the VM's .hdd directory was corrupt. The first half of this file was overwritten with: "Sometime i'll remove this warn and just set the PID here" and a bunch of null bytes. By retrieving the default XML header lines from another VM and then re-creating the missing <Image> elements by recovering the GUIDs from the <Snapshots> section at the and of the XML file, I was able to recover the DiskDescriptor.xml file by hand. I've attached copies of the "before" and "after" versions of this XML file. A few comments/questions: 1) What may have caused the snapshot to fail and corrupt the DiskDescriptor.xml file? I would think that the "Sometime i'll remove this warn and just set the PID here" text at the beginning of the corrupt file might be a clue to the developers! 2) This isn't the first time I've had a VM go bad due to corruption of text files in Parallels. In the past I've had a .PVS file get overwritten with garbage too. Could it not be possible for Parallels to create backups of these files when they are written to, to prevent this very sort of problem? Those files are tiny, so the overhead would be trivial, but it would at the very least allow a technical user to manually go in and restore from them. Ideally, Parallels could automatically attempt to use the backup file when a problem is encountered with the primary one. e.g. a dialog: "Parallels has encountered a problem opening disk image <blah>, would you like to try the backup copy?"
Hello, sorry for inconvenience. We are aware of this problem and investigating it. For corrupted .hdd file this article might help. Best regards, Stacey
Excuse me for being really annoyed, Stacey, but I don't consider it an "inconvenience". I consider it a major *&$%! I have this problem and unfortunately, I wasn't fortunate enough to have the broken XML file to start with, mine is empty make life a "little" bit harder, so maybe while you are "fixing" the problem, you can give us a converter that helps us recover these files and rebuild them with no XML file.
Can Stacey or another Parallels rep please state whether this issue is considered fixed as of version 3, Build 5608 (June 9, 2008)? I was just bitten twice by this bug on two separate machines with the previous build, 5584. Suddenly, I got a disk descriptor file containing only "Sometime i'll remove this warn and just set the PID here" followed by a whole lot of ASCII 00 nulls. I know how to fix, but the shock is still a little rude at the time. Thanks! /swv
@forrestgump2000: Thanks for the post. This is my first visit to this forum, and I'm here because I encountered the very problem you described. Fortunately, I was able to manually edit the DiskDescriptor.xml file to get my VM back up and running again. Your post saved me me much pain and heartache. To Parallels: this is utterly ridiculous. Especially for software you're attempting to sell into the enterprise market. You may well make a VMWare customer of me yet.
Make a Backup of Your DiskDescriptor.xml File I have experienced a "corrupted" hdd file no less than 4 times since owning Parallels, in multiple versions. In reality it was the DiskDescriptor.xml file that was corrupted. I suggest that the KB article describing the fix (4680) will probably work, but if one follows the instructions explicitly it means making backups of 24, 32, 48, or 64 GB files (depending on the size of your disk) which is both time consuming and frustrating. If you are having this issue described in the thread and your .xml file doesn't look similar to the original poster's corrected file, you may want to recreate it manually, then make a backup. If you change drive capacities, you'll want to make a backup then, too, so that the sectors/capacity are recalculated. In all the cases of a corrupted .hdd I was able to restore the XML file and startup as if nothing ever went wrong. I echo the comments by other posters that it would not be terribly difficult upon successful startup of the guest OS to make a copy of the descriptor file such that it could be restored at the "last known good start" and avoid the potential heart attacks when you fear your files are all gone...
Any way to generate the DiskDescriptor.xml file All of my DiskDescriptor.xml files for 3 HDs that I was using in my VM today got corrupted. The problem is that the data in those files is not even remotely close to what it should have. This is on Parallels3 Build 5626 <dict> <key>Created</key> <real>349225771.61431098</real> <key>Domain</key> <string>.bigdatauniversity.com</string> <key>Expires</key> <date>2032-01-20T23:09:31Z</date> <key>Name</key> <string>_jsuid</string> <key>Path</key> <string>/</string> <key>Value</key> <string>3990299269</string> </dict> <dict> <key>Created</key> <real>349152789.38441098</real> <key>Domain</key> <string>www.indeed.com</string> <key>Expires</key> <date>2013-01-25T02:53:09Z</date> <key>Name</key> <string>openSections</string> <key>Path</key> <string>/</string> <key>Value</key> <string>%3Arb_Salary%20Estimate%3Arecentsearches%3Arefineresults</string> </dict> I was able to recover from backup two of the three lost XMLs, but the problem is that those two were not the OS disks. My OS disk, I am not able to recover and I don't have a backup of this one. The filenames and sizes are as below: -rw-r--r--@ 1 staff 54034142720 May 1 21:13 winxp.hdd.0.{0796e588-bd38-40de-b176-c9c3b1276002}.hds -rw-r--r--@ 1 staff 18767819264 Sep 22 13:30 winxp.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds How to reconstruct the DiskDescriptor.xml so I can start the VM again? The VM did not have any snapshots. Can anyone help? Thanks, --H
