Should be fixed in 3.0.10. We were indeed updating the footer in a lazy way. If the VM process crashed (which shouldn't happen in the first place), the VHD could be left in an inconsistent state
Awesome. This should go a long way to reducing disk corruption if the host machine/process dies.
I understand that 3.0.10 fixed the root problem, is there any way to fix a drive that was affected by this problem? I have a VHD that failed due to the INVALID HEADER issue but I still can't mount it in 3.0.10. I was hoping maybe 3.0.10 would be able to do a check on the drive and fix the header before mounting the volume. I also can't access the drive by mounting it directly from Windows.
longwa wrote:Any way to repair the drive or am I just screwed?
You can try my CloneVDI tool, which may be able to convert it to a usable VDI - I have a vague notion that my code will use the "backup footer" (AKA the header) if that is still intact. I offer no guarantees however that this will work.
I suggest you use the "Keep UUID" option. You can then either use the VDI from now on or, if you haven't learned your lesson about VHDs yet, you can use VBoxManage to convert it back into a VHD.
Unfortunately, it didn't fix the problem. It did convert the image to VDI successfully, but I get an error trying to import the drive:
Result Code:
E_INVALIDARG (0x80070057)
Component:
VirtualBox
Interface:
IVirtualBox {3f4ab53a-199b-4526-a91a-93ff62e456b8}
I had no idea using a VHD was a ticking timebomb for destroying my VM. I'm glad they fixed it so quickly, but it's still a huge blow to my confidence in VB.
By "import the drive", I assume you mean registering the VDI in "File | Virtual Media Manager".
As a wild guess I'd say that the "invalid argument" is the drive UUID. If you chose the keepuuid option in CloneVDI then that's ok, but VBox will not allow you to register two virtual disks with the same UUID, so you need to unregister the VHD first. If you want to keep both then they need to have different UUIDs.
When I said "not guaranteed to work" I had in mind something rather more serious than getting the VDI registered (it's a valid VDI, so VBox should accept it). The bigger problem is that we are assuming there will be some discrepency between the disk image and the header, hence it's possible there will be lost files, lost data etc. Do a disk check once you get it to mount. Plus of course CloneVDI knows nothing about snapshots.
You can't blame the VBox team for the poor design of VHD, because they did not design it. They merely added support for it for the benefit of people like you who choose to use it. The issue with lazy updates of the footer was an understandable oversight, but all it did was exaggerate a problem which is inherent in VHD.
You are right, didn't realize that I had to remove the prior drive from the Media Manager before I could import another one with the same UUID. Now that I have the VDI copy imported, I can start the VM, but as you say, the disk is corrupt. I immediately get a Disk Read Error. At least now I can approach it as a bad guest disk and try using the recovery console to make the disk bootable again.
I had a corrupted VHD disk, and it give me the error VERR_VD_VHD_INVALID_HEADER. It happened after i run out of space in my host pc. I closed the session normaly but it never open again. I could not copy the data with the CloneVDI tool. I could open all my data with a tool called WINIMAGE . It's sharware and it let's you extract everything for free. http://www.winimage.com/winimage.htm . It doesn't open VDI files.
The forum has been of great help.
Thank you.
b_ernesto wrote:I could not copy the data with the CloneVDI tool. I could open all my data with a tool called WINIMAGE . It's sharware and it let's you extract everything for free
Sounds like it gave you a corrupted copy - for free. Not the bargain it may at first appear...
A program that doesn't have enough validation checking to at least warn you that its source data is corrupt - is not a tool I would care to use.
What would you think of saving error correction code with the disk images, similar to RAID 5? The ECC-blocks wouldn't have to be as big as in real RAID5, say an ECC-Block could have 1% of the size of a vdi-sector. Other than RAID5 there needn't be several drives/vdis, but only this 1% ECC per vdi-block.
It could be added like another disk write mode like 'normal', 'immutable' and so on. So one has a choice if he wants ECC or not. The choice of performance vs error-tolerance. The amount of ECC-code per sector could be made adjustable to better adapt to a systems performance characteristics. This would be similar to WinRARs ECC. But on a per-sector-level, for better performance. Reduced speed would be obvious, but unrecoverable read errors would occur less often. Error-detection and error-correction would be automatic. In the age of powerful multicore cpus the ECC-threads could run on free cores.
Host: Windows 7 32Bit
Guest: Windows XP Pro 32Bit
CPU: Core 2 Duo T7700 @ 2.4GHz
Frankly, I'd be against it. I'm not familiar with RAID, but I am familiar with error detection and correction. It would carry an overhead which would degrade performance, and it shouldnt be necessary on a host hard disk that already does it in hardware, and anyway it would not address the basic problem of instability in the VHD design, because the problem here is that if the user gets a crash, a power cut, or runs out of host disk space, after new sectors are is written to disk but before the footer is (lazy) written, then the drive is corrupted. In all these scenarios the footer data was never written hence no amount of ECC will recover it.
What about an approach similar to FAT32? It has 2 copies of the FAT. Why not save 2 copies of the header? This way you have a backup and errors can be identified and corrected just like in FAT32. The header is small and doesn't get written very often. Performance wouldn't suffer and a tool can repair the vdi-header.
Host: Windows 7 32Bit
Guest: Windows XP Pro 32Bit
CPU: Core 2 Duo T7700 @ 2.4GHz
Such discussions are moot here, because VirtualBox does not control the VHD format. VirtualBox does control its own format, i.e. VDI, which does not have problems VHD has.
In fact VHD already has two headers, one at each end of the file. The problem is that the one at the end gets overwritten when a dynamic drive enlarges, leading to a potential for corruption mentioned earlier, which validation checks detected as a VHD spec violation. Whether it still does I don't know, this thread is quite old now and there have been no recent reports.
VDI only has a header, not a footer. The header is never overwritten with anything except an updated header, so the problem of invalid intermediate states doesn't arise.
Thanks to b_ernesto, six posts up, for pointing me to WinImage! The Windows XP system and data disks of a VirtualBox VM (both VHD after a P2V conversion of a build server, long ago) were corrupted due to the host disk becoming full. They could no longer be opened by VirtualBox and could not be mounted in Windows 7.
WinImage opened and cloned the system disk. Cloning of the data disk failed, but Winimage copied its contents, except for two files, to another disk. After mounting the new disks in the original VM it booted without problems, whereafter chkdsk fixed an issue on the system disk (which may have existed before the crash). It is now building our software as before, with the build history intact.
Oh yes, after this incident CloneVDI was used to convert the disks to VDI and compact them. Thanks mpack!
A smart user doesn't use any paid VDI/VHD repair or recovery tool when he/she has multiple free options including Microsoft's VHD tool. It can repair VHD file. Also, there's a couple of manual tricks one can try to repair VHD file. Try any of these: 1. Repair VHD file by running script on Windows PowerShell that will help you mount the VHD file in the root folder, and then you can run a CHKDSK on it. 2. repair VHD file by creating a new Virtual Machine, add the corrupt Virtual disk file to it and then compact it.
