Description of problem:
I like using virt-manager for work with my VMs, but it's really crazy in 2014 that it is so single-thread and almost every operation blocks its GUI. For example, when I connect to a remote libvirt host, the whole GUI freezes for a significant time. There's no reason for that.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. run virt-manager
2. connect to a remote host (over SSH in my case)
3. try to do something else in the GUI
GUI working and frozen only for the required moment when the TreeView is populated with the data from the new connection once it is established.
There are many other things that freeze the GUI. For example -- if connection to a remote host hangs up, my local VM view freezes for a significant time.
Let me know if you need any tips and help on how to make a Python+Gtk multi-thread application. Anaconda does it quite a lot and we have lot of experience and a bunch of tips&tricks.
Thanks for the report, but come on, you are making quite a few ignorant assumptions here without having actually looked at the code. I suspect you wouldn't like it if I made comments like 'really crazy in 2014' about _your_ code, even if my comments were as misinformed as yours are.
Much of virt-manager _does_ use threads, for long running libvirt operations like connection opening, connection polling, object starts/stop/pause/create/delete, and a few others.
There's a few potential things that could be causing the issues you are seeing, some fixable and some not so fixable, but I need some more info:
- What's the average ping time to the remote host?
- How many connections are already open when you experience the hangs on connection open?
- What is 'do something else in the GUI' exactly?
- Also, please try virt-manager.git, at least with the connection dropping bits there are some recent changes there which might improve things: git clone git://git.fedorahosted.org/virt-manager.git; cd virt-manager; ./virt-manager --debug, and post debug output
--debug output in general would be handy when reproducing the startup hang.
Also what distro is the remote libvirt host?
Sorry for the delay, I had some high-priority things to do. I'll attach a screencast showing the hang in a minute.
Created attachment 935372 [details]
a screencast showing the hang
In the video I've tried moving the selection on VMs via cursor keys, then double-clicked the connection in the GUI and continued moving the selection with cursor keys. When the selection movement stops the hang begings and lasts almost to the end when it starts moving again. The same hang happens to the whole VM's UI.
$ ping pracovnipc
PING pracovnipc (10.34.102.69) 56(84) bytes of data.
64 bytes from pracovnipc (10.34.102.69): icmp_seq=1 ttl=59 time=96.0 ms
64 bytes from pracovnipc (10.34.102.69): icmp_seq=2 ttl=59 time=91.6 ms
64 bytes from pracovnipc (10.34.102.69): icmp_seq=3 ttl=59 time=100 ms
64 bytes from pracovnipc (10.34.102.69): icmp_seq=4 ttl=59 time=93.5 ms
but I think that the ping time doesn't matter if the implementation is correct and multithread.
Thanks for the video, I reproduced the video on a high latency link ('tc' is pretty cool for testing that)
I added some debugging and indeed a bunch of slow stuff was slipping into the main thread, and we were making a lot of redundant and needlessly serialized libvirt API calls. Upstream is much better but they aren't something I want to risk backporting. Moving this to F21 where we will likely rebase virt-manager in the near future, and it will get these fixes.
However not all usage of libvirt APIs from the main thread has been removed, so some actions elsewhere in the UI do still stall for a moment. These are theoretically fixable but since nearly every action in the UI can map to even trivial UI calls, it basically requires making everything async which is a lot of work to get 100% coverage on. If you notice particularly bad instances with the new code please file additional bugs and we can evaluate them on a case by case basis.
(In reply to Cole Robinson from comment #5)
> Thanks for the video, I reproduced the video on a high latency link ('tc' is
> pretty cool for testing that)
> I added some debugging and indeed a bunch of slow stuff was slipping into
> the main thread, and we were making a lot of redundant and needlessly
> serialized libvirt API calls. Upstream is much better but they aren't
> something I want to risk backporting. Moving this to F21 where we will
> likely rebase virt-manager in the near future, and it will get these fixes.
Sounds good to me, thanks!
> However not all usage of libvirt APIs from the main thread has been removed,
> so some actions elsewhere in the UI do still stall for a moment. These are
> theoretically fixable but since nearly every action in the UI can map to
> even trivial UI calls, it basically requires making everything async which
> is a lot of work to get 100% coverage on. If you notice particularly bad
> instances with the new code please file additional bugs and we can evaluate
> them on a case by case basis.
I can promise I will file bugs on everything I'm able to identify as these kinds of issues as they make my life harder.
virt-manager-1.1.0-2.git30db9ece2.fc21 has been submitted as an update for Fedora 21.
virt-manager-1.1.0-3.git310f6527.fc21 has been submitted as an update for Fedora 21.
* should fix your issue,
* was pushed to the Fedora 21 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.1.0-3.git310f6527.fc21'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
virt-manager-1.1.0-3.git310f6527.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.