Open AmedeeBulle opened 5 months ago
It probably needs a better test, based on the actual version (in this case: 8.0.0)
It is unfortunate that RHEL renames the "virt" machines, in their QEMU build
EDIT: Nope, they actually remove "virt" and add a custom "virt-rhel" machine.
Apparently they are doing this for all versions and architectures (also x86_64).
pc RHEL 7.0.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.0.0)
q35 RHEL-8.6.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel8.6.0)
q35 RHEL-9.4.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel9.4.0)
But the packages should only provide /usr/libexec/qemu-kvm
, and not pretend to be (upstream) qemu
You might have to install the real qemu (from qemu.org) until this compatibility issue can be addressed.
Background: I inadvertently found this by trying to run lima on EL9 on Raspberry Pi where it complained about -device ramfb
. Drilled down in the code where I saw it was only intended for older QEMU...
But the packages should only provide
/usr/libexec/qemu-kvm
This is the case; I am symlinking to make it run and it runs fine on x86_64
The best place to ask about this is qemu-devel or qemu-discuss mailing list:
In this case it was RHEL that renamed and renumbered the QEMU upstream.
The following test doesn't work well for Enterprise Linux distributions:
https://github.com/lima-vm/lima/blob/70e681b1f3c942412eae43917dd34c41b8f8aab2/pkg/qemu/qemu.go#L358
There is no "-7.0" string in
qemu-system-aarch64 -machine help
...