We spent a large amount of time automating the build of KVM domains. There are a number of methods of doing so, but in our discussion on this topic it seems there is some confusion. Our goal is not only to clear up the confusion, but to build an interface that allows for easy orchestration of the entire build of the OS, but also to help in the management the storage components, helping to determine the most efficient storage platform based on the correct requirements.
The first place to start is to understand QEMU and QEMU images. As the QEMU website states: “QEMU is a generic and open source machine emulator and virtualizer. When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance.”
So what this means ina KVM context is that you can use QEMU to build OS images which can either be empty images (.img files) that can be used as volumes to install OS’s via libvirt, or thay can be pre-built .img files that are imported into KVM via libvirt.