Bug 1210159 - 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: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.2
Hardware: ppc64le
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Michal Privoznik
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1209948
Blocks: RHEV3.6PPC 1204970
TreeView+ depends on / blocked
 
Reported: 2015-04-09 04:26 UTC by David Gibson
Modified: 2016-07-07 07:25 UTC (History)
22 users (show)

Fixed In Version: libvirt-1.2.15-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1209948
Environment:
Last Closed: 2015-11-19 06:27:36 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2202 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2015-11-19 08:17:58 UTC

Description David Gibson 2015-04-09 04:26:49 UTC
+++ This bug was initially created as a clone of Bug #1209948 +++

$ 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.

--- Additional comment from Ján Tomko on 2015-04-08 10:12:52 EDT ---

What's the libvirt version?

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

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

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

--- Additional comment from Cole Robinson on 2015-04-08 10:15:41 EDT ---

(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@linux.vnet.ibm.com>
> AuthorDate: 2015-02-26 08:10:58 -0600
> Commit:     Michal Privoznik <mprivozn@redhat.com>
> CommitDate: 2015-03-03 10:57:18 +0100
> 
>     RNG: Add 'ppc64le' arch and newer pseries-2.* machine types
>     
>     Acked-by: Ján Tomko <jtomko@redhat.com>
>     Signed-off-by: Prerna Saxena <prerna@linux.vnet.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

--- Additional comment from Michal Privoznik on 2015-04-08 10:29:08 EDT ---

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.

--- Additional comment from Michal Privoznik on 2015-04-08 11:12:54 EDT ---

Patch proposed upstream:

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

Comment 2 Michal Privoznik 2015-04-24 14:41:04 UTC
I've pushed patch upstream:

commit 0af9325e6a06fd4478d4eebfcd92dfe7e2ec570c
Author:     Michal Privoznik <mprivozn@redhat.com>
AuthorDate: Wed Apr 8 16:59:36 2015 +0200
Commit:     Michal Privoznik <mprivozn@redhat.com>
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@redhat.com>

v1.2.14-221-g0af9325

Comment 4 Dan Zheng 2015-07-28 05:55:05 UTC
Test on below packages:
libvirt-1.2.17-2.el7.ppc64le
kernel-3.10.0-292.el7.ppc64le
qemu-kvm-rhev-2.3.0-9.el7.ppc64le


#  virsh domcapabilities --emulatorbin /usr/libexec/qemu-kvm
<domainCapabilities>
  <path>/usr/libexec/qemu-kvm</path>
  <domain>qemu</domain>
  <machine>pseries-rhel7.2.0</machine>
  <arch>ppc64le</arch>                   ===>ppc64le is default
  <vcpu max='255'/>
  <os supported='yes'>
    <loader supported='yes'>
      <enum name='type'>
        <value>rom</value>
        <value>pflash</value>
      </enum>
      <enum name='readonly'>
        <value>yes</value>
        <value>no</value>
      </enum>
    </loader>
  </os>
  <devices>
    <disk supported='yes'>
      <enum name='diskDevice'>
        <value>disk</value>
        <value>cdrom</value>
        <value>floppy</value>
        <value>lun</value>
      </enum>
      <enum name='bus'>
        <value>ide</value>
        <value>fdc</value>
        <value>scsi</value>
        <value>virtio</value>
        <value>usb</value>
      </enum>
    </disk>
    <hostdev supported='yes'>
      <enum name='mode'>
        <value>subsystem</value>
      </enum>
      <enum name='startupPolicy'>
        <value>default</value>
        <value>mandatory</value>
        <value>requisite</value>
        <value>optional</value>
      </enum>
      <enum name='subsysType'>
        <value>usb</value>
        <value>pci</value>
        <value>scsi</value>
      </enum>
      <enum name='capsType'/>
      <enum name='pciBackend'>
        <value>default</value>
        <value>vfio</value>
      </enum>
    </hostdev>
  </devices>
</domainCapabilities>



#  virsh domcapabilities --emulatorbin /usr/libexec/qemu-kvm --arch ppcemb

<machine>pseries-rhel7.2.0</machine>
  <arch>ppcemb</arch>


#  virsh domcapabilities --emulatorbin /usr/libexec/qemu-kvm --arch ppc64

  <path>/usr/libexec/qemu-kvm</path>
  <domain>qemu</domain>
  <machine>pseries-rhel7.2.0</machine>
  <arch>ppc64</arch>

#  virsh domcapabilities --emulatorbin /usr/libexec/qemu-kvm --arch ppc64le
  <path>/usr/libexec/qemu-kvm</path>
  <domain>qemu</domain>
  <machine>pseries-rhel7.2.0</machine>
  <arch>ppc64le</arch>


#  virsh domcapabilities --emulatorbin /usr/libexec/qemu-kvm --arch ppcle
  <path>/usr/libexec/qemu-kvm</path>
  <domain>qemu</domain>
  <machine>pseries-rhel7.2.0</machine>
  <arch>ppcle</arch>


#  virsh domcapabilities --emulatorbin /usr/libexec/qemu-kvm --arch ppc
  <path>/usr/libexec/qemu-kvm</path>
  <domain>qemu</domain>
  <machine>pseries-rhel7.2.0</machine>
  <arch>ppc</arch>

All above are pass.

Comment 6 errata-xmlrpc 2015-11-19 06:27:36 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html


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