Bug 1074120 - virt-manager doesn't catch errors when checking version at connection startup
Summary: virt-manager doesn't catch errors when checking version at connection startup
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-08 01:52 UTC by Sandro Mathys
Modified: 2014-09-19 10:13 UTC (History)
6 users (show)

Fixed In Version: virt-manager-1.0.1-4.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-19 10:13:20 UTC


Attachments (Terms of Use)

Description Sandro Mathys 2014-03-08 01:52:45 UTC
Description of problem:
Connected to localhost (QEMU), I try to create a new VM. But when I try and click on "New", I get the error as seen in the summary.

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

How reproducible:
Always (on the same system, at least)

Steps to Reproduce:
1. run virt-manager
2. connect to localhost (QEMU)
3. Try to create a new VM

Actual results:
Error launching manager: 'NoneType' object has no attribute 'get_default_storage_format'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 886, in _do_show_create
    self._get_create_dialog().show(src.topwin, uri)
  File "/usr/share/virt-manager/virtManager/create.py", line 170, in show
    self.reset_state(uri)
  File "/usr/share/virt-manager/virtManager/create.py", line 389, in reset_state
    self.addstorage.reset_state()
  File "/usr/share/virt-manager/virtManager/addstorage.py", line 195, in reset_state
    fmt = self.conn.get_default_storage_format()
AttributeError: 'NoneType' object has no attribute 'get_default_storage_format'

Expected results:
Some dialog to set up a new VM on localhost

Additional info:
Started out with F20 + stable updates, since tried updating (the whole system) to updates-testing. No change. Also tried setting a default storage format in the settings (hoping it would not need to call the failing code) but that didn't change anything either.

Comment 1 Cole Robinson 2014-03-08 13:09:56 UTC
Strange... haven't seen other reports of that, I can't reproduce, and I can't really tell from the code how that's happening.

Can you reproduce with virt-manager --debug and provide the output?
And can you provide step by step reproducer instructions, starting from a completely shutoff app. Like, how you open the connection, how you launch the new vm wizard. (or provide a screencast, ctrl+alt+shift+r if using gnome-shell)

Comment 2 Sandro Mathys 2014-03-08 13:41:22 UTC
Well, I fixed the issue for me. I still think this AttributeError must be caught, but I don't get it anymore.

So what I did since reporting this bug was:
- Connect to Localhost (LXC)
- Open the Create VM dialog on the LXC connection
- Change the connection in the dialog to Localhost (Qemu)
- Notice it shows a warning that kvm/qemu is borked
- Install qemu-kvm and libvirt-driver-{qemu,kvm}

After that, the issue was gone.

But if I'd need to reproduce this issue, I'd do:
- Install F20 from DVD, choosing the KDE Desktop and no additional package groups
- Install virt-manager (and make sure qemu-kvm and libvirt-driver-* are missing)
- Start virt-manager and connect to localhost (Qemu)
- Try to create a new VM (either clicking the button in the tool bar or through the right-click menu)

...but it's probably enough to just make sure qemu-kvm and libvirt-driver-* are missing. That should probably trigger the issue.

