virtualbox.org

in order to resize a vdi disk of a linux guest you need a bootable linux live cd (iso image).
further, the linux live cd should include a terminal an gparted.
in my case i choose ubuntu-8.04.2-desktop-i386.iso.

But first of all: BACKUP the linux guest you want to resize!!
use this howto at your own risk.
forgive me, my imperfect language skills

steps to take:

create a new vdi disk with the required size:
a) start virtualbox; go to menu -> file -> virtual disk manager -> hard diks -> new -> follow the assistant
b) attach the new vdi disk to the guest (old vdi disk) you want to resize: go to settings -> hard disks -> add the new vdi disk as primary slave

mount the live cd (iso image)
c) attach a live cd iso image to the linux guest you want to resize: go to settings -> cd/dvd-rom -> highlight cd/dvd drive mount checkbox -> select iso image -> choose a iso image
d) modify the boot order: go to settings -> general -> advanced -> boot order -> disable floppy / move cd/dvd to the top
e) boot the live cd; choose the first option of the ubuntu install menu (if you use the ubuntu 8.04 live cd iso image)

clone the old vdi disk to the new (terminal live cd desktop)
f) start a terminal from the linux guest desktop (ubuntu desktop go to the menu application -> accessories -> terminal)
g) get root privileges; therefore type into the terminal type: sudo -s
h) find ou the devices of the new and old vdi disk; type into the terminal: fdisk -l
i) write down the output of fdisk -l (look for something like /dev/sda and /dev/sdb or /dev/hda and /dev/hdb)
j) clone the old vdi disk to the new; type into the terminal: dd if=/dev/old of=/dev/new (replace old/new according to your needs)
k) wait (cloning the old vdi disk can take some hours)

verify the clone (terminal live cd desktop
l) verify the partition tables; type into the terminal: fdisk -l (the partition table oft the new and old vdi disk should be similar)
m) verify if the clone vdi disk boots and runs fine:
-> shut down the live cd
-> change the cd/dvd drive mount from iso image to cd/dvd drive
-> make the clone vdi disk to the primary master disk and the old vdi disk to a primary slave disk
-> start the clone vdi disk
n) if the clone works fine you are ready to resize the partition so that the clone can use the whole size of the new vdi disk

resize the clone vdi disk (gparted live cd desktop)
o) shut down the clone vdi disk and modify the cd/dvd-rom settings in order to boot into the live cd
p) start gparted on the live cd desktop (ubuntu desktop: menu -> system -> administration -> partition editor)
q) remove the swap partition (this is only necessary if the swap partition split the clone vdi disk):
-> in gparted all the partition are listed below the graphical illustration
-> right-click on to the linux-swap-partiton and switch it of
-> right-click on to the linux-swap-partiton and delete it.
-> after that delete the expanded-partition too (if the swap is in an expanded-partition)
r) expand the data-partition (in my case ext3):
-> right-click the data-partition choose resize/move and expand the partition to the maximum size
-> right-click the data-partition and reduce the size of data-partition by 500MB-1GB (a new empty-grey part should be created)
s) create a new linux-swap-partition:
-> right-click the new empty-grey part -> new -> option expanded partition (creates an expanded)
-> right-click into the new expanded-partition -> new -> option logical partition / filesystem linux-swap (creates a linux-swap)
t) write down the modifications to the partition table:
-> go to the gparted menu -> edit -> apply all operations
u) close gparted

make the clone vdi disk default and verify it
v) shutdown the live cd
w) make clone vdi disk default:
-> modify the cd/dvd-rom mount settings, so that the guest boots from the clone vdi disk
-> modify the hard disk settings: set the clone vdi disk to primary master and the old vdi disk to primary slave (don't delete it yet)
-> boot into the clone vdi disk, check if everthing works fine

delete the old vdi disk
x) shut down the clone vdi disk
y) delete the old vdi disk:
-> do to hard disk settings
-> highlight the old vdi disk and remove it
-> go to the virtualbox menu -> file -> virtual disk manager -> highlight the old vdi disk and delete it

You have it made.

I have to say thank you to all the unknowns out there in the www. I only assembled their ideas. Thank you!

And how does this differ from the one we have in the VirtualBox FAQ, pointing to the Tutorial: All about VDIs? Yes, it's a lot more extended, but the steps and result are the same.

Unfortunately it also embeds some bad ideas. If you are going to use dd then you should first run zerofree (this is now available in the Ubuntu repositories) on the source disk to clear down the unused space, otherwise you will blow up the new VDI with garbage. You are better copying the partitions individually and then using install-grub to fix the grub bootstrap.

You should also reserve 50% dead space between partitions if you are using VDIs then you can just use Gparted to expand the disk next time.

hello TerryE, hello Sasquatch

thanks a lot for your feedback!

i didn't have in mind to publish redundant stuff or 'bad ideas'. i really checked this forum about 'resizing information' and didn't find information about it (seems my search technics wasn't precise enough). therefore i supposed such a howto could be helpful for others. possibly the howto gets useful, because of your answers (it gives an additional link to 'Tutorial: All about VDI's' and the hint about 'bad ideas').

but now i have a question to the topic 'bad ideas':
a) what garbage do i copy in using dd without zeroconf (tmp-files, caches, ...)?
b) does it make sense - in my case - to use zeroconf afterwards to the new vdi disk?
c) you propose to reserve dead space between the new partitions. what advantage does this include (except the possibility of expandig the partitions easier in future)?

kind regards

robxs, if you read the tutorial and the discussion thread linked to it and you will find much of the background material. Sorry, if I sounded a bit negative. Your howto shows that you've got a sound grasp of the broad issues and want to share this with other users. We therefore welcome you to the forum.

