Increase the Vagrant base box root partition
You’re happy with your Vagrant machine, except that sometimes you could use some extra space on your root partition. Especially if you rely on the official Ubuntu image, this may be for you. Note however, this approach provides you with a new base box image and is not meant to increase just your currently running Vagrant machine on the fly.
There are 1000+1 ways to perform these actions to reach the goal but everyone’s need is different. In my case I was using the images from https://vagrantcloud.com/ubuntu/boxes/trusty64 and their root partition size is 40GB. Enough for most; but too small for some, especially for me.
In the past I rolled my own boxes from scratch, but there were always some small differences in kernel settings I didn’t gave a second thought, resulting in degraded performance under certain conditions (e.g. low disk IO with multiple CPUs inside the VM, etc.). So taking the existing image and just expanding upon it, seemed the right way at this point.
Note: I performed this under OSX El Capitan, using Vagrant 1.7.4 and VirtualBox 4.3.30; neither of them which are the most current versions as of now, YMMV!
VirtualBox to the rescue!
For many, VirtualBox is just a virtual machine they use on their workstation, but it comes with a quite good tooling infrastructure, allowing to perform almost all operations in automation or from command line.
Download the vagrant box
You can skip this step if you’re already running the box image you want to expand, but be aware that you have to locate it yourself in your ~/.vagrant.d/ folder, likely ~/.vagrant.d/boxes/ubuntu-VAGRANTSLASH-trusty64/0/virtualbox/box.ovf .
(Thanks to this Stackoverflow Answer)
The file “virtualbox.box” is actually a TAR archive, but to proceed further we first need to extract the *.ovf file inside it:
tar xf virtualbox.box
These now leaves us with the following files:
Import the image into VirtualBox
VBoxManage import box.ovf
At the end you should be greeted with “Successfully imported the appliance.” During the import, since we didn’t specify it, VirtualBox create a name for the VM, in my case this was:
1: Suggested VM name “ubuntu-cloudimg-trusty-vagrant-amd64”
Convert the disk image to the VDI format
This is necessary because VirtualBox is only able to dynamically expand its own virtual file format. Change to the directory where the VM has been imported, in my case:
cd ~/VirtualBox\ VMs/ubuntu-cloudimg-trusty-vagrant-amd64/
Convert (clone) the image into a supported format:
VBoxManage clonehd --format VDI box-disk1.vmdk box-disk1.vdi
Resize that image!
In my case I expanded it to 150GB:
VBoxManage modifyhd box-disk1.vdi --resize 150000
Replace the new image with the old one
Now this part is tricky (for me at least) because I couldn’t sanely figure out how to perform the necessary operations on the command line, thus I had to manually replace the disk within the GUI.
- Open the settings dialog for the imported machine
- Go to “Storage”
- Remove the (old, small) disk
- Add the (new, large) disk we just converted (the *.vdi file)
Export that image!
Make sure the name of the base image matches would you were working on:
vagrant package --base ubuntu-cloudimg-trusty-vagrant-amd64
After a few minutes you should end up with a “package.box” file inside the VirtualBox VM directory:
Using the new box in Vagrant
This *.box file now works exactly like the original image, but has a lot more space on its root partition. If you just want to use it locally, you can change your “config.vm.box” setting in your “Vagrantfile” to simply point to the absolute file path, e.g.
config.vm.box = “file:///.../VirtualBox VM/…/package.box”
Or you can publish it on the web and reference the HTTP(S) URL; either way will work. After a successful vagrant up, you can enjoy your new space :-)
It’s not the most elegant way and almost looks labor intensive. Luckily one wouldn’t need to do this very often.
Other approaches would create a second disk in your Vagrant installation and mount it. But this also means you have to be careful with your services and reconfigure them to be aware of the separate mount point. Perfectly fine and doable, but I opted for this approach as now every developer on our team has access to the same neutral base image and it can even be used for completely different things without requiring any further step.