Bug 1097067

Created attachment 894996 [details]
Virtual machine dump

xml dump of virtual machine

Looks like this is related to:
https://bugzilla.redhat.com/show_bug.cgi?id=978719

(In reply to Robin Hack from comment #2)
> Looks like this is related to:
> https://bugzilla.redhat.com/show_bug.cgi?id=978719
Ignore this comment please. Wrong bug.

Can you provide the --debug output when reproducing with latest upstream?

git clone git://git.fedorahosted.org/virt-manager.git
cd virt-manager
./virt-manager --debug

Created attachment 898572 [details]
Clone log

Hi. Sorry for delay.

This is debugoutput from my fedora 20 (virt-manager-1.0.1-3.fc20.noarch)

Hi Cole.

I'm not able to gain debug output with upstream virt-manager.

This is what I got on my fedora 20 box:
[nobody@bigoook virt-manager]$ ./virt-manager 
ERROR:root:Could not find any typelib for Libosinfo
Can't open '/usr/share/abrt/conf.d/plugins/python3.conf': No such file or directory
Can't open '/etc/abrt/plugins/python3.conf': No such file or directory
Traceback (most recent call last):
  File "./virt-manager", line 32, in <module>
    from virtinst import util as util
  File "/home/rhack/src/virt-manager/virtinst/__init__.py", line 69, in <module>
    from virtinst.distroinstaller import DistroInstaller
  File "/home/rhack/src/virt-manager/virtinst/distroinstaller.py", line 32, in <module>
    from virtinst import urlfetcher
  File "/home/rhack/src/virt-manager/virtinst/urlfetcher.py", line 35, in <module>
    from virtinst import osdict
  File "/home/rhack/src/virt-manager/virtinst/osdict.py", line 25, in <module>
    from gi.repository import Libosinfo as libosinfo
ImportError: cannot import name Libosinfo

it looks you are missing libosinfo on your system.

Created attachment 898593 [details]
Upstream Clone Log file

(In reply to Giuseppe Scrivano from comment #7)
> it looks you are missing libosinfo on your system.
Thanks! It helps.

Log is attached.

What's the output of:

sudo virsh vol-dumpxml /var/lib/libvirt/images/rhel7.img

Hi Cole.

Output is:
[root@bigoook rhack]# virsh --debug 4 vol-dumpxml /var/lib/libvirt/images/rhel7.img
error: An error occurred, but the cause is unknown

Okay, that's the root issue. But not sure why it's failing.

Does restarting libvirtd fix the vol-dumpxml ?
If not, can you try running libvirtd by hand (sudo libvirtd) and see if it prints any interesting message when vol-dumpxml fails?

I started libvirtd by hand.

[root@bigoook rhack]# libvirtd  -v
2014-06-03 06:09:11.620+0000: 20776: info : libvirt version: 1.1.3.5, package: 2.fc20 (Fedora Project, 2014-05-19-22:55:50, buildvm-04.phx2.fedoraproject.org)
2014-06-03 06:09:11.620+0000: 20776: error : virFileReadAll:1284 : Failed to open file '/proc/xen/capabilities': No such file or directory
2014-06-03 06:09:12.064+0000: 20776: error : virStorageBackendFileSystemRefresh:888 : internal error: cannot probe backing volume info: /home/rhack/vms

Now I call voldump:
[root@bigoook rhack]# virsh --debug 4 vol-dumpxml /var/lib/libvirt/images/rhel7.img 
error: An error occurred, but the cause is unknown

Back to libvirtd terminal:
Nothing

But.. this looks interesting:
2014-06-03 06:09:12.064+0000: 20776: error : virStorageBackendFileSystemRefresh:888 : internal error: cannot probe backing volume info: /home/rhack/vms

Can you show:

qemu-img info /var/lib/libvirt/images/rhel7.img

(In reply to Cole Robinson from comment #13)
> Can you show:
> 
> qemu-img info /var/lib/libvirt/images/rhel7.img

# qemu-img info /var/lib/libvirt/images/rhel7.img
image: /var/lib/libvirt/images/rhel7.img
file format: qcow2
virtual size: 35G (37580963840 bytes)
disk size: 196K
cluster_size: 65536
backing file: /home/rhack/vms/
backing file format: raw

And here is same for machine which I want clone:
# qemu-img info /home/rhack/vms/fedora-devel.img 
image: /home/rhack/vms/fedora-devel.img
file format: qcow2
virtual size: 27G (29359079424 bytes)
disk size: 24G
cluster_size: 65536
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         stable systemtap devel enviroment   971M 2014-03-06 14:54:58   09:17:05.214
2         after upgrade          958M 2014-05-16 15:49:06   04:21:35.088

    if (!(mode & flags)) {
        VIR_FORCE_CLOSE(fd);
        VIR_INFO("Skipping volume '%s'", path);

        if (mode & VIR_STORAGE_VOL_OPEN_ERROR) {

This condition should report the error, but it can never be true (it should have been flags & VIR_STORAGE_VOL_OPEN_ERROR)

            virReportError(VIR_ERR_INTERNAL_ERROR,
                           _("unexpected storage mode for '%s'"), path);
            return -1;
        }

        return -2;
    }

It has been fixed upstream by
commit 138e65c3bea86fd5f51d9133bdcd0b36bff143b7
Author:     Cole Robinson <crobinso>
CommitDate: 2014-04-02 12:44:16 -0400

    storage: Report error from VolOpen by default

*** Bug 1117210 has been marked as a duplicate of this bug. ***

*** Bug 1050891 has been marked as a duplicate of this bug. ***

libvirt-1.1.3.6-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/FEDORA-2014-10432/libvirt-1.1.3.6-1.fc20

libvirt-1.1.3.6-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.