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.
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)
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.
(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.
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
Thanks Pablo, I can reproduce that issue with the scenario you provide
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> Date: Fri Jul 4 17:37:42 2014 -0400 connection: Report error if things fall over during connection bring up
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
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).
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.