Virtualization

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).

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.

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.