Description of problem: virt-manager stalls for a minute or so after clicking on the "Browse" button (and then "Browse Local") of the "Use ISO Image" portion of VM creation. The following message appears in /var/log/messages: Nov 27 10:33:20 scott libvirtd[27857]: 2012-11-27 17:33:20.114+0000: 27857: warning : virKeepAliveTimerInternal:156 : No response from client 0x2376eb0 after 5 keepalive messages in 30 seconds When the file selector dialog finally appears and an iso file is selected, virt-manager has lost its connection and the install process fails. This may be specific to KDE as I haven't tried it in any other desktop environment yet. I will hopefully test this some additional systems and additional desktop environments. Version-Release number of selected component (if applicable): virt-manager-0.9.4-3.fc18 libvirt-0.10.2.1-3.fc18.x86_64 How reproducible: Try to create a VM on localhost and try to select an iso to install from (again from localhost as no remote storage is needed to trigger this) and it will time out and disconnect. Steps to Reproduce: 1. Start VM creation process 2. Attempt to pick an iso to install from 3. It will stall and get disconnected ending in creation failure. Actual results: Can't create a VM Expected results: I should be able to select an iso and create a VM. Additional info:
Just wanted to mention that I did do a number of updates since I originally noticed the bug... and have rebooted since... and the bug is still there... so it isn't the result of a transient system condition... caused by such things as package upgrades... or manual monkeying with services.
After some additional testing... yes it appears to be specific to KDE... or at least the problem is not observed in GNOME 3 Shell. Then I switched back to KDE and observed the bug again.
Strange, I can't reproduce on gnome or kde. Can you reproduce when running virt-manager --debug and attach the output here? Also, what's the output of: sudo virsh pool-list --all
Sorry. I'm out of town and won't be able to try it until after Xmas.
No problem Scott, I'll just set needinfo again, please unset when you reproduce. Thanks
Ok, made it back home... and got fully updated. I was still able to duplicate the problem. Then I tried it with the --debug flag... and with that enabled, the problem doesn't happen. Without the --debug flag, I still get the problem. I have no idea why that would be. Because there is no error with --debug, I didn't include the output. I'm make a short video showing I'm having the issue and that it goes away with --debug. Here's the output from virsh pool-list --all: [root@scott ~]# virsh pool-list --all Name State Autostart ----------------------------------------- default active yes
Here's a video showing that I have the problem without --debug but don't have it with --debug: http://www.montanalinux.org/files/newvideos/virt-manager-bug-880781.webm If you have a problem playing that in your browser, just wget it and play it with your preferred video player.
Thanks for the video Scott, it was helpful. I think I fixed this: http://git.fedorahosted.org/cgit/virt-manager.git/commit/?id=da71b2ec5c08707788d9caaf30318a191c5600f1 virt-manager by default forks off like a daemon. This is the only way to get ssh to launch an askpass dialog, which is important for remote server access. Unfortunately this causes issues with dbus related stuff from time to time. We were altering the default gtk icon_theme before forking which was the root 'cause'. My guess is that this causes some internal gtk dbus state to be initialized which is then no longer valid after the fork. If you make it so virt-manager doesn't drop stdio but still forks, you can see bunch of dbus timeouts go by. --debug wasn't reproducing this because --debug doesn't fork, so that we see the debug output on stdout. I always use debug hence why I wasn't seeing it.
*** Bug 901788 has been marked as a duplicate of this bug. ***
*** Bug 901938 has been marked as a duplicate of this bug. ***
Just to let you know the behavior is back. I thought you had fixed it... but I guess the bug has creeped back in.
It's fixed upstream, I still haven't pushed it to Fedora yet. I'd figured I'd have a new upstream release out by now but that hasn't happened yet...
Is there a testing build available? I'm getting somewhat frustrated with the inability to use KVM (the way I like to with virt-manager) on a KDE desktop. I certainly know you are busy and do a lot of work... but I'd appreciate any effort you can muster for an updated package.
virt-manager-0.9.5-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/virt-manager-0.9.5-1.fc18
Package virt-manager-0.9.5-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing virt-manager-0.9.5-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-4629/virt-manager-0.9.5-1.fc18 then log in and leave karma (feedback).
virt-manager-0.9.5-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.