Bug 499703

Summary:	virt-manager should run stats refresh operation in a background thread per connection
Product:	[Fedora] Fedora	Reporter:	Daniel Berrangé <berrange>
Component:	virt-manager	Assignee:	Daniel Berrangé <berrange>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	berrange, crobinso, hbrock, markmc, virt-maint
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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 13:21:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	498969

Description Daniel Berrangé 2009-05-07 17:57:38 UTC

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 16:07:33 UTC

Fixed upstream:

http://hg.et.redhat.com/virt/applications/virt-manager--devel

Moving to POST.

Comment 2 Cole Robinson 2009-05-11 16:11:28 UTC

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 Berrangé 2009-05-11 16:18:28 UTC

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 16:23:18 UTC

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 Berrangé 2009-05-11 16:34:12 UTC

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-15 00:04:00 UTC

This is fixed upstream now. Moving to POST.

Comment 7 Mark McLoughlin 2009-08-07 13:21:04 UTC

Fix was in 0.8.0, closing

http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/7725e47b0623