Goal
The setup and use of Fedora Server Edition as a virtual machine within a Fedora Server installation needs to be simplified and facilitated.
Optimally, a ready-to-use file system image deliverable should be available for download, which can be activated via Cockpit's "Import" feature or via CLI virt-install's "import" parameter.
Criteria
As far as possible, the virtual machine should have the same features and capabilities for users and system administrators as a bare-metal installation, i.e. as similar a 'user experience' as possible. Above all, the same procedures for installation and configuration should be available, e.g. Ansible playbooks.
Some deviations may be necessary or useful due to the technical characteristics of a VM.
E.g. both variants should use the same file system, i.e. XFS. However, it may not make sense to use LVM as well. This may be superfluous for virtualized storage. However, with LVM anyways , the same management routines can be used.
Details need to be discussed and finalized.
Cloud Base Image as VM in Fedora Server Edition
The idea was raised by Matthew Miller in the December 2020 "Reboot" meeting [1] and found its way into the first draft of a revised Fedora Server Edition Product Requirement Document (Server PRD). In March 2021 pboy published an article in Fedora Magazine exploring the use of Cloud Images as VM in Fedora Server Edition [2]. Its conclusion: "... while the use of Fedora Cloud Base Images comes with some inconveniences and suffers from shortcomings in documentation, Fedora Cloud Base images and virt-install version 3 is a great combination for quickly and efficiently creating virtual machines for Fedora Server". Based on this finding, it seemed worthwhile to explore and implement cooperation and possibly better mutual alignment, as discussed on the March 3, 2021 IRC meeting [3].
In contrast to this, Cloud Image WG members see significant factual differences between the runtime environments that a Fedora server as a Cloud Image does not make sense. Fedora Cloud was never set up as a "Fedora Server" lookalike in the first place. That's why it's a distinct Edition. "... If you want to do an "easy" Fedora Server as a VM on classical KVM hosts, you're probably better off with using virt-install... Setting up Fedora Cloud images on regular KVM hosts is a pain and not the intended use-case." [4]. Additionally, interest in cooperation on the part of Cloud WG members is very weak at best. And discussions should preferably cover technical features and implementations.
Resume as of June 2021
After 6 months, this idea has to be assessed as unrealisable. There is a lack of any preconditions for the implementation or realisation of such a plan. Such differences cannot be overcome.
References
Alternative (to Cloud) Fedora Server VM image provider
[1] 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.
[2] Usage of Image 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.
[3] oz install
Seems to be no longer maintained.
Conclusion
Unless I have overlooked an adequate tool, our only option is to supply our own image file.
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?
Issue tagged with: pending activity
Metadata Update from @pboy: - Issue untagged with: meeting - Issue tagged with: ongoing work project
Issue tagged with: in progress
Metadata Update from @pboy: - Issue tagged with: meeting
Metadata Update from @pboy: - Issue untagged with: in progress, meeting
Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.