Red Hat Bugzilla – Bug 1299977
Move lvmlockd to full support, remove tech preview classification for lvmlockd
Last modified: 2016-11-23 08:07:01 EST
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:
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
Peter, this just involves removing lvm2-lvmlockd-tech-preview-warning.patch
*** Bug 1241140 has been marked as a duplicate of this bug. ***
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
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