lvm2 currently cannot support the online lvrename with VDOPOOL type volumes. The reason seems to be VDO's target DM table line uses the name of the device as one of its parameters on table line. For this reason lvm2 currently disabled online lvrename with this upstream patch: https://www.redhat.com/archives/lvm-devel/2020-September/msg00143.html If this patch is reverted the online lvrename causes this kernel errors: kvdo102:lvm: Existing layer named vpool1 already uses device /dev/dm-1 kvdo102:lvm: Could not create kernel physical layer. (VDO error 2053, message Cannot share storage device with already-running VDO) kvdo102:lvm: mapToSystemError: mapping internal status code 2053 (kvdo: VDO_BAD_CONFIGURATION: kvdo: Bad configuration option) to EIO device-mapper: table: 253:2: vdo: Cannot share storage device with already-running VDO device-mapper: ioctl: error adding target to table kernel: 5.9.0-0.rc5.20200916gitfc4f28bb3daf.12.fc34.x86_64 kmod-kvdo-6.2.3.114-2.fc34.x86_64
Updates: lvm2 could eventually pass a 'stable' name isntead of LV name that can be renamed - it could be i.e. "#major:#minor" "dm-#minor" or "UUID" (these cannot be changed while device is active/online) but than tools like 'vdostats' stops working: i.e.: # vdostats Error sampling device /dev/mapper/vg-vpool1-vpool: [Errno 2] No such file or directory: '/proc/vdo/vg-vpool1-vpool/dedupe_stats' so the /proc/vdo isn't populate with expected names for these tools (unclear if there are more users) Of course the change on lvm2 side would brough some non-trivial complexity when the user would already have tables with 'old-way' lines and we would try to use 'new style' Advantage would be that such change would not need 'kernel' change.
*** This bug has been marked as a duplicate of bug 1888419 ***