This bug addresses a wider range of situations than the original one. Refer to comments by rohara: "...the 2-node limitation is not specific to fence_scsi. It is a limitation for all SAN fencing agents. In the future it is probably worthwhile to document this, list the SAN fencing agents that are subject to this limitation, etc. In my opinion, specifically noting that fence_scsi does not work in a 2-node cluster implies that all other fence agents that have that limitation will have the same specific note in the documentation."
To rohara: I'm looking to verify the list of SAN fencing agents that do not support two-node clusters. These are the fencing agents I know about that seem to use SAN devices for fencing: Egenera SAN Controller McData SAN Switch QLogic SANBox2 Switch Vixel SAN Switch Is that the full list, or are any of the other supported fencing agents SAN devices? Thanks, -Steven
For RHEL 5.4, I have added the following note to the Section on Configuring Fence Devices and to the Appendix on Fence Device Parameters: Note: * Use of SCSI persistent reservations as a fence method is supported with the following limitations: * SCSI fencing is not supported in a two-node cluster. * When using SCSI fencing, all nodes in the cluster must register with the same devices so that each node can remove another node's registration key from all the devices it is registered with. * Devices used for the cluster volumes should be a complete LUN, not partitions. SCSI persistent reservations work on an entire LUN, meaning that access is controlled to each LUN, not individual partitions. * SCSI fencing cannot be used in conjunction with qdisk. Documentation on the limitations of using other SAN-based fence devices will be added to this document in later releases after testing of what is and isn't supported, in conjunction with updates to the fence_X man pages for those devices. The note on SCSI limitations will be in the RHEL 5.4 version of this document.
With the release of RHEL 5.4 I'm closing this bug.