On our agenda there is the project "Facilitated and improved support for Fedora
Server Edition VMs". Once started as a prospective cooperation with cloud WG, this
prospect has bluntly failed.
The question now is how can we easily and efficiently provide a virtualised version of
Fedora Server for a bare-metal Fedora Server with virtualisation support installed. This
question becomes urgent given the power of current hardware.
Currently there are 4 Options ready to use:
Usage of Cockpits 'Create VM' which launches Anaconda installation support and
guides you through the standard installation process.
You get a perfect duplum of Fedora Server in virtualized form, but at the price of a
significant amount of work.
Instead of Cockpit you could use an elaborate invocation of virsh, but the effort will not
That's not exactly the goal of our project.
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
You get a disk image file pretty quickly and importing it into KVM is easy and fast as
You will not get a duplum 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
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. 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.
Usage of mage Builder Tool / Cockpit module
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.
Usage of cloud base image
This solution would be Fedora controlled after all. Importing via virsh is simple and
fast. But the result is far from being a duplum of Fedora Server - no firewall, no
cockpit, different file system, missing software, just to name a few. And a duplum is
explicitly not intended by cloud WG.
Altogether, this option is not a solution either.
= Conclusion =
Unless I have overlooked an adequate tool, our only option is to supply our own image file
- similar to what CoreOS does.
We already provide a perfect image file for Arm64 SBC devices - including initial
configurability, similar in scope to Anaconda. Could this serve as a template?
Maybe that would be a realistic goal for F36 release?
Feedback and other possible alternatives are very much appreciated.