-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
rhel-10.2
-
None
-
None
-
None
-
rhel-storage-lvm
-
None
-
False
-
False
-
-
None
-
None
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
-
x86_64
-
None
I thought about adding this to bug https://issues.redhat.com/browse/RHEL-122822 but figured it would be easier to break it out here.
To be fair both the man page (and even gemini) suggest or out right mention this operation is to be used on an ALREADY EXISTING sanlock VG. Even still, it could be confusing in this conversion scenario attempting to get to a sanlock VG, and I think we can provide the user with a message that we either didn't do anything, or didn't even try because this isn't a sanlock VG yet. Initially we get an error to "check that global lockspace is started" and if searching how to start the global lock you see "lvmlockctl --gl-enable".
-E|--gl-enable vgname
Tell lvmlockd to enable the global lock in a sanlock VG.
[root@virt-492 ~]# vgs
VG #PV #LV #SN Attr VSize VFree
vdo_sanity_convert 5 3 1 wz--n- 87.46g <37.36g
[root@virt-492 ~]# vgchange --locktype sanlock vdo_sanity_convert
Global lock failed: check that global lockspace is started
# This didn't do anything and didn't help us
[root@virt-492 ~]# lvmlockctl --gl-enable vdo_sanity_convert
[root@virt-492 ~]# echo $?
0
# Neither did this
[root@virt-492 ~]# vgchange --lock-start vdo_sanity_convert
[root@virt-492 ~]# echo $?
0
[root@virt-492 ~]# vgchange --locktype sanlock vdo_sanity_convert
Global lock failed: check that global lockspace is started
[root@virt-492 ~]# vgs
VG #PV #LV #SN Attr VSize VFree
vdo_sanity_convert 5 3 1 wz--n- 87.46g <37.36g
