There are cases, such as deleting volumes, where engine deletes a volume from the database, VDSM marks the volume for deletion, but the deletion fails. For now, to locate half deleted or half created volumes on storage, we can use: lvs -o vg_name,lv_name,tags | grep '(OVIRT_VOL_INITIALIZING|_remove_me_)' You can find these tags: - OVIRT_VOL_INITIALIZING - volume creation was interrupted. - _remove_me_<image-uuid> - volume of disk disk-uuid marked for deletion - _remove_me_ZERO_<image-uuid> - volume of disk disk-uuid marked for zeroing and deletion <image-uuid> is the vdsm term for disk-uuid in engine UI. The tags are implementation details we should not depend on normally, but since they are part of the storage format, they are unlikely to change. Ideally we should have a fsck-like tool that locate such volumes and delete them.
(In reply to Greg Scott from comment #0) > You can find these tags: > - OVIRT_VOL_INITIALIZING - volume creation was interrupted. > - _remove_me_<image-uuid> - volume of disk disk-uuid marked for deletion > - _remove_me_ZERO_<image-uuid> - volume of disk disk-uuid marked for > zeroing and deletion There are other cases where you may end up with orphan volumes and they dont actually have these tags. This RFE should be covered by BZ1489145, we plan to cross DB and SD information and shout out loud on any differences.
I am closing this bug as a duplicate of bz#1489145. *** This bug has been marked as a duplicate of bug 1489145 ***