Hide Forgot
+++ 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.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 --- 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.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 --- 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
I've 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
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.
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