Description of problem:
In qemu the default mach_virt uses a Cortex A15 CPU, which
is stupid for a 64 bit architecture. Therefore you have to
use -cpu cortex-a57 on the qemu command line.
Unfortunately libvirt refuses to let me use <cpu><model>cortex-a57</model></cpu>,
giving the error:
Unable to find CPU definition
This problem applies with TCG. With KVM we are able to use
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run libguestfs under TCG.
<domain type="qemu" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">
<timer name="rtc" tickpolicy="catchup"/>
<timer name="pit" tickpolicy="delay"/>
<loader readonly="yes" type="pflash">/usr/share/AAVMF/AAVMF_CODE.fd</loader>
<cmdline>panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000 no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color</cmdline>
[omitted -- boring and irrelevant]
<qemu:env name="TMPDIR" value="/home/rjones/d/libguestfs/tmp"/>
I remembered that I came across this bug before. See:
Andrea, please have a look at this one. Thanks.
FWIW it's very likely this is already fixed with latest RHEL bits, someone just needs to test it
This seems to no longer be a problem with current libvirt.
Rich, can you try removing the libguestfs workaround and
giving it another go?
By the way, I'm very confused about how the libguestfs
workaround could work in the first place: the "Unable to
find CPU definition" error is coming from qemu-kvm, not
libvirt, so it would stand to reason that using <qemu:arg>
to add the same '-cpu cortex-a57' option libvirt would add
because of <cpu><model>cortex-a57</model></cpu> would lead
to the same failure...
I tested this by reverting libguestfs commit 7e4b7a346a4558a02ae and
using this command against the latest libguestfs sources:
$ make quickcheck \
Host libvirt version Result
RHEL 7 libvirt-1.2.17-13.el7_2.4.aarch64 Good
RHEL 7 libvirt-1.3.5-1.el7.aarch64 Fails b/c bug 1337869
Fedora 24 libvirt-22.214.171.124-2.fc24.aarch64 Good
Fedora 24 libvirt-126.96.36.199-3.fc24.aarch64 Good
I also checked that the right -cpu flag was being passed.
So I think we can declare this bug fixed. It would be nice to
get final confirmation with bug 1337869 fixed as well, since I've
not been able to use recent versions of libvirt on RHELSA at all.
I have also pushed the revert patch to libguestfs upstream (not RHEL
however, but will consider it for inclusion in the next round of
(In reply to Richard W.M. Jones from comment #7)
> I tested this by reverting libguestfs commit 7e4b7a346a4558a02ae and
> using this command against the latest libguestfs sources:
> $ make quickcheck \
> LIBGUESTFS_BACKEND=libvirt LIBGUESTFS_BACKEND_SETTINGS=force_tcg
> Host libvirt version Result
> RHEL 7 libvirt-1.2.17-13.el7_2.4.aarch64 Good
> RHEL 7 libvirt-1.3.5-1.el7.aarch64 Fails b/c bug 1337869
> Fedora 24 libvirt-188.8.131.52-2.fc24.aarch64 Good
> Fedora 24 libvirt-184.108.40.206-3.fc24.aarch64 Good
> I also checked that the right -cpu flag was being passed.
> So I think we can declare this bug fixed.
Nice, thanks for trying it out!
> It would be nice to
> get final confirmation with bug 1337869 fixed as well, since I've
> not been able to use recent versions of libvirt on RHELSA at all.
Do you want me to prepare a scratch build of libvirt 1.3.5
that includes the two or three commits that have been merged
upstream last week to fix Bug 1337869, hence making libvirt
usable on RHELSA once again?
I guess that wouldn't just be useful for the bug at hand.
> I have also pushed the revert patch to libguestfs upstream (not RHEL
> however, but will consider it for inclusion in the next round of
Yup, added a comment on the other bug.
Great! Moving this one to ON_QA then.