VBoxManage modifyhd resize does not honor desired size and fills complete partition => fixed in SVN/next maintenance

[Sunwolf]

Hello, on a current Debian stable (Jessie) host I tried many times to expand a 30G Win7 Pro disk (no snapshots) using "VBoxManage modifyhd /path/to/disk.vdi --resize 47000" and also the newer "modifymedium disk /path/*.vdi" both with "--resize" and and also "--resizebyte 47000000000". In all cases the resize operation ended only when the vdi had completely filled all free space there was on the partition (about 60G in my case). This is a showstopper to the free upgrade of the virtual machine to Win10 that would need to be completed before the end of the month. Greetings, Sunwolf

[Frank Mehnert]

Cannot reproduce, this works very well with VBox 5.0.24. I would like to see the output of

VBoxManage showhdinfo /path/to/disk.vdi

before and after you tried to resize the image. Also, on which file system is your disk image located?

[Sunwolf]

Thanks, Frank.

BEFORE:

# VBoxManage showhdinfo /mnt/ssd-vm/virtualbox/Machines/win7-ordi/win7-ordi.vdi
UUID:           d91d7251-dc2d-44b1-bb4f-5f1a8ac1c80a
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /mnt/ssd-vm/virtualbox/Machines/win7-ordi/win7-ordi.vdi
Storage format: VDI
Format variant: dynamic default
Capacity:       30820 MBytes
Size on disk:   30750 MBytes
Encryption:     disabled

# ls -lh <DIR>
total 31G
drwx------ 2 avh avh 4,0K Jul  8 12:13 Logs
drwx------ 2 avh avh 4,0K Jän 13  2015 Snapshots
-rw------- 1 avh avh  22K Jul  8 12:31 win7-ordi.vbox
-rw------- 1 avh avh  22K Jul  8 12:13 win7-ordi.vbox-prev
-rw------- 1 avh avh  31G Jul  8 12:31 win7-ordi.vdi

CMD:

# VBoxManage modifymedium disk /mnt/ssd-vm/virtualbox/Machines/win7-ordi/win7-ordi.vdi --resize 44000

This time for the first time I get an error message and the progress figures are stuck instead of ending with 100%:
0%...
Progress state: VBOX_E_FILE_ERROR
VBoxManage: error: Failed to resize medium
VBoxManage: error: Code VBOX_E_FILE_ERROR (0x80BB0004) - File not accessible or erroneous file contents (extended info not available)
VBoxManage: error: Context: "RTEXITCODE handleModifyMedium(HandlerArg*)" at line 701 of file VBoxManageDisk.cpp

AFTER:

# VBoxManage showhdinfo /mnt/ssd-vm/virtualbox/Machines/win7-ordi/win7-ordi.vdi
UUID:           d91d7251-dc2d-44b1-bb4f-5f1a8ac1c80a
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /mnt/ssd-vm/virtualbox/Machines/win7-ordi/win7-ordi.vdi
Storage format: VDI
Format variant: dynamic default
Capacity:       30820 MBytes
Size on disk:   60577 MBytes
Encryption:     disabled

# ls -lh <DIR>
total 60G
drwx------ 2 avh avh 4,0K Jul  8 14:24 Logs
drwx------ 2 avh avh 4,0K Jän 13  2015 Snapshots
-rw------- 1 avh avh  22K Jul  8 14:25 win7-ordi.vbox
-rw------- 1 avh avh  22K Jul  6 19:27 win7-ordi.vbox-prev
-rw------- 1 avh avh  60G Jul  8 16:22 win7-ordi.vdi

DISK: 
# df -hT: /dev/sdc5 ext4 219G  198G   17G  93% /mnt/ssd-vm
# fstab:  /dev/sdc5 /mnt/ssd-vm ext4 noatime,commit=60 0 2
# hdparm: Model=Samsung SSD 850 PRO 256GB, FwRev=EXM01B6Q

KERNEL:
Linux <hostname> 4.6.0-0.bpo.1-amd64 #1 SMP Debian 4.6.1-1~bpo8+1 (2016-06-14) x86_64 GNU/Linux

PS: This was a vdi backup put in place after the previous failed attempt at resizing. The virtual machine started normally for a brief test run and shut down cleanly. Should I have issued a

# fstrim -v /mnt/ssd-vm before resizing?

Regards, Andreas

[Sunwolf]

