Bug 1123266 - virt-manager hangs on initial ssh connection (and other hangs)
Summary: virt-manager hangs on initial ssh connection (and other hangs)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 21
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-07-25 08:01 UTC by Vratislav Podzimek
Modified: 2014-09-29 03:54 UTC (History)
5 users (show)

Fixed In Version: virt-manager-1.1.0-3.git310f6527.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-29 03:54:14 UTC


Attachments (Terms of Use)
a screencast showing the hang (779.58 KB, application/octet-stream)
2014-09-08 14:39 UTC, Vratislav Podzimek
no flags Details

Description Vratislav Podzimek 2014-07-25 08:01:00 UTC
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):
virt-manager-1.0.1-3.fc20.noarch

How reproducible:
100%

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

Actual results:
GUI frozen

Expected results:
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.

Additional info:
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.

Comment 1 Cole Robinson 2014-07-25 18:34:38 UTC
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

Comment 2 Cole Robinson 2014-07-25 18:49:33 UTC
--debug output in general would be handy when reproducing the startup hang.
Also what distro is the remote libvirt host?

Comment 3 Vratislav Podzimek 2014-09-08 14:35:54 UTC
Sorry for the delay, I had some high-priority things to do. I'll attach a screencast showing the hang in a minute.

Comment 4 Vratislav Podzimek 2014-09-08 14:39:51 UTC
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.

Additional info:
$ 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.

Comment 5 Cole Robinson 2014-09-15 14:01:27 UTC
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.

Comment 6 Vratislav Podzimek 2014-09-16 07:18:00 UTC
(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.

Comment 7 Fedora Update System 2014-09-22 22:10:06 UTC
virt-manager-1.1.0-2.git30db9ece2.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/virt-manager-1.1.0-2.git30db9ece2.fc21

Comment 8 Fedora Update System 2014-09-23 23:03:07 UTC
virt-manager-1.1.0-3.git310f6527.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/virt-manager-1.1.0-3.git310f6527.fc21

Comment 9 Fedora Update System 2014-09-24 18:26:33 UTC
Package virt-manager-1.1.0-3.git310f6527.fc21:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2014-11291/virt-manager-1.1.0-3.git310f6527.fc21
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2014-09-29 03:54:14 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.