Bug 1299977

Summary: Move lvmlockd to full support, remove tech preview classification for lvmlockd
Product: Red Hat Enterprise Linux 7 Reporter: David Teigland <teigland>
Component: lvm2Assignee: Peter Rajnoha <prajnoha>
lvm2 sub component: LVM lock daemon / lvmlockd QA Contact: cluster-qe <cluster-qe>
Status: CLOSED ERRATA Docs Contact: Petr Bokoc <pbokoc>
Severity: unspecified    
Priority: unspecified CC: agk, cmarthal, heinzm, jbrassow, pbokoc, prajnoha, sbradley, teigland, zkabelac
Version: 7.3   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: lvm2-2.02.161-1.el7 Doc Type: Enhancement
Doc Text:
Improved LVM locking infrastructure `lvmlockd` is a next generation locking infrastucture for LVM. It allows LVM to safely manage shared storage from multiple hosts, using either the `dlm` or `sanlock` lock managers. `sanlock` allows `lvmlockd` to coordinate hosts through storage-based locking, without the need for an entire cluster infrastructure. For more information, see the *lvmlockd(8)* man page. This feature was originally introduced in Red Hat Enterprise Linux 7.2 as a Technology Preview. In Red Hat Enterprise Linux 7.3, `lvmlockd` is fully supported.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-04 04:14:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1295577, 1313485    

Description David Teigland 2016-01-19 16:21:08 UTC
Description of problem:

Remove the tech preview classification, and remove the RHEL-specific commit that prints a warning when a shared VG is created:

WARNING: shared lock type "sanlock" and lvmlockd are Technology Preview.
For more information on Technology Preview features, visit:
https://access.redhat.com/support/offerings/techpreview/

The lvmlockd man page provides a fairly good starting point for defining what should currently work with lvmlockd, and which lvm features/commands are not yet supported on shared VGs.  I intend to add more unsupported features/commands to the lvmlockd man page as they are discovered.

(There are some odd or exotic features that are not specifically mentioned such as --test mode, or swapping pool metadata LVs.)

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 David Teigland 2016-01-22 17:16:47 UTC
The following tests are of particular interest to me because they exercise locking in ways where a problem would be most directly apparent.

"parallel" means that multiple hosts (any number) run the following command concurrently.

--

This is a sequence of commands where one generally uses the result of the previous.

parallel: vgcreate --shared vg /dev/foo
result: one succeeds, others fail

parallel: lvcreate -L1G vg (no name)
result: pick different lvol# names

parallel: lvcreate -n `hostname` -L1G vg; lvchange -an vg/`hostname`; lvremove vg/`hostname`
result: all succeed

parallel: lvcreate -n foo -L1G -an vg
result: one succeeds, others find it exists

parallel: lvremove vg/foo
result: one succeeds, others don't find it

parallel: lvcreate -n foo -L1G -an vg
result: one succeeds, others find it exists

parallel: lvextend -L+1G vg/foo
result: all succeed

parallel: lvextend -L2G vg/foo
result: one does it, others find it's already done

parallel: lvchange -aey vg/foo
result: one succeeds, others fail

parallel: lvchange -an vg/foo
result: all succeed

parallel: lvchange -asy vg/foo
result: all succeed

parallel: lvchange -aey vg/foo
result: all fail

parallel: lvchange -an vg/foo
result: all succeed

parallel: lvchange --addtag `hostname` vg/foo
result: all succeed

parallel: lvchange --deltag `hostname` vg/foo
result: all succeed

parallel: for i in `seq 1 200`; do lvcreate -L 10M vg; sleep 1; done
result: all succeed

parallel: vgchange -an vg
result: all succeed

parallel: lvremove --yes vg
result: all succeed (one does the removals, others find no lvs)

parallel: lvcreate -n `hostname` -L1G vg
result: all succeed

parallel: lvextend -L+1G vg/`hostname`
result: all succeed

parallel: lvrename vg/`hostname` vg/`hostname`-2
result: all succeed

parallel: lvremove vg/`hostname`-2
result: all succeed

host1: lvcreate -n foo -L1G vg
result: succeeds

host2: lvremove vg/foo
result: fails

host1: lvchange -an vg
result: succeeds

host2: lvremove vg/foo
result: succeeds

host1: lvcreate -n foo -asy -L1G vg
result: succeeds

host2: lvchange -asy vg/foo
result: succeeds

host2: lvchange -an vg/foo
result: succeeds

