+ The Cloud image is used directly as ready to use (virtual) system disk in a virtual machine to be created. The first barrier is to perform the necessary initial basic configuration (network connection, root account, etc) so that the VM can start at all and you can log in. In a standard installation this is part of the distribution-specific installer, Anaconda in case of Fedora. In case of a Cloud image there is nothing to install and therefore no installer. Instead, a more or less standardized cloud-specific initialization procedure is used, cloud-init. In the absence of cloud, the system administrator must provide a replacement. The developers of cloud-init fortunately had some foresight and provided a 'nocloud' procedure of that said standardized cloud-specific initialization procedure. As you may guess, in a cloud centric development a nocloud option has a tough time. It remains somewhat of a challenge. 

+ For an autonomous Fedora server, i.e. not integrated into a cloud or into a development environment such as Vagrant, we use virt-install, the libvirt standard installer. With version 3, as included in Fedora since 33, it provides an easy to use emulation of the cloud-init 'noCloud' procedure. It allows both a very simple installation in a default configuration using a single parameter and a very elaborate configuration using two quite simple configuration files. Before version 3 this was relatively laborious, since a special iso image had to be crafted to inject configuration data.

+ In particular, you get time. The workload is significantly lower and correspondingly faster. But by Cloud Base Image you (currently) don’t get an alternatively built but otherwise identical build of Fedora Server Edition. There are some subtle differences. For example, Fedora Server Edition uses xfs as its file system, Cloud Base Image still uses the older ext4. Fedora Server Edition now persists the network configuration completely and stringently in NetworkManager, Cloud Base Image still uses the old ifcfg plugin. Other differences are conceptual. For example, Cloud Image does not install a firewall. This function is usually managed by the cloud system. The use concept for the persistent storage is also different due to technical differences.  But overall, the functionality is so far identical and the advantages noticeable that it is worthwhile and makes sense to use it. 

+ | --name VM_NAME |  Unique name of the VM to install as shown e.g.in VM  list

+ *In the end it takes only some 5 minutes to set up a fully functional system with minimal effort.* It is ideal to quickly create a virtual machine for an ad-hoc solution or as an interim solution for a test.

+ Usually, a VM is more complex and there are several issues to deal with. There is a public facing interface that requires a firewall that is not included in the Fedora Cloud Base image. You have either to configure the host to protect the VM or install a firewall. Furthermore it is a peculiarity of the cloud-init process that the second, internal interface is not configured persistently. Instead, it is set up anew each time the system is booted. This makes it impossible to assign a firewall zone to this interface. The public interface also provides ssh access. So a root key file is needed to secure the login.

+ According to specifications a static network connection may get configured in meta-data. Basically it works. But some – obviously long standing – bugs require manual intervention in any case. So it is easier to configure a static network by adjusting the default initialization in the other, custom specific file user-data.

+ 2. Set up the user root, the public SSH key is copied into the file as well as set up the fallback account "hostmin" (or alike) which should also be able to log in by password. It will be assigned to the group wheel and his public key will be copied into the file

+ a. Optional: convert interface eth0 to static

+   ##- nmcli con mod path 1 ipv4.gateway '<IPv4>' ipv4.dns '<IPv4>'