Four possible causes have been documented below. Please follow the steps in each section to determine cause and resolution


Possible Cause 1
The diskgroup is imported on another node in the cluster. The cluster node with the diskgroup imported maintains an active SCSI reservation on all imported disks and if another node attempts to import these, it will fail.

Solution: Ensure the Diskgroup is not imported on any nodes in the cluster. If the cluster software is working properly, this should not occur. However, if there are cluster communication issues (resulting in a split-brain) or manual imports/deports are being performed outside of the cluster (i.e. through Veritas Enterprise Administrator [VEA]) this can occur.


Possible Cause 2
SFW/Infoscale is configured to use SCSI-3, but the array does not support it.

Solution: Verify if SFW/Infoscale is configured to use SCSI-3, and if so, perform SCSI-3 tests on storage to ensure it is supported.

1. Open the VEA console

2. Go to Control Panel > System Settings > SCSI Support to determine SCSI type configured (see Figure 1)

Figure 1

3. Download the scsicmd utility from the following Tech Article: https://supportinfoscale.cloud.com/support-home/kbsearch/article?articleNumber=100021389&articleTitle=how-to-use-the-scsicmd-utility-to-perform-various-scsi2-and-scsi3-reservation-related-actions& 

. Once the article is loaded, choose the 'Download Attachments' option on the right side of the page. 

Note:
For SFW 5.1 or earlier, download the version for SFW 5.x
For SFW 6.x and above and Infoscale 7.x and above, download the version for SFW 6.x

4. Once downloaded, extract to a temporary location

5. Open a command prompt (run as administrator) and CD into the scsicmd directory (Note: after extracting scsicmd, there are actually two scsicmd directories, so make sure to CD into the full path to where scsicmd.exe resides).

6. Run command: scsicmd -dx -sscsi3_test

where x is the harddisk number

• x can be a single harddisk (-x4)
• x can be several harddisks in sequential order (-x4-8 would return results for 4,5,6,7, and 8)
• x can be several non-sequential harddisks (-x6,8,11,14,19)
• x can = all which will run the command on all disks on the server (-xall)

Note: the command line switch -s, and all commands start with SCSI, so make sure not to forget to have both S's in the command (-sscsi_reserved_status)

7. The output of this command is rather long, but the end should show that all tests passed successfully (Figure 2):

Figure 2

8. If all tests pass, then the array supports SCSI-3.

Note: If this test fails, try running the following commands to ensure the failure wasn't due to a stuck reservation on the disk

• scsicmd -dx -sscsi3_clear
• scsicmd -dx -sscsi2_clear
• scsicmd -dx -sscsi3_test

Possible Cause 3
There could be a stuck reservation on the server which is causing any reserve requests to fail. Follow the steps provided below:

1. Check the current reservation status of one or more disks in the problem diskgroup to ensure there is no current reservation in place by running command: scsicmd -dx -sscsi_reserved_status (see Figure 3)

Figure 3

Note: There is no direct query for SCSI-2 in order to determine reservation, so this utility cannot consistently determine if a disk is under SCSI-2 reservation or not. It is not uncommon to see the utility report a disk is under SCSI-2 reservation when it isn't (as shown in Figure 3 below). SCSI-3 does have a direct query, so we are able to properly query the status.

2. If a disk is under reservation, you will see one of the following, depending on SCSI type: Figure 4 below shows what is returned if a disk is under SCSI-2 reservation. Figure 5 shows what is returned if a disk is under SCSI-3 reservation on another server:​

Figure 4

Figure 5

3. If reservations are seen, the following commands can be run to clear any potentially "stuck" reservations

• scsicmd -dx -sscsi2_clear
• scsicmd -dx -sscsi3_clear

SCSI-3 Clear

4. Ensure this is run against all disks in the Diskgroup. Once complete, the scsicmd -dx -scsi_reserved_status command can be run to again ensure the reservations are now clear. A couple points on this:

• A disk may show as SCSI-2 reserved even when it is not (as explained above).
• If another node has the Diskgroup imported, it will re-reserve disks every 3 seconds. This would result in the scsi2_clear and scsi3_clear operations being successful, however, the active node would reserve them again and the scsi_reserved_status operation would show the disks still reserved

5. Once reservations have been cleared (SCSI-2 and SCSI-3), try performing the Diskgroup import operation again.


Possible Cause 4
The disks do not support any type of reservation. SCSIcmd can be used to place SCSI-2 or SCSI-3 reservations. Please follow the steps provided below

1. Determine if SFW/Infoscale is configured for SCSI-2 or SCSI-3 (explained in 'Possible Cause 2' above).

2. On one or more disks in the problem Diskgroup, run the proper command to place a reservation on the disk.

• SCSI-2: scsicmd -dx -sscsi2_reserve
• SCSI-3: scsicmd -dx -sscsi3_reserve

3. If reservations fail, work with the Storage Team or array vendor to investigate. 

4. If reserving disks is successful, please run the following command to release the reservation that was added to the disk

• SCSI-2: scsicmd -dx -sscsi2_clear
• SCSI-3: scsicmd -dx -sscsi3_clear