Bug 1000116 - getVersion() causes 'libvirt.libvirtError: internal error Cannot find suitable emulator for x86_64'
getVersion() causes 'libvirt.libvirtError: internal error Cannot find suitabl...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
21
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-22 14:05 EDT by Dan Prince
Modified: 2016-04-26 22:28 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-05 19:01:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Prince 2013-08-22 14:05:41 EDT
Description of problem:

I get the following error on Fedora 19 after performing a fresh install of libvirt and starting libvirtd:

[root@nova1 ~]# cat test.py
import libvirt
conn = libvirt.open("qemu:///system")
conn.getVersion()

[root@nova1 ~]# python test.py 
libvirt: QEMU Driver error : internal error Cannot find suitable emulator for x86_64
Traceback (most recent call last):
  File "test.py", line 3, in <module>
    conn.getVersion()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3550, in getVersion
    if ret == -1: raise libvirtError ('virConnectGetVersion() failed', conn=self)
libvirt.libvirtError: internal error Cannot find suitable emulator for x86_64


Version-Release number of selected component (if applicable):

[root@nova1 ~]# rpm -qa | grep libvirt
libvirt-daemon-driver-network-1.0.5.5-1.fc19.x86_64
libvirt-daemon-driver-qemu-1.0.5.5-1.fc19.x86_64
libvirt-daemon-driver-uml-1.0.5.5-1.fc19.x86_64
libvirt-daemon-driver-storage-1.0.5.5-1.fc19.x86_64
libvirt-daemon-driver-interface-1.0.5.5-1.fc19.x86_64
libvirt-daemon-driver-nodedev-1.0.5.5-1.fc19.x86_64
libvirt-daemon-config-nwfilter-1.0.5.5-1.fc19.x86_64
libvirt-python-1.0.5.5-1.fc19.x86_64
libvirt-client-1.0.5.5-1.fc19.x86_64
libvirt-daemon-1.0.5.5-1.fc19.x86_64
libvirt-daemon-driver-lxc-1.0.5.5-1.fc19.x86_64
libvirt-daemon-driver-secret-1.0.5.5-1.fc19.x86_64
libvirt-daemon-driver-xen-1.0.5.5-1.fc19.x86_64
libvirt-daemon-config-network-1.0.5.5-1.fc19.x86_64
libvirt-daemon-driver-nwfilter-1.0.5.5-1.fc19.x86_64
libvirt-daemon-driver-libxl-1.0.5.5-1.fc19.x86_64
libvirt-1.0.5.5-1.fc19.x86_64
Comment 1 Dan Prince 2013-08-22 14:20:03 EDT
Adding a bit more relevant information.

Yes. Qemu is installed:

[root@nova1 ~]# rpm -qa | grep qemu
qemu-system-x86-1.4.2-6.fc19.x86_64
qemu-system-cris-1.4.2-6.fc19.x86_64
qemu-system-unicore32-1.4.2-6.fc19.x86_64
qemu-system-ppc-1.4.2-6.fc19.x86_64
qemu-system-mips-1.4.2-6.fc19.x86_64
libvirt-daemon-driver-qemu-1.0.5.5-1.fc19.x86_64
ipxe-roms-qemu-20130517-2.gitc4bce43.fc19.noarch
qemu-system-arm-1.4.2-6.fc19.x86_64
qemu-system-m68k-1.4.2-6.fc19.x86_64
qemu-system-s390x-1.4.2-6.fc19.x86_64
qemu-system-microblaze-1.4.2-6.fc19.x86_64
qemu-img-1.4.2-6.fc19.x86_64
qemu-system-xtensa-1.4.2-6.fc19.x86_64
qemu-system-sh4-1.4.2-6.fc19.x86_64
qemu-system-lm32-1.4.2-6.fc19.x86_64
libvirt-daemon-qemu-1.0.5.5-1.fc19.x86_64
qemu-common-1.4.2-6.fc19.x86_64
qemu-user-1.4.2-6.fc19.x86_64
qemu-kvm-1.4.2-6.fc19.x86_64
qemu-system-or32-1.4.2-6.fc19.x86_64
qemu-system-sparc-1.4.2-6.fc19.x86_64
qemu-system-alpha-1.4.2-6.fc19.x86_64
qemu-1.4.2-6.fc19.x86_64

The really weird thing is that actually calling 'virsh capabilities' fixes it.

