Backup or restore or image expiration fails with Hitachi arrays

The following table lists possible explanations:

Table: Backup or restore or image expiration fails

Issue	Explanation/Recommended Action
A problem occurred that involved the Hitachi instance number. For example, the Hitachi snapshot provider did not receive the instance number for the command device. The instance number is needed to connect to the array. The /usr/openv/netbackup/logs/bpfis/hitachi.log.<date> log contains the following message: Couldn't get instance no failed with message .... The log may contain the following additional messages: Fri Mar 21 2008 16:26:49.818233 <Pid - 9477 / Thread id - 1> Entering Function attachCmd [156, providers/hitachi/hitachi_rmlibintf.cpp] Fri Mar 21 2008 16:26:49.173893 <Pid - 9477 / Thread id - 1> attachcmddev is called with cmd dev /dev/dsk/c1t0d0s2 and instance number 0. Fri Mar 21 2008 16:26:49.818308 <Pid - 9477 / Thread id - 1> Exiting Function attachCmd [156, providers/hitachi/hitachi_rmlibintf.cpp] The attachcmddev message should list the Hitachi command device (for the enclosure ID that was specified in the policy) and the instance number. If the Hitachi command device is not included in the message, then the instance number was not received. A limited number of instance numbers are allowed per command device. If the maximum number of processes is using the same command device, no more instance numbers are available. This situation may indicate a problem with the instance number management logic of the Hitachi provider. Note also the following potential messages: Fri Mar 21 2008 16:26:49.818233 <Pid - 9477 / Thread id - 1> Entering Function attachCmd [156, providers/hitachi/hitachi_rmlibintf.cpp] Fri Mar 21 2008 16:26:49.173893 <Pid - 9477 / Thread id - 1> Couldn't get instance no failed with message '%s'. Fri Mar 21 2008 16:26:49.818308 <Pid - 9477 / Thread id - 1> Exiting Function attachCmd [156, providers/hitachi/hitachi_rmlibintf.cpp] Another example message is the following: Fri Mar 21 2008 16:26:49.173893 <Pid - 9477 / Thread id - 1> Couldn't get instance no failed with message 'Instance No Exhausted, couln't reclaim giving up'	These messages indicate that the instance number is not available. A problem may exist with the instance number management logic. Remove the following file. /usr/openv/lib/vxfi/cachefiles/hitachi/ UDID##HITACHI##HDS##enclosure id##* The enclosure id is the array's serial number that is specified in the policy's Snapshot Resources. Gather the appropriate Hitachi logs and contact Veritas customer support for NetBackup.
The default array controller of the source device is not the same as the controller of the snapshot device. Use the Storage Navigator interface to verify.	Recommended action: Make sure that the clone (or snapshot) device has the same default controller as the source device. See the Hitachi documentation.

Issue

Explanation/Recommended Action

A problem occurred that involved the Hitachi instance number. For example, the Hitachi snapshot provider did not receive the instance number for the command device. The instance number is needed to connect to the array.

The /usr/openv/netbackup/logs/bpfis/hitachi.log.<date> log contains the following message:

Couldn't get instance no failed with message ....

The log may contain the following additional messages:

Fri Mar 21 2008 16:26:49.818233 <Pid - 9477 / Thread id - 1> Entering Function attachCmd [156, providers/hitachi/hitachi_rmlibintf.cpp] Fri Mar 21 2008 16:26:49.173893 <Pid - 9477 / Thread id - 1> attachcmddev is called with cmd dev /dev/dsk/c1t0d0s2 and instance number 0. Fri Mar 21 2008 16:26:49.818308 <Pid - 9477 / Thread id - 1> Exiting Function attachCmd [156, providers/hitachi/hitachi_rmlibintf.cpp]

The attachcmddev message should list the Hitachi command device (for the enclosure ID that was specified in the policy) and the instance number. If the Hitachi command device is not included in the message, then the instance number was not received. A limited number of instance numbers are allowed per command device. If the maximum number of processes is using the same command device, no more instance numbers are available. This situation may indicate a problem with the instance number management logic of the Hitachi provider.

Note also the following potential messages:

Fri Mar 21 2008 16:26:49.818233 <Pid - 9477 / Thread id - 1> Entering Function attachCmd [156, providers/hitachi/hitachi_rmlibintf.cpp] Fri Mar 21 2008 16:26:49.173893 <Pid - 9477 / Thread id - 1> Couldn't get instance no failed with message '%s'. Fri Mar 21 2008 16:26:49.818308 <Pid - 9477 / Thread id - 1> Exiting Function attachCmd [156, providers/hitachi/hitachi_rmlibintf.cpp]

Another example message is the following:

Fri Mar 21 2008 16:26:49.173893 <Pid - 9477 / Thread id - 1> Couldn't get instance no failed with message 'Instance No Exhausted, couln't reclaim giving up'

These messages indicate that the instance number is not available. A problem may exist with the instance number management logic.

Remove the following file.
/usr/openv/lib/vxfi/cachefiles/hitachi/ UDID##HITACHI##HDS##enclosure id##*
The enclosure id is the array's serial number that is specified in the policy's Snapshot Resources.
Gather the appropriate Hitachi logs and contact Veritas customer support for NetBackup.

The default array controller of the source device is not the same as the controller of the snapshot device. Use the Storage Navigator interface to verify.

Recommended action: Make sure that the clone (or snapshot) device has the same default controller as the source device. See the Hitachi documentation.

More Information

Troubleshooting Hitachi arrays

Backup or restore or image expiration fails with Hitachi arrays

Feedback

Feedback