4

In continuation to Failure to resize a virtualbox volume I used the following commands in order to increase the space available in my virtual machine (Ubuntu):

VBoxManage.exe clonehd "c:\users\a_b\VirtualBox VMs\MyBox_default_1510839571239_2193\Box1.vmdk" "C:\Users\a_b\VirtualBox VMs\MyBox_default_1510839571239_2193\clone.vdi" --format vdi

VBoxManage.exe modifyhd "c:\users\a_b\VirtualBox VMs\MyBox_default_1510839571239_2193\clone.vdi" --resize 102400

VBoxManage.exe clonehd "c:\users\a_b\VirtualBox VMs\MyBox_default_1510839571239_2193\clone.vdi" "C:\Users\a_b\VirtualBox VMs\MyBox_default_1510839571239_2193\Box2.vmdk" --format vmdk

No errors were outputted in the process. However, neither the size of clone.vdi nor Box2.vmdk files was increased to 100GB (that should probably have been my first clue that something was amiss).

I replaced Box1.vmdk with Box2.vmdk as the storage accessed by the VM using the VirtualBox GUI.

When I activated and entered the VM via Vagrant, I checked it size using 

df

and saw that the space available to the VM was not increased.

Indeed the sizes available to the two VMs (before and after "resizing") was similar:

Box1:

/dev/mapper/vagrant--vg-root  39625324  13644568  23944840  37% /

Box2:

/dev/mapper/vagrant--vg-root  39625324  13644564  23944844  37% /

How should I proceed to actually resize the VM? If the space is unavailable because the partition needs to be resized, how should I resize it?

Using 

sudo resize2fs /dev/mapper/vagrant--vg-root

as suggested in https://askubuntu.com/questions/390769/how-do-i-resize-partitions-using-command-line-without-using-a-gui-on-a-server

Yields only 

resize2fs 1.42.13 (17-May-2015)
The filesystem is already 498688 (1k) blocks long.  Nothing to do!

And 

sudo resize2fs /dev/sda1

Yields 

    resize2fs 1.42.13 (17-May-2015)
The filesystem is already 498688 (1k) blocks long.  Nothing to do!

With no changes to size (as evident from the use of df)

Lafayette
  • 183
  • 1
  • 4
  • 12

1 Answers1

5

There are a few misconceptions in your train of thought, probably caused by multiple layers of abstraction.

Resizing virtual disk doesn't necessarily cause the disk file to grow.

By default, virtual disks are sparse, ie. disk files don't actually occupy space that isn't occupied on the virtual disk. That's why growing the virtual disk doesn't affect file size at all - it just changes a number that indicates disk's size.

Resizing virtual disk doesn't change its contents in any way.

And the first layer of abstraction in disk's contents is the partition table. The command that resizes HD doesn't care about it. It treats disk as a series of bytes and doesn't even know what partition table is.

After resizing the disk, you have to find a tool that understands partition tables and resize appropriate partitions.

resize2fs doesn't resize partitions.

There's one more layer of abstraction - a filesystem (FS) that resides on a partition. For all reasonable applications its size should match partition's size, but it can be smaller as well. Extra space will be wasted, though, because you can't store files outside of FS.

What resize2fs does is it adjusts filesystem's size. When ran without any extra arguments, it adjusts FS size to use entire device it resides on.

resize2fs doesn't know what partitions are, too. As I said, it operates on devices, ie. sequences of bytes of known length. Partition is a device, but so is a hard disk. resize2fs doesn't care. It only works with filesystems, not partitions.

Steps to increase disk space available for VM

  1. Grow the virtual hard disk.
  2. Grow appropriate partitions.
  3. Adjust filesystem sizes.

You did #1 and attempted #3, but forgot #2, so #3 didn't do anything. #2 can be done with fdisk (for MBR partitioning scheme) or `gdisk (for GPT partitioning scheme). If you can use tools with graphical interface, I'd strongly recommend using GParted, which works with both partitioning schemes and will do #2 and #3 simultaneously.

gronostaj
  • 58,482