NovaImageBuilding
Libvirt Image Building
This page considers what work is required in order to enable OpenStack to be used as a service for building cloud images for arbitrary operating systems
Background: Oz
There are many tools for building cloud images, but most of them are tailored towards specific operating systems. This is typically due to an approach focused on installing packages in a chroot environment, or similar. The Oz project is somewhat different in that it aims to be a tool that is portable to building images for any common operating system. The key architectural design of Oz is to make use of KVM to run the operating systems native installer, using its built in automation capabilities. For Fedora/RHEL this implies using kickstart scripts, for Debian/Ubuntu this would use the installer answer files, for Windows this involves SIF files, and so it. It has been ported to all commonly used operating systems.
Of course Oz requires a host which has KVM available in order to do its, unless the user is happy to fallback to the slower QEMU. The latter is not really a practical option speedwise. Requirement for KVM means Oz requires a Linux host of some kind. Consumers of OpenStack services may be using Windows or OS-X, or any number of operating systems. It is desirable that they have an easy way to build images to be used with OpenStack. A key observation is that while we can't assume the consumer's machine can run KVM, OpenStack of course has virtualization capabilities. There is nothing especially KVM specific in what Oz does, it was merely the best choice for its original developer.
Oz' approach to building images is as follows
- Obtain a installer automation file for building a JEOS image. The Oz codebase has such automation files available for most common operating systems
- Modify the original installer ISO image to include the automation file
- Determine the optimal hardware to run the guest OS installer in KVM. The Oz codebase has a set of classes which determine hardware for each OS
- Launch a KVM guest with an empty disk and the installer ISO
- Wait for the guest to shutdown (indicating completion of install), monitoring disk/net I/O to determine if it hangs
- Boot the resulting JEOS image, SSH into it and install extra packages required by the final appliance
- Convert the final raw image into qcow2 format
Background: libosinfo
In the years since virtualization has become commonplace, a great many applications have been developed to manage virtual machines. Many of these applications have duplicated each others functionality in a many areas. For example, every application needs to figure out the optimal hardware devices for running a particular OS as a guest on a particular hypervisor. Any application may want to know the recommended / minimum disk/ram resources to allocate for a particular guest. Any application which wants todo automated installs of new guest OS images, has to write out the same installer automation scripts. Any application may want to know how to identify which OS a particular ISO image corresponds to, and whether it is an installer ISO or a LiveCD image or something else. Any application may want to know where to find installer trees or appliance images online.
The libosinfo project is an attempt to remove the extensive duplication of work / knowledge from virtualization management applications. At its core it provides a database containing information about operating systems and hypervisors. The database includes details of supported hardware devices, minimum/recommended hardware devices, metadata required to identify ISO images, templates for creating installer automation scripts, and much more besides. Alongside the database is a library API for querying information in the database.