host2: lvremove vg/foo
result: fails

--

These tests create/remove local VGs on shared devices.
system_id should not be used during these tests so that
the locking is exercised.

parallel: vgcreate vg /dev/foo
result: one succeeds, others fail (name exists)

parallel: vgextend vg /dev/bar
result: one succeeds, others fail

parallel: vgextend vg /dev/<different_devs>
result: all succeed

parallel: vgremove vg
result: one suceeds, others fail (not found)

parallel: vgcreate vg-`hostname` /dev/<different_devs>
result: all succeed

parallel: vgextend vg-`hostname` /dev/foo
result: one succeeds, others fail

parallel: vgextend vg-`hostname` /dev/<different_devs>
result: all succeed

parallel: vgremove vg-`hostname`
result: all succeed

parallel: vgcreate vg /dev/<different_devs>
result: one succeeds, others fail (name exists)

parallel: vgremove vg
result: one succeeds, others fail (not found)

parallel: vgcreate vg1 /dev/foo
result: one succeeds, others fail (name exists)

parallel: vgrename vg1 vg2
result: one succeeds, others fail

parallel: vgremove vg2
result: one succeeds, others fail

parallel: vgcreate vg1-`hostname` /dev/<different_devs>
result: all succeed

parallel: vgrename vg1-`hostname` vg2-`hostname`
result: all succeed

parallel: vgrename vg2-`hostname` vg2
result: one succeeds, others fail

parallel: pvcreate /dev/X /dev/Y
result: all succeed

parallel: pvchange -u /dev/X /dev/Y
result: all succeed

Comment 3 David Teigland 2016-06-30 17:19:57 UTC
Peter, this just involves removing lvm2-lvmlockd-tech-preview-warning.patch

Comment 4 Peter Rajnoha 2016-07-11 09:53:34 UTC
*** Bug 1241140 has been marked as a duplicate of this bug. ***

Comment 7 Corey Marthaler 2016-09-27 18:38:13 UTC
Marking this verified in the latest rpms. All of the commands listed in comment #1 passed (assuming an already existing global lock VG); as well as a large portion of the current lvm regression tests which were made to be executed on shared lvmlockd volumes.


3.10.0-510.el7.x86_64
lvm2-2.02.165-4.el7    BUILT: Thu Sep 22 01:47:19 CDT 2016
lvm2-libs-2.02.165-4.el7    BUILT: Thu Sep 22 01:47:19 CDT 2016
lvm2-cluster-2.02.165-4.el7    BUILT: Thu Sep 22 01:47:19 CDT 2016
device-mapper-1.02.134-4.el7    BUILT: Thu Sep 22 01:47:19 CDT 2016
device-mapper-libs-1.02.134-4.el7    BUILT: Thu Sep 22 01:47:19 CDT 2016
device-mapper-event-1.02.134-4.el7    BUILT: Thu Sep 22 01:47:19 CDT 2016
device-mapper-event-libs-1.02.134-4.el7    BUILT: Thu Sep 22 01:47:19 CDT 2016
device-mapper-persistent-data-0.6.3-1.el7    BUILT: Fri Jul 22 05:29:13 CDT 2016
cmirror-2.02.165-4.el7    BUILT: Thu Sep 22 01:47:19 CDT 2016
sanlock-3.4.0-1.el7    BUILT: Fri Jun 10 11:41:03 CDT 2016
sanlock-lib-3.4.0-1.el7    BUILT: Fri Jun 10 11:41:03 CDT 2016
lvm2-lockd-2.02.165-4.el7    BUILT: Thu Sep 22 01:47:19 CDT 2016


Here is a list of currently open lvmlockd bugs not affecting the full support verification:


1379799 RFE: VG lock-stop propagation issue
1379793 RFE: better error when unable to grab VG lock on one node
1375664 confusion over --splitmirrors support on shared lvmlockd VGs
1374786 'R VGLK lock_san acquire error -202' potential errors when attempting shared volume configurations
1351805 "_update_pv_in_udev no dev found" warning when starting global lock space
1350051 unable to scrub raid with tpool on top residing on a shared VG
1269608 RFE: add command to restore missing lvmlock
1268445 limitations to what can be done to shared (-asy) activated LVs on shared VGs
1265768 unable to swap thin meta volume residing on a shared VG

Comment 9 errata-xmlrpc 2016-11-04 04:14:25 UTC
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.

https://rhn.redhat.com/errata/RHBA-2016-1445.html