Creating VirtualBox VMs command-line style

When most people run VirtualBox (vbox for short), they install the package, double click on the virtual box icon, and off they go. That is fine when you are running it off your desktop or in a server that has a gui (a Windows server does come to mind, being immediately followed by its OSX brethen). But, what if you are remotely connecting to a server through ssh or just do not want to run the gui? Or, what if you want to have vbox start/stop the vms automagically (say, during a reboot)?

Well, you can do that: like VMWare, KVM, and Xen, vbox allows you to do a lot of interesting things through the command line. Since I wrote Virtual Box in the title, I better focus on vbox. In this episode, how about if we create a little test vm from scratch?

We will use an 64bit ubuntu server as example, assuming we already downloaded the iso for it (I also like to convert install CDs/DVDs to ISOs so I can do it all remotely). We will create the VM as user root instead of your normal user.

1. First step is to create a directory to put the VMs. Because I came from solaris, I
   tend to put stuff in /export; ubuntu likes to put it in /srv. It is your server, you do whatever you want. Anywhoo,

   sudo mkdir -p /export/vms

   NOTE: I also like to have /export in a different partition. Well, I do like to partition the hard drive both for security and to avoid the important partitions running out of space. LVM is great here too.

2. Define the vm

   sudo VBoxManage createvm --name "testbox" --basefolder /export/vms --register

   Output should look like this:

   Virtual machine 'testbox' is created and registered.
   UUID: 260ac334-d914-47af-842d-378275130c0f
   Settings file: '/export/vms/testbox/testbox.vbox'

   Note the vm has its own UUID; this can be used to refer to it down the line, but I rarely need it. Just be ware it is there. Now, if you go to /export/vms, you will see a new directory called testbox
   was created.

3. Let's configure testbox:

   sudo VBoxManage modifyvm "testbox" --ostype "Ubuntu_64" --memory "256"
   --hwvirtex on --nestedpaging on --cpus 1

   I am only giving it 256MB because I do not plan on running apache or
   other memory-intensive application in it. Also, note I am only giving it 1 CPU but am telling it to use the hardware virtualization provided by my CPU; do check whether yours is enabled or not.

4. We need to define its network card. I will set it to be an intel gigabit (since it is nicely supported by all the Linux distros I have met) and set it to bridged mode, so it will be visible in the same network as the vm host:

   sudo VBoxManage modifyvm "testbox" --nic1 bridged --nictype1 82543GC
   --bridgeadapter1 eth0

5. Now we need a hard drive. I think a 10GB hard drive will do; this
   is just a test. I will use the .vdi format so it will expand itself up
   to 10GB as needed. Note we can always add more drives later. Or move
   stuff around. Or even resize.

   sudo VBoxManage createhd --filename "/export/vms/testbox/drive1.vdi"
   --size 10000 --format VDI

   We will attach it to the SATA chain.

   sudo VBoxManage modifyvm "testbox" --sata on
   sudo VBoxManage modifyvm "testbox" --sataportcount 4
   sudo VBoxManage storageattach "testbox"  \
       --storagectl SATA --port 1 --device 0 \
       --medium "/export/vms/testbox/drive1.vdi" --type hdd

6. Remember the installation disk we downloaded as .iso? It is time to feed it to the vm. Just to be different, let's put it in the IDE chain. I am guessing the ISO is in, say, /export/ISOs.

   sudo VBoxManage storagectl "testbox" --name IDE --add ide  --controller PIIX4
   sudo VBoxManage storageattach "testbox" \
       --storagectl IDE --port 1 --device 0 \
       --medium "/export/ISO/ubuntu-12.04-desktop-amd64.iso" \
       --type dvddrive

7. And now to define the vrdp/vrde port (say, 5050) so we can do a
   remote install. This will not work right of the boxl you must first download and install the VirtualBox Extension Pack, which is conveniently found at https://www.virtualbox.org/wiki/Downloads. Once that is installed, you can then do
   

   sudo VBoxManage modifyvm "testbox" --vrdeport 5050 --vrde on \
     --vrdeauthtype external

And that should be it. Now we need to start the VM. Something like

sudo VBoxHeadless --startvm "testbox" &

should do the trick. Now, we can and should have a script to start and stop the vm and any vms we have running in the machine (say, when vm host/server is shut down/restarted), but we can talk about that later.

You probably noticed you would be happier by writing a script do to all the steps we did above; we shall talk about that in another episode.

Deleting VirtualBox drives that do not want to be deleted

