Bug 1316911

Description of problem
----------------------

Post update to libvirt-1.3.2-2.fc25 (or libvirt-1.3.2-1.fc24), and
restarting the libvirt daemon, (a) previously existing VMs are not
enumerated; (b) explict attempt to define a guest fails with:

      $ virsh define /etc/libvirt/qemu/devstack1.xml
      error: Failed to define domain from devstack1.xml
      error: invalid argument: could not find capabilities for arch=x86_64

While we're at it, I tried to explictly get capabilities this way, sure
enough it fails:

    $ virsh cpu-models x86_64
    error: failed to get CPU model names
    error: this function is not supported by the connection driver: virConnectGetCPUModelNames

Okay, this error gives us a hint to check the `virsh uri`.  Let's do
that:

    $ virsh uri
    lxc:///

Whoops!  Upgrading packages has reset the URI to "lxc:///", while we're
expecting it to be "qemu:///system".

Okay, let's try to explicitly set the URI, and try:

    $ virsh -c qemu:///system list
    error: failed to connect to the hypervisor
    error: no connection driver available for qemu:///system

Why is it so?  Let's quickly check if we have
'libvirt-daemon-driver-qemu' package is installed.  Sure, we have it:  

    $ rpm -q libvirt-daemon-driver-qemu
    libvirt-daemon-driver-qemu-1.3.2-2.fc25.x86_64

But is 'libvirt_driver_storage.so' loaded for sure?  Let's check
`journalctl` [I manually wrapped the error message]:

   $ journalctl --since=today | grep libvirt_driver_storage.so Mar 11
   06:04:04 foohost libvirtd[32474]: failed to load module
   /usr/lib64/libvirt/connection-driver/libvirt_driver_storage.so
   /usr/lib64/libvirt/connection-driver/libvirt_driver_storage.so:
   undefined symbol: rbd_diff_iterate2
   [...]

Ah-ha!  So, indeed, it failed to load due to "undefined symbol:
rbd_diff_iterate2".

    * * *

Downgrading the packages (`dnf downgrade libvirt\* qemu\*
--allowerasing`) and restarting the libvirtd restores the correct
behavior (for both defining guests, and getting CPU model info) -- as it
sets the URI back to "qemu:///system").

Maybe these are the perils of selective testing from Rawhide (or F24),
while on F23.

Version
-------

Tested with libvirt/QEMU packages updated to Rawhide

    libvirt-1.3.2-2.fc25.x86_64
    qemu-system-x86-2.5.0-9.fc25.x86_64

This is also reproducible with F24 (branched) with:

    libvirt-1.3.2-1.fc24.x86_64
    qemu-system-x86-2.5.0-8.fc24.x86_64


How reproducible: Consistently


Steps to reproduce
------------------

(1) If testing with packages Rawhide, update libvirt & QEMU packages : 

      $ sudo dnf install fedora-repos-rawhide
      $ sudo dnf --releasever=24 update libvirt\* qemu\*

    If you're on F24:

      $ sudo dnf --releasever=rawhide update libvirt\* qemu\*

(2) Restart the libvirt daemon:

      $ sudo systemctl restart libvirtd

(3) Enumerate instances (assuming you already had a few instances
    defined before doing the package update):

      $ virsh list --all

    Nothing comes up.

    So, try to explicitly define a VM:

      $ virsh define devstack1.xml 


Actual results
--------------

Post libvirt/QEMU package update, the libvirt storage driver fails to
load, which results in the libvirt URI to changed to to "lxc:///" (while
we're expecting it to be "qemu:///system").  Which further leads to the 
two commands from step (3) in the previous section fail (as expected?)
-- no instances are listed, and explicit attempt to define a guest fails
with errors mentioned in the description.


Expected results
----------------

Libvirt storage driver should be loaded successfully.