Bug 1045861

Summary:	virt-manager always tries to deactivate VGs when delisting them.
Product:	[Community] Virtualization Tools	Reporter:	emailadhoc
Component:	virt-manager	Assignee:	Cole Robinson <crobinso>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acathrow, berrange, crobinso, gscrivan
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:	2014-02-01 15:56:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description emailadhoc 2013-12-22 16:15:29 UTC

Description of problem:

virt-manager, when trying to delist an lvm based storage pool, always tries to deactivate it first. Well, it doesn't really offer a way to delist VGs without "stopping" them.

This proves to be a problem when virt-manager/libvirtd is using a (shared) volume group with volumes in use in other applications, eg, mounted filesystems

In such cases, virt-manager fails to deactivate the volume group with active logical volumes, and doesn't offer any way to simply delist the storage pool.
One is forced to manually delete the pool specification in /etc/libvirt/storage/VolumeGroupName.xml to solve the problem.


How reproducible:
always, when the volume group is is not used exclusively for kvm and has active volumes.

Steps to Reproduce:
create a logical VolumeGroup.
create one or more LogicalVolumes, create a filesystem on them and mount it.
open virt-manager and add the previously created VolumeGroup as a logical storage pool.
now, try to delist it from available storage pools

Actual results:
virt-manager always tries to stop the whole VolumeGroup without checking for active and/or mounted logical volumes, and fails.
It doesn't provide any other mean to delist the storage pool.

Expected results:
virt-manager should first check if the logical volume group to be delisted has active or mounted logical volumes out of kvm scope/control.
furthermore, virt-manager should be able, in such a case, to simply delist the storage pool without deactivating it.

Comment 1 emailadhoc 2013-12-22 16:30:04 UTC

more specifically, it only supports calling virStoragePoolDestroy (pool-destroy in virsh), when in the case specified in the bug report, it would be useful to be able to fallback to virStoragePoolUndefine (pool-undefine in virsh)

Comment 2 Cole Robinson 2014-02-01 15:56:28 UTC

virt-manager does allow pool-undefine, it's the 'delete pool' option. the UI forces the pool to be shutoff in order to undefine it though. Reason is, if you undefine a pool while it is running, libvirt won't delist/forget about it until the pool is finally shutdown.

I agree that in the case of a shared volume group this setup is problematic, but it's just how libvirt works. If we allowed what you are suggesting, I'm sure we will get reports of 'hey I deleted my volume group, but it's still appearing in the UI'.

So from virt-manager's perspective we are being reasonable here. Closing as WONTFIX