virtualbox.org

Has anyone seen the problem where after resizing a vdi, filesystems on partitions within the expanded disk space fail to mount?

I have spent days now on this problem and have googled extensively as well as searched these forums.

My host is running VirtualBox 5.0 on CentOS 7.3. My guest is SLES 12 SP1. My VM is a vdi with snapshots.

My guest has 100GB but I needed to increase the disk to 200GB to accomodate a large data set. I expanded the "Current State" "snapshot" with vboxmanage modifyhd '{0e60a57b-83c4-45e0-94b9-ad50778b1d8c}.vdi' --resize 204800.

This seemed to work fine. I could see it in the settings and when I started the VM, I could see the 200GB space with fdisk, parted, etc.

However, if I create a new primary partition in the expanded space, any filesystem that I create in that partition will fail to mount (giving all kinds of errors, but typically references to bad superblock etc.).

If I create a partition in the "old" (pre-expanded/first 100GB) space, an associated filesystem mounts fine. But if I create a partition in the newly expanded space (in the 100GB or higher range of the disk (/dev/sda)), an associated filesystem will not mount. This is not a function of the filesystem, as I have tried ext4, xfs, btrfs, etc. This is not a function of the partitioning agent as I have used fdisk, parted, gparted, and various versions of each. I have tried with and without Host I/O Caching enabled.

Here is a typical experience:

[vbox-head-sles12:~ #] parted
GNU Parted 3.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mkpart primary ext4 60GiB 75GiB
(parted) mkpart primrKary ext4 110GiB 125GiB
(parted) u GiB
(parted) p
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 200GiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 0.00GiB 2.01GiB 2.01GiB primary linux-swap(v1) type=82
2 2.01GiB 41.4GiB 39.4GiB primary btrfs boot, type=83
3 60.0GiB 75.0GiB 15.0GiB primary ext4 type=83
4 110GiB 125GiB 15.0GiB primary type=83

(parted) q
Information: You may need to update /etc/fstab.

[vbox-head-sles12:~ #] mkfs -t ext4 /dev/sda3
mke2fs 1.42.11 (09-Jul-2014)
Creating filesystem with 3932160 4k blocks and 983040 inodes
Filesystem UUID: 46a9bfe2-227b-49ed-9a75-5b46e46541f5
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done120
Writing inode tables: done120
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done120

[vbox-head-sles12:~ #] mkfs -t ext4 /dev/sdaK4
mke2fs 1.42.11 (09-Jul-2014)
Creating filesystem with 3932160 4k blocks and 983040 inodes
Filesystem UUID: 1b866828-587b-4581-a07d-bdfea3f3b41a
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done120
Writing inode tables: done120
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done120

[vbox-head-sles12:~ #] mount /dev/sda3 /mnt/home3
[vbox-head-sles12:~ #] mount /dev/sda4 /mnt/home4
mount: wrong fs type, bad option, bad superblock on /dev/sda4,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try
dmesg | tail or so.

After much continued searching of VirtualBox tickets, and much experimentation, I believe I have an answer to my question.

This has been complicated by a range of answers on the supportability of resizing of snapshots, with seemingly authoritative responses such as:

* you have to resize the correct differencing image
* you have to resize the base image and all snapshot/differencing images
* you can't do it period
* you can only do it on the base image and only if you delete/merge your snapshots first
* you can only do it on your base image after cloning (without snapshots)
etc.

Ultimately, I tried all of these things, and many more. I found the responses in VirtualBox ticket #13046 and the link referenced therein to be the most helpful and the closest to my experience.

I found that if I wanted to resize a particular snapshot, that I first had to clone the snapshot and select "Current machine state" so that it would create it as a VM without snapshots. Then in this new VM, you can resize the base vdi (there will be no Snapshots directory), and then things work pretty well from there.

It does appear, that it causes corruption if you attempt to do any resizing when any Snapshots are associated with the VM.