VBoxManage modifyhd

[Carlos V]

I used VBoxManage modifyhd --resize to add space to a disk vdi, but now it doesn't start, it says "Missing operating system". How can I repair the vdi disk? Thanks.

[Carlos V]

Both systems, host and guess, are Windows 7.

[mpack]

Does this VM use snapshots?

What was the precise command you entered?

The best fix is to restore the VDI from that backup you sensibly chose to take right before starting this procedure.

[Carlos V]

No, I didn't get a snapshot.
The command was: vboxmanage modifyhd Windows7.vdi -–resize 800000.
And no... I didn't take a backup...
When I try to repair the VM with the disk of Windows 7 it shows me two partitions, C (with the new added size) and D (with the original space). I think the OS is in D and C is empty. I would need a tool to swap the partitions, set D as C and can start the machine...

[mpack]

The command was: vboxmanage modifyhd Windows7.vdi -–resize 800000.

Well, that explains what's wrong with the disk. 800000MB is 781.25TB, which is comfortably larger than the 2TB max size drive supported supported by a non-EFI BIOS. With no backup the only thing that will fix this is hacking the VDI header with a hex editor.

... though another possibility just occurred, which however will require lots of free disk space.

Please check whether CloneVDI accepts this VDI as input. Do not try the clone the disk normally because the output will be humungous!, your host will not have the disk space for it. Instead go into the sector viewer feature and tell it to dump the first X sectors to a file with a .raw extension. It's important to: dump starting from sector 0, dump enough sectors to cover the old disk size (nSectors = DiskSizeInBytes/512). Later you will clone the .raw file using CloneVDI, which will give you back a usable VDI. You can use CloneVDI's disk enlargement feature while making the clone.

No promises, just take your time to be sure you do it right. This advice relies on your assurance that this VM did not use snapshots.

[Carlos V]

CloneVDI says me "Source file corrupt - block maps contains error"...

[mpack]

In that case we're back to the hex editor idea, as discussed for example here. Remember to make a backup before you start, so you can't make anything worse.

[Martin]

Well, that explains what's wrong with the disk. 800000MB is 781.25TB, which is comfortably larger than the 2TB max size drive supported supported by a non-EFI BIOS

According to my calculator that would be about 780 Gigabytes, not TB?

[mpack]

Out of interest I tried reproducing your results. I took a dynamic VDI representing a 32GB disk, and enlarged it using "VBoxManage modifyhd <vdiname> --resize 800000" (after making a backup of course).

I then tried to read the resulting VDI using CloneVDI, and got the error message "Block map contains errors". On investigating this error I found that the VDI header claimed to have 1740 blocks allocated, but the block map only contained "normal" references to 1739 allocated blocks. IMHO this appears to be a bug in the resizing logic in VBoxManage. I suppose another thing to try would be to check if VBoxManage gets it right when it isn't being asked to create a humungous disk.

[mpack]

Well, that explains what's wrong with the disk. 800000MB is 781.25TB, which is comfortably larger than the 2TB max size drive supported supported by a non-EFI BIOS

According to my calculator that would be about 780 Gigabytes, not TB?

Whoops! Quite right. I missed out the gigabyte order of magnitude entirely.

In that case I don't need to do that "humungous disk" check, as the answer is already known.

Edit:  Now that I know that the size request isn't invalid on its face for an XP (non EFI) guest, I tried booting my own XP guest - which is what the resized disk happened to contained. And in fact it booted normally. So, there is no systemic error in VBoxManage which prevents the "--resize 800000" request from working properly... though the header conflict still needs to be resolved. I don't believe the validation error is a CloneVDI bug: it's been doing this same validation check since 2009, on every VDI file it opens - why would it single out a VDI that has been manipulated in this particular way?

[Carlos V]

In that case I don't need to do that "humungous disk" check, the answer is already known.

What's the known answer? Do I fix the error with hex editor?

[mpack]

I meant that the answer to the "humungous disk check" experiment is known.

No, you don't need a hex editor. The disk size you chose is rather large, probably unintentionally so, but in fact is well within the size limit (my earlier statement to the contrary was a mistake).

Which means that your disk has been trashed for some other reason. Snapshots are usually that reason, or other variations of the same technology since as immutable disks, linked clones etc. None of which you've mentioned using, and snapshot use in particular you have actually denied.

Just for a larf, can you list the contents of your <VM folder>\Snapshots subfolder? Please make sure that your Windows host folder options do not include the enabled setting "Hide extensions for known file types".

Oh - and please state explicitly that this VM had not been manipulated in any other way since it was last known to be working as a Virtualbox VM. That includes cloning it or copying it out of another VM folder or from another host etc.

[Carlos V]

Yes, the subfolder Snapshots is empty, I never did a snapshot with that VM.
None manipulation. I executed the command 'vboxmanage modifyhd Windows7.vdi -–resize 800000' and inmediately I started the VM and it said "Missing operating system".

[mpack]

I still need you to state explicitly that this "Windows 7" image was previously working as a VirtualBox VM.

Yes, the subfolder Snapshots is empty, I never did a snapshot with that VM.
None manipulation. I executed the command 'vboxmanage modifyhd Windows7.vdi -–resize 800000' and inmediately I started the VM and it said "Missing operating system".

Then the only possibility that occurs to me is that Windows 7 itself does not like what you've done to the disk.

Windows XP and later has an optional feature called "Dynamic Disks" - this should not be confused with the "Dynamic VDI" feature of VirtualBox. Most people I think don't bother with dynamic disk (the equivalent of Linux's LVM), because of its incompatibility with all kinds of tools which manipulate the disk, e.g. partition managers, disk imagers etc. Dynamic Disk hides partition information in a 1MB unpartitioned region at the top of the disk. If such a disk was to be enlarged then of course that data would no longer be at the end of the disk and Windows may fail to boot... I never use Dynamic Disks, in fact I don't know that the Win7 implementation does it the same way as the XP version I've experimented with - but perhaps you will know if this is a valid possibility.

As to solutions: the only solution, given the lack of a backup, is to somehow shrink the drive again back to its original size - and it must be restored to exactly its original size. Neither CloneVDI nor VBoxManage will allow you to shrink a disk, there is however a third party tool called Vidma which claims to allow it. See the authors thread here. Make a backup first, as I said earlier. Also note that I've letting you know that this tool exists, however I've never used it myself and cannot promise anything about it.

If that doesn't work then a final solution is to mount the VDI as a 2nd drive in a Linux VM, attach a third drive to that VM, of the original size, and 'dd' the appropriate number of sectors from the 2nd to the 3rd drives. Of course you could also use something like this to copy important data off the drive.

I'm assuming that the data on the drive is important?

[Carlos V]

Yes, that VM was working ok with Windows 7. I used it as test system but also to work with Access 2007 (in my host I've Access 2010). I was developing a new bd and I need to recover it .
I 've a VM with Ubuntu and I can try your final solution.