Fredrik Arneving, Peter Boy, Jan Kuparinen Versão F35-F40 Last review: 2024-04-26
For more than a decade now, server hardware has been powerful enough to run not only one operating system, but many of them simultaneously. This inspired software developers to create virtualisation solutions for affordable (Intel) server architecture, as was already common on mainframes at the time.

Virtualization means that several complete and probably different operating systems – the virtual guest machines (guest VM) – run on one and the same hardware, even if intended for a different hardware architecture (full virtualization). In any case, each guest VM uses its own kernel und operates as far as possible independently and isolated from each other and the host system. The basis is a 'hypervisor' that manages hardware resources and assigns them to the individual operating systems rsp. virtual guest machines.

Containers are an alternative often discussed. Here, several containers use the kernel of the host system simultaneously. The mutual isolation is lower, but the performance overhead is also lower.

Virtualization options in Fedora


XEN was the first virtualisation technique suitable for inclusion in a open source distribution as Fedora. This solution first boots a hypervisor that manages resource access and then subsequently loads the distribution kernel, which in the case of XEN takes on a special management function (Dom0). This technology is called 'Type-1' hypervisor and is the basis of many commercial virtualisation solutions, especially in the mainframe world.

Xen initially involved considerable administration and development effort, as special kernel extensions were necessary. Licensing problems also contributed to this.

Fedora was an early adoptor of XEN but preferred later KVM as virtualization solution.

XEN is still natively supported by Fedora Server


The development of KVM began later, when the issues with kernel additions were largely settled. It also benefited from being a true open source project, which made it easier to integrate modules into the kernel.

Technically, KVM follows a different approach as XEN. It requires an already installed complete operating system and uses kernel capabilities that are already part of its standard scope. And there is a tight cooperation with Qemu, the open source emulation Software (hence the naming kvm/qemu). It is thus more like a 'Type-2' hypervisor, whose typical characterisation is the prerequisite of a complete operating system. The well-known Virtual Box is an example of a 'Type-2' hypervisor.

Fedora was an early adoptor of KVM/Qemu and it is natively supported by Fedora Server.

Fedora Project decided some time ago to replace XEN as the preferred virtualization and use KVM as default instead.

Due to the 'Type-2'-like concept of KVM, Fedora Server Edition is first installed and configured as usual. System software required for virtualization is not automatically installed. In a second step, virtualization capabilities are added (it can be added as an option during installation to combine both into one step on the surface. However, a subsequent, precisely fitting installation is very much preferrable).

Adding Virtualization Support

This step includes the installation of the libvirt software and further configuration steps. For example, external connectivity must be set up for virtual machines, e.g. through a virtual bridge or mac-vlan. Often, an internal network is also required for protected communication between the virtual machines or with the host system.

After Fedora Server is enabled for virtualization, one or more virtual machines can be installed. This might be Fedora Server, or any other Linux distribution.

Adding Virtual Machines

There are two common ways to install virtual machines:

  • Use of the distribution’s native installer, often a bootable iso file originally intended for burning to DVD or transferring to a USB stick. A utility boots this iso file into an initially temporary virtual machine that runs the native installer, permanently setting up the virtual machine with the desired system.

  • Use of a virtual disk image containing a preconfigurated, ready to boot operational system, often optimized for virtualization. A special case are cloud (base) images.

Distribution’s native installer

With this method, the distribution’s own installation procedure of the targeted distribution is executed in a virtual machine. In the case of Fedora, this is Anaconda, which most administrators are already familiar with from the host server installation. The learning curve is therefore very flat.

In most cases, the installation procedure is interactive, as in the case of Anaconda on Fedora Server installation media. Advantages are the familiarity of administrators with the tool, the customizability in all the details that the installation of each distribution offers, and the perfect replication of all the features and capabilities that are offered.

The big disadvantage is that this process is very time-consuming. If several VMs have to be installed or you only need a test instance "quickly", this is not an efficient solution.

As the tool to run the distribution’s native installer, Fedora recommends Cockpit, a web-based graphical and comfortable administration tool. An alternative is Virt-Manager, also a graphical utility. However, it must be installed on the local workstation (Linux only) and then works via a ssh connection. Execution on Fedora Server itself is not supported, as Fedora Server is designed to be "headless", i.e. without a graphical user interface.

