Bug 435879

Created attachment 296711 [details]
screenshot of the last screen after which Forward doesn't work

Hmm, ideally it should be showing an error dialog if something is wrong. Can you
reproduce either running virt-manager --no-fork from the console and paste any
error messages, or post ~/.virt-manager/virt-manager.log here? Thanks.

Cole,
I'm getting few different tracebacks when running with --no-fork

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 114, in
_do_connection_changed
    for vmuuid in self.connections[hvuri]["windowDetails"].keys():
KeyError: 'xen:///'

^^^ after connecting to localhost (only the first time)


Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 181, in _do_show_create
    self.show_create(uri)
  File "/usr/share/virt-manager/virtManager/engine.py", line 319, in show_create
    self.connections[uri]["windowCreate"].show()
  File "/usr/share/virt-manager/virtManager/create.py", line 116, in show
    self.reset_state()
  File "/usr/share/virt-manager/virtManager/create.py", line 223, in reset_state
    if self.connection.get_type().lower() == "qemu":
AttributeError: 'NoneType' object has no attribute 'lower'

^^^ after choosing virtualization type (I think)

[root@ibm-x3250m2-02 ~]# Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 295, in forward
    if(self.validate(notebook.get_current_page()) != True):
  File "/usr/share/virt-manager/virtManager/create.py", line 915, in validate
    if self._disk.is_conflict_disk(self.connection.vmm) is True:
  File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 195, in
is_conflict_disk
    ids = conn.listDomainsID();
AttributeError: 'NoneType' object has no attribute 'listDomainsID'

^^^ after assigning storage and pressing Forward. In this case the default
filename was /root/test.img. After running virt-manager again the default file
is /var/lib/xen/images/test.img and I'm able to proceed to the next screen.

Created attachment 296869 [details]
virt-manager.log

After the second run I'm able to proceed and the guest install is initiated.
Pressing the shutdown button from the UI the guest shuts down and another
traceback is printed on the console:

libvir: Xen Daemon error : failed Xen syscall xenDaemonDomainDumpXMLByID failed
to find this domain 128185408
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/console.py", line 391, in retry_login
    self.try_login()
  File "/usr/share/virt-manager/virtManager/console.py", line 436, in try_login
    protocol, host, port, trans = self.vm.get_graphics_console()
  File "/usr/share/virt-manager/virtManager/domain.py", line 452, in
get_graphics_console
    type = self.get_xml_string("/domain/devices/graphics/@type")
  File "/usr/share/virt-manager/virtManager/domain.py", line 421, in get_xml_string
    xml = self.get_xml()
  File "/usr/share/virt-manager/virtManager/domain.py", line 53, in get_xml
    self.xml = self.vm.XMLDesc(0)
  File "/usr/lib64/python2.4/site-packages/libvirt.py", line 196, in XMLDesc
    if ret is None: raise libvirtError ('virDomainGetXMLDesc() failed', dom=self)
libvirt.libvirtError: virDomainGetXMLDesc() failed failed Xen syscall
xenDaemonDomainDumpXMLByID failed to find this domain 128185408

The second issue seems seperate: if you can easily reproduce it please post a
seperate bug.

That first issue has plagued me for months. The funny thing is it will usually
only hit the first time you run virt-manager, and never again. I managed to
track it down, patch posted shortly.

Created attachment 296950 [details]
Fix ui unresponsiveness when running virt-manager for the first time

Updated bug description to more accurately reflect problem.

To reproduce the problem:
Run virt-manager, delete all visible connections, close virt-manager
Run 'virt-manager --no-fork' from the console
Connect to the auto-populated xen connection
See exceptions on the console.

Yep, the first time you run, if no stored connections are present it will try to
populate a default connection - with incorrect 'xen' instead of 'xen:///'. The
patch you added in comment #7 makes total sense.

Filed the second traceback as bug #436320 after applying your patch.
UI seems ot be responsible now.

dev acking for Cole.

Fixed in:

* Thu Mar  6 2008 Daniel P. Berrange <berrange> - 0.5.3-4.el5
- Fix default Xen hypervisor URI (rhbz #435879)

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0480.html