The fencing module starts up as follows:
The coordinator disks are placed in a disk group.
This allows the fencing startup script to use Veritas Volume Manager (VxVM) commands to easily determine which disks are coordinator disks, and what paths exist to those disks. This disk group is never imported, and is not used for any other purpose.
The fencing start up script on each system uses VxVM commands to populate the file /etc/vxfentab with the paths available to the coordinator disks.
When the fencing driver is started, it reads the physical disk names from the /etc/vxfentab file. Using these physical disk names, it determines the serial numbers of the coordinator disks and builds an in-memory list of the drives.
The fencing driver verifies that the systems that are already running in the cluster see the same coordinator disks.
The fencing driver examines GAB port B for membership information. If no other system is up and running, it is the first system up and is considered to have the correct coordinator disk configuration. When a new member joins, it requests the coordinator disks configuration. The system with the lowest LLT ID will respond with a list of the coordinator disk serial numbers. If there is a match, the new member joins the cluster. If there is not a match, vxfen enters an error state and the new member is not allowed to join. This process ensures all systems communicate with the same coordinator disks.
The fencing driver determines if a possible preexisting split brain condition exists.
This is done by verifying that any system that has keys on the coordinator disks can also be seen in the current GAB membership. If this verification fails, the fencing driver prints a warning to the console and system log and does not start.
If all verifications pass, the fencing driver on each system registers keys with each coordinator disk.