VirtualBox on the command line: Importing, Exporting, and Duplicating VMs
Posted in Today I Learned... on February 17th, 2010 by addie – Be the first to commentVirtualization is really useful for webservers, which are pretty low-resource but are good to have in numbers for the sake of redundancy. So you can make much better use of a resource-rich system by virtualizing it and putting several webservers on it - if that’s your particular task of the moment.
That’s one perk for the marriage of virtualization and webservers. The one I like the best, though, is easy duplication. See, setting up a webserver on FreeBSD takes a LOT of time. I know there are some great advantages to being able to directly compile all your software via ports (more sophisticated configurations, etc.), but we simply aren’t using any of those advantages with regards to our dependencies. It also strikes me as pretty crazy that basic programs like bash, vim, and screen don’t come pre-installed. You can literally take a nap while waiting for vim to install.
As a result, getting a single webserver set up can take up to a full workday - between time-consuming port installations and myriad CPAN dependencies (our web app has a Perl foundation). And it hurts the programmer’s aesthetic of “don’t repeat yourself” to do this same webserver setup across several machines - although this is exactly what I’ve had to do in the past. Luckily, we can almost entirely skip that hefty setup and install with VirtualBox.
There are two ways to go about this - by exporting and then importing a VM under a new name, or by cloning a virtual hard drive and attaching the clone to a newly created VM. I actually prefer the latter, because the configuration of the VM itself isn’t necessarily a step I want to skip - but the installation of all the software on the hard drive is. I suspect that most people would prefer the import / export option, but I just have more of a mostly-inexplicable attachment to hd cloning (much like how I have always preferred while loops over for loops despite their individual strengths / weaknesses). Anyhow, I’ll show how both are done in this entry.
To start out with: make sure the vm you are either exporting or whose hard drive you are cloning is powered off. That said, you won’t need to detach the hard drive you are cloning from the VM, if you decide to clone.
Here’s how I’d export my vm “addievm”. Note that you have to specify the name of the file you’re going to output to, and .ovf is the common extension.
VBoxManage export addievm --output addievm.ovf
Exporting isn’t instantaneous, but you’ll see a little text prompt iterating from 0% to 100% to give you an idea of your progress. If you’ve done any configuration on your machine since setting it up (like installing the operating system and some software), this can take a few minutes, and longer for systems with very large hard drives.
The export (for a single machine - you can actually export multiple machines at once, but I’m not particularly interested in it) will give you three files - in this case, they’ll be addievm.ovf, addievm.mf, and addievm.vmdk. The .ovf has the VM configuration, and the .vmdk is the virtual hard drive (a format that is compatible with virtualization platforms like VMWare, more info here). The .mf file contains the UUIDs of the virtual machine and the virtual hard drive. You’ll want to keep all three in the same place (i.e. at the same directory level) so VirtualBox can locate the additional two files (.mf and .vmdk) during an import of the .ovf. Note also that the .vmdk takes the name of the virtual hard drive itself, not the name you have given to the .ovf file - so if I had a hard drive named addiehd.vdi instead of addievm.hdi and ran the same command as above, my resulting files would be addievm.ovf, addievm.mf, and addiehd.vmdk.
To import - in this use case, to import as a copy on the same machine as the original - you can run the VBoxManage import command in the same location that you exported to. You’ll want to start with this command:
VBoxManage import -n addievm.ovf
This command doesn’t actually perform the import. Instead, because of the use of the -n option (–dry-run also works), you’ll get a description of what the import will look like with its defaults set, and the options you can use to change those defaults. Here’s what mine looks like for addievm:
Disks: vmdisk1 52428800000 -1 http://www.vmware.com/specifications/vmdk.html#sparse addievm.vmdk 1261356544 -1
Virtual system 0:
0: Suggested OS type: "FreeBSD_64"
(change with "--vsys 0 --ostype "; use "list ostypes" to list all possible values)
1: Suggested VM name "addievm_1"
(change with "--vsys 0 --vmname ")
2: Number of CPUs: 1
(change with "--vsys 0 --cpus ")
3: Guest memory: 1024 MB
(change with "--vsys 0 --memory ")
4: Network adapter: orig Bridged, config 3, extra type=Bridged
5: CD-ROM
(disable with "--vsys 0 --unit 5 --ignore")
6: IDE controller, type PIIX4
(disable with "--vsys 0 --unit 6 --ignore")
7: Hard disk image: source image=addievm.vmdk, target path=/home/addie/.VirtualBox/HardDisks/addievm.vmdk, controller=6;channel=0
(change controller with "--vsys 0 --unit 7 --controller ";
disable with "--vsys 0 --unit 7 --ignore")
The only one I really want to change in my typical use case is the name of the vm. So my command to actually import the copy will look like:
VBoxManage import addievm.ovf --vsys 0 --vmname addievm_copy
You’ll get similar output as you did with the “dummy run”, but this time it will be followed up with the text “progress bar” as with the export, incrementing from 0% to 100%. Expect a similar wait on import as you did on export.
You can also import as many times as you’d like. You’ll see from the “Hard disk image” information that the hard disk created on the import is renamed like addievm_1.vmdk, addievm_2.vmdk, etc. You aren’t able to change how this is named from the import. I really don’t like having so little control over the naming of hard disks with regards to keeping a collection of virtual machines and virtual hardware organized, but I have found a renaming workaround hack that I’ll be documenting in another post soon.
As for taking the second approach, start by creating a new VM and configuring it as you see fit. The settings don’t have to be the same for a VM with a cloned hard drive, with the exception of HD-related settings (like the operating system). Then, go ahead and clone the disk:
VBoxManage clonehd addievm.vdi addie-clone.vdi --format VDI --remember
The options for this command are very similar to those for creating a hard disk from scratch. The “–remember” option will automatically register the cloned hd with your system of virtual machines and hardware, so if you use the command
VBoxManage list hdds
the cloned hard drive will show up.
Then it’s just a matter of attaching the cloned hard drive to the new VM you’ve created. You’ll need to start up the cloned machine and change things like hostname, networking configuration, etc. so there aren’t any conflicts when both machines are running at once on the same network, but such changes are independent to the actual systems that are being cloned and are out of scope for this documentation.
As I mentioned before, one of the issues you might discover here is that, especially with import and export, you don’t have the full control over naming of your virtual hardware that you’d like. Although there is support in VBoxManage for renaming a machine, there isn’t support for renaming a piece of hardware. I’ve found ways to get around this that I’ll document in my next post; it’s a bit hacky but leaves me with a system that I feel like I actually have full control over.