Bug 1151800 - virt-manager: gui breaks on different operations with VNC/SPICE servers
Summary: virt-manager: gui breaks on different operations with VNC/SPICE servers
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: rawhide
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-10-11 23:51 UTC by Christoph Anton Mitterer
Modified: 2014-10-14 08:24 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-10-14 08:24:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screen.jpg (73.03 KB, image/jpeg)
2014-10-11 23:52 UTC, Christoph Anton Mitterer
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Debian BTS 764880 0 None None None Never

Description Christoph Anton Mitterer 2014-10-11 23:51:28 UTC
Hi.

From: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764880

Today I've stumbled over server issues when creatig
VNC/SPICE servers from within virt-manager.

1) It started with that I tried to change the type
of a Display Server hardware in a VM from VNC to
SPICE via the dropdown list.
Which makes a popup with the title:
Error changing VM configuration: unsupported configuration: unknown graphics device type '<gi.overrides.Gtk.TreeModelRow object at 0x7f16b0da6d50>'
And message:
Error changing VM configuration: unsupported configuration: unknown graphics device type '<gi.overrides.Gtk.TreeModelRow object at 0x7f16b0da6d50>'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/details.py", line 2310, in _change_config_helper
    self.vm.redefine_cached()
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 213, in redefine_cached
    self._redefine_xml(xml)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 238, in _redefine_xml
    return self._redefine_helper(origxml, newxml)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 230, in _redefine_helper
    self._define(newxml)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1012, in _define
    self.conn.define_domain(newxml)
  File "/usr/share/virt-manager/virtManager/connection.py", line 787, in define_domain
    return self._backend.defineXML(xml)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3442, in defineXML
    if ret is None:raise libvirtError('virDomainDefineXML() failed', conn=self)
libvirtError: unsupported configuration: unknown graphics device type '<gi.overrides.Gtk.TreeModelRow object at 0x7f16b0da6d50>'

Just deleting the "hardware" and readding it doesn't help either.


2) I assumed that maybe the format of the XMLs have changed
so I removed all VMs from /etc/libvirt/qemu and started from
scratch.

Now when I now create a VM, and select "configure before
installation".
And try to change (actually "set" it - since it's unset)
the Display Server type there, something even more creepy
happens, which you can see on the attached screenshot.

If I start completely over from scratch and do *not*
change the type of the Display Server during the "configure
before installation"... it actually creates the VM with a
SPICE server (the type is then set after installation o.O).


3) Now at that point when I try to configure the spice server
i.e. change Address from "Hypervisor default" to "Localhost
only" (which IMHO should be default for security reasons
aynway)
Something completely awkward happens:
The first time I try to set/apply it I get this error:
Error changing VM configuration: unsupported configuration: unknown graphics device type '<gi.overrides.Gtk.TreeModelRow object at 0x7f16b0d6ac10>'
Error changing VM configuration: unsupported configuration: unknown graphics device type '<gi.overrides.Gtk.TreeModelRow object at 0x7f16b0d6ac10>'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/details.py", line 2310, in _change_config_helper
    self.vm.redefine_cached()
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 213, in redefine_cached
    self._redefine_xml(xml)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 238, in _redefine_xml
    return self._redefine_helper(origxml, newxml)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 230, in _redefine_helper
    self._define(newxml)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1012, in _define
    self.conn.define_domain(newxml)
  File "/usr/share/virt-manager/virtManager/connection.py", line 787, in define_domain
    return self._backend.defineXML(xml)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3442, in defineXML
    if ret is None:raise libvirtError('virDomainDefineXML() failed', conn=self)
libvirtError: unsupported configuration: unknown graphics device type '<gi.overrides.Gtk.TreeModelRow object at 0x7f16b0d6ac10>'

When I then click to another part of the VM (other hardware)
and afterwards try it again, localhost+apply.
It gives no error, but the dropdown shows "Hypervisor default"
again.

When repeating that once more (i.e. going to some other hardware,
then back, then localhost+apply) it gets a popup:
Error changing VM configuration: xmlParseDoc() failed
Error changing VM configuration: xmlParseDoc() failed

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/details.py", line 2307, in _change_config_helper
    define_func(devobj, False, **define_args)
  File "/usr/share/virt-manager/virtManager/domain.py", line 811, in define_graphics
    return self._redefine_device(change, devobj, use_live_device)
  File "/usr/share/virt-manager/virtManager/domain.py", line 538, in _redefine_device
    dev = self._lookup_device_to_define(origdev)
  File "/usr/share/virt-manager/virtManager/domain.py", line 520, in _lookup_device_to_define
    guest = self._get_xmlobj_to_define()
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 223, in _get_xmlobj_to_define
    self._xmlobj_to_define = self.get_xmlobj(inactive=True)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 148, in get_xmlobj
    return self._build_xmlobj(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/guest.py", line 102, in __init__
    XMLBuilder.__init__(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtinst/xmlbuilder.py", line 777, in __init__
    parent_xpath, relative_object_xpath)
  File "/usr/share/virt-manager/virtinst/xmlbuilder.py", line 679, in __init__
    self._parse(parsexml, parsexmlnode)
  File "/usr/share/virt-manager/virtinst/xmlbuilder.py", line 692, in _parse
    doc = libxml2.parseDoc(xml)
  File "/usr/lib/python2.7/dist-packages/libxml2.py", line 1325, in parseDoc
    if ret is None:raise parserError('xmlParseDoc() failed')
parserError: xmlParseDoc() failed

Apply doesn't work then, I can only click cancel.
When I then restart virt-manager.
The whole VM is no longer shown (even though the XML is still there,
though corrupted I guess).




All this seems to be 100% reproducible every time,
but if you still like me to do the debug logs
(--debug --no-fork), just tell me.


Thanks,
Chris.

Comment 1 Christoph Anton Mitterer 2014-10-11 23:52:10 UTC
Created attachment 946069 [details]
screen.jpg

Comment 2 Cole Robinson 2014-10-13 15:15:33 UTC
That is an old bug which is fixed in the latest virt-manager release. I appreciate that you are trying to help and file bugs, but please do not open a bug against fedora unless you have actually confirmed it affects fedora.

Comment 3 Christoph Anton Mitterer 2014-10-13 15:19:44 UTC
Well I thought libvirt/virtmanager are RH products and even the website redirects me to bugzilla.redhat.com.

Comment 4 Cole Robinson 2014-10-14 08:24:59 UTC
(In reply to Christoph Anton Mitterer from comment #3)
> Well I thought libvirt/virtmanager are RH products and even the website
> redirects me to bugzilla.redhat.com.

The website explicitly points to bugzilla.redhat.com 'Virtualization Tools' product, which is for upstream virt bugs. product=Fedora is a distribution with potentially different code from upstream, and potentially different code from debian.


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