Bug 1209948

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

(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

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.

Patch proposed upstream:

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

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.

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

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

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

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.