Comment 2 for bug 1628101

Hi,
first of all thank you for the pre-analysis.
I must admit that it is long enough that I was mislead at first :-)

I as well have:
    <os_type>hvm</os_type>
    <arch name='ppc64le'>
      <wordsize>64</wordsize>
      <emulator>/usr/bin/qemu-system-ppc64le</emulator>
      <machine maxCpus='255'>pseries-yakkety</machine>

On:
ii libvirt-bin 2.1.0-1ubuntu6 ppc64el programs for the libvirt library
ii qemu-kvm 1:2.6.1+dfsg-0ubuntu3 ppc64el QEMU Full virtualization

But not
virsh capabilities | grep '2\.7'

And actually there should be no 2.7 around ever as this is qemu 2.6.
I assume you had a self provided qemu 2.7 around on the system before?

Following your pre-analysis I finally understood that you got rid of the main issue by clearing some cache.
Quote: "Had a discussion with Shiva, after removing libvirt cache, libvirt restart the virsh capabilities output became consistent"

So I understand you hit your custom qemu 2.7 with that by "missing" a hard coded path in the kvm wrapper? And your suggestion is to hardcode the full path in the kvm wrapper.

So that is an issue I understand - but not related to the type changes we had.
Just falling into that time incidentally I think.

IMHO - users are supposed to be able to overwrite their qemu used for KVM by providing one that is preferred in path.
Your suggestion would break that, don't you think that is loosing more than it fixes?

Waiting for your feedback before going into too much more detail.
If you want more of a fast discussion please catch cpaelzer on freenode e.g. #ubuntu-server (European timezone)