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.
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).
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.
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.
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.
The easiest way to obtain a suitable virtual disk image is, to back up a copy of the disk image created by Anaconda during the initial or a follow-up VM installation.
To do this, the administrator could copy the virtual disk file created by Anaconda from the
~/libvirt/images/ directory to, for example, the
~/libvirt/boot/ directory, the Installation Media pool. The appropriate opportunity is after completion of the installation and before the first boot and prior to any post-install steps. As many as desired VMs can import this (custom) image to their own disk.
Of course, each of these VMs uses the same initial configuration, especially the same root password and the same administrative user. A static configuration of the Ethernet interfaces would also be impractical, because it leads to conflicts at the beginning, unless the original VM is stopped temporarily. Therefore, the initial Ehernet configuration should use DHCP in any case, even if DHCP is not available. In any case, at least the internal network uses DHCPand results in a working configuration.
All of this is a bit cumbersome and not optimal, but the initial post-install stage can adjust all this. And it is the only way to get a perfect resemblance of Fedora Server Edition so far.
There are several offerings available
Installation of guestfs-tools (f35, libguestfs-tools-c in f34) and use virt-builder to create a partly customized disk image (e.g. root password) that you can import using virsh
You get a disk image file pretty quickly and importing it into KVM is easy and fast as well.
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.
The qcow2 image file created by default has a capacity of 10 GiB and also occupies 10 GiB in the file system - so no use of dynamic capability of qcow2 format for thin provisioning. 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.
Overall, this is not a suitable solution.
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.
So it is a similarly limited suitable solution.
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.