Downloading an appliance
In theory, appliances are easy: download an appliance, point your favorite virt management tool at the downloaded image, and you have yourself a running, working virtual machine doing great things for you in no time (bandwidth limits may apply).
In practice, that’s not quite the case: after picking the appliance that tickles your fancy, you have to figure out which appliance image you need to download. If you are like me, you have a variety of machines with different virtualization technologies, say some hosts running RHEL5 paravirt Xen, others RHEL5 Xen with hardware-virt support, and others running Fedora 7 and kvm. You may even know that that means that you either need a paravirt Xen kernel with PAE support, or a fullyvirt kernel, and what image formats your tools can digest.
Armed with that knowledge, and a burning desire to use that LAMP appliance you’ve had your eyes on for far too long now, you go to the download page and stop cold in your tracks — there are 12 (twelve) different images you can download for this appliance. Which one is right for your hosts ? Some of them you can rule out quite quickly: you don’t have VMWare installed, and you’re not running Viridian. Your hosts are (still, sigh) all i386, so those x86_64 images won’t do you any good. You’re not interested in the Demo CD, you really mean it. But which of the images that mention Xen in their name will work for you ? Maybe download that installable CD ? And what about those Parallels and Virtual Iron images ? Could those be made to work ? You wish you had paid more attention what Parallels and Virtual Iron are doing. With a sinking feeling, you start downloading something …
In theory, a tool should make those decisions for you, a tool that knows what host(s) you have and what images you can run on them. Even better if you could just download one image and use that for different hosts, with the tool adapting the image to each host. Some of this will be addressed once paravirt_ops is fully in the upstream kernel, and kernels that can run on a number of host platforms are widely available — though you’ll still be dependent on the appliance provider to tell you for which of them they built their kernels.
In practice, libvirt’s capabilities give you enough information to at least decide whether a given image can be run on a host. You can even play a dirty trick and build one image that runs on both paravirt Xen and on fullyvirt hosts: build an image that puts /boot on a separate disk from the rest of the filesystem, and install both the bare-metal and the paravirt Xen kernel into it, and make sure all file systems get mounted by label rather than by device name. After installation finishes, shut down the guest, copy the file backing /boot and modify the grub.conf in the copy to boot the other kernel by default. Depending on which of the two files you use for /boot, you can run your image as aparavirt or as a fullyvirt guest.
Clearly, that’s a hack, and if you keep going back and forth booting the guest paravirt and fullyvirt, and perform updates, you run the danger of yum updating only one of the /boot disks and confusing rpm mightily when you switch to the other one. Unfortunately, more tasteful approaches to multi-boot guests, like leaving /boot on the main disk and only bind-mounting a different grub.conf from a host-dependent disk fail because of the idiosyncrasies of the paravirt Xen boot process.
This experiment though helps to underscore a larger point: using libvirt makes it possible to capture the important aspects of a host in metadata, and letting a tool decide whether a certain image can be run on a given host, or even letting the tool decide which of a number of possible image configurations to use. The proposed image metadata that the image patches for virt-install use explain in detail how that can be done. That metadata lays a solid foundation for libvirt-based appliances.
Ultimately, we’d like users to forget about the arcane differences between virtualization platforms and focus on the fact that they need an appliance to do X. If we get to a point where users only need to know that their hosts use libvirt, and let the tools decide which image to download, and how to boot that image, we’ve made a good step forward.
Watzmann.Blog by David Lutterkort is licensed under
a Creative Commons Attribution-Share Alike 3.0
United States License.
Generated with Jekyll