Bug 1209948 - domcapabilities failes for --arch ppc64le --emulatorbin /usr/bin/qemu-system-ppc64
Summary: domcapabilities failes for --arch ppc64le --emulatorbin /usr/bin/qemu-system-...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Privoznik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1210159
TreeView+ depends on / blocked
 
Reported: 2015-04-08 13:48 UTC by Cole Robinson
Modified: 2016-07-28 07:18 UTC (History)
14 users (show)

Fixed In Version: libvirt-1.2.13.1-1.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1210159 (view as bug list)
Environment:
Last Closed: 2015-05-01 16:44:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Cole Robinson 2015-04-08 13:48:07 UTC
$ sudo virsh domcapabilities --emulatorbin /usr/bin/qemu-system-ppc64 --arch ppc64le
error: failed to get emulator capabilities
error: invalid argument: architecture from emulator 'ppc64' doesn't match given architecture 'ppc64le'

When the capabilities block is:

  <guest>
    <os_type>hvm</os_type>
    <arch name='ppc64le'>
      <wordsize>64</wordsize>
      <emulator>/usr/bin/qemu-system-ppc64</emulator>
      <machine canonical='pseries-2.3' maxCpus='255'>pseries</machine>
      <machine maxCpus='1'>ref405ep</machine>
      <machine maxCpus='1'>virtex-ml507</machine>
      <machine maxCpus='32'>ppce500</machine>
      <machine maxCpus='15'>mpc8544ds</machine>
      <machine maxCpus='1'>bamboo</machine>
      <machine maxCpus='1'>g3beige</machine>
      <machine maxCpus='1'>prep</machine>
      <machine maxCpus='255'>pseries-2.1</machine>
      <machine maxCpus='255'>pseries-2.2</machine>
      <machine maxCpus='1'>mac99</machine>
      <machine maxCpus='1'>taihu</machine>
      <domain type='qemu'/>
    </arch>
    <features>
      <cpuselection/>
      <deviceboot/>
      <disksnapshot default='on' toggle='no'/>
    </features>
  </guest>



Given that nowadays we can have the same emulatorbin map to multiple architectures, and the same architecture provided by multiple emulators, I think any use of virQEMUCapsCacheLookup* should be audited since a single arch or emulatorbin is not always sufficient to lookup what is needed.

Comment 1 Ján Tomko 2015-04-08 14:12:52 UTC
What's the libvirt version?

This could have been fixed by
commit 0afa6be8153518fad5862da022f63042cb72abbb
Author:     Prerna Saxena <prerna.ibm.com>
AuthorDate: 2015-02-26 08:10:58 -0600
Commit:     Michal Privoznik <mprivozn>
CommitDate: 2015-03-03 10:57:18 +0100

    RNG: Add 'ppc64le' arch and newer pseries-2.* machine types
    
    Acked-by: Ján Tomko <jtomko>
    Signed-off-by: Prerna Saxena <prerna.ibm.com>

git describe: v1.2.13-35-g0afa6be contains: v1.2.14-rc1~293

