Red Hat Bugzilla – Full Text Bug Listing
|Summary:||virt-manager should run stats refresh operation in a background thread per connection|
|Product:||[Fedora] Fedora||Reporter:||Daniel Berrange <berrange>|
|Component:||virt-manager||Assignee:||Daniel Berrange <berrange>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||berrange, crobinso, hbrock, markmc, virt-maint|
|Fixed In Version:||virt-manager-0.8.0-1.fc12||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-08-07 09:21:04 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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): 0.7.0 How reproducible: Always for machines on slow link Steps to Reproduce: 1. Connect to remote machine over slow link 2. 3. Actual results: UI periodically freezes Expected results: Additional info:
Comment 1 Cole Robinson 2009-05-11 12:07:33 EDT
Fixed upstream: http://hg.et.redhat.com/virt/applications/virt-manager--devel 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 http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/7725e47b0623