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.
-
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-builderships no licensed RHEL guest template, so the RHEL family needs the GenericCloud qcow2 +virt-customizepath, plus specifics that each break the build if the Debian recipe is copied verbatim:.rpm.sh/dnfand theguestfs-toolspackage,--selinux-relabeland image placement under/var/lib/libvirt/images/, the modular-vs-monolithic libvirt daemon (virtqemud/libvirtd),qemu:///system, and RHEL-family--os-variantIDs. RHEL, CentOS, and AlmaLinux are the common self-managed footprint, so they belong as a first-class option rather than a footnote. -
Bug fix. The Prepare script built a
debian-12image but registered the guest as--os-variant debian11. Corrected todebian12.
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.