Cloning VirtualBox VMs… Sledgehammer – Meet Nut

So I want to play around with a few bits and bobs, specifically Puppet, and MySQL/Tomcat clustering.  I never really have the time, but the aim is there, but it also means I don`t have time to faff around with lots of fiddly, shite configuration.  It`s possible to do all of this on one server, but in the real world, these services will be distributed over a number of servers, either physical or virtual.  So I decided to get a few VM instances up and running in VirtualBox.

The source VM was built with 2CPUs and 1024MB of RAM to speed up installation and was carried out using the latest build of Umbongo 10.10, The Naughty Numpty, and as Windows (eesh) is used as the host, the virtual disks (vdi files) are stored at c:virtual.

 

The idea was fairly simple, install a build of Umbongo, get the latest updates, install openssh server, and then create a couple of clones for messing around with.

 

In the ideal world, you`d run a script, or press a button in VirtualBox to create a cloned VM with the same virtual hardware, disk, etc.  In the real world, faffing about is required.  The steps were broadly as follows – in case I need to do it again:

 

1. Create new (source) VM with 1024MB of RAM and 8GB virtual hard disk, install Umbongo.  I installed a full desktop build in case I fancied running a GUI or VNC on there.

 

The Laughing Gnome

2. Switch off the graphical desktop.  By god this was a pain in the arse.  By day I work with RedHat Enterprise Linux, using /etc/inittab, chkconfig, runlevels as expected, etc. Umbongo ditched most of this a few releases back so there is no inittab, the default runlevel, 2 also starts X, Gnome, etc.  This is a complete head melter as it`s not how things are done anywhere else.  It`s a nobel aim to fix a lot of problems with sysv init gubbins, but this is a big tangent.  After a bit of searchy searchy, I took a sledgehammer to the system and stopped the GUI from loading using GRUB.  This is a terrible approach but sysv-rc-conf, update-rc.d, and checking /etc/rc?.d/ gave no joy.

 

Notice I`m not afraid to work as root.. fear my lack of fear.  We need to edit the GRUB configuration to tell the system to boot in text mode, then update the GRUB bootloader.

 

richard@virtual:~ sudo bash
root@virtual:~# vi /etc/default/grub

 

GRUB_CMDLINE_LINUX_DEFAULT=”text“

 

root@virtual:~# update-grub2

 

3. The next step was to update the system as it`s pointless having clones all requiring updates as soon as they`re booted.

root@virtual:~# apt-get update && apt-get -f upgrade
Hit http://extras.ubuntu.com maverick Release.gpg
Ign http://extras.ubuntu.com/ubuntu/ maverick/main Translation-en
[…]
Hit http://gb.archive.ubuntu.com maverick-updates/universe i386 Packages
Hit http://gb.archive.ubuntu.com maverick-updates/multiverse i386 Packages
Fetched 220kB in 1s (177kB/s)
Reading package lists… Done
Reading package lists… Done
Building dependency tree
Reading state information… Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

4. Then to install the SSH daemon so I can log in through PuTTy, use scp, etc.  I also checked PermitRootLogin was enabled.

root@virtual:~# apt-get install openssh-server

 

5. Finally, mount the VirtualBox Guest Additions and install those various bits and bobs to hopefully pump up performance a little.  The virtual CDROM presented as /dev/sr0 here, so your mileage may vary.

 

root@virtual:~# mkdir /mnt/vbox
root@virtual:~# vi /etc/fstab

 

/dev/sr0 /mnt/vbox      udf,iso9660     user,ro,exec 0 0

 

root@virtual:~# mount /mnt/vbox
root@virtual:~# /mnt/vbox/VBoxLinuxAdditions-x86.run

Verifying archive integrity… All good.
Uncompressing VirtualBox 3.2.8 Guest Additions for Linux……..
VirtualBox Guest Additions installer
Building the VirtualBox Guest Additions kernel modules
Building the main Guest Additions module …done.
Building the shared folder support module …done.
Building the OpenGL support module …done.
Doing non-kernel setup of the Guest Additions …done.
Starting the VirtualBox Guest Additions …done.
Installing the Window System drivers
Warning: unknown version of the X Window System installed.  Not installing
X Window System drivers.
Installing graphics libraries and desktop services components …done.
root@virtual:~#

Oddness – VirtualBox or Umbongo?

After a reboot, the VM wouldn`t come up cleanly, freezing at the “checking battery state” step.  I love when that happens.  Spend time slowly installing the OS, and updating only to find it`s buggered.  A newer build of VirtualBox didn`t sort this out.  However, adding a second CPU to the VM and switching on IOAPIC did the trick.  What the hell?  Lame.

 

6. Next to clone the VM.  This clone will be named – clone2.  It`s hard to be original when you just want to get stuff done.

Make sure the VM has been fully shut down and quit out of the VirtualBox GUI thingie.  Off into a smelly DOS prompt we go…

 

Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:Windowssystem32>cd virtual

C:virtual>dir
Volume in drive C has no label.
Volume Serial Number is ECB9-BDA2

Directory of C:virtual

13/10/2010  22:17    <DIR>          .
13/10/2010  22:17    <DIR>          ..
14/10/2010  12:12     3,239,084,544 clone1.vdi
[…]

 

We then copy the current disk to a new disk…

 

C:virtual>copy clone1.vdi clone2.vdi
1 file(s) copied.

VirtualBox (reasonably) expects all disks to have a unique ID, so we need to use the sneaky setvdiuuid function:

C:virtual>”C:Program FilesOracleVirtualBoxVBoxManage.exe” internalcommands setvdiuuid clone2.vdi
Oracle VM VirtualBox Command Line Management Interface Version 3.2.10
(C) 2005-2010 Oracle Corporation
All rights reserved.

UUID changed to: a1df35a6-1d30-4673-8826-72779a541f57

 

7. Now we can create another virtual machine within VirtualBox, using clone2.vdi as “existing hard disk”.  Unfortunately you can`t just pick up the same hardware configuration, which is a pain in the bum so the virtual hardware needs to be configured all over again.

If you`re feeling adventurous,  you can copy the existing VM definition (XML format) for clone1, and carry out some hackery, setting up clone2.xml from clone1.xml.  Each VM has its own directory on disk, and its own XML configuration file.

 

C:Usersrichard.VirtualBoxMachinesclone1clone1.xml
C:Usersrichard.VirtualBoxMachinesclone2clone2.xml

 

If you look at the XML, you`ll see unique IDs for the network interface MACs and all storage devices, so it`s not a 30 second job to hack as these must make some kind of sense and VirtualBox will barf if it sees IDs it doesn`t recognise, so the GUI is actually quicker.

 

vbox-cloned - 2 VMs

It`s not an ideal setup, but by default Umbongo brings network interfaces up with DHCP, so there`s no risk of IP address conflicts.  Just remember to change the hostname of each VM.

 

root@virtual:~# vi /etc/hostname

 

It`s a little quicker than configuring a PXE system, but that`s for another day where I`ll try to set up PXE, have it create a bunch of VMs, and get Puppet up and running to configure a bunch of services on each VM.

One Response to Cloning VirtualBox VMs… Sledgehammer – Meet Nut

  1. Of course, later builds of VirtualBox as I`ve now discovered, have cloning built in. Ho hum. Then again, you may still have an ancient copy.

Leave a Reply