Today's episode began with me wanting to delete a VirtualBox virtual machine (vm for short) that was acting up in a rather bad way. I was at the point that all I wanted to do was wipe it and restart from scratch. Problem is I screwed up, out of frustration, in the deleting the old vm. I thought I had done it right and then wiped the old directory and proceded to recreate the vm... just to find out that virtualbox thought the new disk image was associated with some snapshots that were in fact associated with the old image. So, I decided to tell virtualbox to just delete the image:

root@fileserver:~# VBoxManage closemedium disk /export/hosts/sambabox/sambabox.vdi --delete
VBoxManage: error: Storage for the medium '/export/hosts/sambabox/sambabox.vdi' is already created
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component Medium, interface IMedium, callee nsISupports
Context: "DeleteStorage(progress.asOutParam())" at line 1166 of file VBoxManageDisk.cpp
VBoxManage: error: Failed to delete medium. Error code Unknown Status 0x80BB000C
VBoxManage: error: Cannot close medium '/export/hosts/sambabox/sambabox.vdi' because it has 2 child media
VBoxManage: error: Details: code VBOX_E_OBJECT_IN_USE (0x80bb000c), component Medium, interface IMedium, callee nsISupports
Context: "Close()" at line 1182 of file VBoxManageDisk.cpp
root@fileserver:~#

As you can see, it did not work quite as I expected. What to do now since all the old files, snapshots included, are gone? Well, it seems that virtualbox still somehow knows about all the drives even though they are not mentioned in VirtualBox.xml:

root@fileserver:~# VBoxManage list hdds
UUID:        1c2b04ba-7090-4ad9-8db0-9884f254ca23
Parent UUID: base
Format:      VMDK
Location:    /export/hosts/windowsXP32/windowsXP32-disk1.vmdk
State:       locked write
Type:        normal
Usage:       windowsXP32 (UUID: d5c4efde-5587-43b6-bf81-8f606a746c58)

UUID:        a9275089-0812-43d3-b3b8-da7dea5c0dc7
Parent UUID: base
Format:      VDI
Location:    /export/hosts/sambabox/sambabox.vdi
State:       inaccessible
Type:        normal

UUID:        98a1f274-93af-4747-988d-b8e91cac00b8
Parent UUID: a9275089-0812-43d3-b3b8-da7dea5c0dc7
Format:      VDI
Location:    /export/hosts/sambabox/Snapshots/{98a1f274-93af-4747-988d-b8e91cac00b8}.vdi
State:       inaccessible
Type:        normal

UUID:        d33e0420-4f1f-461c-abc8-bb38c55697b8
Parent UUID: a9275089-0812-43d3-b3b8-da7dea5c0dc7
Format:      VDI
Location:    /export/hosts/sambabox/Snapshots/{d33e0420-4f1f-461c-abc8-bb38c55697b8}.vdi
State:       inaccessible
Type:        normal

root@fileserver:~# 

Look at the inaccessible ones. Note their path: as far as virtualbox is concerned, they are in the sambabox snapshot directory. I would bet a cookie that is my problem. Now, how to delete it? I tried providing the path (/export/hosts/sambabox/Snapshots/{98a1f274-93af-4747-988d-b8e91cac00b8}.vdi) and that did not work.

Well, it did not work because the file itself is no longer with us. But, what if we enter the UUID instead?

root@fileserver:~# VBoxManage closemedium disk 98a1f274-93af-4747-988d-b8e91cac00b8
root@fileserver:~# VBoxManage list hdds
UUID:        1c2b04ba-7090-4ad9-8db0-9884f254ca23
Parent UUID: base
Format:      VMDK
Location:    /export/hosts/windowsXP32/windowsXP32-disk1.vmdk
State:       locked write
Type:        normal
Usage:       windowsXP32 (UUID: d5c4efde-5587-43b6-bf81-8f606a746c58)

UUID:        a9275089-0812-43d3-b3b8-da7dea5c0dc7
Parent UUID: base
Format:      VDI
Location:    /export/hosts/sambabox/sambabox.vdi
State:       inaccessible
Type:        normal

root@fileserver:~# VBoxManage closemedium disk a9275089-0812-43d3-b3b8-da7dea5c0dc7
root@fileserver:~# VBoxManage list hdds
UUID:        1c2b04ba-7090-4ad9-8db0-9884f254ca23
Parent UUID: base
Format:      VMDK
Location:    /export/hosts/windowsXP32/windowsXP32-disk1.vmdk
State:       locked write
Type:        normal
Usage:       windowsXP32 (UUID: d5c4efde-5587-43b6-bf81-8f606a746c58)

root@fileserver:~# 

As you can see from above, using the UUID did work out rather nicely. You have to delete the inaccessible files in the reverse order they were created but after a few steps all the offending images were gone. And now we can install a new version of this vm without fear that unloved images will come back to haunt us.