Increase Virtual Partition Storage for VirtualBox

Posted by JD 08/09/2011 at 08:00

This weekend, my 3 yr old VirtualBox VDI storage for this, my primary virtual machine, was getting close to 100% filled. It was a 10G partition that started out as a 6.06 installation, then was upgraded to 8.04 and finally to 32-bit Ubuntu Server running 10.04. To get a GUI, I added LXDE a few minutes after the 10.04 upgrade about a year ago. So as I wanted to start a new development project leveraging PerlBrew to manage different versions of entire Perl versions, libraries and CPAN modules, I knew the little space remaining would not be enough.

I did a little research before I began. The web pages that I found seemed to be taking the long way around to solve a fairly easy issue. They wanted users to download some tool, which was completely unnecessary. Anyway, below the shortest, easiest, way to increase the available storage in a VDI-based virtual machine.

The Steps

My old VDI file was 10GB with about 500MB for swap and 9.5G for /dev/sda1. The new VM will be 13G with the same 500MB for swap and the rest expanded for /dev/sdb1. That should be about 3G more room for growth. I’m being cheap since I backup this data and the raw VDI file as part of my backup strategy. Every bit that gets created needs to be backed up, period.

We will be working inside the VM, just booting from different devices.

Close the Too-Small Virtual Machine

Before we can make changes to a virtual machine settings, we need to shut down any running VM which will be modified. Simple enough. Just be certain to shut the specific VM to be resized.

Add a New Disk Sized Larger

Open the settings for the VM. Go to the

  • Storage tab,
  • Add a new Disk,
  • Create a New Disk file.
    Be certain to choose a fully pre-allocated setup so your VM won’t be slow. In my case, I chose a 13GB size and watched it be created. It took about 2 minutes to complete. This is just a raw file acting like an empty, unformatted hard drive. It is automatically attached to the VM. You should see 2 disks attached to the VM now. Perfect.

Inside the Settings for that VM, Add a Gparted ISO

In the Storage tab again,

  • Add a new CDROM,
  • Select the gparted ISO you previously downloaded
    If you had another ISO selected, simply replace it with the gparted.iso file.
    Save your settings.

Boot the Gparted ISO Inside the VM

Boot the VM. On mine, the CDROM booted automatically and started the GParted program.

Review the Partition data for both HDDs

When Gparted boots, it automatically starts the gparted program. In my case, there was a 10GB /dev/sda and a 13GB /dev/sdb device. I kept track of which was sda and which was sdb. This is critical for the next step.

Shutdown Gparted, the program

Click the ‘X’ to shutdown the gparted program, not the OS.

Open a “root” Terminal

We are going to clone the original HDD – all the data, all the partitions, everything. dd is the tool for that.

# nice dd if=/dev/sda of=/dev/sdb  bs=1024000

This command will mirror everything from SDA into SDB. Be very careful to get sda and sdb in the correct places on this command. If you get them backwards, you will overwrite all your data with garbage.

The ‘dd’ here took just under 6 minutes. Now we’ve completely mirrored one virtual HDD into another HDD, bit for bit. Next we need to move and resize some partitions in the new HDD for our needs.

Startup Gparted Again

Startup the Gparted program. Access the larger virtual (physical) disk, that’s where our changes need to be made. Don’t touch the smaller HDD.
Inside the HDD were 3 partitions.

  1. sdb1 – OS Partition
  2. sdb2 – Extended Partition
  3. sdb5 – logical swap partition, located inside the extended partition

We need to move the Extended Partition and all the partitions and data inside to the end of the newer, larger virtual hard drive. Gparted makes that easy. Use the move command on sdb2. I always align on cylinders – was burned by not doing this once.

Now you can resize the sdb1 partition to take up the additional 3.5G or so. Use the resize command and align on cylinders.

Be certain to click Apply or your modifications won’t happen. Gparted will perform the tasks, in order, and provide a log. Doing all this took about 3 minutes. If you watch it by following the details, you will see that the last step was to resize the file system inside sdb1. That was important.
This file system resize completely depends on gparted understanding the file system. If it doesn’t, you may need to use a rescue disk, however, gparted knows about all the popular Linux file systems, so this issue shouldn’t impact many people.

Shutdown the VM with Gparted

Now we’ve moved and resized our data, we need to shutdown the Gparted program and shutdown the running VM. We need to edit the VM settings and remove a few things.

Edit the VM Settings Again

Go back into the settings for the VM. Go to the Storage tab again and

  • remove the gparted ISO
  • remove the old /dev/sda disk from the VM
    This doesn’t delete the old VDI from the disk, so your data and everything else is still there as a backup. I’d keep this for a week before removing it, just to be certain everything went well. After a week, be certain to delete this old VDI file so it doesn’t waste storage unnecessarily.

Startup Your New, Larger VM

This time when you start the VM, you are running using the new, larger VM. The HDD will appear to be /dev/sda and the booted partition will be /dev/sda1 from inside the VM. All your data is there and a df -k will show:

$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 13211492 8771296 3769140 70% /

Pretty nice.

From start to finish, this took about 15 minutes.

Make a Backup via Export

Now that the VM is larger, I will make a VM backup using the Export capability of VirtualBox. I have a script which does this, but using the GUI works too. This is not a replacement for my daily backups using rdiff-backup. Think of it as the difference between an image-based and a file-based backup. Both have their places.

Tonight the normal, automatic, backups that run inside this VM will happen again, as usual.