Comment 2 Cole Robinson 2015-04-08 14:15:41 UTC
(In reply to Ján Tomko from comment #1)
> What's the libvirt version?
> 
> This could have been fixed by
> commit 0afa6be8153518fad5862da022f63042cb72abbb
> Author:     Prerna Saxena <prerna.ibm.com>
> AuthorDate: 2015-02-26 08:10:58 -0600
> Commit:     Michal Privoznik <mprivozn>
> CommitDate: 2015-03-03 10:57:18 +0100
> 
>     RNG: Add 'ppc64le' arch and newer pseries-2.* machine types
>     
>     Acked-by: Ján Tomko <jtomko>
>     Signed-off-by: Prerna Saxena <prerna.ibm.com>
> 
> git describe: v1.2.13-35-g0afa6be contains: v1.2.14-rc1~293

Still relevant with libvirt.git. That commit sounds like it's only about domain RNG. This error is a specific error message in qemu_drivers.c domcapabilities implementation

Comment 3 Michal Privoznik 2015-04-08 14:29:08 UTC
The problem is here:

qemu_driver.c:18739) qemuConnectGetDomainCapabilities(virConnectPtr conn,
qemu_driver.c:18740)                                  const char *emulatorbin,
qemu_driver.c:18741)                                  const char *arch_str,
qemu_driver.c:18742)                                  const char *machine,
qemu_driver.c:18743)                                  const char *virttype_str,
qemu_driver.c:18744)                                  unsigned int flags)
qemu_driver.c:18745) {


qemu_driver.c:18780) 
qemu_driver.c:18781)     if (emulatorbin) {
qemu_driver.c:18782)         virArch arch_from_caps;
qemu_driver.c:18783) 
qemu_driver.c:18784)         if (!(qemuCaps = virQEMUCapsCacheLookup(driver->qemuCapsCache,
qemu_driver.c:18785)                                                 emulatorbin)))
qemu_driver.c:18786)             goto cleanup;
qemu_driver.c:18787) 
qemu_driver.c:18788)         arch_from_caps = virQEMUCapsGetArch(qemuCaps);
qemu_driver.c:18789) 
qemu_driver.c:18790)         if (arch_from_caps != arch &&
qemu_driver.c:18791)             (arch_from_caps != VIR_ARCH_X86_64 || arch != VIR_ARCH_I686)) {
qemu_driver.c:18792)             virReportError(VIR_ERR_INVALID_ARG,
qemu_driver.c:18793)                            _("architecture from emulator '%s' doesn't "
qemu_driver.c:18794)                              "match given architecture '%s'"),
qemu_driver.c:18795)                            virArchToString(arch_from_caps),
qemu_driver.c:18796)                            virArchToString(arch));
qemu_driver.c:18797)             goto cleanup;
qemu_driver.c:18798)         }
qemu_driver.c:18799)     } else {

The check for arch_from_caps should cope with all the architectures that binary can run. I'm working on a patch.

Comment 4 Michal Privoznik 2015-04-08 15:12:54 UTC
Patch proposed upstream:

https://www.redhat.com/archives/libvir-list/2015-April/msg00301.html

Comment 5 David Gibson 2015-04-09 04:27:31 UTC
Thanks for filing this.  I've cloned this for RHEL, since the case I'm actually working with has virt-manager running on Fedora, but connecting to libvirt on RHEL at the backend.

Comment 6 Michal Privoznik 2015-04-17 15:05:16 UTC
I've just pushed patch upstream:

commit 0af9325e6a06fd4478d4eebfcd92dfe7e2ec570c
Author:     Michal Privoznik <mprivozn>
AuthorDate: Wed Apr 8 16:59:36 2015 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Fri Apr 17 17:00:15 2015 +0200

    domcaps: Check for architecture more wisely
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1209948
    
    So we have this bug. The virConnectGetDomainCapabilities() API
    performs a couple of checks before it produces any result. One of
    the checks is if the architecture requested by user can be run by
    the binary (again user provided). However, the check is pretty
    dumb. It merely compares if the default binary architecture
    matches the one provided by user. However, a qemu binary can run
    multiple architectures. For instance: qemu-system-ppc64 can run:
    ppc, ppcle, ppc64, ppc64le and ppcemb. The default is ppc64, so
    if user requested something else, like ppc64le, the check would
    have failed without obvious reason.
    
    Signed-off-by: Michal Privoznik <mprivozn>


v1.2.14-221-g0af9325

Comment 7 Fedora Update System 2015-04-28 16:54:25 UTC
libvirt-1.2.13.1-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libvirt-1.2.13.1-1.fc22

Comment 8 Fedora Update System 2015-04-29 13:03:12 UTC
Package libvirt-1.2.13.1-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-1.2.13.1-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-7122/libvirt-1.2.13.1-1.fc22
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2015-05-01 16:44:50 UTC
libvirt-1.2.13.1-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.