Vxfenadm

1 view

Skip to first unread message

Angelique Syria

unread,

Aug 3, 2024, 2:41:43 PM8/3/24

to grilocfisub

The disk array does not support returning success for a SCSI TEST UNIT READY command when another host has the disk reserved using SCSI-III persistent group reservations. This happens with Hitachi Data Systems 99XX arrays if bit 186 of the system mode option is not enabled.

Although unlikely, you may attempt to use the vxfentsthdw utility to test a disk that has a registration key already set. If you suspect a key exists on the disk you plan to test, use the vxfenadm -g command to display it.

If the disk is not SCSI-III compliant, an error is returned indicating: Inappropriate ioctl for device.
If you have a SCSI-III compliant disk and no key exists, then the output resembles:

Reading SCSI Registration Keys...
Device Name:
Total Number Of Keys: 0
No keys ...Proceed to test the disk using the vxfentsthdw utility.
Testing Data Storage Disks Using vxfentsthdw.

If keys exist, you must remove them before you test the disk.
Refer to Removing Existing Keys From Disks.

A cluster that is currently fencing out (ejecting) a node from the cluster prevents a new node from joining the cluster until the fencing operation is completed. The following are example messages that appear on the console for the new node:

If you see these messages when the new node is booting, the startup script (/sbin/init.d/vxfen) on the node makes up to five attempts to join the cluster. If this is not sufficient to allow the node to join the cluster, reboot the new node or attempt to restart vxfen driver with the command:

For example, suppose the cluster of system 1 and system 2 is functioning normally when the private network links are broken. Also suppose system 1 is the ejected system. When system 1 reboots before the private network links are restored, its membership configuration does not show system 2; however, when it attempts to register with the coordinator disks, it discovers system 2 is registered with them. Given this conflicting information about system 2, system 1 does not join the cluster and returns an error from vxfenconfig that resembles:

However, the same error can occur when the private network links are working and both systems go down, system 1 reboots, and system 2 fails to come back up. From the view of the cluster from system 1, system 2 may still have the registrations on the coordinator disks.

When you have encountered a split brain condition, use the vxfenclearpre command to remove SCSI-III registrations and reservations on the coordinator disks as well as on the data disks in all shared disk groups.