Bug 499703 - virt-manager should run stats refresh operation in a background thread per connection
virt-manager should run stats refresh operation in a background thread per co...
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
Depends On:
Blocks: F12VirtTarget
  Show dependency treegraph
Reported: 2009-05-07 13:57 EDT by Daniel Berrange
Modified: 2009-08-07 09:21 EDT (History)
5 users (show)

See Also:
Fixed In Version: virt-manager-0.8.0-1.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-08-07 09:21:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2009-05-07 13:57:38 EDT
Description of problem:
When managing remote libvirt connections over a slow link (eg a 2000 mile VPN link :-), virt-manager can get quite slow and periodically hang, even if a low -refresh rate is set.

This is because we currently do the periodic polling in a timer event from the main GTK event loop.

libvirt recently became fully thread safe, so we could trivally spawn 1 background thread per connection, and do all the stats refreshes there, ensuring the main UI never gets blocked. We wouldn't need to open duplicate connection objects for this anymore - just have everything reuse one object

Version-Release number of selected component (if applicable):

How reproducible:
Always for machines on slow link

Steps to Reproduce:
1. Connect to remote machine over slow link
Actual results:
UI periodically freezes

Expected results:

Additional info:
Comment 1 Cole Robinson 2009-05-11 12:07:33 EDT
Fixed upstream:


Moving to POST.
Comment 2 Cole Robinson 2009-05-11 12:11:28 EDT
Sigh, wrong bug, AND useless link. Moving back to ASSIGNED.

Danpb, so we no longer need to duplicate connections to do async work? That is pretty handy, I didn't realize that was one of the perks of making libvirtd thread safe.
Comment 3 Daniel Berrange 2009-05-11 12:18:28 EDT
Yeah, just make sure you have a mandatory dep on libvirt >= 0.6.0 and you will only ever need a single virConnectPtr instance per host - get rid of those duplicates we used to create for background thread.s
Comment 4 Cole Robinson 2009-05-11 12:23:18 EDT
Does this affect connecting to older libvirtd instances, or is this relevant for the host version only?

The nice thing is that I centralized all the duplication recently, so it would be pretty easy to fall back to the old dup behavior if the libvirt version isn't sufficiently new (though is that detectable for a remote host?)
Comment 5 Daniel Berrange 2009-05-11 12:34:12 EDT
There's two things here

 - We created a duplicate virConnectPtr instance because the client end was not thread safe. This can now go if we mandate a new enough client install
 - We created a background thread to stop long operations blocking the UI

The latter didn't actually really help us because

 - libvirtd itself is 100% single threaded, so the stats refresh would still get blocked by the long operations in the background thread, blocking the whole UI
 - even if no long operation was taking place, the latency on slow links effectively blocked the whole UI

Moving all the stats refresh code to background threads will ensure the UI is never blocked for both old and new libvirtd. The duplicate connection instances can be removed regardless.
Comment 6 Cole Robinson 2009-07-14 20:04:00 EDT
This is fixed upstream now. Moving to POST.
Comment 7 Mark McLoughlin 2009-08-07 09:21:04 EDT
Fix was in 0.8.0, closing


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