[root@nova1 ~]# python test.py 
libvirt: QEMU Driver error : internal error Cannot find suitable emulator for x86_64
Traceback (most recent call last):
  File "test.py", line 3, in <module>
    conn.getVersion()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3550, in getVersion
    if ret == -1: raise libvirtError ('virConnectGetVersion() failed', conn=self)
libvirt.libvirtError: internal error Cannot find suitable emulator for x86_64

[root@nova1 ~]#  virsh capabilities

[root@nova1 ~]# python test.py 
1004002
Comment 2 Daniel Berrange 2013-08-27 12:44:07 EDT
Can you expand a bit on how you did the installation of Fedora 19.

Did you install Fedora including libvirt and qemu bits at once from anaconda. Or did you install bare Fedora, then use yum to add libvirt/qemu bits. If the latter, can you tell me the exact sequence of commands used, including any related to systemd service start.
Comment 3 Jakub Ruzicka 2013-08-27 12:51:57 EDT
I can reproduce this on a fresh fully updated Fedora 19 VM installed using Oz.

`virsh capabilities` doesn't magically fix for me.
Comment 4 Jakub Ruzicka 2013-08-27 14:00:51 EDT
Never mind, I didn't have QEMU installed.

When I install both libvirt and QEMU on updated system at once, problem doesn't appear:

# yum update
# yum install libvirt libvirt-python qemu
# service libvirtd start
# python test.py
1004002


I can only reproduce the problem by running getVersion() against libvirtd that started without QEMU installed. After installing QEMU, getVersion() still fails until libvirtd is restarted or `virsh capabilities` is called.

# yum update
# yum install libvirt libvirt-python
# service libvirtd start
# python test.py
FAIL
# yum install qemu
# python test.py
FAIL
# virsh capabilities || service libvirtd restart
# python test.py
1004002


Getting error when accessing qemu:///system without QEMU installed sounds OK, doesn't it? So the only fix I see here is libvirtd checking for available emulators at proper moment (when calling getVersion), but restarting libvirtd (or calling virsh capabilities) after you install QEMU doesn't sound unreasonable to me.

Can you reproduce this in another way, Dan?
Comment 5 Daniel Berrange 2013-08-28 07:14:01 EDT
Yes, that makes sense now.

During libvirtd startup, we populate the virCapsPtr object with info about the QEMU binaries we detected.

The 'virConnectGetCapabilities' method will force a refresh of the virCapsPtr object to detect any changes in installed QEMU binaries

The virConnectGetVersion method, however, will not do such a refresh. So if QEMU was not present when libvirtd was first started, it will fail. We need to address this in libvirt to force a refresh, if no binaries were previously cached.
Comment 6 Jakub Ruzicka 2013-09-03 15:38:34 EDT
Giving this low priority as it only happens in rare occasion and can be easily fixed.
Comment 7 Pádraig Brady 2013-09-09 06:58:48 EDT
BTW, in openstack nova >= Havana milestone 3, there is a workaround
to switch the order of the getVersion and getCapabilities calls.
https://review.openstack.org/#/c/43338/

Also 2 users have reported that even with qemu installed a restart of libvirtd is not enough to workaround the issue.
Comment 8 Cole Robinson 2014-01-16 17:12:40 EST
Bug seems misassigned to Jakub, please correct if I'm wrong
Comment 9 Sergey Gotliv 2014-06-12 12:53:04 EDT
The problem is reproducible on my Fedora 20, what happened to workaround?

2014-06-12 16:52:02.148+0000: 8652: error : virQEMUCapsGetDefaultVersion:1736 : internal error: Cannot find suitable emulator for x86_64
Comment 10 Chad Feller 2014-09-22 14:38:46 EDT
For the people that stumble across this bug report, I ran into it this morning after upgrading to the most recent libvirtd (1.1.3.6) in fedora-updates (Fedora 20).  

Afterwards, I was seeing this, when trying to connect to libvirt from virt-manager:

>Unable to connect to libvirt.
>
>internal error: Cannot find suitable emulator for x86_64
>
>Libvirt URI is: qemu:///system
>
>Traceback (most recent call last):
>  File "/usr/share/virt-manager/virtManager/connection.py", line 1118, in _open_notify
>    logging.debug("conn version=%s", self._backend.conn_version())
>  File "/usr/share/virt-manager/virtinst/connection.py", line 290, in conn_version
>    self._conn_version = self._libvirtconn.getVersion()
>  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3676, in getVersion
>    if ret == -1: raise libvirtError ('virConnectGetVersion() failed', conn=self)
>libvirtError: internal error: Cannot find suitable emulator for x86_64

