Bug 1097067 - vol-dumpxml fails: An error occurred, but the cause is unknown
Summary: vol-dumpxml fails: An error occurred, but the cause is unknown
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1050891 1117210 (view as bug list)
Depends On:
Blocks: 1064285
TreeView+ depends on / blocked
 
Reported: 2014-05-13 06:11 UTC by Robin Hack
Modified: 2014-09-19 10:14 UTC (History)
13 users (show)

Fixed In Version: libvirt-1.1.3.6-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-19 10:14:07 UTC


Attachments (Terms of Use)
virt-manager --dump (16.80 KB, text/x-log)
2014-05-13 06:11 UTC, Robin Hack
no flags Details
Virtual machine dump (4.55 KB, text/xml)
2014-05-13 06:12 UTC, Robin Hack
no flags Details
Clone log (26.92 KB, text/x-log)
2014-05-23 08:00 UTC, Robin Hack
no flags Details
Upstream Clone Log file (30.48 KB, text/x-log)
2014-05-23 08:56 UTC, Robin Hack
no flags Details

Description Robin Hack 2014-05-13 06:11:14 UTC
Created attachment 894995 [details]
virt-manager --dump

Description of problem:
Hi.

I'm not able to clone my machine when virt-manager is used.

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


How reproducible:
Always for me.

Steps to Reproduce:
1. I have old VM installed.
2. Try to clone machine via virt manager
3.

Actual results:
Error window with:
Error setting clone parameters: An error occurred, but the cause is unknown
Error setting clone parameters: An error occurred, but the cause is unknown

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 888, in _do_show_clone
    clone_window.show(src.topwin)
  File "/usr/share/virt-manager/virtManager/clone.py", line 173, in show
    self.reset_state()
  File "/usr/share/virt-manager/virtManager/clone.py", line 243, in reset_state
    self.storage_list, self.target_list = self.check_all_storage()
  File "/usr/share/virt-manager/virtManager/clone.py", line 374, in check_all_storage
    vol = self.conn.get_vol_by_path(path)
  File "/usr/share/virt-manager/virtManager/connection.py", line 757, in get_vol_by_path
    if vol.get_target_path() == path:
  File "/usr/share/virt-manager/virtManager/storagepool.py", line 68, in get_target_path
    return self.get_xmlobj().target_path or ""
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 141, in get_xmlobj
    xml = self._get_raw_xml(inactive, refresh_if_nec)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 197, in _get_raw_xml
    self.refresh_xml()
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 160, in refresh_xml
    self._xml = self._XMLDesc(self._active_xml_flags)
  File "/usr/share/virt-manager/virtManager/storagepool.py", line 44, in _XMLDesc
    return self._backend.XMLDesc(flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2697, in XMLDesc
    if ret is None: raise libvirtError ('virStorageVolGetXMLDesc() failed', vol=self)
libvirtError: An error occurred, but the cause is unknown

Expected results:
Clonet machine

Additional info:
I ran virt-manager with --debug option. Please look at attached log file.
Another attachment is dump of virtual machine.

Have nice day.

Comment 1 Robin Hack 2014-05-13 06:12:20 UTC
Created attachment 894996 [details]
Virtual machine dump

xml dump of virtual machine

Comment 2 Robin Hack 2014-05-19 12:51:38 UTC
Looks like this is related to:
https://bugzilla.redhat.com/show_bug.cgi?id=978719

Comment 3 Robin Hack 2014-05-19 12:52:17 UTC
(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.

Comment 4 Cole Robinson 2014-05-19 21:33:45 UTC
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

Comment 5 Robin Hack 2014-05-23 08:00:35 UTC
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)

Comment 6 Robin Hack 2014-05-23 08:06:27 UTC
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

Comment 7 Giuseppe Scrivano 2014-05-23 08:48:49 UTC
it looks you are missing libosinfo on your system.

Comment 8 Robin Hack 2014-05-23 08:56:27 UTC
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.

Comment 9 Cole Robinson 2014-05-31 16:18:10 UTC
What's the output of:

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

Comment 10 Robin Hack 2014-06-02 06:57:43 UTC
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

Comment 11 Cole Robinson 2014-06-02 14:18:27 UTC
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?

Comment 12 Robin Hack 2014-06-03 06:11:07 UTC
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

Comment 13 Cole Robinson 2014-06-03 12:57:10 UTC
Can you show:

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

Comment 14 Robin Hack 2014-06-04 06:59:21 UTC
(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

Comment 15 Ján Tomko 2014-06-04 08:07:39 UTC
    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@redhat.com>
CommitDate: 2014-04-02 12:44:16 -0400

    storage: Report error from VolOpen by default

Comment 16 Cole Robinson 2014-07-08 17:26:07 UTC
*** Bug 1117210 has been marked as a duplicate of this bug. ***

Comment 17 Cole Robinson 2014-09-09 13:05:43 UTC
*** Bug 1050891 has been marked as a duplicate of this bug. ***

Comment 18 Fedora Update System 2014-09-14 19:00:43 UTC
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

Comment 19 Fedora Update System 2014-09-19 10:14:07 UTC
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.


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