PPS: Once I accidentally attempted a resize on the backup-vdi that rests on an ordinary ext4 partition (rw,relatime,data=ordered) on a standard 2.5" SATA-hdd (Model=HGST HTE541010A9E680, FwRev=JA0OA560), running as the active partition in a degraded new RAID1 that I am in the process of building. The partition has the same size as the previously described SSD partition, therefore resizing also stopped when the disk was almost 60G big: Same story albeit followed through until 100% without any error message. The output of # tail -n2 <my_backup>.vdi after the failed resize to some 48G ended with the following characters:

#��i�+ 78ӌ�(����+78ԌE(����+�68Ռi(����+�68֌(����+�68׌#�(t��+�68،(�(��A�+�68ٌ-�(��e�+�68ڌ2�(����+�68ی7y(4���+�68 ▒�U        xs\0 ▒�U        _mi0 ▒�U        ws-0 ▒8 #.bi0 ▒8      #56a0 ▒8        #6000 ▒�U       0 ▒�U   0 ▒�U   0 ▒�U   � ▒8    #37d0   ▒8      #$TXF_DATAml

[Frank Mehnert]

Thanks. Could you also provide the output of

dump2efs -h /dev/sdc5

[Frank Mehnert]

And please also

ls -l /mnt/ssd-vm/virtualbox/Machines/win7-ordi/win7-ordi.vdi

before and after the attempt to resize the image.

[Sunwolf]

Thanks again.

# dumpe2fs -h /dev/sdc5
dumpe2fs 1.42.12 (29-Aug-2014)
Filesystem volume name:   ssd-vm
Last mounted on:          /mnt/ssd-vm
Filesystem UUID:          9f2f2f18-6e2a-4079-a826-a6b288296f9a
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              14548992
Block count:              58188881
Reserved block count:     1163777
Free blocks:              6689718
Free inodes:              14512927
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1010
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Mon Jan  5 00:09:22 2015
Last mount time:          Tue Jun 28 12:26:30 2016
Last write time:          Tue Jun 28 12:26:30 2016
Mount count:              63
Maximum mount count:      -1
Last checked:             Mon Jan  5 00:09:22 2015
Check interval:           0 (<none>)
Lifetime writes:          575 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      151e1f03-5129-44d7-8f90-377fb7daa974
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00031fa6
Journal start:            8220

rest will follow asap

[Frank Mehnert]

Thanks. Looks like some block allocation in your VDI went mad. Could you provide the first 2048KB of the VDI file (dd if=... of=... bs=1024 count=2048)? You will not be able to attach this file to this ticket, so could you mail it to me at frank _dot_ mehnert _at_ oracle _dot_ com? Thank you!

[Sunwolf]

Replying to frank:

Thanks. Looks like some block allocation in your VDI went mad. Could you provide the first 2048KB of the VDI file (dd if=... of=... bs=1024 count=2048)? You will not be able to attach this file to this ticket, so could you mail it to me at frank _dot_ mehnert _at_ oracle _dot_ com? Thank you!

Here it is: ​https://hasel.sandpsych.at/owncloud/s/3Sx3ko8jERpgPMe

[aeichner]

We were able to reproduce the issue and fixed it. Will be part of the next maintenance release. Btw. did you use VBox to create the VDI in the first place or some third party tool? The header of your image albeit not against the spec has an unusual value for the offset of the first data block (1,2 GB, normal is somewhere in the MB range).

[Sunwolf]

Hello Frank, great that you you were able to reproduce and fix the issue. The VDI was indeed created by VBox, but I guess when I ran out of disk space once before I used some online calculating tool and transformed the desired disk size in GB to the appropriate size in MB and expanded the disk on the basis of this value. I seem to remember that at the first attempt I created a 300GB disk instead of 30 GB and either went through great pains to make it a smaller disk again because I had no backup and too much trust in my ability to get it right immediately, or I did have a backup and perhaps used some wrong parameter upon the second attempt? Cant't tell if this explains the strange offset size. - BTW, will it be possible to enlarge even my strange disk properly with the next maintenance release's resize command? When will it be out? - And one small wishlist item: is it perhaps possible to let the expansion process ask for confirmation, telling you once how many GB the disk will have after the resize? I guess I am not the only one who ran into troubles when omitting or adding one number too much as the resize MB option. Best regards from Vienna, Austria, Andreas

[Sunwolf]

Hello again, thanks for pushing out the new 5.1. release. VBoxManage modify... <*.vdi> --resize 47000 now worked immediately, keeping the dynamic disk's size identical but when starting the machine I get a black Windows screen saying "FATAL: No bootable medium found! System halted." Is this a problem related to my huge offset? Is there a workaround? I can handle a hex editor and would be glad for advice. Or would cloning the disk do away with the offset? Or is this another problem? Greetings, A.