'virsh capabilities' returned just fine, but the problem didn't go away.  Restarting libvirtd a second time - before trying to connect with virt-manager - yielded a different error though:

> internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-kvm -help) unexpected exit status 127: /usr/bin/qemu-system-x86_64: symbol lookup error: /usr/bin/qemu-system-x86_64: undefined symbol: glfs_discard_async

Searching for that 'undefined symbol' led me to here: 

  https://bugzilla.redhat.com/show_bug.cgi?id=1099847#c3

Interestingly enough, on this particular machine I have glusterfs 3.4.5 installed, as our production GlusterFS servers are still on the 3.4.x branch (for reasons outside this bug report).

For bug reporting sake, I upgraded the GlusterFS version on this client (the same machine I'm seeing this error) to the most recent version in Fedora (3.5.2).  Now everything works perfectly fine.

Bottom line is in certain configurations, it seems as if an older glusterfs-api can cause problems.
Comment 11 Michael Simoni 2014-12-22 14:53:35 EST
I would like to update this for fedora 20:
I just did an update from fedora 19 to fedora 20 and now the virtual machines do not work:

trying to connect using hte virt-manager gui provides this:
Unable to connect to libvirt.

internal error: Cannot find suitable emulator for x86_64

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1118, in _open_notify
    logging.debug("conn version=%s", self._backend.conn_version())
  File "/usr/share/virt-manager/virtinst/connection.py", line 290, in conn_version
    self._conn_version = self._libvirtconn.getVersion()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3676, in getVersion
    if ret == -1: raise libvirtError ('virConnectGetVersion() failed', conn=self)
libvirtError: internal error: Cannot find suitable emulator for x86_64

the following commands produces the following error:
# virsh version
Compiled against library: libvirt 1.1.3
Using library: libvirt 1.1.3
Using API: QEMU 1.1.3
error: failed to get the hypervisor version
error: internal error: Cannot find suitable emulator for x86_64

restarting the libvirtd deamon provides this output in the /var/log/messages file
Dec 22 14:36:58 ronin systemd: Stopping Virtualization daemon...
Dec 22 14:36:58 ronin systemd: Starting Virtualization daemon...
Dec 22 14:36:58 ronin journal: libvirt version: 1.1.3.8, package: 1.fc20 (Fedora Project, 2014-11-16-03:48:03, buildhw-05.phx2.fedoraproject.org)
Dec 22 14:36:58 ronin journal: failed to load module /usr/lib64/libvirt/connection-driver/libvirt_driver_storage.so libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory
Dec 22 14:36:58 ronin journal: Unable to lookup SELinux process context: Invalid argument
Dec 22 14:36:58 ronin systemd: Started Virtualization daemon.
Dec 22 14:37:07 ronin dnsmasq[2434]: read /etc/hosts - 2 addresses
Dec 22 14:37:07 ronin dnsmasq[2434]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
Dec 22 14:37:07 ronin dnsmasq-dhcp[2434]: read /var/lib/libvirt/dnsmasq/default.hostsfile
Dec 22 14:37:09 ronin journal: Failed to open file '/proc/xen/capabilities': No such file or directory
Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-alpha -help) unexpected exit status 127: /usr/bin/qemu-system-alpha: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-arm -help) unexpected exit status 127: /usr/bin/qemu-system-arm: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-cris -help) unexpected exit status 127: /usr/bin/qemu-system-cris: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-i386 -help) unexpected exit status 127: /usr/bin/qemu-system-i386: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-kvm -help) unexpected exit status 127: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-lm32 -help) unexpected exit status 127: /usr/bin/qemu-system-lm32: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-m68k -help) unexpected exit status 127: /usr/bin/qemu-system-m68k: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-microblaze -help) unexpected exit status 127: /usr/bin/qemu-system-microblaze: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-microblazeel -help) unexpected exit status 127: /usr/bin/qemu-system-microblazeel: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-mips -help) unexpected exit status 127: /usr/bin/qemu-system-mips: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-mipsel -help) unexpected exit status 127: /usr/bin/qemu-system-mipsel: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-mips64 -help) unexpected exit status 127: /usr/bin/qemu-system-mips64: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-mips64el -help) unexpected exit status 127: /usr/bin/qemu-system-mips64el: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-ppc -help) unexpected exit status 127: /usr/bin/qemu-system-ppc: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-ppc64 -help) unexpected exit status 127: /usr/bin/qemu-system-ppc64: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-ppcemb -help) unexpected exit status 127: /usr/bin/qemu-system-ppcemb: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-s390x -help) unexpected exit status 127: /usr/bin/qemu-system-s390x: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-sh4 -help) unexpected exit status 127: /usr/bin/qemu-system-sh4: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-sh4eb -help) unexpected exit status 127: /usr/bin/qemu-system-sh4eb: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-sparc -help) unexpected exit status 127: /usr/bin/qemu-system-sparc: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-sparc64 -help) unexpected exit status 127: /usr/bin/qemu-system-sparc64: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-unicore32 -help) unexpected exit status 127: /usr/bin/qemu-system-unicore32: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-x86_64 -help) unexpected exit status 127: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-kvm -help) unexpected exit status 127: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-xtensa -help) unexpected exit status 127: /usr/bin/qemu-system-xtensa: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: internal error: Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin /usr/bin/qemu-system-xtensaeb -help) unexpected exit status 127: /usr/bin/qemu-system-xtensaeb: error while loading shared libraries: libboost_thread-mt.so.1.53.0: cannot open shared object file: No such file or directory

Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm
Dec 22 14:37:09 ronin journal: unknown OS type hvm

