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: | lvm2 | Assignee: | 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
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 |