A typical filesystem such as ext3 or NTFS divides the partition into allocation units or clusters, typically of 4Kbytes. Files are mapped onto a set of clusters, and when a file is deleted the clusters that were allocated to the file are returned to a free pool. Hence during use clusters are rotated between file use and free pool. Except for specialist secure file systems, when blocks are returned to the free pool they are not cleared down to zero. Hence during this churn all blocks slowly get used and filled with non-blank data.

The way that VBox dynamic VDIs work is that the virtual disk is divided into 1Mbye pages -- that is each page contains 256 clusters. A map is maintained at the front of the VDI and the 1Mbyte pages are only allocated "Just-in-Time" when non-zero content is written to the 1Mbyte page. What zerofree does is to scan free pool clusters in the file system (which can't be mounted r/w) and overwrites any which have non-zero content with zeros. Hence only the sectors which are used in files (or the filesystem management blocks) have non-zero content.

When you dd a filesystem then when dd reads from an unallocated 1Mbyte page, zeros are returned; write which are all zeros to an unallocated 1mbyte page are optimised away. Hence when you dd a partition, the VDI ends up only containing the non-zero 1Mbyte pages. If you want to keep the size of your new FS to a minimum (which is a good idea if you are going to distribute it or snapshot from it) then zeroing the free pool cluster before you doing the copy will avoid copying any 1Mbyte blocks that only contain free pool. Doing after won't.

Because of this churn effect, the VDI will slowly grow to the size of the allocated partitions. So if you are using 8 GByte then you should always have a minimum 20% free in a filesystem and you want some growth so you may want to allocate 12Gyte -- and hence the VDI won't grow above that. However if you put this 12Gb partition on a 12Gb disk then you will need to copy the VDI to grow it. However, if you put it on a 24Gbyte dynamic VDI, then it still won't grow above 12Gbyte, but if you do need to allocate another 4 Gbyte, say, then booting of a GParted ISO and expanding the partition to 12Gb doing only takes a couple of minutes -- and this is such a relatively painless and safe operation that you can keep a tighter control on your VDI space and only expand them as necessary.

hello TerryE

Thank you, for your detailed explanations.

Kind regards.

robxs wrote:clone the old vdi disk to the new (terminal live cd desktop)
...
i) write down the output of fdisk -l (look for something like /dev/sda and /dev/sdb or /dev/hda and /dev/hdb)
j) clone the old vdi disk to the new; type into the terminal: dd if=/dev/old of=/dev/new (replace old/new according to your needs)
k) wait (cloning the old vdi disk can take some hours)

dont wait that long: dd will be faster if you dont copy bytewise but specify a blocksize of e.g. 1024k (replace sda/sdb according to your needs)

Thank you ~!!! Everything worked well after follow your instruction except I need to apply everytime after changing delete/create/resize partition in each step.
unless applying everytime, gparted always made errors.
Only that made me spend much time~!!!!

Thanks for the tutorial but I ran into a problem at step i).
fdisk -l only showed /dev/sda, the new, larger vdi (also saying
that it "doesntcontain a valid partition table")

The old, smaller vdi (dev/?) doesn't show up?

Host is mac os x (leopard) - guest is Vista.

Would appreciate your advice.

Thanks.

Bruce

Hello robxs,

Thanks a lot for your great how-to. I follow your procedures and successfully enlarged my vdi disk.

Your how-to is easy-to-follow, yet detail enough for me.

Thanks for sharing.

Regards,

The simplest instructions to follow yet

I have desperately tried to increase the size of my VDI for a week. All the instructions I got from elsewhere assumed that i'm a NERD and gave high level instructions such as attach your new vdi, without explaining how this is done. After many days on the internet trying to find a solution to a problem that must be well documented now, I'd say, whatever the flows (if any) this how to has given me the answer I have been looking for. Thanks for sharing.

thanks for sharing, very useful.
but it seem a little bit complicated.
actually we might rezise it directly instead of creating a new virtual disk, cause disks are pretty much the same in both physical and virtual machine.
and here's a free partition tool that i've been using, easy to use and reliable.
and, do backup the data before resizing any of the partitions.

Bailifei,
I agree using a partitioning tool is benefical, but you're assuming you have physical space to re-allocate. So far from what I can tell, you cannot increase the logical size of a VDI, just like you can't make a physical 10GB drive become a 100GB drive. This is unfortunate as you can do this with VMWare's VDMK disk image files. If you caught yourself with a VDI that is too small for your needs, your only choice is to create a new VDI, copy the data from the small VDI to the large using a disk clone utility, and THEN use a partition editor such as yours or GPartEd to extend the partition within the drive, shuffling partition location and sizes as needed.

VMWare made this all much easier: increase the size of the VMDK, then use the approriate partitioning tool to increase the partition(s). I used to do this all the time for client VM machines where I used to work.

There just has to be a way to increase the logical size of a VDI. I say "logical" since the VDI can be dynamic, which could make its physical size smaller than what its size limit is.

It turns out that since version 4.0, you CAN increase the size of a VDI using the vboxmanage CLI command modifydh <file> -resize <new size in MB>
Be sure vbox and cmd shell is running as administrator.

DanMan32 wrote:It turns out that since version 4.0, you CAN increase the size of a VDI using the vboxmanage CLI command modifydh <file> -resize <new size in MB>

And before that, i.e. since September 2009, you can resize disks using the CloneVDI tool. The only reason people keep spreading that copy-between-disks rubbish is that they don't bother to read the user manual, read the FAQs or do any other basic research.