VBoxManage modifyhd

[Carlos V]

The solution with vidma didn't work, I'll try with Ubuntu.

[mpack]

If the problem with Vidma was that you couldn't remember (or didn't know) the exact size of the old disk then you'll have the same problem with the Ubuntu idea.

[Carlos V]

The size of old disk was 20 Gb, vidma worked ok apparently, but the VM doesn't start...

[mpack]

Have you tried booting from a Win7 setup DVD and attempting to repair the installation?

ps. "VM doesn't start" is not very informative. VMs always start unless VBox itself is broken. Please try to describe each failure precisely.

[Carlos V]

I meant VM says always the same thing: "Missing operating system".
I tried to repair with W7 DVD but it doesn't detect operating system in drive C (with the new size) and ask for formatting. I don't know like to force it to repair the drive D (with the old size).

[frank]

See ticket 11344. Sounds related.

[mpack]

See ticket 11344. Sounds related.

Yes, almost certainly. Ouch, this looks catastrophic - I really wish VBox had not gone down the route of in-place mods to important data files.

For those who don't want to read the ticket, apparantly in VirtualBox v4.2.6 and earlier (to v4.0.0 when the resize feature was introduced), the code had an implicit assumption that a disk would never might be increased in logical size by more than <old header slack>+256GB in a single step. I.e. the code assumed that it could relocate the first 1MB image block following the block table, and fill that 1MB with an extended block map. 1MB of block map gives 1MB/4 slots = 256K slots, each of which holds the position of a 1MB block. Hence 256GB.

Consequences would depend on how much of the enlarged block map gets written to disk.

• If the correct (larger) block table size is used when writing the header then at least part of the (new) first image block would be overwritten. In most guest OS's I guess it's highly likely that this would be important metadata. Note that in a dynamic disk the second image block is the 2nd 1MB of data ever written the disk, I would expect the first few MB of data written to the drive to be fileysystem stuff.
• If the incorrect (smaller) block table size is used for the header write then the drive is a timebomb. As soon as the code tries to access those unmapped blocks then there's no telling what it will do.

Thankfully, I expect few people will have used VBoxManage to resize a disk by 256GB or more in a single step. If you have then I suggest using something like Disk2VHD or CloneZilla inside the VM to move the drives partitions into a good container. Unfortunately CloneVDI can't be used because it detects the corrupted header and refuses to do anything.