I updated another machine that I updated from FC19 to FC20. The "virsh version" commands has no problems on that one. That machine currently needs pending updates and it loooks like the boost-filesystem is one of them. I have not updated it yet. Will do that and see what happens.
   Compiled against library: libvirt 1.1.3
   Using library: libvirt 1.1.3
   Using API: QEMU 1.1.3
   Running hypervisor: QEMU 1.6.2

In the mean time any help is appreciated.
Comment 12 Michael Simoni 2014-12-24 11:47:42 EST
the system that was workng never stopped working even with all he new pending patches for qemu. 
in the mean time the following patches came out and this fixed my virtual machine processes. So for me this issue is closed.
qemu-img-1.6.2-12.fc20.x86_64
qemu-common-1.6.2-12.fc20.x86_64
qemu-system-x86-1.6.2-12.fc20.x86_64
qemu-system-cris-1.6.2-12.fc20.x86_64
qemu-user-1.6.2-12.fc20.x86_64
qemu-system-m68k-1.6.2-12.fc20.x86_64
qemu-system-alpha-1.6.2-12.fc20.x86_64
qemu-system-xtensa-1.6.2-12.fc20.x86_64
qemu-system-microblaze-1.6.2-12.fc20.x86_64
qemu-system-sh4-1.6.2-12.fc20.x86_64
qemu-system-arm-1.6.2-12.fc20.x86_64
qemu-system-lm32-1.6.2-12.fc20.x86_64
qemu-system-moxie-1.6.2-12.fc20.x86_64
qemu-system-mips-1.6.2-12.fc20.x86_64
qemu-system-or32-1.6.2-12.fc20.x86_64
qemu-system-unicore32-1.6.2-12.fc20.x86_64
qemu-system-s390x-1.6.2-12.fc20.x86_64
qemu-system-ppc-1.6.2-12.fc20.x86_64
qemu-system-sparc-1.6.2-12.fc20.x86_64
qemu-1.6.2-12.fc20.x86_64

Thank you.
Comment 13 Cole Robinson 2015-04-21 11:23:56 EDT
Upstream now:

commit 95546c43de51a3d54f9a7f65059a6492a64d4f69
Author: Cole Robinson <crobinso@redhat.com>
Date:   Thu Apr 16 14:51:26 2015 -0400

    qemu: Always refresh capabilities if no <guests> found
Comment 14 Cole Robinson 2015-04-27 19:21:16 EDT
I've pushed this patch to the libvirt f20 maint branch upstream, but it's not major enough to warrant and F20 build at this point since it will be EOL soon. So moving this bug to F21.

But if something major comes up that requires a new f20 build it will get this bug fix.
Comment 15 Fedora Update System 2015-04-28 12:54:38 EDT
libvirt-1.2.9.3-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/libvirt-1.2.9.3-1.fc21
Comment 16 Fedora Update System 2015-04-29 09:05:45 EDT
Package libvirt-1.2.9.3-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 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.9.3-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-7150/libvirt-1.2.9.3-1.fc21
then log in and leave karma (feedback).

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