Qemu-system-aarch64, who dis?

Rocky Linux Help & Support
1

Is it just me or did qemu-system-aarch64 get dropped from RHEL and EPEL somewhere back in pre-7 days? Don’t see it in 7, 8, or 9. Guess that’s what I get for missing staff meetings…

2

Yea, that’s what you get for missing staff meetings. RH has done a lot of strange things. First they nuked KDE as a DE, and then then nuked CentOS halfway through its life expectancy. Didn’t you get the Memo? :laughing: A whole lot of CentOS users were sent scrambling, and here we are in Rocky Linux. The flock (?) of penguins is now starting to reconstitute itself here. Welcome to your new Watering Hole.

3

Getting back to this … I’m finding the whole “make an aarch64 Guest on an x86_64 Host with libvirt/qemu” thing works out of the box for anything except RHEL-derived bundles. It starts innocently enough, with something that works pretty much everywhere other than RHEL-land:

<install the equivalent of libvirt, libvirt-client, virt-install, virt-manager, and all dependencies>

mkdir -m 0750 /tmp/godzilla
chown kvm:kvm /tmp/godzilla
virsh -c qemu:///system --quiet pool-define-as godzilla dir --target /tmp/godzilla
virsh -c qemu:///system --quiet pool-autostart godzilla
virsh -c qemu:///system --quiet pool-start godzilla
virt-install \
    --connect qemu:///system \
    --name godzilla \
    --metadata 'title=godzilla' \
    --os-variant rhel8.4 \
    --arch aarch64 \
    --vcpus 4 \
    --ram 4096 \
    --rng /dev/urandom \
    --nonetwork \
    --noautoconsole \
    --controller 'type=scsi,model=virtio-scsi' \
    --disk 'pool=godzilla,size=20,format=raw,bus=scsi,boot.order=1,alias.name=sda' \
    --location /tmp/Rocky-8.4-aarch64-dvd1.iso \
    --initrd-inject /tmp/Rocky8.cfg \
    --extra-args 'ks=file:/Rocky8.cfg console=ttyS0'

This errors out with

ERROR    Host does not support any virtualization options for arch 'aarch64'

For RHEL/Fedora/Rocky/Alma 7/8/9 there’s no qemu softmmu target other than that matching the arch of the package build. A quick look at the src rpm specfile reveals a series of #ifarch clauses that match the local system arch and set build_arch to match, which then gets “-softmmu” appended and copied into the target-list, along with hardcoded values throughout both the ./configure call and the rest of the specfile that only make sense for a target-list of only the native [softmmu] {arch}. Similarly the %global have_fdt (FDT libraries and headers are required to build the aarch64 target in both the qemu-kvm and qemu-org master source) is statically set based not on whether the rpmbuild-ing system has libfdt installed or whether -lfdt works or libfdt.h exists, but on whether #ifarch aarch64 is enforced true.

On Ubuntu, SLES, BSD, Debian, and Arch, the qemu-kvm aarch64 target support is either in the base qemu-kvm packaging or in a secondary qemu-system-aarch or qemu-system-arm package, and works out of the box with the above commands. There’s functional parity even between Apple and Microsoft. But RHEL?

Do the RHEL-derived bundles still not provide any qemu softmmu targets besides whichever one is native? The aarch64 userspace emulation doesn’t appear to be buildable even from a git clone of the qemu-org master – there’s no “./aarch64*”, much less “./aarch64-softmmu/config-devices.mak”. The latest notes from RedHat, internally, are from 2017 with requests to expand the aarch64-softmmu support to EPEL from Fedora, but evidently that’s still not done now in 2022, and despite aarch64 ISOs having been issued for RHEL[-derived] bundles for longer than that.

Is there a legal issue, an question of ownership, or RedHat/QEMU pissing match I don’t know about?