Docs: add RHEL-family libvirt base image, fix --os-variant

What does this MR do and why?

The libvirt Custom executor example is Debian-only and carries one bug.

  1. RHEL family as a co-equal option. Restructure the base-image step into two options under a new Build the base image section: Debian and Ubuntu (virt-builder, unchanged) and RHEL, CentOS, and AlmaLinux (virt-customize). virt-builder ships no licensed RHEL guest template, so the RHEL family needs the GenericCloud qcow2 + virt-customize path, plus specifics that each break the build if the Debian recipe is copied verbatim: .rpm.sh/dnf and the guestfs-tools package, --selinux-relabel and image placement under /var/lib/libvirt/images/, the modular-vs-monolithic libvirt daemon (virtqemud / libvirtd), qemu:///system, and RHEL-family --os-variant IDs. RHEL, CentOS, and AlmaLinux are the common self-managed footprint, so they belong as a first-class option rather than a footnote.

  2. Bug fix. The Prepare script built a debian-12 image but registered the guest as --os-variant debian11. Corrected to debian12.

The RHEL path was validated end to end on AlmaLinux 9 (base image built with virt-customize, ephemeral VM created and destroyed per job, rootful build inside the disposable VM). Observed there: the guestfs-tools package, --os-variant rhel9.0, --selinux-relabel, qemu:///system, and the libvirtd compatibility unit active. The grub2-mkconfig note is advisory; the cloud image needed no kernel-command-line edit.

Merge request reports

Loading