Looks like this was never fixed in RHEL7.

[root@host-119 ~]# vgchange -aye linear_1_3782
  1 logical volume(s) in volume group "linear_1_3782" now active
[root@host-119 ~]# lvs -a -o +devices
  LV             VG            Attr       LSize   Devices       
  linear_1_37820 linear_1_3782 -wima----- 336.00m /dev/sdb1(0)  


[root@host-123 ~]# vgchange -aye linear_1_3782
  Error locking on node 3: Volume is busy on another node
  0 logical volume(s) in volume group "linear_1_3782" now active
[root@host-123 ~]# echo $?
0
[root@host-123 ~]# lvs -a -o +devices
  LV             VG            Attr       LSize   Devices       
  linear_1_37820 linear_1_3782 -wim------ 336.00m /dev/sdb1(0)  



3.10.0-229.el7.x86_64
lvm2-2.02.115-3.el7    BUILT: Wed Jan 28 09:59:01 CST 2015
lvm2-libs-2.02.115-3.el7    BUILT: Wed Jan 28 09:59:01 CST 2015
lvm2-cluster-2.02.115-3.el7    BUILT: Wed Jan 28 09:59:01 CST 2015
device-mapper-1.02.93-3.el7    BUILT: Wed Jan 28 09:59:01 CST 2015
device-mapper-libs-1.02.93-3.el7    BUILT: Wed Jan 28 09:59:01 CST 2015
device-mapper-event-1.02.93-3.el7    BUILT: Wed Jan 28 09:59:01 CST 2015
device-mapper-event-libs-1.02.93-3.el7    BUILT: Wed Jan 28 09:59:01 CST 2015
device-mapper-persistent-data-0.4.1-2.el7    BUILT: Wed Nov 12 12:39:46 CST 2014
cmirror-2.02.115-3.el7    BUILT: Wed Jan 28 09:59:01 CST 2015

This existed in 7.0 as well.

I don't think there is a bug.

When you want to 'exclusively' activate LV - it will get activated this way on any cluster node.

So it's just like when you want to activate already active LV.

So if in the past repeated exclusive activation of already active LV reported error - it was a bug which has been fixed.

The 'return code' reflects the actual state - and if the actual state is 'exclusively active LV' - it's then correctly returning 0.

Asking to activate an already activate local volume is different. There, in the end, you get exactly what you asked for even if the cmd didn't actually need to do anything since it was already in the state you requested.

Here, you are requesting the exclusive activation of that volume, on that specific machine in the cluster. This command not only produces locking errors, but the result is that volume *not* being exclusively activated on that specific machine (since it's already exclusively active on a different cluster machine). The command was unable to do what you requested.

I may have to stand corrected. From the lvchange man page: "If clustered locking is enabled, -aey will activate exclusively on *one* node..."

I would argue that running -aye on nodeA implies that you are requesting it be exclusively active on nodeA, but that is not what is technically guaranteed by the man page.

I still argue that a non zero return is more helpful to the user, but feel free to close this bug.

Yep - we technically do not have 'local exclusive' activation command available.

Normally 'exclusive' activation prefers 'local' node, but it's not a rule and could be further controlled by filters and tags.

I admit it's quite complicated and likely not very used in its full capability.

New  'sanlock' will be far less complex here.

At least it's not 'lvchange -aly' allowing the same LV to be active locally on multiple machines in the cluster. :)

What could be a bug/issue here is the  'Error' locking message which may look confusing, it should rather state something about LV being already exclusively active on another node.

Test has to also fail, if the LV is active non-exclusively on any of cluster nodes.

Probably for BZ completeness it's worth to mention:
http://people.redhat.com/agk/talks/CLVM-UKUUG2007/