Hide Forgot
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.
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)
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