Creating a virtual machine using a distribution’s Cloud base image – the example of CentOS

A Cloud Image is a virtual machine disk image containing the operating system of a specific distribution. It is ready to run in a virtual runtime environment, customized to one of the cloud-platforms such as Openstack, Amazon EC2, Google GCE etc. Most distributions also provide a generic image or base image with a runtime environment without additions to a specific cloud system. Such a generic image is (usually) suitable for a QEMU/KVM/libvirt runtime environment.

The procedure described here is therefore only suitable for distributions that provide such a generic image.

Depending on the distribution, cloud images may differ more or less from a default installation using the distribution’s installation media. There are also distributions, e.g. Ubuntu, that explicitly distinguish between cloud images and server images. Documentation about goals and differences are mostly sparse or non-existent. Debian at least makes an attempt to document differences.

The system administrator must investigate whether the cloud image does meet the requirements and expectations associated with using a VM of the distribution.

A cloud image is a kind of template, a runtime agnostic bootable generic operating system directory tree. It is used directly as a bootable (virtual) system disk in a virtual machine to be created, although still practically unusable due to lack of concrete runtime-specific configuration.

The challenge is to initially inject the specific runtime configuration into the image. This includes first of all a user account with password and administration authorization. In addition, network configuration, console or other devices may be required. Only then does a cloud image gets the ability to run in a specific environment and, above all, become usable. This is the prerequisite for being able to perform detailed and more extensive configurations later on, if necessary.

In a standard installation this basic configuration is part of the distribution-specific installer. In case of a cloud image there are two widely used disk image modification tools for Cloud images

Both are designed to get the configuration data from the cloud system at the first boot and apply it to the image. The developers fortunately had some foresight and provided a 'nocloud' procedure, too. So, the system administrator of an autonomous server can provide a replacement. As you may guess, in a cloud centric development a nocloud option has a tough time. It remains somewhat of a challenge.

A third option is

a generic tool to modify any non-running virtual machine, provided by guestfs-tools. It allows to install cloud images of older distributions like CentOS 7 or earlier Ubuntu editions.

In particular, you get time. The workload is significantly lower and correspondingly faster.

But by cloud base image you (usually) don’t get an alternatively built but otherwise identical build of a (server) distribution. There are some subtle differences. Some are conceptual. For example, most cloud images do not install a firewall. The cloud system usually provides this function. The use concept for the persistent storage is also different due to technical differences. And last but not least, cloud image developers may have different goals than the developers of the server variant installation of a distribution.

It is up to the system administrator to decide whether the functionality is identical to the extent that the advantages outweigh the disadvantages and it makes sense to use a specific cloud image as a virtual machine.

First of all you need a working Fedora Server Edition including virtualization support added and libvirtd daemon active. We assume an internal network 'default' with virbr0, DHCP, and DNS set up as well (see section 'Add Virtualization Support'). External network connectivity will be provided by macvlan (ethernet interface) rsp. macvtap (libvirt naming).

You have various options:

We will only cover the former two variants here. They are so universal that they are applicable to virtually all distributions. The latter ones are heavily dependent on details of a particular distribution.

Whichever of the presented installation methods is chosen, a cloud image always has to be downloaded and verified. In the case of CentOS, this involves the following steps.

You can start without any additional preparations.

This type of installation uses the --cloud-init parameter of virt-install without any value or subparameters. The approach causes the generation and display of a root password shortly after the start of installation, enabling a one-time login. You have to note or copy it, of course.

Apart from that, the configuration is limited to configuring and starting DHCP-supported Ethernet interfaces. Other interfaces are basically defined but not dealt with further.

Using any of the described installation methods, provides an quite comfortable installation and configuration process that would otherwise consume a lot of time. It is this performance that makes the use of cloud images so attractive.

The use of Cloud Base Images to create a distribution’s virtual machine installation comes with some inevitable inconveniences and shortcomings due to the different nature of the techniques. So, in a production deployment you may be better off with dedicated virtual machine images, if available. But for experimentation and testing it should be viable and suitable.