Hi everyone,
I have been happily using VirtualBox for several years. Over the weekend, my server ran out of disk space and crashed. Now, when I try to run my VM, I get the following error:
VERR_VD_VMDK_INVALID_HEADER
Result Code: E_FAIL (0x80004005)
I have done some searching, and the most promising suggestion is to use vmware-vdiskmanager to repair the corrupted VMDK file: viewtopic.php?f=6&t=82051
I have tried installing VMware Workstation 16 Player for Windows, but it doesn't seem to include this tool.
Can anyone help me fix this VM please?
VMDK: inconsistency between grain table and backup grain table
-
- Posts: 10
- Joined: 6. May 2019, 05:37
VMDK: inconsistency between grain table and backup grain table
- Attachments
-
- Error Message
- VirtualBox1.png (77.92 KiB) Viewed 3386 times
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: VMDK: inconsistency between grain table and backup grain table
The message indicates a corrupted VMDK. VirtualBox offers no repair tools for VMDK (it is not the native format), so your best bet is a good backup.
Failing a good backup, a suggestion that comes with absolutely no guarantees: try cloning the VMDK using CloneVDI, remember to check "Compact" and "Keep UUID". If it works (it might, since ISTR it doesn't bother with that backup grain table validation check) then you should have a usable VDI, perhaps with a corrupted filesystem that will have to be repaired using guest tools.
I suggest that you stick with VDI in future if you expect repair expertise on the VirtualBox forums.
Your situation is greatly complicated by your inexplicable decision to use snapshots. When using CloneVDI you must select as source the newest readable snapshot file, not the base VMDK.
Failing a good backup, a suggestion that comes with absolutely no guarantees: try cloning the VMDK using CloneVDI, remember to check "Compact" and "Keep UUID". If it works (it might, since ISTR it doesn't bother with that backup grain table validation check) then you should have a usable VDI, perhaps with a corrupted filesystem that will have to be repaired using guest tools.
I suggest that you stick with VDI in future if you expect repair expertise on the VirtualBox forums.
Your situation is greatly complicated by your inexplicable decision to use snapshots. When using CloneVDI you must select as source the newest readable snapshot file, not the base VMDK.
-
- Posts: 10
- Joined: 6. May 2019, 05:37
Re: VMDK: inconsistency between grain table and backup grain table
Hi, thanks for the answer.
I do have a good backup -- I did a full export of the appliance into an .ova file about 6 weeks ago. I believe this includes a good copy of the VMDK.
I understand that snapshots complicate things, but that's how the VM was when I found it. How can I stop using snapshots after I restore from backup?
I do have a good backup -- I did a full export of the appliance into an .ova file about 6 weeks ago. I believe this includes a good copy of the VMDK.
I understand that snapshots complicate things, but that's how the VM was when I found it. How can I stop using snapshots after I restore from backup?
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: VMDK: inconsistency between grain table and backup grain table
There are a couple of ways:LogicalUnit wrote:How can I stop using snapshots after I restore from backup?
You can simply delete the three snapshots pictured in the screenshot above, leaving the current state as the only remaining state. Note that I never use snapshots myself, so I don't know for certain that that eliminates all snapshot-isms from the VM config, but I'm hopeful that it does. You will still have your backup, so no need to be nervous doing this.
Another option is to clone the VM, keeping the current state only. The clone will have no snapshots. Be sure to use the option to preserve machine IDs, in case you have software that must maintain activation. Test the VM and if everything is working you should be able to delete the older VM.
Finally, note that exporting the VM to "OVA" does not make a true backup, it instead makes a new VM with new machine IDs. That may not matter to a Zen Server (I have no idea about that), but a better general VM backup strategy is simply to copy the VM folder to secondary storage. That guarantees that the restored VM is identical to what you backed up, which is surely the goal of any backup.
-
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: VMDK: inconsistency between grain table and backup grain table
If I have read correctly over the years, your VM may import as a single-disk non-snapshotted VM. I don't think that exporting is compatible with snapshots, so the VM's snapshots may have been merged down to one disk file to make the OVA.LogicalUnit wrote:I did a full export of the appliance into an .ova file
-
- Posts: 10
- Joined: 6. May 2019, 05:37
Re: VMDK: inconsistency between grain table and backup grain table
I have tried to import my .ova appliance file but there was a problem
Result Code: E_INVALIDARG
(0x80070057)
Any idea what to do here? This backup was made well before the VMDK was corrupted.
Result Code: E_INVALIDARG
(0x80070057)
Any idea what to do here? This backup was made well before the VMDK was corrupted.
- Attachments
-
- Error Code
- VirtualBox3.png (32.39 KiB) Viewed 3290 times
-
- Posts: 10
- Joined: 6. May 2019, 05:37
Re: VMDK: inconsistency between grain table and backup grain table
Thanks for this suggestion. Does it stand any chance of working if the VMDK is in Differencing mode? This is due to the snapshot complications, I think.mpack wrote:The message indicates a corrupted VMDK. VirtualBox offers no repair tools for VMDK (it is not the native format), so your best bet is a good backup.
Failing a good backup, a suggestion that comes with absolutely no guarantees: try cloning the VMDK using CloneVDI, remember to check "Compact" and "Keep UUID". If it works (it might, since ISTR it doesn't bother with that backup grain table validation check) then you should have a usable VDI, perhaps with a corrupted filesystem that will have to be repaired using guest tools.
I suggest that you stick with VDI in future if you expect repair expertise on the VirtualBox forums.
Your situation is greatly complicated by your inexplicable decision to use snapshots. When using CloneVDI you must select as source the newest readable snapshot file, not the base VMDK.
Clarification: I don't need snapshots at all and am happy to get rid of them if it will recover my disk.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: VMDK: inconsistency between grain table and backup grain table
From my above post:
Put the base VMDK and all snapshots into a single folder, select the newest snapshot and clone it. CloneVDI doesn't give you a choice about retaining the snapshot structure - the data is kept (in a VDI) but the structure itself is discarded.When using CloneVDI you must select as source the newest readable snapshot file, not the base VMDK.
-
- Posts: 10
- Joined: 6. May 2019, 05:37
Re: VMDK: inconsistency between grain table and backup grain table
I had a go with CloneVDI but it looks like it's not going to work
- Attachments
-
- CloneVDI error
- VirtualBox4.png (12.73 KiB) Viewed 3224 times
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: VMDK: inconsistency between grain table and backup grain table
You can try the next oldest snapshot, see if that can be recovered. With your description of the problem it makes no sense that every file in the set would be corrupted: only the last file was opened for writing. For all files to be corrupted something would have to have been left out of the story, e.g. deleting the files and then trying an undelete tool.
p.s. Per my instructions above, the "Keep old UUID" option should be set.
p.s. Per my instructions above, the "Keep old UUID" option should be set.