Bug 1020877 - lvm2 does mishandle implicit availability changes
lvm2 does mishandle implicit availability changes
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2 (Show other bugs)
6.6
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Zdenek Kabelac
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-18 08:23 EDT by Zdenek Kabelac
Modified: 2014-10-14 04:24 EDT (History)
11 users (show)

See Also:
Fixed In Version: lvm2-2.02.107-1.el6
Doc Type: Bug Fix
Doc Text:
Cause: In the cluster many volume types support only exclusive activation (snapshot, thins...). lmv2 tool has been automatically converting then any non-exclusive activation into 'exclusive' activation. Consequence: Such conversion however is not always correct. When a user has requested local activation, volume could have been activated exclusively on a different node in cluster. Fix: Local activation is properly converted into local-exclusive activation. Result: When the local activation is successful the volume is locally and exclusively active.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-14 04:24:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
nperic: needinfo-


Attachments (Terms of Use)

  None (edit)
Description Zdenek Kabelac 2013-10-18 08:23:14 EDT
Description of problem:

Activation and deactivation logic for 'local' flag is not working properly.

Current state:
For some volume types like snapshots/origins, thins, raids  - local activation is converted implicitly into exclusive activation - but this is a bug,
since the user requested local activation, and we may exclusively activate
device on a different node via lvm.conf tags.

Desired state:
Local activation should be implicitly converted (for selected types) to local exclusive activation - which may fail to activate exclusively if i.e. tags setting prevent exclusive activation on the local node.

--

We hit similar problem on deactivation as well, where we even influence non-clustered VG. Local deactivation is refused in non-clustered VG and in clustered VG it's converted to deactivation. 

Desired state:

In non-clustered VG deactivation always need to work  (-aln == -an)
In clustered VG we may deactivate LV only if it's activated locally,
so exclusively activated snapshot on a different node must stay 
running for lvchange -aln and command needs to return error.


Version-Release number of selected component (if applicable):
<=2.02.102

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Zdenek Kabelac 2013-12-05 09:04:47 EST
This has been improved with upstream patch:
https://www.redhat.com/archives/lvm-devel/2013-November/msg00002.html
Comment 3 Nenad Peric 2014-07-30 08:35:18 EDT
Tested activation and deactivation of raid1, thin pools, ordinary LVs and snapshots of ordinary LVs and thin LVs. 

There was a small issue with LVM behavior if an already inactive LV was being told to deactivate, which I opened a separate bug for (Bug #1124766)

Additional issues with commands which are handling activation/deactivation are:

-aen == -an which may not be what a user wants (it deactivates the LV on ALL the nodes, regardless of the fact that there may be no exclusively activated LVs)

-aly fails silently, and returns 0 (even though id doesn't do anything) in case the volume_list check does not pass:

[root@virt-064 ~]# grep "  volume_list" /etc/lvm/lvm.conf
    volume_list = [ "vg1", "@tag1", "cluster/linear" ]
[root@virt-064 ~]# lvs
  LV      VG         Attr       LSize   Pool Origin  Data%  Meta%  Move Log Cpy%Sync Convert
  linear  cluster    -wi-------   1.00g                                                     
  lvol1   cluster    Vwi---tz-k  10.00g pool thin_lv                                        
  pool    cluster    twi---tz--   2.00g              0.00   1.17                            
  raid1   cluster    rwi---r---   2.00g                                                     
  thin_lv cluster    Vwi-a-tz--  10.00g pool         0.00                                   
  lv_root vg_virt064 -wi-ao----   6.71g                                                     
  lv_swap vg_virt064 -wi-ao---- 816.00m                                                     
[root@virt-064 ~]# lvchange -aly cluster/raid1
[root@virt-064 ~]# echo $?
0
[root@virt-064 ~]# lvs
  LV      VG         Attr       LSize   Pool Origin  Data%  Meta%  Move Log Cpy%Sync Convert
  linear  cluster    -wi-------   1.00g                                                     
  lvol1   cluster    Vwi---tz-k  10.00g pool thin_lv                                        
  pool    cluster    twi---tz--   2.00g              0.00   1.17                            
  raid1   cluster    rwi---r---   2.00g                                                     
  thin_lv cluster    Vwi-a-tz--  10.00g pool         0.00                                   
  lv_root vg_virt064 -wi-ao----   6.71g                                                     
  lv_swap vg_virt064 -wi-ao---- 816.00m                                                     
[root@virt-064 ~]# 


It should try and at least warn the user that it didn't actually DO anything. 

Should this all be split into more bug reports or can it be handled inside this one which is related to handling the availability changes?
Comment 4 Nenad Peric 2014-07-30 08:40:32 EDT
Changing the needinfo to another address.
Comment 5 Nenad Peric 2014-08-07 06:47:16 EDT
Closing this bug as VERIFIED since the intended behaviour can be observed. 
However, will open a new bug for the funny things with CLI arguments.

Marking it verified with:

lvm2-2.02.109-1.el6    BUILT: Tue Aug  5 17:36:23 CEST 2014
lvm2-libs-2.02.109-1.el6    BUILT: Tue Aug  5 17:36:23 CEST 2014
lvm2-cluster-2.02.109-1.el6    BUILT: Tue Aug  5 17:36:23 CEST 2014
udev-147-2.57.el6    BUILT: Thu Jul 24 15:48:47 CEST 2014
device-mapper-1.02.88-1.el6    BUILT: Tue Aug  5 17:36:23 CEST 2014
device-mapper-libs-1.02.88-1.el6    BUILT: Tue Aug  5 17:36:23 CEST 2014
device-mapper-event-1.02.88-1.el6    BUILT: Tue Aug  5 17:36:23 CEST 2014
device-mapper-event-libs-1.02.88-1.el6    BUILT: Tue Aug  5 17:36:23 CEST 2014
device-mapper-persistent-data-0.3.2-1.el6    BUILT: Fri Apr  4 15:43:06 CEST 2014
cmirror-2.02.109-1.el6    BUILT: Tue Aug  5 17:36:23 CEST 2014
Comment 6 errata-xmlrpc 2014-10-14 04:24:50 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1387.html

Note You need to log in before you can comment on or make changes to this bug.