Using a cloud image with kvm

It would be convenient to have a virt-builder oneliner such as

$ virt-builder --arch i386 --ssh-inject ~/.ssh/id_rsa.pub fedora-21

to get an image suitable to run and login with

$ qemu-kvm -m 1024 -net user,hostfwd=tcp::2222-:22 \
  -drive file=fedora-21.qcow2 &
$ ssh -p 2222 localhost grep PRETTY /etc/os-release
PRETTY_NAME="Fedora 21 (Twenty One)"

Docker users have a simpler form because there is no need to ssh to enter the container:

$ docker run fedora:21 grep PRETTY /etc/os-release
PRETTY_NAME="Fedora 21 (Twenty One)"

It is not currently possible to use virt-builder as described above because

  • the set of images available by default is limited (no i386 architecture for instance)
  • the –inject-ssh option is only available in the development version

The libguestfs.org toolbox can however be used to implement a script modifying images prepared for the cloud (see ubuntu cloud images for instance):

  • wget the image
    wget -O my.img http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-i386-disk1.img
    
  • create a config-drive for cloud-init to feed it the ssh public key.
    mkdir -p config-drive
    cat > config-drive/user-data <<EOF
    #cloud-config
    ssh_authorized_keys:
     - $(cat ~/.ssh/id_rsa.pub)
    chpasswd: { expire: False }
    EOF
    cat > config-drive/meta-data <<EOF
    instance-id: iid-123459
    local-hostname: testhost
    EOF
    ( cd config-drive ; LIBGUESTFS_BACKEND=direct virt-make-fs \
      --type=msdos --label=cidata .  ../config-drive.img )
    
  • launch the image with the config drive attached and it will be auto detected
    qemu-kvm -m 1024 -net user,hostfwd=tcp::2222-:22 \
      -drive file=my.img -drive config-drive.img
    


It is also possible to generate a virt-builder image using debian.preseed and setup an alternate source of images for virt-builder to download. Such a repository could eventually be maintained by a community. There currently is no up to date library of images with virgin/gold/pristine operating systems for various architectures.

2 Replies to “Using a cloud image with kvm”

  1. Loïc, sorry for the rambling, but it’s a subject I have given a bit of thought on.

    Actually, I would say your post is about two separate, but related, subjects: virtual machine image distribution and virtual machine setup (or customisation) during the first boot.

    Both of those have been addressed by the vagrant community. Vagrant allows the end-user to customise the images by editing the Vagrantfile file, and comes by default with a well-known, and therefore totally insecure, public/private ssh keypair. And you still have the opportunity to run custom shell scripts when the machine is provisioned. As for the distribution, I know of at least vagrantbox.es and the one from hashicorp (formely vagrantcloud). If you think about it, virtual machines images tend to be quite large, especially if you install them using the distribution’s default package selection. I think it’s one of the reason there aren’t many community effort to maintain such images, as the cost of making them available for download would be prohibitive. Still, I know of at least two other projects
    trying to make such images available, bento (from chef) and boxcutter.

    Another way to look at it would be to provide installer profiles so that anyone could customise their install and host their own images. This was the way chosen by veewee, with their community templates.

    For the second part, I think cloud-init is a neat trick but is, imho, a messy and overkill solution. I don’t know of any alternative, but I would love a very simple tool which only responsability is to download a script from “somewhere” and run it during boot. That “somewhere” could default to AWS’s magical medatada URL, but could be overridden on the kernel command line (for KVM virtual machines, for exemple). Bonus points if this new tool is a statically compiled binary, as opposed to the Python mess that cloud-init is (I didn’t say someone should write this in Golang, but… you know :p).

    Circling back to your point about docker, you are not the only one wishing for the docker image workflow applied to virtual machines. Some people even have acted on it very recently.

    1. Thanks a lot for the pointers, I did not know half of them 🙂 I hope something will come up so that we can run any os/version/architecture image from a oneliner and forget it ever was a topic worth discussing.

Comments are closed.