Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionRichard W.M. Jones
2015-01-21 10:28:32 UTC
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
host-passthrough.
Version-Release number of selected component (if applicable):
libvirt-daemon-1.2.8-12.sa1.4.aarch64
How reproducible:
100%
Steps to Reproduce:
1. Run libguestfs under TCG.
Additional info:
libvirt XML:
<?xml version="1.0"?>
<domain type="qemu" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">
<name>guestfs-v6ubsyyn76uet5r4</name>
<memory unit="MiB">500</memory>
<currentMemory unit="MiB">500</currentMemory>
<cpu>
<model>cortex-a57</model>
</cpu>
<vcpu>1</vcpu>
<clock offset="utc">
<timer name="rtc" tickpolicy="catchup"/>
<timer name="pit" tickpolicy="delay"/>
</clock>
<os>
<type machine="virt">hvm</type>
<loader readonly="yes" type="pflash">/usr/share/AAVMF/AAVMF_CODE.fd</loader>
<nvram>/home/rjones/d/libguestfs/tmp/libguestfsgPniCg/AAVMF_VARS.fd.2</nvram>
<kernel>/home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel</kernel>
<initrd>/home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd</initrd>
<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>
</os>
<on_reboot>destroy</on_reboot>
<devices>
[omitted -- boring and irrelevant]
</devices>
<qemu:commandline>
<qemu:env name="TMPDIR" value="/home/rjones/d/libguestfs/tmp"/>
</qemu:commandline>
</domain>
Comment 1Richard W.M. Jones
2015-01-21 10:31:27 UTC
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...
Comment 7Richard W.M. Jones
2016-06-21 13:49:40 UTC
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-1.3.3.1-2.fc24.aarch64 Good
Fedora 24 libvirt-1.3.3.1-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
patches).
(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-1.3.3.1-2.fc24.aarch64 Good
> Fedora 24 libvirt-1.3.3.1-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
> patches).
Fair enough.
Comment 9Richard W.M. Jones
2016-06-21 14:08:56 UTC
Yup, added a comment on the other bug.
Comment 10Andrea Bolognani
2016-06-21 14:19:51 UTC