Version 3 of virt-manager / virt-install introduced with Fedora 33 now offers the option --cloud-init. For Fedora Server, this opens up the possibility of installing a new VM based on Fedora Cloud base images (or other distributions) with much less effort than before and simplifies system administration.
Cloud images thus become a real alternative to the installation of VMs via the Fedora Server Install Image. Fedora Server and Cloud Image thus complement each other much better.
I have written a text that explains these possibilities in detail for our internal documentation and demonstrate them with two examples. If the topic would be interesting for Fedora Magazine, I would like to expand and formulate the text accordingly. It would then round up previous articles, “Creating virtual machines with Cockpit in Fedora” (Nov. 27, 2019) and “Installing and running Vagrant using qemu-kvm” (Sept. 21, 2020).
Welcome to the discussion area! As you no doubt have noticed, your idea has met with approval, side topics notwithstanding. I created a card on our Fedora Project Taiga instance for the magazine https://teams.fedoraproject.org/project/asamalik-fedora-magazine/kanban, it is card #280.
If you haven’t done so already, please follow the incredibly detailed instructions on getting setup as a writer for Fedora Magazine found at https://docs.fedoraproject.org/en-US/fedora-magazine/contributing/. Once you are setup on Taiga I can assign the card to you and when you are ready to work on it, just drag the card to the “In progress” column. If you have any questions, just reply here on this topic, and one of the editors can likely assist you.
I just moved the article to ‘in progress’.
II would like to give a brief overview / table of content of what I am currently planning and ask if this fits in Fedora Magazine and/or anything else to consider.
Table of Content
Why Use Cloud Images?
widespread installation via Anaconda - straight forward, but time consuming, not scriptable / reproducible, a viable option only for a kind of “nice to have” VM or for lack of reasonable alternatives.
pre-built libvirt compatible filesystem image offered by various third parties - concerns about security and reliability, not part of the Fedora QA process, probably subtle inconsistencies that may lead to not-so-subtle problems
reliable option: cloud base image - issue: managing cloud-init without cloud runtime
development usage: vagrant 
otherwise: virt-install pre version 3: laborious workaround [3,] - version 3 offers an efficient and straightforward installation path providing 2 options: (a) quick and minimal configuration, (b) easy elaborate configuration
A Typical Use Case
Fedora Server, key based ssh access only, minimal number of system users, providing backoffice services (e.g. database, wildfly/jboss application server, etc), natively or containerized
one or more VMs providing public access
internal protected communmication path between VMs and host via virbr0
external public access via bridge or mac-vlan/macvtab
libvirt installed and working
bridge for public access configured
Example 1: Quick and Minimal Configuration
Virt-install --cloud-init without any options
Completing the installation
Brief explanation of the virt-install parameters used
Example 2: An Easy Way to an Elaborate Configuration
Which properties can be configured
Creation and storage/management of the configuration files
Virt-install --cloud-init with user-data and meta-data
Firewall (either install in VM or use host firewall, possible by brouter type of bridge)
Further streamlining via scripting and/or Ansible playbooks (not the subject of this article)
Console does not open - Additional configuration options required
 Create virtual machines with Cockpit in Fedora (Fedora Magazin November 27, 2019)
 Installing and running Vagrant using qemu-kvm (Fedora Magazin September 21, 2020)
8000 words is pretty long. It might be worth splitting it into multiple articles. That’s something you can figure out as you write it. Sometimes the break points naturally show themselves. One possibility would be an intro article explaining the why and what (so up through the “typical use case”) and then a second article for preparation, examples, and post-install considerations. Troubleshooting might be a third article, depending on how much content you have there.
As for the “Why use cloud images?” section, I’d suggest focusing on the benefits of cloud images. You can explain why you might not want to use Anaconda installs or pre-built images, but in the context of what cloud images offer. In other words: talk about what makes cloud images good, not what makes other options bad. Does that make sense?
Of course, that makes perfectly sence. The current structure is due to my habitualisation of my scientific approach of first collecting all available information and analysing it comparatively in order to base a research project or expert opinion on it. In other contexts, this can lead to irritations, which I myself become aware of too late, a kind of professional “blind spot”. Thanks for the hint.