Bug 726897

Summary:	Storage volumes do not refresh correctly.
Product:	[Fedora] Fedora	Reporter:	Darryl L. Pierce <dpierce>
Component:	virt-manager	Assignee:	Cole Robinson <crobinso>
Status:	CLOSED DEFERRED	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	berrange, crobinso, hbrock, jforbes, tross, virt-maint
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-08-23 17:36:25 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Darryl L. Pierce 2011-07-30 12:30:52 UTC

Description of problem:

If storage volumes change from outside of the VMM app, it does not always notice the changes and update the list of volumes.


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

(mcpierce@mcpierce-laptop:~)$ rpm -q virt-manager
virt-manager-0.8.7-4.fc15.noarch


How reproducible:

100%


Steps to Reproduce:
1. Open VMM and navigate to the storage pools tab.
2. Select a storage pool.
3. In another app, such as VMMTUI, create a new volume for that storage pool
  

Actual results:

The new volume does not show up in VMM, even though it exists.


Expected results:

The new volume to be displayed in VMM.


Additional info:

If I select a different pool and then select the one affected the volume shows up.

Comment 1 Cole Robinson 2011-08-23 17:36:25 UTC

This is intentional. virt-manager's poll loop doesn't call 'refresh' because it is very slow for some storage pools. there is a manual refresh button in the storage pool window for this.

the correct solution here is that libvirt should grow storage lifecycle events, and anytime a volume is created or the pool is refreshed virt-manager would be signaled and update the UI. but since that work doesn't exist yet and there are libvirt RFEs tracking it I don't think it's worth carrying a virt-manager bug for it.