Skip to main content

Spawning many VirtualBox machines from a single VDI

What I'm taking about here is a way to have many VirtualBox machines based upon a single hard drive image. There are many reasons why you might like to do this, but the most compelling is probably saving time by not having to install an OS over and over again, especially useful if you do anything like software testing.

Our goal is a single vdi (virtual disk) file which contains a vanilla installation of our favourite OS which we can then use to conjure up a fresh new machine in a jiffy.

Assuming you already have VirtualBox installed our first step is (maybe for the last time ever!) to install our OS into a new virtual machine. Now I shan't go through this as it's pretty straight forward and if you're reading this it's the sort of thing you have probably done a hundred times before.

One thing of note during the initial setup is the 'Virtual Hard Disk' configuration. Be sure to allocate enough space to allow for all potential applications of the image. It would be wise to select 'Dynamically expanding storage' so that your vdi will only be as big as it needs to be.

Once you have your new machine in a state suitable to spawn other machine from (patched, base software installed etc) shut it down and we can move on.

Now unregister the vdi from the virtual machine used to constuct it, you can do this on the command line using VBoxManage, or a number of ways through the gui. I use the gui 'Virtual Media Manager' (found under the 'file' menu in your VirtualBox interface).

Now this is where we run out of functionality in the VirtualBox gui and we'll have to resort to the command line. We need to change the type of our vdi from 'normal' to 'immutable' by running:
VBoxManage modifyhd /full/path/to/my/vdi --type immutable

Back in the gui interface, in the machine storage configuration, reallocate the now immutable vdi file to the original build machine. You should now be able to boot this again just as before. Excellent!

Now create a new machine, but this time when selecting a hard disk choose to use an existing disk and select our immutable vdi. Awesome it works! (hopefully)

That is almost it! Just one more thing to be very aware of. Going back into the Virtual Media Manager your'll notice you can now expand a list against the immutable vdi. Inspecting these will show you that they are 'differencing' disks, associated to our machines using the immutable vdi above. These differencing disks allow our machine to diverge in state.

HOWEVER the default configuration of these differencing disks is to RESET each time the machine is powered on. This may be just what you want, to be able to boot a clean state each time, perfect for testing software. However if you want your new machines to preserve their states there is one more command to run.

From the media manager note the id of the differencing disk you want to preserve state, it's contained in the Location path at the bottom of the window and is enclosed in {}. It'll look a bit like this,

Now run,
VBoxManage modifyhd Your-Disk-Id-In_Here --autoreset off

This will be remember from here on in for this machine and all snapshots taken from it in the future.


  1. Very easy to understand Paul! I like this idea, might just have to implement it ;)

  2. I think the behaviour of the differencing disk might've changed in recent versions, as it seems to not be autoreseting for me

  3. with 3.1.6, no worries about autoresetting:

    From the help file:
    The differencing image is only reset when the machine is powered on from within VirtualBox, not when you reboot by requesting a reboot from within the machine.

    so if you reboot from your guest os, you're ok. Tried it myself and it works.

  4. Yes, state is preserved for REBOOTS, but not if you shutdown. Therefore you'll need to set the autoreset property if you expect that the VM will ever be cold booted again and you don't want to loose state... which it will.

  5. Hi, one hint which could help linux-like sysadmins. You may type in console:

    VBoxManage list hdds

    Newly created drives should be at the bottom. Than you may just use cmd above.

    For example:
    UUID: b8ac13a3-8ce3-4e0d-886f-511cebe1693e
    Parent UUID: base
    Format: VDI
    Location: /kaplajir/centos6_fix/centos_6.vdi
    State: locked read
    Type: immutable

    UUID: 9b11e4d8-f507-4e89-9021-ed9df599bbf2
    Parent UUID: b8ac13a3-8ce3-4e0d-886f-511cebe1693e
    Format: VDI
    Location: /centos6_test11/Snapshots/{9b11e4d8-f507-4e89-9021-ed9df599bbf2}.vdi
    State: locked write
    Type: normal
    Usage: centos6_test1 (UUID: 7558d7ab-6381-465f-bbc7-99f820d789a9)

    VBoxManage modifyhd 9b11e4d8-f507-4e89-9021-ed9df599bbf2 --autoreset off

    And if you have many vbox drives I advice to use grep functionality. This will show info about all immutable devices:

    VBoxManage list hdds | grep -B 5 immutable

    With UUID of immutable drive you may use

    VBoxManage list hdds | grep Your-Disk-Id-In_Here -A 5

    Sorry for long comment and thank you for you nice article :)
    Jiri Kaplan

  6. Hey Paul! Just wanted to say thank you so much for writing this post. I desperately need this feature and you made it so easy to implement. Thanks

  7. Being able to share your digital data safely is a must if you want your company to be in cleint's good books.
    Richard Brown vdr data room

  8. Thanks a lot for this info, it helped me becoming unstuck in a course I'm doing :)


Post a Comment

Popular posts from this blog

Raspberry Pi A2DP Bluetooth Audio Receiver

I wanted to use a Raspberry Pi to act as a Bluetooth audio receiver or my Hi-Fi so that I could connect a phone/tablet easily to some proper speakers wirelessly. Rather than reinventing the wheel 'kmonkey' has already achieved most of what I set out to do over here ; check this out first. The only issue now is the manual intervention needed to connect up a new Bluetooth source to the output sink. I initially created a simple bash script to poll pulseaudio (every 5 seconds) and run the necessary commands as and when a new device is connected. You can see the script here and all the pertinent commands are explained over in kmonkey's blog. This is all good, but will need to be run manually using something like, # nohup ./bt_audio_attach & This is a bit rubbish and you'll be pleased to know there is a better way to get this done, UDEV! Over at the Raspbery Pi forums   there's some discussion on using UDEV scripts to automate this process entirely. Initia

Blocking Adverts from the Roku Menu

UPDATE: 18 May 2013 - A new firmware (v5) has changed the way ads are handled on the Roku such that this guide is no longer relevant.  Roku are are a pretty neat little media streaming box but one thing that I think lets them down are the trashy and mostly irrelevant adverts on the home page. Wouldn't it be great if you could get rid of these? The ads are served by the third party ad platform,  ZEDO . You can block the ads from displaying by simply blocking this domain entirely or by being more targeted and blocking the specific sub-domain serving the Roku ads. A TCPDUMP of my Roku shows that the ad images currently come from '' (although this may change). I block them by adding a custom DNS record for this sub-domain to my home router pointing to the loopback address ( There are or course many other ways you could do this, but the best way will largely depend on your own set-up and resources.