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.
Description of problem:
Presently LUN registration/reservation is done by either the unfencing functionality of fence-scsi during node startup (RHEL6) or the scsi-reserve init script during node startup (in RHEL5)
Because these scripts are only run at node startup, the set of LUNs that can be fenced via fence_scsi are fixed.
Need to be able to dynamically add new storage (LUNs) to a cluster w/o needing to restart the entire cluster or reboot nodes.
One possibility here is to restrict the use case to clusters where clvm is used to detect the available LUNs for fencing. This way there is no static list of block devices that need to be edited in cluster.conf.
So the procedure for adding a new LUN to a running cluster node could be:
1. Add the LUN to all nodes in the cluster from storage management UI
2. Create a new VG and enable the cluster bit so that the VG is controlled by clvm
3. On each node in the cluster, run a command that registers that new LUN with the key for the specific host. This would need to be repeated on each node in the cluster
4. Step 2 should be done quickly enough across all hosts so that the chances of fencing occurring while doing this storage addition are minimized
Once all nodes have the new LUN and have registered on that LUN, a fencing operation should automatically pick that LUN and issue the preempt and abort command on it.
Just run 'scsi_reserve start'. You can run this command at any time (assuming the cluster is up). It will get a new list of devices and issue a registration and reservation (if needed) command to all devices, including the new one.
Ah, ok. And you just mentioned to me on irc that this can also be done w/ fence_node -U to do unfencing operation.
I'm going to leave this bz open though both for doc impact and to make sure we get testing of this specific use case.
(In reply to comment #2)
> Ah, ok. And you just mentioned to me on irc that this can also be done w/
> fence_node -U to do unfencing operation.
The fence_node -U is specific to RHEL6. In RHEL5, running 'scsi_reserve start' or 'scsi_reserve restart' will re-register all devices. The list of devices is determined at run-time, so any new devices should be detected.
By "re-register" I mean that all devices that are found will be registered, even if they are already registered. This works by using the sg_persist register-ignore command, which will overwrite any existing registration key for that particular I_T nexus.