Copyright ©
2010-2017 Dot Hill Systems Corp.
October 2017
The latest,
approved companion versions of drive enclosure firmware are included in this
firmware package. When firmware on 3000 series controller enclosures is updated
using this firmware package, firmware on cascaded drive enclosures is also
updated. For a list of supported companion drive enclosure firmware, see “Additional
devices.”
|
Operating
system |
AssuredSAN 3000 series
controller model |
||||
|
FC |
FC/iSCSI |
SAS |
10GbE iSCSI |
1GbE iSCSI |
|
|
Apple
Mac OS |
√ |
√ |
|||
|
Microsoft
Windows Server 2008 |
√ |
√ |
√ |
√ |
√ |
|
Microsoft
Windows Server 2012 |
√ |
√ |
√ |
√ |
√ |
|
Red
Hat Enterprise Linux 5.x |
√ |
√ |
√ |
√ |
√ |
|
Red
Hat Enterprise Linux 6.x |
√ |
√ |
√ |
√ |
√ |
|
Solaris
10 |
√ |
√ |
|
|
|
|
Solaris
11 |
√ |
√ |
|
|
|
|
SuSE
Linux Enterprise Server 10 |
√ |
√ |
√ |
√ |
√ |
|
SuSE
Linux Enterprise Server 11 |
√ |
√ |
√ |
√ |
√ |
|
VMware
5.x |
√ |
√ |
√ |
√ |
√ |
On the FC/iSCSI controller, Apple
Mac OS and Solaris are supported for FC connections only.
AssuredSAN 3000 series System array
controller enclosures support the cascading of drive enclosures. The following
table lists supported drive enclosure models and firmware versions.
|
Cascaded drive enclosure model |
Minimum qualified drive enclosure firmware |
|
|
TS252P006 |
Dot
Hill 3120 and 3130 Drive Enclosures |
S200B28 |
|
Dot
Hill 2122 Drive Enclosure |
E110B17 |
|
|
Dot
Hill 2130 Drive Enclosure |
O320B13 |
After updating array controller
firmware or after connecting new drive enclosures to an existing controller
enclosure, verify the firmware compatibility of all devices. If needed, obtain
and install the supported controller or drive enclosure firmware. Firmware is
available for download from the Customer Resource Center at the Cloud
Systems Group support site.
Previous versions of the AssuredSAN 3000 Series firmware required an AssuredSAN
3000 series software plug-in in order to work with the VMware vStorage API for
Array Integration (VAAI). This plug-in enabled the offloading of key ESX
operations to 3000 Series storage systems.
Beginning with the TS251R004 firmware release, the AssuredSAN 3000 Series
VAAI Plug-in is no longer supported. The AssuredSAN 3000 Series controller
firmware now uses T10 compliance in an ESX Environment.
In order to properly upgrade your ESX Environment, perform the following
actions:
1.
Determine
whether your ESXi/ESX 5.x host has the AssuredSAN 3000 Series VAAI Plug-in
installed.
2.
Disable
the AssuredSAN 3000 Series VAAI Plug-in.
3.
Remove
the VAAI vSphere Installation Bundle (VIB).
4.
Remove
all claim-rules associated with the AssuredSAN 3000 Series VAAI Plug-in.
|
|
|
|
NOTE: Failure to correctly remove the AssuredSAN 3000 Series VAAI Plug-in and associated claim-rules will result in degraded performance and possible loss of access to datastores. |
|
|
|
|
This firmware contains security updates. After any security update is
applied to your array, Dot Hill highly recommends that you change user
passwords.
The following features were added or enhanced in
TS252P006:
·
Upgraded to OpenSSL
1.0.2k.
·
Made various security
improvements.
The following features were added or enhanced in TS252P005:
·
Added
event 590, which is logged when a vdisk has been quarantined because of a cache
flush/restore failure.
·
OpenSSL
upgraded to 1.0.2j.
The following
features were added or enhanced in TS252P002:
·
Disabled
the RC4 cipher to resolve CVE-2015-2808.
·
Controller
will automatically be restarted when it ceases operation due to a PCI
communication problem.
·
Disabled
96-bit and MD5-based HMAC and CBC mode ciphers.
·
OpenSSL
upgraded to 1.0.1q.
·
Disabled
SSL compression to mitigate CRIME attacks (CVE-2012-4929 and CVE-2012-4930).
·
Implemented
fixes for CVE-2013-5600 and CVE-2013-4548.
·
Disabled
weak SSL ciphers.
·
Disabled
TCP timestamp response.
·
Certificate
is signed using SHA-1 algorithm.
·
Enhanced
handling of aborted ATS commands.
·
Added
new Event 600: WARNING: An error was detected on this controller while
performing an XOR operation.
·
Added
new Event 601: CRITICAL: Killed partner controller multiple times. (Reason:
XOR/DMA validation failed).
The following
features were added or enhanced in TS252R007:
·
Improved
the vdisk scrub utility.
·
Improved
array stability.
·
Added
security enhancements to the system.
·
Ensured
that potentially disruptive or data loss actions require user confirmation in
RAIDar.
·
Ensured
that the secure HTTPS protocol is used for AssuredRemote.
·
Improved
recommended actions and descriptions for events.
·
Ensured
that the CLI show license command displays the licensing serial number.
·
Improved
security certificate values.
·
The
secured HTTPS protocol is enabled by default, and a warning is generated when
the unsecured HTTP protocol is enabled by the user.
·
Fixed
date and time panel to reflect appropriate changes when NTP option is enabled
or disabled.
·
Improved
the help text for the CLI show chap-records and show users
commands.
·
Improved
the help text for certificate information in RAIDar and the CLI.
·
Improved
storage system stability during controller reboots.
The following issues were fixed in TS252P006:
·
SEAVE/CRIER:
Computed XOR using CPU for parity error LBA detected using HW XOR.
·
Recovered
RAID invalid metadata for a particular corner case.
·
Fixed
RAID-5/6 parity errors on power cycle.
·
Debug
log additions to track direct I/O originator (host/internal) for error
responses.
·
Fixed
XOR/DMA validation engine memory allocation failures.
·
Fixed
an issue that caused a controller to crash with a page fault during linear
replication.
·
Fixed
a corner case of a linear-replication metadata integrity issue and controller
crash (page fault) that occurred when a new controller was inserted.
·
Debug
added to identify the root cause for metadata corruption.
·
Changed
handling of failed DMAs in snapshot functionality that caused controller
stalls.
·
Added
debug prints for message timeouts.
·
Fixed
the display of vdisk historical performance statistics after the restart of
both the storage controllers.
·
Fixed
an issue where after a clean shutdown and restart of both controllers, one
controller's vdisks had QTOF status.
·
Fixed
an issue where a controller crashed with a page fault and all of it host links
were down.
·
Fixed
bug in the cleanup of coalesced messages.
·
Added
debug prints in forwarded commands to identify page fault issue.
·
Prevented
vdisk going to QRTD state after an upgrade to firmware which supports 'flush
restore qrtd vdisk' feature.
·
Prevented
hang in the failback phase, after the deletion of host i/o due to an abort.
·
Fixed
a crash due to a topology change timeout.
·
Fixed
a web server hang related to SSL.
·
Changed
the set network-parameters command
to enable Ethernet link speed auto-negotiation by default.
·
Fixed
an issue with enclosure numbering that interfered with obtaining Storage
Controller logs.
The following
issues were fixed in TS252P005:
·
Event
314 was improperly reported for controller module and expansion module FRUs.
·
Controller
iSCSI port chip failed with queue full error.
·
Controller
page fault occurred during failover.
·
Issue
caused by CompactFlash card failure.
·
Incorrect
"Maximum Transfer Size" value reported by VPD (Vital Product Data).
·
Controller
page fault occurred due to running out of non-cache read memory.
·
Could
not use OpenSSL certificate after upgrade to TS252R007.
·
CLI set
network-parameters command did not update the link-speed and
auto-negotiation settings in relation to the duplex-mode setting.
·
After
a controller was killed with a PCIE Link fault, invalid status was reported for
both controllers.
·
Network
settings were improperly displayed by Management Controller interfaces.
·
WBI
became inaccessible via HTTP.
·
Performing
a host-channel reset while linear replication was active caused a controller
page fault.
·
Could
not create a customer-supplied security certificate if NTP time-zone offset
value is non-zero.
·
Controller
page fault occurred, related to linear snapshot functionality.
·
To
prevent system problems caused by SES broadcasts from third-party storage
devices on a SAN, the in-band SES management interface is now disabled by
default.
·
After
a controller crash, the system was power cycled and all configuration settings
reverted to factory defaults.
·
After
the system was power cycled, old replication images are not being recycled.
·
Fixed
issues with replication operations becoming stalled.
·
Controller
failback took longer than 60 seconds to complete.
·
Controller
page fault occurred, related to an internal timer queue issue.
·
Resolved
security vulnerabilities: CVE-2016-0742, CVE-2016-0746, and CNAME resolution
was insufficiently limited.
·
Added
support for SCSI Send Diagnostic command when in-band SES is disabled, so the
command is not rejected for the default LUN.
·
Added
support for SCSI Receive Diagnostic Results command when in-band SES is
disabled, so the command is not rejected for the default LUN.
·
Added
vendor, product ID, and serial number for FRU failure events 313 and 314.
·
Closed
a security hole in the ping command.
·
Fixed
an issue where disk metadata was not updated properly on members of a vdisk.
·
Fixed
an issue by disabling auto-fix mode when scrubbing mirror data in RAID-1 and
RAID-10 vdisks.
·
Prevented
reconstruction from running on a quarantined RAID-6 vdisk, and subsequent
controller crash.
·
Enhanced
cache debug to determine root cause of a page fault.
·
Updated
FC Patch Libs to incorporate QLogic fix for stuck request queue that prevented
FC host port from working.
·
Resolved
issue leading to MC error "'RA_3' isn't a known key in this map".
·
Corrected
event 173 to properly identify whether a vdisk was dequarantined automatically
or manually.
The following
issues were fixed in TS252P002:
·
MC
NOT TALKING error message seen after doing multiple logins and logouts using
scripts.
·
Systems
upgraded from TS251 to TS252R007 are prevented from replicating from a primary
system running GL200 because of an inability to attach the target system.
·
A
drive with a low level hardware error requesting spin up results in loss of
data access.
·
Creating
a replication volume might fail using RAIDar if a space exists in the source
volume name.
·
Both
controllers ceased to operate while handling heavy XCOPY commands.
·
FRU Event
314 for Power Supplies does not display the product ID or Serial Number.
·
Event
401 is not logged when logs reach warning threshold.
·
Uninstalling
and reinstalling replication license file results in confusing digits in the
license display.
·
A
vdisk was quarantined on one controller by the other controller when both
controllers are shutdown within one second.
·
Controller
may cease operation during copy-on-write restart while a vdisk is being
dequarantined.
The following
issue was fixed in TS252R007-02:
·
Fixed
a certificate validation issue that prevented the WBI from connecting using
HTTPS. When upgrading an array from TS251 to TS252R007 this issue prevented
replication from a primary system running GL200 because of an inability to
attach the target system.
The following
issues were fixed in TS252R007:
·
Fixed
an issue where a controller hung during failback.
·
Fixed
an issue where the host SAS port does not always report the correct Target ID.
·
Fixed
an issue where the SMI-S returns incorrect date on some occasions.
·
Fixed
an issue where, when an illegal request is sent, an incorrect message stating
that the disk is not supported is generated.
·
Fixed
an issue where the Event 8 drive warning does not always generate a 314 event.
·
Fixed
an issue where the controller may fault when Read Ahead Cache is set to
a non-default value.
·
Fixed
an issue where the CLI command show frus reports power supply FRU status
incorrectly.
·
Fixed
an issue where the Event 8 message provides an incorrect recommended action.
·
Fixed
an issue where a controller may rarely fault due to double deletion of host IO.
·
Fixed
an issue where SATA spare drives may not be ready on some occasions.
·
Fixed
an issue where there may be invalid data points in historical disk statistics.
·
Fixed
an issue where there is insufficient PCIE link recovery between the
controllers.
·
Fixed
an issue where the array may hang when the controllers have overlapping
commands.
·
Fixed
an issue where there is no message informing of an IP address conflict when a
user assigns a host port IP address that conflicts with an internal IP address
used by the controller.
·
Fixed
an issue where there is no warning while manually changing ownership of a vdisk
with active host IO.
·
Fixed
an issue where the 314 event for SMART event on disk reports incorrect disk
drive location.
·
Fixed
an issue where the scheduler is unable to delete snapshots on some occasions.
·
Fixed
an issue where the CLI command set email-parameters doesn't preserve the
current settings if the include-logs parameter is not specified.
·
Fixed
an issue where the array health is incorrectly reported as good, even though
the disk channel is critical.
·
Fixed
an issue where vdisks were lost after controller failover.
·
Fixed
an issue where the CLI show frus command does not list the memory card.
·
Fixed
an issue where the CLI show sensor-status command may not report numeric
status values correctly.
·
Fixed
an issue where the sequential read performance of NRAID is impacted if HDD mode
page 08h, Max Prefetch is set to less than 64Kb.
·
Fixed
an issue where the write-back cache was disabled event should be a
higher severity event than informational.
·
Fixed
an issue where an incorrect error message is displayed when attempting to
default-map a volume using a duplicate LUN number.
·
Fixed
an issue where the RAIDar Create Volume-Set option fails when a default
mapping LUN ID is not unique.
·
Fixed
an issue where the local replication between volumes owned by the same
controller fails on some occasions.
·
Fixed
an issue where an incorrect vdisk name is listed in event 485.
·
Fixed
an issue where a faulty drive may crash a controller during firmware update.
·
Fixed
an issue where events for faulty compact flash card incorrectly indicate
replacing the entire controller.
·
Fixed
an issue where Event 314 reports incorrect location information for faulty
drives.
·
Fixed
an issue where uninstallation of a license may fail.
·
Fixed
an issue where in SMI-S alert indications, the power supply device ID keys are
incorrect.
·
Fixed
an issue where the SMI-S alert indication for a hard disk failure reports
incorrect drive location.
·
Fixed
an issue where the CLI show frus command does not show controller memory
card information.
·
Fixed
an issue where the user is unable to get the SKU (Stock Keeping Unit) part
number through SNMP or SMI-S queries.
·
Fixed
an issue where the power supply failure event does not include product ID and
serial number (SN).
·
Fixed
an issue where the SNMP event for disk failure has incorrect information in the
event field.
·
Fixed
an issue where the volumes created and mapped using Microsoft diskraid
incorrectly shows 4 ports per controller for a 2-port FC controller.
·
Fixed
an issue where the RAIDar Configuration > System Settings >
Host Interfaces option may not display host port IPs correctly.
·
Fixed
an issue where the CLI map volume command may not return valid data.
·
Fixed
an issue where a RAIDar user is unable to expand a RAID 10 vdisk with two
sub-vdisks at a time.
·
Fixed
an issue in RAIDar where an incorrect warning message is displayed when
attempting to create a snapshot after reaching the maximum volume limit in a
vdisk.
·
Fixed
an issue where a RAIDar user is unable to get logs when multiple login attempts
exist with HTTPS.
·
Fixed
an issue in the CLI where no error message is generated using the create
replication-set command with a replication set name of more than 20
characters.
·
Fixed
an issue in the CLI where the recommended action message for the show disks
command for partially reconstruction disks is incorrect.
·
Fixed
an issue where the CLI show frus command does not show top level SKU
information.
·
Fixed
an issue where, after removing 2 drives in a RAID 6 vdisk, the remaining drives
are not shown in the vdisk.
·
Fixed
an issue where the SMI-S Life-Cycle Indications are not sent to Windows Server
2012 R2.
·
Fixed
an issue where on some occasions, drives might incorrectly be set as leftover
during PFU (Partner Firmware Upgrade).
·
Fixed
an issue where out-of-sync and partially reconstructed drives may not be
reported correctly when using the trust command.
·
Fixed
an issue where some errors might be encountered using RAIDar with HTTPS.
·
Fixed
an issue where the power supply and fan location information is not correct in
CLI API mode.
·
Fixed
an issue where the power supply status might not be reported correctly after
its removal.
·
Fixed
an issue where the Management controller might occasionally stop functioning.
·
Fixed
an issue where the CLI create volume-set command does not error
correctly when some parameters are missing.
·
Fixed
an issue where an error is generated when attempting to delete a replicated
snapshot.
·
Fixed
an issue where the CLI show fans command does not include all fans in
the system.
·
Fixed
an issue where the CLI show enclosures command does not report correctly
when Storage Controller is in a shutdown state.
·
Fixed
an issue where attempting to create a snapshot on a vdisk in a stopped state
does not error correctly.
·
Fixed
an issue where the System Health incorrectly
displays OK status when a controller is in a shutdown state.
·
Fixed
an issue where the System Health erroneously
displays degraded status when system is healthy.
·
Fixed
an issue where an error message is not generated when attempting expansion of
two vdisks concurrently.
·
Fixed
an issue where a controller may fault when multiple drives were removed from a
RAID 50 vdisk during expansion.
·
Fixed
an issue where the CLI session may not close properly after issuing the logout
command.
·
Fixed
an issue where the CLI create volume command does not error when
attempted on a vdisk initializing offline.
·
Fixed
an issue where after converting a master volume to a standard volume, the
volume is still listed incorrectly as a master volume.
·
Fixed
an issue where an incorrect message is generated confirming the success of a
vdisk dequarantine operation when in fact the operation failed.
·
Fixed
an issue where an incorrect number of drives are displayed when an entire
sub-vdisk is missing from a multilevel vdisk.
·
Fixed
an issue where snapshot creation fails when attempting to automatically create
a snap-pool using the default name and a snap-pool with that name already
exists.
·
Fixed
an issue where the CLI set advanced-settings command accepts invalid
numbers and characters for the emp-poll-rate parameter.
·
Fixed
an issue where the CLI set enclosure command accepts invalid numbers for
the rack-number and rack-position parameters.
·
Fixed
an issue where the CLI show master-volumes controller both command does
not return master-volumes for both controllers.
·
Fixed
an issue where the controller may fault occasionally when a misconfigured drive
is inserted.
·
Fixed
an issue where some single controller systems may not provide a list of
enclosures and disks after a firmware upgrade or downgrade, resulting in
failures when creating volumes and replication sets and with replication using existing
sets.
·
Fixed
an issue where creating a AssuredSnap replication set may fail due to a slow
SSL connection.
·
Fixed
an issue where an error message is generated with the internal USB drive.
·
AssuredSAN
3000 series systems contain an embedded SMI-S provider for use by SMI-S client
applications. The embedded provider is designed to support 3000 series
configurations with up to 24 hard drives and up to 250 mapping paths. A mapping
path is defined as a 3000 series volume presented through a 3000 series target
port to a Host initiator.
·
In
environments using replication, all AssuredSAN 3000 series controllers must
have the same firmware version installed. Running different firmware versions
among AssuredSAN 3000 series controllers might prevent replications from
occurring.
·
To
replicate between an AssuredSAN 3000 series system and an AssuredSAN 4004
series series system or AssuredSAN Ultra series system, the secondary volume
must be exactly the same size as the primary volume. To ensure that the size is
exactly the same when creating the secondary volume manually, use the CLI replicate
volume command as described in the AssuredSAN 3000 Series CLI Reference
Guide and the AssuredSAN 4004 Series CLI Reference Guide.
·
When
changing a replication set (for example, adding or removing a replication
volume, or deleting the replication set), do so from the source system; when
aborting, suspending, or resuming a replication, do so from the destination
system.
·
When
changing the primary volume of a replication set, do so from the destination
system first, then perform the change on the source system.
·
When
using Windows Dynamic Disk (software RAID) on top of hardware RAID, there are
some cautions to be considered. For more information, see the section “Real
World: Dynamic versus Basic Disks” on the topic at http://technet.microsoft.com/en-us/library/dd163558.aspx.
·
Failover
and failback times are affected by the number of system volumes; the more
volumes there are on the system, the more time is required for failover and
failback to complete.
·
For
AssuredSAN 3920 and 3930 hybrid FC/iSCSI controllers, mapping a volume via
iSCSI and FC to the same server is not a supported configuration. Many
operating systems' multipath solutions will not correctly handle the
multi-protocols. Do not map a LUN in this manner.
The following sections discuss installing firmware:
·
Installation
notes and best practices
·
Installing
firmware using RAIDar
Do not
cycle power or restart devices during a firmware update. If the update is
interrupted or there is a power failure, the module could become inoperative.
If this occurs, contact technical support. The module may need to be returned
to the factory for reprogramming.
Before
upgrading firmware, ensure that the system is stable and is not being
reconfigured or changed in any way. If changes are in progress, monitor them
and wait until they are completed before proceeding with the upgrade.
In dual-module enclosures, both
controllers or both I/O modules must have the same firmware version installed.
Running different firmware versions on installed modules may cause unexpected
results.
·
Create
a full backup of system data. (Strongly recommended.)
·
Schedule
an appropriate time to install the firmware:
o For single domain systems, I/O must be
halted.
o
For
dual domain systems, because the online firmware upgrade is performed while
host I/Os are being processed, I/O load can impact the upgrade process. Select
a period of low I/O activity to ensure the upgrade completes as quickly as
possible and avoid disruptions to hosts and applications due to timeouts.
·
Allocate
sufficient time for the update:
It takes
approximately 45 minutes for the firmware to load and for the automatic restart
to complete on the first controller module. When dual modules are installed,
the full process time is approximately 90 minutes. If cascaded drive enclosures
are also being updated, total process time may be as long as 180 minutes.
·
Set
the Partner Firmware Update option so that, in dual-controller systems,
both controllers are updated. When the Partner Firmware Update option is
enabled, after the installation process completes and restarts the first
controller, the system automatically installs the firmware and restarts the
second controller. If Partner Firmware Update is disabled, after updating
software on one controller, you must manually update the second controller.
·
Monitor
the system display to determine update status and see when the update is
complete.
·
Verify
system status in the system's management utility and confirm that the new
firmware version is listed as installed.
·
Review
system event logs.
·
Updating
array controller firmware may result in new event messages that are not
described in earlier versions of documentation. For comprehensive event message
documentation, see the most current version of the AssuredSAN 3000 Series
Event Descriptions Reference Guide.
·
Ensure
that both Ethernet connections are accessible before downgrading the firmware.
·
When
using a Binary firmware package, you must manually disable the Partner Firmware
Update (PFU) and then downgrade the firmware on each controller separately (one
after the other).
·
Reverting
from TS250 or later to firmware prior to TS230 is not supported.
Using RAIDar to install TS252
firmware is supported only when upgrading from TS230 or later firmware. When
upgrading from all other firmware versions, install the TS252 firmware using
FTP.
1. Obtain the firmware package in .zip file
format from the Customer Resource Center website at the Cloud
Systems Group support site. Save it to a temporary directory, and extract
the contents.
2.
Locate
the extracted firmware file. The firmware filename is in the following format: TSxxxRyyy-zz.bin or TSxxxPyyy-zz.bin.
3.
In
single-domain environments, stop all I/O to vdisks in the enclosure before
starting the firmware update.
4.
Log
in to RAIDar and, in the Configuration View panel, right-click the system and
then select Tools > Update Firmware.
A table displays currently installed firmware
versions.
5.
Click
Browse and select the firmware file to install.
6.
Click
Install Controller-Module Firmware File.
7. Wait for the installation to complete.
During installation, each updated module automatically restarts.
8.
In
the RAIDar display, verify that the expected firmware version is installed on
each module.
1. Obtain the firmware package in .zip file
format from the Customer Resource Center website at Cloud
Systems Group support site. Save it to a temporary directory, and extract
the contents.
2.
Locate
the extracted firmware file. The firmware file name is in the following format:
TSxxxRyyy-zz.bin or TSxxxPyyy-zz.bin.
3.
Using
RAIDar, prepare to use FTP:
a. Determine the network-port IP addresses of
the system controllers.
b.
Verify
that the system FTP service is enabled.
c.
Verify
that the user you will log in as has permission to use the FTP interface and
has manage access rights.
4.
In
single-domain environments, stop I/O to vdisks in the enclosure before starting
the firmware update.
5.
Open
a command prompt (Windows) or a terminal window (UNIX), and navigate to the
directory containing the firmware file to load.
a. Enter a command using the following
syntax:
ftp
<controller-network-address>. (For example: ftp 10.1.0.9)
b.
Log in
as an FTP user (user = ftp, password = !ftp).
c.
Enter
a command using the following syntax:
put
<firmware-file> flash
where <firmware-file>
represents the binary firmware filename.
6. Wait for the installation to complete.
During installation, each updated module automatically restarts.
7.
If
needed, repeat these steps to load the firmware on additional modules.
9.
Verify
that the expected firmware version is installed on each module.
·
Using
RAIDar, right-click the system in the Configuration View panel, and then select
Tools > Update Firmware.
·
In
the CLI, execute the show version or the show enclosures command.
If you
experience issues during the installation process, do the following:
1. When viewing system version information in
the RAIDar System Overview panel, if an hour has elapsed and the components do
not show that they were updated to the new firmware version, refresh the
browser. If version information is still incorrect, proceed to the next
troubleshooting step.
2.
If
version information does not show that the new firmware has been installed,
even after refreshing the browser, restart all system controllers. For example,
in the CLI, enter the restart mc both command. After the controllers
have restarted, one of three things happens:
·
Updated
system version information is displayed and the new firmware version shows that
it was installed.
·
The
Partner Firmware Update process automatically begins and installs the firmware
on the second controller. When complete, the versions should be correct.
·
System
version information is still incorrect. If system version information is still
incorrect, proceed to the next troubleshooting step.
3.
Verify
that all system controllers are operating properly. For example, in the CLI,
enter the show disks command and read the display to confirm that the
displayed information is correct.
·
If
the show disks command fails to display the disks correctly,
communications within the controller have failed. To reestablish communication,
cycle power on the system and repeat the show disks command. (Do not
restart the controllers; cycle power on the controller enclosure.)
·
If
the show disks command from all controllers is successful, perform the
firmware update process again.
The following is a cumulative
list of known issues and workarounds:
|
Issue: CAPI hangs can occur in a linear replication environment. Workaround: Increase the bandwidth between the primary and secondary systems. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Cannot use IPv6 addressing for controller network (management) ports. Workaround: N/A. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Booting both controller modules with no seated disks can cause data loss. Workaround: When booting controller modules with no seated disks, only run one controller module at a time. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Online help incorrectly indicated that spare drive scrub occurs every 24 hours instead of every 72 hours. Workaround: N/A. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Live disk statistics IOPs do not match the ones displayed by Iometer. Workaround: Use the host port or controller statistics IOPs. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: FTP session disconnects or hangs on some occasions during firmware update. Workaround: Enable auto negotiation on the management network ports. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Vdisk scrub may report errors incorrectly if it is started right after a power failure and there is still a lot of data in cache that needs to be written to the drives. Workaround: Retry the vdisk scrub. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: After firmware update to TS252, the e-mail notification for controller failure may not have part number (PN) and serial number (SN) information. Workaround: Reboot both controllers in the system one after the other. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: If drives that had been active members of a vdisk are added to a system, and that vdisk's name is the name of a vdisk currently present on the array, commands that use the vdisk name may fail. This prevents actions from affecting the wrong vdisk. Workaround: Rename the vdisk, delete it, or use the vdisk serial number instead of its name in commands. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Vdisks created with the CLI whose name includes angle brackets cannot be used in RAIDar to create volumes, snapshots, snap-pools or to perform a volume copy. Workaround: Rename the vdisk using the CLI. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Drives in the array head do not spin up after adding expansion unit. Workaround: None, drives do not need to spin up in this instance. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In the Configuration > Services > SNMP Notification page and Wizards > Configuration Wizard, Notification step, clicking on the Submit or Next button without explicitly providing the community strings will replace the community strings with an actual sequence of asterisks. Workaround: Explicitly supply the community strings. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: The AssuredSAN 3000 System Setup Guide describes the Cache LED on the rear panel in a way that might be confusing or misleading. Workaround: Clarification of Cache Status LED details: If the LED is blinking evenly, a cache flush is in progress. When a controller module loses power and the write cache contains data that has not been written to disk, the super-capacitor pack provides backup power to flush (copy) data from the write cache to the CompactFlash memory. When the cache flush is complete, the LED is no longer blinking. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Replications stop after a few iterations. Workaround: Restart the management controller. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Newly installed drives reported errors. Workaround: Replace the drive. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Historical data for a drive is cleared when a controller crashes. Workaround: None. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: A warning about the coin battery was not displayed in the RAIDar events log. Workaround: Reset the controller date and time to be current and restart the management controller. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: RAIDar reports an error of "input too long" when trying to map a volume that is part of a replication image. Workaround: Shorten the length of the Snapshot Name. Selecting defaults in RAIDar adds 4 characters to an image name if the replication occurs when the set is created. If replications are scheduled when the set is created, 4 characters are added as a prefix, and 6 characters are added for the unique snapshot name. In either case 5 characters are added for the exported snapshot name. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: When updating drive firmware, a message is returned stating that the disk is unsupported. Workaround: None. The message is incorrect. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: When creating a volume in RAIDar, if the user changes the units from GB to MB but does not change the volume size, the volume will be created in GB not MB. Workaround: Validate the volume size after creating a new volume. If the volume was created with the wrong units, delete and re-create the volume. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: The controller may take longer than expected to respond to SSH and Telnet requests. Workaround: Restart the management controller. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: The SMI-S modify volume name shows up as non-supported in Windows Server Manager 2012. Workaround: Modify the volume name using RAIDar or the CLI. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: An error message may be displayed when restarting the controller, even when the controller restarted successfully. Workaround: None |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In the RAIDar Configuration > Remove User page, the User Name field is not enabled, even though the asterisk indicates it is required. Workaround: Select the user from the list using the radio buttons. The User Name field will be automatically filled in. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: RAIDar may incorrectly report the local link status of controller host ports. Workaround: Use the CLI verify links command to verify the local link status. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: During a firmware upgrade of the controller, events will be generated indicating a mismatch of the versions compared to the versions in the firmware bundle (Event 363, Severity Error). This is normal operation, as the checks are done during the management controller boot process. After firmware upgrade is complete on both controllers, verify the versions are correct, and a new informational event the firmware versions match those in the firmware bundle (Event 363, Severity Informational). Workaround: None |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Historical disk and vdisk performance data is not persistent across controller power events. Workaround: None |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Vdisk Data Transferred and Data Throughput numbers appear to be much higher when using the CLI historical show vdisk-statistics [vdisk] historical command, compared to CLI live output show vdisk-statistics command. This is caused by the way that the historical and live values are calculated. · Live values are calculated based on the vdisk as viewed from the controller cache perspective. In the live statistics, performance numbers are obtained by accounting for when data is written from cache to disk or read from disk to cache. · Historical data is obtained by using the summation of the disk statistics for the disks in the vdisk. The historical vdisk data shows transfers to and from the disks in the vdisk that include the overhead of any RAID transfers as well as any host activity. Because I/Os from the RAID engine are included, numbers for the historical data appear higher than the numbers for the live data. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Saving historical disk performance statistics from RAIDar fails with an invalid time-range parameter. Workaround: Change the start date/time of the time range. Make sure the start date/time is after the last reset and, for new systems, is after the system install time. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In environments using replication, if the controllers have different firmware versions installed, replications may be suspended. Workaround: Ensure that all controllers in replicating systems have the same firmware version installed. When firmware on the controllers is the same version, suspended replications automatically resume. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: When a previously used drive is inserted in the enclosure, it may retain information about vdisks, volumes and volume mappings from its previous use. However, the LUN numbers of these volume mappings may conflict with LUN numbers currently in use in volume mappings on the system. If this occurs, the system resolves those conflicts by removing the mappings. Workaround: Remap the volumes as desired. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In RAIDar, while trying to modify a vdisk name, / is replaced by a space. Workaround: None |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In the CLI, the create volume-set command using the same basename parameter for more than 999 volumes generates an error. Workaround: Do not exceed 999 when assigning the volume identifier number. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In the CLI, the show sensor-status command does not show warning levels or indicate fan status. Workaround: None |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: When a vdisk becomes critical, the array may generate multiple events. Workaround: None |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In event messages, power supplies are referred to by different terminology. Sometimes power supply 0 is reported as ”left” and sometimes reported as “0”. Likewise, power supply 1 is sometimes reported as “right” and sometimes reported as “1”. Workaround: None |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: A serial number was not generated for SMART drive event 55. Workaround: Identify the drive using the enclosure and slot number. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: When using the CLI show master-volumes command, a volume that has been converted to a standard volume is still included in the display. Workaround: Log out and then log back in to the CLI. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In RAIDar, global spares have a status of Up even if they are spun down using the drive spin down feature. Workaround: None |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In the CLI, the set prompt command allows you to enter more than 16 characters. Workaround: None |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In RAIDar, when logging in using an unsupported browser, the returned display does not show the correct list of which browsers are supported. Workaround: Use only the following supported browsers: · Microsoft Windows Internet Explorer 7, 8, or 9 · Mozilla Firefox 7 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: On the Configuration > Advanced Settings > System Utilities page, changing the Vdisk Scrub and Managed Logs settings at the same time may result in an error. Workaround: Make these changes one at a time. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Manually creating a replication-prepared (secondary) volume and associating it with a primary volume originally created with pre-TS230 firmware can fail. Automatically created secondary volumes do not have this problem. Workaround: · In RAIDar, use the Replication Setup Wizard or the Replicate Volume task or, in the CLI, use the create replication set command to automatically create the secondary volume. (Preferred workaround) · Issue the following commands in the CLI to specify the block size of the manually created secondary volume, ensuring that it is exactly the same size as the source volume (Alternative workaround): 1. In CLI API format, use the show volumes <volume-name> command to determine the size of the pre-T230 volume in blocks. This is displayed by the "size-numeric" property. 2. Use the create volume command and specify the size in blocks (obtained in Step 1) to create the replication-prepared volume. 3. Create a replication set that associates the two volumes. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: When using both the primary and secondary paths on both ports of the Qlogic iSCSI HBAs, failover does not work correctly on cable pulls. Workaround: When setting up the Qlogic iSCSI HBAs, set up only the primary path for both ports. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: When creating a volume set with the volumes mapped to LUNs, if there is a LUN conflict, the array stops mapping volumes to LUNs, but creates the volumes as requested. Workaround: Ensure that there are no LUN conflicts before creating the volume set with mapping or map the remaining volumes to LUNs after the conflict. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: For Fibre Channel systems connected directly to the server, the QLogic 8 Gb FC driver version 9.1.9.25 on Microsoft Windows Server 2008 R2 x64 does not see LUNs when the array is set up for point to point. Workaround: Upgrade to the latest driver version available or change the array host ports to loop mode. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: For SAS systems, failover is slow when more then 128 LUNs are accessed from a Red Hat Enterprise Linux 4.x or SuSE Linux Enterprise Server 10 SP3 client. Workaround: Map less than 128 LUNs to SAS clients. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In RAIDar, the Japanese version of some pages and some error messages displays English text. Workaround: None. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: The array incorrectly accepts a DNS name for the address of the NTP server in the Storage Management Utility. The array does not use DNS, and translates the name into an invalid “255.255.255.255” IP address. Workaround: Instead of a network name, enter the NTP server IP address. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In the Command Line Interface, the array incorrectly accepts a DNS name for the address for the SMNP, SMTP, and NTP servers. The array does not use DNS, and cannot connect to the server correctly. Workaround: Instead of network names, enter the IP addresses for the servers. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In Windows configurations, the IQN shown by the NC551 card during POST may not match the IQN seen in the array controller. This occurs when the NC551 was set up in a boot-from-storage configuration. After an operating system is installed, the POST message shows the IQN that is supplied by the iSCSI Software Initiator, but the NC551 BIOS continues to use the IQN setup to boot the OS. Workaround: Using the NC551 BIOS Utility, remove the boot settings and then log back into the array with the new IQN. If the volume used for mapping was explicitly mapped to the host, recreate the mapping for the new IQN. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: When accessing more than 128 LUNs using a Qlogic iSCSI HBA in boot-from-storage configurations, the system may hang when a reset is issued on the array. Workaround: Access 128 LUNs or less via the Qlogic iSCSI HBA when using the card in boot-from-storage configurations. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: RHEL 4.8 may not discover all multipath devices and partitions during boot or reboot. Workaround: This issue is addressed by applying the updated device-mapper-multipath package described in RedHat Bug Fix Advisory RHBA-2009:1524-1, available at http://rhn.redhat.com/errata/RHBA-2009-1524.html. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Under rare circumstances, some events from one controller are not seen on the other controller. Workaround: Review the events from both controllers. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: During a firmware upgrade, the firmware bundle version may show incorrectly. Workaround: Wait until the firmware upgrade process is complete before checking the firmware bundle version. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: JavaScript issues are seen when using Microsoft Internet Explorer in multi-byte language locales, resulting in truncated messaging and hung pop-up windows. These issues will be resolved in a future firmware release. Workaround: This is a display problem only. When a pop-up window remains on screen with no update for a prolonged period, close and then re-open the browser. The Internet Explorer English locale and the Firefox browser do exhibit the issues. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In SLES 11 environments, when using the iSCSI initiator tools included in SLES 11, the host occasionally does not correctly log into the iSCSI array on reboot, even when set to automatically connect. Workaround: Restart the iSCSI service on the SLES 11 host. This can be done by entering the following command: /etc/init.d/open-iscsi restart |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: SLES 11 may require multiple minutes (15+/-) to create all multipath devices during boot. This typically involves a system with a large number of LUNs and multiple LUN paths. Workaround: None. Wait for the system to complete LUN and path discovery. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: SLES 11 SP1 may not create all devices during boot. This typically involves a system with a large number of LUNs, multiple LUN paths, and the SLES 11 SP1 open-iscsi utilities. Workaround: Do one of the following: · Install the following Novell patches: o kpartx-0.4.8-40.23.1.x86_64.rpm o libvolume_id1-128-13.11.4.x86_64.rpm o multipath-tools-0.4.8-40.23.1.x86_64.rpm o open-iscsi-2.0.871-0.22.1.x86_64.rpm o udev-128-13.11.4.x86_64.rpm · Run the /sbin/multipath -v 0 command to force multipathd to rescan all LUNs and paths and create any devices that were not correctly created before. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In rare conditions, the array controller may report that a supported 10 GbE SFP+, 10GbE Copper Cable, or 10GbE Direct Attach Cable is unsupported. This condition is most likely to occur when a SFP+, Copper Cable, or Direct Attach Cable is hot plugged into the controller while the controller is running. When this occurs, the following Warning message is recorded in the event logs: “An unsupported cable or SFP was inserted." At the same time, the host port does not show a status of "Down." Workaround: Do the following: 1. Verify that the SFP+, Copper Cable, or Direct Attach Cable is a supported component. 2. If the component is a supported model, remove and reinsert the SFP+, Copper Cable, or Direct Attach cable. 3. If this does not correct the issue with the SFP+, Copper Cable, or Direct Attach Cable connected to the controller, either remove and reinsert the controller or power down and reapply power to the array. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: RHEL 5 Update 5 does not shutdown properly when using the iSCSI initiator utilities shipped in RHEL 5 Update 5 to access the array. Workaround: See issue 583218 on the Red Hat Bugzilla bug-tracking system https://bugzilla.redhat.com/show_bug.cgi?id=583218 for the current status of the issue and possible workarounds. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: When using explicit LUN mapping, using long IQN names for the iSCSI Initiator can cause the array to map the LUN incorrectly. A predefined area is used to store explicit LUN mapping information per LUN and, with longer IQN names, this area can be exhausted. This issue is not dependent on the number of paths to the LUN. Workaround: Shorten the IQN name on the nodes. The following formula is used to calculate the maximum IQN name length
based on the number of hosts being explicitly mapped to a LUN on the array:
The following table provides the calculated values based on the number of
hosts being explicitly mapped to a LUN on the array:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: USB CLI becomes unusable after a Management Controller reboot in Windows environments. Workaround: 1. Close down the terminal application. (Example: HyperTerminal) 2. Open Device Manager and disable the “Disk Array USB Port” under Ports (COM & LPT). 3. Re-enable the “Disk Array USB Port.” If the problem persists, reboot the host. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: There is no indication that a LUN has failed over to the other controller. Workaround: Using RAIDar, open up system events and scan for failover events. When using the CLI, use the show events command. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: A replication is initiated, but only a snapshot on the primary volume occurs, or the replication is queued. Workaround: Ensure that all systems involved have valid replication licenses installed and that all volumes and vdisks involved in the replication have started, are attached, and are in good health, including vdisks that contain the snap pools for the volumes involved. A replication normally queues when a previous replication involving the same volumes is active. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: A replication set was deleted, but is later shown with the primary volume status of “Offline” and the status-reason is record-missing. Workaround: This generally occurs when the secondary volume is detached and its vdisk stopped when the replication set was deleted, and then the vdisk of the secondary volume restarted. To correct this issue, reattach the secondary volume, set it as the primary volume, and delete the replication set. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: An error message indicating “controller busy” occurs while creating a replication set. Workaround: Creating a replication set immediately following another replication set creation may result in "Controller Busy." This is expected behavior. Wait and try the operation again at a later time. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In RAIDar, the Vdisk > Provisioning > Create Multiple Snapshots task allows a secondary volume to be selected, but fails the operation. Workaround: User initiated snapshots are not allowed on secondary volumes. Do not select a secondary volume. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: A scheduled replication is missing or replications are queued, but do not complete. Workaround: A best practice is to schedule no more than four volumes to start replicating at the same time and for those replications to recur no less than 30 minutes apart. If you schedule more replications to start at the same time or schedule replications to start more frequently, some scheduled replications may not have time to complete. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Unable to perform a local replication (a replication where the external view volume and the destination volume reside on the same system) with a single vdisk. Workaround: Create a second vdisk for the destination volume. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Deleting the replication-set from the destination system fails. Workaround: Delete the replication set from the source system (the system where the external view volume resides.) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: A replication set is missing the primary volume and the replication set cannot be deleted. Workaround: Set the primary volume to the remaining volume in the set. You should then be able to delete the replication set. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: On rare occasions, deleting a vdisk when volumes are in the process of rolling back may cause communications issues between the management controller and the storage controller. Workaround: Cycle power on the array to resolve the issue. To avoid this situation, allow the rollbacks to complete or delete the volumes before deleting the vdisk. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Scheduled tasks are not occurring, and there is no indication of a problem in the schedules or the tasks. Workaround: Restart both management controllers (MCs) of the array(s) involved in the tasks. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Cannot schedule volume copy operations, or scheduled volume copy operations for snapshots and standard volumes do not occur. Workaround: Perform the volume copy manually. Scheduled volume copies of master volumes should complete successfully if the schedule permits completion of the volume copy before the next occurrence. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Debug logs are incomplete. Workaround: Determine if the logs are incomplete by unzipping the log file retrieved from the array and examining the last line of the store_YYYY_MM_DD__HH_MM_SS.logs file for the lines: End of Data ]]></LOG_CONTENT></RESPONSE>. If the file contains these two lines at the end of the file, it is complete and you can forward it to your service support organization for analysis. If the file does not contain these two lines at the end, it is incomplete and may not be useful. In this case, repeat the log collection process after a 5 minute delay. Should the second collection contain the above specified lines at the end of the file, send it to your service support organization for analysis along with the first set of logs. However, if the second file does not contain the above specified lines at the end of the file, reboot the system and try once more to collect the logs. Be sure to send all collected logs back to your service support organization with a brief note explaining the actions you took and the result. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: In a dual controller system, log in to one of the controllers fails, but log in to the other controller succeeds. Workaround: Log in to the other controller and restart the inaccessible management controller using the CLI restart mc command or RAIDar Tools > Shut Down or Restart Controller page. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: IOPs and Bytes per second may be lower or higher than expected for the workload. Workaround: This is a reporting issue and not a performance issue. The correct values can be calculated by using the change in the Number of Reads and Number of Writes over time to determine IOPs, and the change in Data Read and Data Written over time to determine Bytes per second. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: The array controller may interpret a switch login as an HBA login and erroneously present the switch port as a discovered host. This does not affect storage functionality. Workaround: Either identify the erroneous host and do not attempt to use, or Disable Device Scan on switch ports connected to the array controller and restart the array controller. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: During firmware upgrade, FTP is aborted from a Windows client after starting the upgrade. Workaround: This is a client side FTP application issue. If this issue persists try updating from RAIDar, use another client, or use another FTP application. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: Upgrading firmware failed with the error, “Unwritable cache data present.” Workaround: The controller is not in a state that can reliably perform an upgrade without losing data currently in cache. Resolve the unwritable cache issue and retry the upgrade. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: While updating the array firmware using RAIDar, if the array must reboot the management controller the web page may not automatically log the user out completely resulting in a blank page. Workaround: Refresh the browser window; if the login page is not displayed, close the browser and restart it to access the login page and complete the firmware update. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Issue: While performing a firmware update using RAIDar to multiple arrays, the window showing the status of the upgrade may appear as a blank window. Workaround: Updating multiple arrays at the same time can cause this issue. Perform one firmware update from one client at a time. Updating one array at a time from a client allows the window to refresh more accurately. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
AssuredSAN 3000 series model |
Release date |
|
|
TS252P005 |
All |
December
2016 |
|
TS252P002 |
All
|
April
2016 |
|
TS252R007-02 |
All
|
June
2015 |
|
TS252R007 |
All
|
June
2015 |
|
TS251R004-05 |
All
|
May
2014 |
|
TS251R004 |
All
|
March
2014 |
|
TS250P002 |
All
|
August
2013 |
|
TS250R023 |
All
|
April
2013 |
|
TS240P004 |
All
|
November
2012 |
|
TS240P003 |
All
|
July
2012 |
|
TS240P001 |
All
|
June
2012 |
|
TS240R037 |
All
|
May
2012 |
|
TS230P008 |
All
|
November
2011 |
|
TS230P006 |
All
|
August
2011 |
|
TS230R044
|
All
|
July
2011 (updated notes to announce support for all AssuredSAN 3000 series System
controllers) |
|
iSCSI |
June
2011 |
|
|
TS201P007
|
FC
and hybrid FC/iSCSI |
February
2011 |
|
TS220R004 |
iSCSI |
November
2010 |
|
TS210R016 |
iSCSI |
September
2010 |
|
TS200R021 |
SAS |
June
2010 |
|
Rev.
A |
Part
number: 83-00004779-23-01 |