When deleting a volume which is migrated from another backend to LVM, it fails, and cinder-volume.log shows the backend logical volume is in use, as following:

TRACE oslo.messaging.rpc.dispatcher Stderr: u'File descriptor 7 (/dev/urandom) leaked on lvremove invocation. Parent PID 27071: /usr/bin/python2\n Logical volume cinder-volumes/volume-a7c7ef18-e52f-4149-b610-8a3f1c3751b1 in use.\n'

Using dmsetup and lvs, it is clear that the logical volume is open.

# dmsetup info cinder--volumes-volume--a7c7ef18--e52f--4149--b610--8a3f1c3751b1
Name:              cinder--volumes-volume--a7c7ef18--e52f--4149--b610--8a3f1c3751b1
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 8
Number of targets: 1

While, there is no open trace by lsof, so I don't know which process opened the logical volume. Other way to change the open attribute of logical volume is not found yet.

lvchange -an <given lv=""> didn't work. Neither did deleting symlinks to the /dev/dm-* devices. Any information from you is appreciated.

Following are some additional information for reference. Migrating from another backend to LVM backend, the volume is available now, shown as below

90b457db-fc41-412a-a9d2-aef64ac65133 |   available    | cyl-fs

os-vol-mig-status-attr:Name_id shows another id after migration

|     os-vol-mig-status-attr:name_id    | a7c7ef18-e52f-4149-b610-8a3f1c3751b1 |

Information about the backend logical volume by lvs

# lvs | grep a7c7e
  volume-a7c7ef18-e52f-4149-b610-8a3f1c3751b1    cinder-volumes -wi-ao---- 500.00g

Last and not least, not all volumes migrated from another backend to LVM are of such status, among 5 migrated volumes, one volume can be deleted, as its backend logical volume's attributes are -wi-a-----(no open count).