Bug 1072770 - can't do install with virt-manager-1.0.0-3.fc20: xmlParseDoc() failed
Summary: can't do install with virt-manager-1.0.0-3.fc20: xmlParseDoc() failed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-05 08:03 UTC by Jens Petersen
Modified: 2014-03-11 03:58 UTC (History)
4 users (show)

Fixed In Version: virt-manager-1.0.0-5.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-11 03:58:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
debug output with ~/Downloads/some\&file.ext (6.34 KB, application/x-bzip)
2014-03-10 05:05 UTC, Jens Petersen
no flags Details

Description Jens Petersen 2014-03-05 08:03:33 UTC
Description of problem:
I seem unable to install guests now after updating to latest virt-manager.

Version-Release number of selected component (if applicable):
virt-manager-1.0.0-3.fc20
libvirt-1.1.3.4-1.fc20

How reproducible:
100%

Steps to Reproduce:
1. try to do local or net install of guest in virt-manager 

Actual results:

Uncaught error validating install parameters: xmlParseDoc() failed

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 1397, in validate
    return self.validate_storage_page()
  File "/usr/share/virt-manager/virtManager/create.py", line 1638, in validate_storage_page
    if self.addstorage.validate_disk_object(ret) is False:
  File "/usr/share/virt-manager/virtManager/addstorage.py", line 360, in validate_disk_object
    names = disk.is_conflict_disk()
  File "/usr/share/virt-manager/virtinst/devicedisk.py", line 863, in is_conflict_disk
    read_only=self.read_only)
  File "/usr/share/virt-manager/virtinst/devicedisk.py", line 380, in path_in_use_by
    for vol in conn.fetch_all_vols() if vol.backing_store)
  File "/usr/share/virt-manager/virtinst/connection.py", line 237, in fetch_all_vols
    return self.cb_fetch_all_vols()  # pylint: disable=E1102
  File "/usr/share/virt-manager/virtManager/connection.py", line 181, in fetch_all_vols
    ret.append(vol.get_xmlobj(refresh_if_nec=False))
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 151, in get_xmlobj
    self._reparse_xml()
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 216, in _reparse_xml
    self._xmlobj = self._build_xmlobj(self._get_raw_xml())
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 219, in _build_xmlobj
    return self._parseclass(self.conn.get_backend(), parsexml=xml)
  File "/usr/share/virt-manager/virtinst/storage.py", line 535, in __init__
    _StorageObject.__init__(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtinst/xmlbuilder.py", line 770, in __init__
    parent_xpath, relative_object_xpath)
  File "/usr/share/virt-manager/virtinst/xmlbuilder.py", line 678, in __init__
    self._parse(parsexml, parsexmlnode)
  File "/usr/share/virt-manager/virtinst/xmlbuilder.py", line 689, in _parse
    doc = libxml2.parseDoc(xml)
  File "/usr/lib64/python2.7/site-packages/libxml2.py", line 1325, in parseDoc
    if ret is None:raise parserError('xmlParseDoc() failed')
parserError: xmlParseDoc() failed

Expected results:
no backtrace

Comment 1 Cole Robinson 2014-03-05 13:03:58 UTC
I'm guessing this is some other instance of this root libvirt bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1066564

Basically either a storage pool or storage volume is weirdly named and causes libvirt to generate invalid XML. Maybe this is more common than I thought and we should try to at least ignore the error in virt-manager.

Jens, can you do the following:

- git clone git://git.fedorahosted.org/virt-manager.git
- cd virt-manager
- ./virt-manager --debug
- reproduce the issue, post the debug output here

(upstream has some additional debugging that should tell us the culprit)

Comment 2 Cole Robinson 2014-03-06 17:09:44 UTC
Should be fixed upstream now with:

commit df7012a68b6a13a676e2019523f6863617a110d8
Author: Cole Robinson <crobinso>
Date:   Thu Mar 6 12:04:08 2014 -0500

    Handle libvirt generating invalid volume XML (bz 1072770)

Comment 3 Fedora Update System 2014-03-06 18:24:19 UTC
virt-manager-1.0.0-4.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/virt-manager-1.0.0-4.fc20

Comment 4 Jens Petersen 2014-03-07 09:47:24 UTC
virt-manager-1.0.0-4.fc20 may help but I can't select an iso
file (clicking Open just hangs) and net install seems to not
to show any console.

Comment 5 Cole Robinson 2014-03-07 14:33:13 UTC
Chosing the iso is likely also impacted by the root issue, but to work around it in virt-manager entirely is going to be really difficult. I'd recommend finding the bad XML that libvirt is generating (as requested in comment #1) and removing the associated storage volume. You don't need to pull virt-manager git though, just use the latest update.

The console issue sounds different, please check virt-manager --debug output and file a new bug if necessary

Comment 6 Fedora Update System 2014-03-07 15:05:19 UTC
virt-manager-1.0.0-5.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/virt-manager-1.0.0-5.fc20

Comment 7 Fedora Update System 2014-03-08 03:31:10 UTC
Package virt-manager-1.0.0-5.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing virt-manager-1.0.0-5.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-3581/virt-manager-1.0.0-5.fc20
then log in and leave karma (feedback).

Comment 8 Jens Petersen 2014-03-10 05:01:27 UTC
(In reply to Cole Robinson from comment #5)
> Chosing the iso is likely also impacted by the root issue, but to work
> around it in virt-manager entirely is going to be really difficult.

Seems to be caused by filenames containing '&' in "~/Downloads/".
I have had those files around for a long time though...

If I "rm ~/Downloads/*\&*" then it is possible to select an
iso file from the local fs, but it takes about 10s for the
filechooser dialog to appear.

> I'd recommend finding the bad XML that libvirt is generating (as requested in
> comment #1) and removing the associated storage volume. You don't need to
> pull virt-manager git though, just use the latest update.

Ok, I already pulled git.  To get debug output from the latest update
I still need a source tree, right?

Comment 9 Jens Petersen 2014-03-10 05:05:31 UTC
Created attachment 872575 [details]
debug output with ~/Downloads/some\&file.ext

Here is the debug output using the git tree.
Since it is over 1.7MB I compressed it.

Comment 10 Cole Robinson 2014-03-10 13:23:43 UTC
(In reply to Jens Petersen from comment #8)
> (In reply to Cole Robinson from comment #5)
> > Chosing the iso is likely also impacted by the root issue, but to work
> > around it in virt-manager entirely is going to be really difficult.
> 
> Seems to be caused by filenames containing '&' in "~/Downloads/".
> I have had those files around for a long time though...

Yeah virt-manager 1.0 acts differently here, it tries to create a storage pool for the containing directory of any media you point it at. This allows us to determine the image format among other things. But it's causing us to trip on this bug.

Having & in filenames is certainly far more common than the control code bug I linked to, and thankfully there's a libvirt patch for that issue. I've filed a separate bug to track it, will do an update shortly:

https://bugzilla.redhat.com/show_bug.cgi?id=1074528

Comment 11 Fedora Update System 2014-03-11 03:58:50 UTC
virt-manager-1.0.0-5.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.