6.0 HP StorageWorks X9000 File Serving Software Release Notes (TA768-96042, October 2011)
• Email notifications do not include information about failed attempts to collect the cluster
configuration.
• In some situations, ibrix_collect successfully collects information after a system crash but
fails to report a completed collection. The information is available in the /local/ibrixcollect/
archive directory on one of the file serving nodes.
Migration to an agile management console configuration
When a cluster is configured with a dedicated, standard management console, the Quick Restore
installation procedure installs both the Fusion Manager and the File Serving Node packages on the
dedicated, standard management console and on each node of the cluster. If you then attempt to
migrate to an agile management console configuration, the migration procedure will fail. To avoid
the failure, uninstall the Ibrix Server package from the dedicated, standard management console, and
uninstall the Ibrix Fusion Manager package from the file serving nodes. You can then perform the
migration.
Complete the following steps:
1. On the standard management console, check for the IbrixServer RPM:
# rpm –qa | grep –i IbrixServer
If the RPM is present, the output will be similar to the following:
IbrixServer-<version>
2. If the IbrixServer RPM is present, uninstall the RPM:
# rpm -e IbrixServer-<version>
3. On each file serving node, check for the Ibrix Fusion Manager RPM:
# rpm –qa | grep –i IbrixFusionManager
If the RPM is present, the output will be similar to the following:
IbrixFusionManager-<version>
4. If the RPM is present on the node, remove the RPM:
# rpm -e IbrixFusionManager-<version>
Cluster component states
• Changes in file serving node status do not appear on the management console until 6 minutes
after an event. During this time, the node status may appear to be UP when it is actually DOWN
or UNKNOWN. Be sure to allow enough time for the management console to be updated before
verifying node status.
• Generally, when a vendorstorage component is marked Stale, the component has failed
and is not responding to monitoring. However, if all components are marked Stale, this implies
a failure of the monitoring subsystem. Temporary failures of this system can cause all monitored
components to toggle from Up, to Stale, and back to Up. Common causes of failures in the
monitoring system include:
◦ Reboot of a file-serving node
◦ Network connectivity issues between the management console and a file serving node
◦ Resource exhaustion on a file serving node (CPU, RAM, I/O or network bandwidth)
While network connectivity and resource exhaustion issues should be investigated, they can occur
normally due to heavy workloads. In these cases, you can reduce the frequency at which
vendorstorage components are monitored by using the the following command:
ibrix_fm_tune -S -o vendorStorageHardwareStaleInterval=1800
12 Workarounds