Beta 1! Please comment on server mailing list
For more than a decade now, PC 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 the (Intel) PC 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. virtuel 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 an 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. 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 distribution.
There are two common ways to install virtual machines:
Use of the distribution-specific installation program with the help of specialized utilities
Installation of cloud (base) images, a variant of the operating system optimized for virtualization.
To do this, the standard ISO file is copied to the server and then executed via a utility. The web-based administration tool Cockpit is currently recommended for Fedora Server. An alternative is Virt-Manager, a graphical utility. However, it must be installed on the local workstation (Linux only) and then works via a ssh connection. Execution on the 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, this is comparatively time-consuming and error-prone.
A special feature of cloud images is a configuration for a specific runtime environment and purpose with the help of a special program, cloud-init. The necessary information is provided by the cloud system, e.g. Open Stack. These are not readily available on an autonomous server. With Fedora 33 and version 3 of the virt-install program, the installation and use of cloud images and cloud-init has been greatly simplified.
Installation is now accomplished with a single and simple invocation of the virt-install CLI program. Currently, no support is available through a graphical or web-based program.