virtualbox.org

Hi,

I'm using Mac OS X 10.6.8 with a Ubuntu 12.04 LTS guest on VirtualBox 4.2.12 r84980. The VM itself has a single snapshot of the machine in a blank but set up state.

...and I made the mistake of running this VM without enough space on the host's hard drive to accomodate the maximum space of the guest vmdk.

I ran out of hard drive space on the host, and around that time the guest became unresponsive to anything but a force quit. When I cleared some disk space and VirtualBox came to again, I got this error when I tried to run the machine again:
This error only seems to apply to the differenced vmdk, whereas a very early snapshot is okay...I was able to create a linked clone with the base vmdk, I just don't have my recent work on there.

I've searched around a lot on this error, tried CloneVDI to no avail, tried some other crufty VMWare tools that proved too crufty (a VMDK mounting tool from 2004 and Ken Kato's vdk tool), and the general consensus seems to be that all my work on the differenced vmdk is gone, never to return. Is this true? Do I have any hope of even just getting a few files out of that vmdk...since they're probably still there in raw form? If not I'll have to redo two days of work.

Also, I got the impression from this site: <a wordpress post titled "VIRTUALBOX VDI vs VMDK" that I apparently don't have the cred to post> (...which looks incredibly reliable...) that I would've just gotten a gentle warning about this rather than a corrupted virtual hard drive if I had been using a vdi and not a vmdk. Is this true?

I know this error has been covered in the forums, but after reading I still had these questions. Thank you for any help.

Evan

The current state (i.e. what you would call the latest snapshot) is toast, but you should be able to clone any of the earlier states and build a new VM around that.

If you expect help then rather more detail is required than e.g. "tried CloneVDI to no avail". We'll need symptoms, error messages etc.

If you expect help then rather more detail is required than e.g. "tried CloneVDI to no avail". We'll need symptoms, error messages etc

Alright. When I entered the latest snapshot as the source in CloneVDI, I get "Source file corrupt - block map contains errors", and I am not allowed to proceed. The other tools I tried I was not able to even get them running on my Windows machine. One was VMware Diskmount. The other was called vdk, which I think didn't run because my Windows system is 64-bit. Both of those tools were meant to mount the vmdk on the host system, but the vmdk is using ext4, so not sure if that would have worked anyways.

The only thing I am allowed to do to the snapshot within the VirtualBox GUI is release it...everything else is grayed out. I posted the errors VirtualBox gave to me. I am not able to start the broken VM without it giving the first errors I gave. I don't think I saw any other error messages or symptoms.

You basically answered my main question though...that the current state is toast. The previous states aren't of much use to me unfortunately. If I am able to at least rescue the files from the corrupted vmdk, that would be awesome. If that's not possible either, then I'll start duplicating my work. I didn't get an answer to whether the VDI format would have handled the host disk space problem more gracefully though. Is that true?

Ok, so CloneVDI and VirtualBox are saying essentially the same thing ("block map" is a generic term used by CloneVDI, the VMDK spec calls their version of it a grain table, a la the VirtualBox message.

I've only ever succeeded in repairing damaged block maps in stand alone files, never a difference image. I tend to avoid difference images in all forms (e.g. snapshots) because of their obvious fragility in situations like this - and of course the space they take up on the host disk, which of course makes problems like yours more likely.

Alright then. Lesson learned I guess. I am too infrequent of a user of VirtualBox (or VMs in general) for the fragility of difference images to be obvious to me. It is now.

I did manage to get vdk running on a 32-bit Windows host by the way, but it just seemed very confused by what it was trying to mount: it asked me to ignore about 10 entries in the vmdk and claimed the entire partition had one file.

Thanks for your replies!

Evan

Even if you get it to mount with your third party tool: if the block map / grain table is corrupted then you really can't trust anything that comes off the disk. Still, data you can't trust might be marginally better than no data at all, it depends on what you're trying to recover.

Oh, and I forgot to mention: for future ref your problem with mounting couldn't have been due to using a 64bit filesystem. Apart from minor tweaks the filesystem (NTFS) used by Win8 64bit is the same as that used by Win2k-32bit and every version of NT in between. There may be differences in partition map, boot manager etc, but the filesystem format is unchanged.

Right...my understanding is that the specific tool (vdk) only worked on 32-bit Windows. I've found that someone has since ported it, but I didn't try the ported version.

I really just wanted a few C++ source files that I modified, so I would be able to figure out if it was trustworthy or not. But you're right...in general that wouldn't necessarily help. The code ended up being pretty easy to regurgitate again, so all is good.