5.6.2 HP IBRIX X9000 Release Notes

NOTE: For storage support on X9300 systems, do not set the Custom Delivery ID. (The MSA is an
exception; the Custom Delivery ID is set as previously described.)
Test the configuration
To determine whether the traps are working properly, send a generic test trap with the following
command:
snmptrap -v1 -c public <CMS IP> .1.3.6.1.4.1.232 <Managed System IP> 6 11003 1234 .1.3.6.1.2.1.1.5.0
s test .1.3.6.1.4.1.232.11.2.11.1.0 i 0 .1.3.6.1.4.1.232.11.2.8.1.0 s "X9000 remote support testing"
For example, if the the CMS IP address is 10.2.2.2 and the X9000 node is 10.2.2.10, enter the
following:
snmptrap -v1 -c public 10.2.2.2 .1.3.6.1.4.1.232 10.2.2.10 6 11003 1234 .1.3.6.1.2.1.1.5.0
s test .1.3.6.1.4.1.232.11.2.11.1.0 i 0 .1.3.6.1.4.1.232.11.2.8.1.0 s "X9000 remote support testing"
For IRSS, replace the CMS IP address with the IP address of the IRSS server.
Troubleshooting Insight Remote Support
Following are tips for troubleshooting Insight Remote Support:
• If a discovered device is reported as unknown on CMS/IRSS, run the following command on the
file serving node to determine whether the Insight Remote Support services are running:
# service snmpd status
# service hpsmhd status
# service hp-snmp-agents status
If the services are not running, start them:
# service snmpd start
# service hpsmhd start
# service hp-snmp-agents start
• If nodes are configured and the system is discovered properly but alerts are not reaching the
CMS/IRSS, verify that a trapif entry exists in the cma.conf configuration file on the file serving
nodes. See “Configure SNMP on the file serving nodes” (page 8) for more information.
Workarounds
Following are workarounds for product situations that may occur:
Remote Replication
• When remote replication is running, if the target file system is unexported, the replication of data
will stop. To ensure that replication takes place, do not unexport a file system that is the target
for a replication (for example, with ibrix_exportcfr -U).
• Remote replication will fail if the target file system is unmounted. To ensure that replication takes
place, do not unmount the target file system.
• When continuous remote replication is used and File Serving Nodes are configured for High
Availability, you will need to take the following steps following failure of a node:
1. Stop continuous remote replication.
2. After the migration to the surviving node is complete, restart continuous remote replication
to heal the replica.
If these steps are not taken, any changes that had not yet been replicated from the failed node
will be lost.
• No alert is generated if the continuous remote replication target becomes unavailable. Confirm
the connection to the target system by issuing a ping command and by inspecting
ibrcfrworker.log.
Workarounds 11