Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Starting the cluster (1) with fence_scsi will end up with duplicate scsi_key for one of the nodes.
I believe that when the cluster is started clean there should be only one scsi key present per node.
This command is used to find out scsi keys:
/usr/bin/sg_persist --in --no-inquiry --read-key --device=/dev/sdc
Version-Release number of selected component (if applicable):
pacemaker-1.1.22-1.el7.x86_64
fence-agents-all-4.2.1-41.el7.x86_64
How reproducible: in about 10% of the cases run an vmware nodes.
Steps to Reproduce:
1. start cluster with fence_scsi as fencing method
2. observe number of scsi keys on shared drive
Actual results: more scsi keys than nodes
Expected results: same number of scsi keys as is number of nodes
Additional info:
I'm filling this in hope to find out whether this really is or is not the right behaviour.
I'm filling this under fence agents because I believe it's their role to manipulate scsi keys an shared drive.
(1) pcs config
Cluster Name: vmware-brq-stable-12
Corosync Nodes:
vmware-stable-23.cluster-qe.lab.eng.brq.redhat.com vmware-stable-24.cluster-qe.lab.eng.brq.redhat.com
Pacemaker Nodes:
vmware-stable-23.cluster-qe.lab.eng.brq.redhat.com vmware-stable-24.cluster-qe.lab.eng.brq.redhat.com
Resources:
Clone: dlm-clone
Meta Attrs: interleave=true ordered=true
Resource: dlm (class=ocf provider=pacemaker type=controld)
Operations: monitor interval=30s on-fail=fence (dlm-monitor-interval-30s)
start interval=0s timeout=90 (dlm-start-interval-0s)
stop interval=0s timeout=100 (dlm-stop-interval-0s)
Clone: clvmd-clone
Meta Attrs: interleave=true ordered=true
Resource: clvmd (class=ocf provider=heartbeat type=clvm)
Attributes: with_cmirrord=1
Operations: monitor interval=30s on-fail=fence (clvmd-monitor-interval-30s)
start interval=0s timeout=90s (clvmd-start-interval-0s)
stop interval=0s timeout=90s (clvmd-stop-interval-0s)
Stonith Devices:
Resource: fence_scsi (class=stonith type=fence_scsi)
Attributes: devices=/dev/disk/by-id/wwn-0x600c0ff0001592fc5dd4855e01000000,/dev/disk/by-id/scsi-3600c0ff0001592fc5dd4855e01000000 pcmk_host_check=static-list pcmk_host_list=vmware-stable-23.cluster-qe.lab.eng.brq.redhat.com,vmware-stable-24.cluster-qe.lab.eng.brq.redhat.com pcmk_reboot_action=off
Meta Attrs: provides=unfencing
Operations: monitor interval=60s (fence_scsi-monitor-interval-60s)
Fencing Levels:
Location Constraints:
Ordering Constraints:
start dlm-clone then start clvmd-clone (kind:Mandatory) (id:order-dlm-clone-clvmd-clone-mandatory)
Colocation Constraints:
clvmd-clone with dlm-clone (score:INFINITY) (id:colocation-clvmd-clone-dlm-clone-INFINITY)
Ticket Constraints:
Alerts:
Alert: forwarder (path=/usr/tests/sts-rhel7.9/pacemaker/alerts/alert_forwarder.py)
Recipients:
Recipient: forwarder-recipient (value=http://virt-072.cluster-qe.lab.eng.brq.redhat.com:40917/)
Resources Defaults:
No defaults set
Operations Defaults:
No defaults set
Cluster Properties:
cluster-infrastructure: corosync
cluster-name: vmware-brq-stable-12
dc-version: 1.1.22-1.el7-63d2d79005
have-watchdog: false
no-quorum-policy: freeze
Quorum:
Options:
auto_tie_breaker: 1
wait_for_all: 1
Comment 3Oyvind Albrigtsen
2020-11-10 11:52:14 UTC
Patch to avoid writing key to dev again (doesnt make any difference on RHEL8, as sg_persist seems to avoid it there), and to not write devices to /var/run/cluster/fence_scsi.dev again (e.g. if you stop/start cluster):
https://github.com/ClusterLabs/fence-agents/pull/364
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 (fence-agents bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2021:1745
Starting the cluster (1) with fence_scsi will end up with duplicate scsi_key for one of the nodes. I believe that when the cluster is started clean there should be only one scsi key present per node. This command is used to find out scsi keys: /usr/bin/sg_persist --in --no-inquiry --read-key --device=/dev/sdc Version-Release number of selected component (if applicable): pacemaker-1.1.22-1.el7.x86_64 fence-agents-all-4.2.1-41.el7.x86_64 How reproducible: in about 10% of the cases run an vmware nodes. Steps to Reproduce: 1. start cluster with fence_scsi as fencing method 2. observe number of scsi keys on shared drive Actual results: more scsi keys than nodes Expected results: same number of scsi keys as is number of nodes Additional info: I'm filling this in hope to find out whether this really is or is not the right behaviour. I'm filling this under fence agents because I believe it's their role to manipulate scsi keys an shared drive. (1) pcs config Cluster Name: vmware-brq-stable-12 Corosync Nodes: vmware-stable-23.cluster-qe.lab.eng.brq.redhat.com vmware-stable-24.cluster-qe.lab.eng.brq.redhat.com Pacemaker Nodes: vmware-stable-23.cluster-qe.lab.eng.brq.redhat.com vmware-stable-24.cluster-qe.lab.eng.brq.redhat.com Resources: Clone: dlm-clone Meta Attrs: interleave=true ordered=true Resource: dlm (class=ocf provider=pacemaker type=controld) Operations: monitor interval=30s on-fail=fence (dlm-monitor-interval-30s) start interval=0s timeout=90 (dlm-start-interval-0s) stop interval=0s timeout=100 (dlm-stop-interval-0s) Clone: clvmd-clone Meta Attrs: interleave=true ordered=true Resource: clvmd (class=ocf provider=heartbeat type=clvm) Attributes: with_cmirrord=1 Operations: monitor interval=30s on-fail=fence (clvmd-monitor-interval-30s) start interval=0s timeout=90s (clvmd-start-interval-0s) stop interval=0s timeout=90s (clvmd-stop-interval-0s) Stonith Devices: Resource: fence_scsi (class=stonith type=fence_scsi) Attributes: devices=/dev/disk/by-id/wwn-0x600c0ff0001592fc5dd4855e01000000,/dev/disk/by-id/scsi-3600c0ff0001592fc5dd4855e01000000 pcmk_host_check=static-list pcmk_host_list=vmware-stable-23.cluster-qe.lab.eng.brq.redhat.com,vmware-stable-24.cluster-qe.lab.eng.brq.redhat.com pcmk_reboot_action=off Meta Attrs: provides=unfencing Operations: monitor interval=60s (fence_scsi-monitor-interval-60s) Fencing Levels: Location Constraints: Ordering Constraints: start dlm-clone then start clvmd-clone (kind:Mandatory) (id:order-dlm-clone-clvmd-clone-mandatory) Colocation Constraints: clvmd-clone with dlm-clone (score:INFINITY) (id:colocation-clvmd-clone-dlm-clone-INFINITY) Ticket Constraints: Alerts: Alert: forwarder (path=/usr/tests/sts-rhel7.9/pacemaker/alerts/alert_forwarder.py) Recipients: Recipient: forwarder-recipient (value=http://virt-072.cluster-qe.lab.eng.brq.redhat.com:40917/) Resources Defaults: No defaults set Operations Defaults: No defaults set Cluster Properties: cluster-infrastructure: corosync cluster-name: vmware-brq-stable-12 dc-version: 1.1.22-1.el7-63d2d79005 have-watchdog: false no-quorum-policy: freeze Quorum: Options: auto_tie_breaker: 1 wait_for_all: 1