Virtualbox disk is corrupt after host disk became full

[BrettW]

Afternoon,
One of my colleagues is running a Windows 10 VM using VirtualBox that sits on her MacBook. Last week she started getting a message to say her Mac disk was full. At this point her Windows 10 VM stopped running and came up with an error stating the virtual disk was corrupt.

I followed some instructions online which said to unmount the disk from within VirtualBox and then re-attach but at this point I now get an error saying "failed to open the disk image file /users/...location....". "Could not get the storage format of the medium /users/...location....vmdx (VERR_NOT_SUPPORTED). It's then followed by some additional codes which are:

Result code: VBOX_E_IPRT_ERROR (Ox80BB0005)
Component: MediumWrap
Interface: !Medium
Callee: !VirtualBox
Callee RC: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)

The files on this VM are important and I was wondering if anyone could advise how to repair the VM, or attach the VM as an additional disk in another VM to then extract the files required?

Thanks.

[socratis]

The files on this VM are important

... and I bet there is no backup, right?

she started getting a message to say her Mac disk was full

... which she completely ignored. The limit to get that message is at around 90-95% (roughly 50-200 GB these days), so there must have been plenty of space and time (no pun intended) to quit whatever she was doing and address the issue. Immediately and unequivocally!

attach the VM as an additional disk in another VM to then extract the files required

You're going to get the same message exactly. A broken file does not get fixed by opening it from another computer.

could advise how to repair the VM

*If* it is repairable, there is a user that has a much better understanding of the VDI format that the rest of us (so far that is, I'm studying hard ). Let's hope he sees your message, otherwise I'm going to ping him and ask him nicely if he could help you out.

Finally, I'm not trying to lecture your colleague here, I'm trying to give a warning to any other users that might be reading this:

• If your data is important, backup. Then, backup the backup.
• If you ignore severe warnings from your OS, you're (mostly) on your own.

[mpack]

I followed some instructions online which said to unmount the disk from within VirtualBox and then re-attach but at this point I now get an error saying "failed to open the disk image file /users/...location....".

That advice you followed is ludicrous. How did you vet this advice before you carried it out? At best this action would do nothing. At worst the VM uses snapshots and this action just destroyed the VM. Since people who use snapshots are most likely to run out of host disk space, this scenario is actually a strong possibility in my view.

"Could not get the storage format of the medium /users/...location....vmdx (VERR_NOT_SUPPORTED).

VMDX? As the error message says, "VMDX" is not a supported disk format in VirtualBox. You probably mean VMDK, but that leads to further bad news: VMDK is not the native format of VirtualBox, so relevant expertise around here may be limited.

The files on this VM are important...

But not important enough to warrant making backups, eh? Well, you live and learn I guess.

All you've told me so far is the error messages, which don't mean much given that they result from incorrect actions. I'd like to know what files are present in the VM folder, and in the VM "Snapshots" subfolder. You could also post the (zipped) .vbox file for this VM.

[socratis]

I just notice the following (missed it the first time), since you were talking about VDIs:

/users/...location....vmdx

Is this a VMWare virtual hard drive? If so, your chances of recovery in these forums has dramatically decreased...

[BrettW]

Thanks for the responses, lessons are being learned!!

As requested, I've attached a zip file of the vbox file. As for what's in the VirtualBox VM's folder, initially there's a Windows 10 folder, and then within this there are a Logs folder (with 4 log files in) a Snapshot folder (with nothing in) and then 4 files - 2 x .vbox files, 1 x .vbox-prev file and 1 x .vmdk file which is nearly 50GB.

Hope that helps and you can possibly provide any assistance to recover the files, someway!

[mpack]

Because of the confusion over vmdk vs vmdx I wanted to see a directory listing, not just a summary. Well, the .vbox file does at least confirm that you aren't using any snapshots.

Can you clarify the "vmdx" matter? Was that just a typo? If not then I want to know the precise error message you get if you try to mount the .vmdk in the Storage section of the VM settings.

Another thing to try: open a terminal window, navigate to VM folder, and type "VBoxManage clonehd <vmdk filename> <filename>.vdi -- format VDI". It probably won't work, but make sure you do it correctly, and let me know any error message that isn't a syntax error message.

A final thing to try: copy the VMDK to a Windows PC, or install Wine on the Mac. In either case download and install the Windows tool CloneVDI. See if CloneVDI can open the VMDK without errors (don't be too optimistic), if yes then proceed to clone the disk - CloneVDI output is always a VDI.

[mpack]

Only if nothing else works: use a hex editor to save the first 1MB or from the VMDK to a binary file. Zip the file and attach here. I may be able to tell if the header can be repaired - I warn you however that VMDK is a complex and alien format - not the VDI format when we use every day - and so I'm not promising that a repair is possible.

[BrettW]

Thanks again for the further info to try.

Yes it was a typo and meant to be VMDK

Please see screenshots attached of the error when trying to attach to VirtualBox, and when using CloneVDI in Windows.

Below is the message that appears when running the command in terminal as per your instructions:

VBoxManage: error: Could not find file for the medium '/Volumes/MAC/JO Backup/Windows 10-disk1.vmdk' (VERR_FILE_NOT_FOUND)
VBoxManage: error: Details: code VBOX_E_FILE_ERROR (0x80bb0004), component MediumWrap, interface IMedium, callee nsISupports
VBoxManage: error: Context: "OpenMedium(Bstr(pszFilenameOrUuid).raw(), enmDevType, enmAccessMode, fForceNewUuidOnOpen, pMedium.asOutParam())" at line 178 of file VBoxManageDisk.cpp

In terms of using a hex editor, I really appreciate you offering to look at the header for me but this is all alien to me as it is so without instructions on how to extract the header I'm struggling to get you that I'm afraid...

[BrettW]

Update:

I've managed to mount the vmdk image using PowerISO on a Windows device and can now extract all the data as its not the VM that I require, but the data on it. We're up to 38% and I can see the data restored is what I need already so seems to have done the trick.

Still interested to see if the VM can be fixed but appreciate this may be too much of an effort so thanks for all the replies and things to try.

Thanks.

[socratis]

Hey, great that you got a solution! Of note is the fact that this PowerISO program is supporting VDIs as well. Something to keep in mind.

As for support here, that would be kind of tough. I mean we're all volunteers and I don't think that anyone (except mpack who wrote CloneVDI) had a significant personal interest in mounting/fixing VMDK images...

[mpack]

I've managed to mount the vmdk image using PowerISO on a Windows device and can now extract all the data as its not the VM that I require, but the data on it. We're up to 38% and I can see the data restored is what I need already so seems to have done the trick.

Dubious. PowerISO can no more get by without a block map than VirtualBox or CloneVDI can. This might suggest that its validation is poor and some or all of the files which it "recovers" will in fact contain garbage. Be sure to check.

On the other hand...

The CloneVDI error message implies that the main VMDK header is ok, and the problem is a mismatch between the block map and the image: e.g. the block map contains references to blocks that are beyond the end of the file - and this is indeed the sort of thing that might be caused by running out of disk space. In this case you may be in luck - the files you recover may be ok. The only way to fix the VMDK would be to pad the file with dummy blocks out to the expected length. Of course any files which use those blocks will be lost.