Bug 499703

Summary: virt-manager should run stats refresh operation in a background thread per connection
Product: [Fedora] Fedora Reporter: Daniel Berrange <berrange>
Component: virt-managerAssignee: Daniel Berrange <berrange>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: berrange, crobinso, hbrock, markmc, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: virt-manager-0.8.0-1.fc12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-08-07 09:21:04 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 498969    

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