lxc with fast cloning via overlayfs and userdata via clone hooks

Serge Hallyn and Stéphane Graber made some really nice improvements to LXC in the last few months.  These include:

• user namespaces, which will bring us secure containers in 14.04 and the ability to safely run containers without root. 
• a library with bindings for C, go and python3.
• cloning with overlayfs
• hooks executed at clone time.

I had previously worked with Ben Howard on the 'ubuntu cloud' template, and I just finished some updates to it that take advantage of overlayfs and clone hooks to provide a great environment to use or test cloud-init.

Previously the ubuntu cloud template (which downloads a cloud image to create a container) allowed the user to specify userdata or public keys at container creation time.  The change was really just to move the container customization code to a clone hook.

Thanks to the daily build ppa, you can do this on any release from 12.04 to 13.10.

Hopefully the example below explains this better.  The times reported are from my Thinkpad X120e, which is a netbook class cpu and slow disk.  Times clearly will vary, and these are not meant to be scientific results. If you do not see the embedded file below, please read the remainder of this post in the gist on github.

Using Ubuntu cloud images on VirtualBox

A few months ago, I wrote an article on "Using Ubuntu cloud-images without a cloud".  That article showed how to do this with kvm.  Virtualbox is another virtualiztion technology that is especially popular on Mac and Windows.  So, I figured I'd give the same basic article a try, but using virtualbox rather than kvm.

I used 'virtualboxmanage' and 'virtualbox' here, but I'm sure the same can be accomplished via the virtuabox gui, and probably similar commands to do the same thing on Mac/OSX or windows.

So, below is roughly the same thing as the kvm post but with virtualbox.  Also to verify function, I did this on Ubuntu 12.04 host with Ubuntu 12.04 guest, but later versions should also work.

Using Ubuntu cloud-images without a cloud

Since sometime in early 2009, we've put effort into building the Ubuntu cloud images and making them useful as "cloud images". From the beginning, they supported use as an instance on a cloud platform. Initially that was limited to EC2 and Eucalyptus, but over time, we've extended the "Data Sources" that the images support.

A "Data Source" to cloud-init provides 2 essential bits of information that turn a generic cloud-image into a cloud instance that is actually usable to its creator. Those are:

• public ssh key
• user-data

Without these, the cloud image cannot even be logged into.

Very early on it felt like we should have a way to use these images outside of a cloud. They were essentially ready-to-use installations of Ubuntu Server that allow you to bypass installation. In 11.04 we added the OVF as a data source and a tool in cloud-init's source tree for creating a OVF ISO Transport that cloud-init would read data from. It wasn't until 12.04 that we improved the "NoCloud" data source to make this even easier.

Available in cloud-utils, and packaged in Ubuntu 12.10 is a utility named 'cloud-localds'. This makes it trivial to create a "local datasource" that the cloud-images will then use to get the ssh key and/or user-data described above.

After boot, you should see a login prompt that you can log into with 'ubuntu' and 'passw0rd' as specified by the user-data provided.

Some notes about the above:

•  None of the commands other than 'apt-get install' require root.
•  The 2 qemu-img commands are not strictly necessary. 
• The 'convert' converts the compressed qcow2 disk image as downloaded to an uncompressed version.  If you don't do this the image will still boot, but reads will go decompression.
• The 'create' creates a new qcow2 delta image backed by 'disk1.img.orig'. It is not necessary, but useful to keep the '.orig' file pristine. All writes in the kvm instance will go to the disk.img file.
• libvirt, different kvm networking or disk could have been used. The kvm command above is just the simplest for demonstration. (I'm a big fan of the '-curses' option to kvm.)
• In the kvm command above, you'll need to hit 'ctrl-alt-3' to see kernel boot messages and boot progress. That is because the cloud images by default send console output to the first serial device, that a cloud provider is likely to log.
• There is no default password in the Ubuntu images. The password was set by the user-data provided.

The content of 'my-user-data' can actually be anything that cloud-init supports as user-data.  So any custom user-data you have can be used (or developed) in this way.