virtualbox.org

Hi everyone,

I tried to resize my my virtual machine (it's another Ubuntu instance) from 1TB to 1.5TB but I made a mistake and put the wrong size in.

Code: Select all

vboxmanage modifyhd dellnewubuntu.vdi --resize 1592890138624

It did finish but when trying to starting the virtual machine, I receive the following:

Code: Select all

Could not open the medium '/mnt/bigspace/dellnewubuntu.vdi'.

VDI: invalid header in '/mnt/bigspace/dellnewubuntu.vdi' (VERR_VD_VDI_INVALID_HEADER).

VD: error VERR_VD_VDI_INVALID_HEADER opening image file '/mnt/bigspace/dellnewubuntu.vdi' (VERR_VD_VDI_INVALID_HEADER).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: Medium
Interface: IMedium {29989373-b111-4654-8493-2e1176cba890}

I was reading on the forum about vidma and when I tried to shrink the size down, I receive the following error:

Code: Select all

 ./vidma /mnt/bigspace/dellnewubuntu.vdi 112400
Recognized file format:
        Virtual Disk Image (vdi)

ERROR   BAM overlaps data.
ERROR   block size (1048576), block count (3752239104) and disk size (1670266369997799424) mismatch.

Here is what vidma spits out for the image:

Code: Select all

Recognized file format:
        Virtual Disk Image (vdi)

pre.file_info                    = <<< Oracle VM VirtualBox Disk Image >>>

pre.signature                    = beda107f 3201962111
version                          = 00010001 65537
header.size                      = 00000190 400
header.type                      = 00000001 1 (dynamic)
header.flags                     = 00000000 0
header.offset.bam                = 00001000 4096
header.offset.data               = 7e9d3000 2124230656
header.pchs.cylinders            = 00000000 0
header.pchs.heads                = 00000000 0
header.pchs.sectors              = 00000000 0
header.pchs.sector_size          = 00000200 512
header.dummy                     = 00000000 0
header.disk.size                 = 172dfa6a00000000 1670266369997799424
header.disk.blk_size             = 00100000 1048576
header.disk.blk_extra_data       = 00000000 0
header.disk.blk_count            = dfa6a000 3752239104
header.disk.blk_count_alloc      = 000e72ca 946890
header.uuid.create               = 9aec216f-0d20-468f-8fab-709a80a46875
header.uuid.modify               = 27466faa-4cd5-4ba5-be90-afc9ac7e96fd
header.uuid.linkage              = 00000000-0000-0000-0000-000000000000
header.uuid.parent_modify        = 00000000-0000-0000-0000-000000000000
header.lchs.cylinders            = 479dca7d 1201523325
header.lchs.heads                = 000000ff 255
header.lchs.sectors              = 0000003f 63
header.lchs.sector_size          = 00000200 512

Any help will be appreciated, I do have a backup but it's a little dated and I would kind of like to see if I could restore this vdi. Thanks.

Mistakes like that are hard to recover (if at all possible), but mpack, the guru for anything VDI related, filed a report on behalf of all the people that make the same mistake (ticket #16311). A workaround has been implemented 8 days ago, where in the next VirtualBox version, you won't be allowed to make a VDI bigger than 1000 its original size. Unfortunately, you're too late (or too early). I can't say for sure if you hit the limits that mpack is talking in the bug report, but I believe you might have.

See Ticket #16311: VBoxManage modifyhd resize needs better parameter checking to prevent catastrophic data loss.

Certainly a disk that size probably is large enough that the block map alone is too large for the host partition, so yes, the VM is most likely toast and that backup is your only option.

What VirtualBox version was this? The block map should not end up overlapping the disk image no matter what size you resize to. There was a bug where this happened, but AFAIK it was fixed a long time ago.

Thanks for the replies. I'm running 4.2.6. Do you think it would be possible to run the compact command and then try editing the first x bytes of the header? Or do you think it's possible to mount this messed up vdi in another instance just to get some data off the drive?

Wilki wrote: Do you think it would be possible to run the compact command and then try editing the first x bytes of the header?

No, for several reasons. First VirtualBox can't compact a disk format it doesn't recognize. Second compaction requires you to zero out the filesystem first, which you could only do by booting the VM, which would require a working VM. Third and most important, compaction doesn't change the logical disk size at all anyway, it only changes how much space is allocated on the host for the same disk.

This isn't repairable by editing the header. Disk blocks have been moved to make way for the enlarged block map, and then it looks like the humungous block map caused some kind of secondary errors because of the previously known bug when enlarging >256GB. Possibly 4.2.6 is old enough to still have that bug, I'm not sure.

virtualbox.org

Resizing Issue

Resizing Issue

Re: Resizing Issue

Re: Resizing Issue

Re: Resizing Issue

Re: Resizing Issue