Comment 3 Cole Robinson 2014-03-10 13:08:39 UTC
(In reply to Sandro Mathys from comment #2)
> Well, I fixed the issue for me. I still think this AttributeError must be
> caught
> 

We should only catch an exception if it's something that we should expect to happenn. In this case, there should always either be a connection available, or we raise an error long before we get to the code that caused the AttributeError. So either something really weird happened, or its just a plain old bug to be fixed.

Any chance you had virt-manager running while yum update ran? If virt-manager was overwritten in place, then the new VM wizard was launched for the first time, weird things might have happened. We've had similar reports in the past.

Either way, as mentioned in my first comment, I can't understand how we hit that error from inspecting the current code. I can't reproduce after removing qemu + libvirt either, or deleting all connections, and a few other permutations. So closing this as WORKSFORME. But if you reproduce again, please reopen and we can continue from there.

Comment 4 Pablo Iranzo Gómez 2014-07-10 09:03:40 UTC
Debug output of F20 with all updates:

[root@kvmhost ~]# virt-manager --debug
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (cli:187) Launched with command line: /usr/share/virt-manager/virt-manager --debug
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (virt-manager:150) virt-manager version: 1.0.1
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (virt-manager:151) virtManager import: <module 'virtManager' from '/usr/share/virt-manager/virtManager/__init__.pyc'>

** (virt-manager:20348): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-7fcUmH0qCn: Conexión rehusada
Gtk-Message: Failed to load module "pk-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (virt-manager:209) GTK version: 3.10.9
[jue, 10 jul 2014 10:58:03 virt-manager 20348] ERROR (importer:51) Could not find any typelib for AppIndicator3
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (engine:457) libguestfs inspection support: False
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (systray:152) Showing systray: False
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (engine:231) About to connect to uris ['qemu:///session']
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (manager:216) Showing manager
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (engine:358) window counter incremented to 1
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (connection:1031) Scheduling background open thread for qemu:///session
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (connection:1048) Background 'open connection' thread is running
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (connection:1099) Background open thread complete, scheduling notify
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (connection:1104) Notifying open result
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (connection:1110) libvirt version=1001003
[jue, 10 jul 2014 10:58:03 virt-manager 20348] DEBUG (connection:1112) daemon version=1001003
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/baseclass.py", line 46, in cb
    return func(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/connection.py", line 1113, in _open_notify
    logging.debug("conn version=%s", self._backend.conn_version())
  File "/usr/share/virt-manager/virtinst/connection.py", line 290, in conn_version
    self._conn_version = self._libvirtconn.getVersion()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3676, in getVersion
    if ret == -1: raise libvirtError ('virConnectGetVersion() failed', conn=self)
libvirtError: Error interno: No se pudo encontrar emulador para x86_64

[jue, 10 jul 2014 10:58:06 virt-manager 20348] DEBUG (connection:218) Using libvirt API for netdev enumeration
[jue, 10 jul 2014 10:58:06 virt-manager 20348] DEBUG (connection:240) Using libvirt API for mediadev enumeration
[jue, 10 jul 2014 10:58:13 virt-manager 20348] DEBUG (create:167) Showing new vm wizard
[jue, 10 jul 2014 10:58:13 virt-manager 20348] ERROR (addstorage:100) Error determining host disk space
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/addstorage.py", line 98, in _update_host_space
    max_storage = self._host_disk_space()
  File "/usr/share/virt-manager/virtManager/addstorage.py", line 78, in _host_disk_space
    pool = self.conn.get_default_pool()
AttributeError: 'NoneType' object has no attribute 'get_default_pool'
[jue, 10 jul 2014 10:58:13 virt-manager 20348] DEBUG (error:82) error dialog message:
summary=Error al lanzar gestor: 'NoneType' object has no attribute 'get_default_storage_format'
details=Error al lanzar gestor: 'NoneType' object has no attribute 'get_default_storage_format'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 859, in _do_show_create
    self._get_create_dialog().show(src.topwin, uri)
  File "/usr/share/virt-manager/virtManager/create.py", line 170, in show
    self.reset_state(uri)
  File "/usr/share/virt-manager/virtManager/create.py", line 388, in reset_state
    self.addstorage.reset_state()
  File "/usr/share/virt-manager/virtManager/addstorage.py", line 196, in reset_state
    fmt = self.conn.get_default_storage_format()
AttributeError: 'NoneType' object has no attribute 'get_default_storage_format'



After installing "qemu-kvm" and restarting libvirtd service, the error no longer appears.

Regards,
Pablo

Comment 5 Cole Robinson 2014-07-18 14:38:10 UTC
Thanks Pablo, I can reproduce that issue with the scenario you provide

Comment 6 Cole Robinson 2014-07-18 14:56:56 UTC
The libvirt error that triggers the virt-manager issues is this pre-existing bug:

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

However upstream virt-manager correctly catches this error and shows it to the user, and cancels the connection opening rather than have it fail later in weird ways.

commit e12d7a6a8c21f0d8e0331fa06f53523258bdfaae
Author: Cole Robinson <crobinso@redhat.com>
Date:   Fri Jul 4 17:37:42 2014 -0400

    connection: Report error if things fall over during connection bring up

Comment 7 Fedora Update System 2014-09-08 15:29:53 UTC
virt-manager-1.0.1-4.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/virt-manager-1.0.1-4.fc20

Comment 8 Fedora Update System 2014-09-09 22:06:06 UTC
Package virt-manager-1.0.1-4.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.1-4.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-10332/virt-manager-1.0.1-4.fc20
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2014-09-19 10:13:20 UTC
virt-manager-1.0.1-4.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.