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:
Fixed upstream: http://hg.et.redhat.com/virt/applications/virt-manager--devel Moving to POST.
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.
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
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?)
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.
This is fixed upstream now. Moving to POST.
Fix was in 0.8.0, closing http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/7725e47b0623