Experienced administrators can also initialize an installation via the command line using VNC and virt-install. However, if you don’t have a routine for this and no stock of configuration snippets to build on, this is also quite time-consuming and, moreover, then error-prone.

Virtual disk image

The basic idea is not to always create a virtual disk anew when a new VM is to be installed. This involves going through the same configuration steps in Anaconda over and over again and let Anaconda copying the same rpm packages one by one from the installation media to the virtual disk. Instead, the administrator resorts to a preconfigured, bootable generic disk image and "imports" it in its entirety unchanged into the virtual machine as a virtual hard disk on one go.

This import is unproblematic, since the virtualized central hardware elements of a QEMU/kvm Linux virtual machine of the same architecture hardly differ. Any remaining differences can be adjusted in the course of post-installation tasks. In this way, an installation that would otherwise easily take about a quarter of an hour is reduced to a few minutes.

Fedora Server KVM virtual disk images

Fedora provides on the Fedora Server download page with "Fedora Server 39 QEMU" a VM disk image in the qcow2 format. This format allocates dynamically only the amount of disk space which it actually required.

This VM resembles a Fedora Server installed on hardware as complete as possible.

The article Creating a virtual machine using Fedora Server Edition disk image describes the process in detail.

Custom virtual disk image repositories and generation tools

There are several offerings available

  • ImageFactory

    This is the tool that Fedora Release Engineering currently uses to create the various Fedora VM images. You can install the program on your local hard drive and use it to create your own Fedora VM image. By default, it uses Fedora rpm packages and the various Fedora VM images are available in source code, which you can copy and customize to your specific requirements. This way you get an image that is as close as possible to the images provided by Fedora.

    The article ImageFactory – How to Create a Virtual Machine Disk Image describes the process in detail.

  • Virtual Builder

    The guestfs-tools, included in the Adding Virtualization Support installation task, include the _virt-builder tool to create a partly customized disk image (e.g. root password). You get a disk image file pretty quickly and importing it into KVM is easy and fast as well.

    The tools uses prebuild-images on a third-party server that provides images for many distributions.

    If you specify "Fedora Server" as yourtarget, you will not get a resemblance of Fedora Server virtualized, contrary to the description in virt-builder. Cockpit is not installed, filesystem is without LVM, many software packages are missing (vim, tar , sshfs, etc), firewall without Fedora Server zone - just to name a few. rovisioning. The image is generated on an external server and imported as a binary.

    With all the effort we put into Fedora to build even the smallest rpm package completely from source on Fedora infrastructure, it seems pretty absurd to use a complete VM binary from a third party source or to rely on an external binary image. Therefore, to create a Fedora image this is probvably not a suitable solution.

    But you can easily get VM images of other distributions and install it on a Fedora Server host. However, it remains to be seen how closely the corresponding distribution system will be replicated.

  • Image Builder Tool

    The tool creates an elaborated image file. But in the current implementation it requires almost a similar effort as an Anaconda installation. And as in the case of virt-builder, a binary is imported from an external source.

    The extent to which the VM images created replicate the respective distribution is similarly questionable as with Virtual Builder.

Cloud base images

Most distributions provide "cloud images". These are virtual disk images, each custom built for easy installation in one of the cloud systems, e.g. Amazon’s AWS or Google’s GCP. They use cloud system specific features for configuration and administration provided by the respective cloud system, e.g. cloud-init for initialization at the first boot. These are not readily available on an autonomous server.

In addition, most distributions also provide a "cloud base image", a base system built like the specific cloud images, but without the respective configuration and administrative tools. For example, it supports the "no-cloud" option for cloud-init. These are installable (i.e. "imported") in an autonomous server as a VM.

It is very different to what extent these cloud base images resemble an autonomous server of the respective distribution. In the case of Fedora, there is intentionally a fairly low resemblance to Fedora Server Edition. This path might be considered to be of limited usefulness.

Installation is accomplished on the command line with a single and simple invocation of the virt-install program. The article Creating a virtual machine using a distribution’s Cloud base image – the example of CentOS describes the work to do in detrail for CentOS 9 stream.