Sun Storage 6580 Array
 
Sun Storage 6780 Array
 
Sun Storage 6540 Array
 
Sun Software - Generic
 
Sun Storage 6140 Array
 
Sun Hardware - Generic
 

PLA-Support>Sun Systems>Sun_Other>Sun Collections>SN-OTH: Sun Alert
 
.Old GCS Categories>Sun Microsystems>Sun Alert>Release Phase>Preliminary
 

In this Document

Description

Occurrence

Symptoms

Workaround

History

References

Applies to:

Description

When upgrading existing Sun 6000 storage array hardware to a Sun Storage Array 6x80 running firmware 7.80.xx.xx, the system may incorrectly report all drives as incompatible. Misdiagnoses of this issue could lead to loss of data integrity or unnecessary hardware replacement.

To better identify if you are at risk of encountering this problem, it is necessary to understand the different methods of changing the hardware. There are 3 basic ways of changing the existing hardware configuration of a 6xx0 storage array:

    1.  Adding new or removing existing storage capacity by adding or removing drives or trays.

    2.  Using Portable Virtual Disks to migrate existing data between two arrays.  

    3.  Upgrading the array type.

The first two are covered in CAM's (Sun Storage Common Array Manager) Service Advisor and are not the focus of this document. They are only mentioned here for context. The first assumes drives being added have no configuration of their own, and those being removed have had their configuration cleared. The second involves the existence of a second array and uses a migration process. The migration process, which is only supported with 7.x firmware, only keeps the data (volumes) intact but not licensed features, LUN mappings or other array configuration information.

Upgrading the array type is a change in controllers and utilizes the adoption process. The difference between this and the migration process is that in addition to keeping the data intact, the adoption process will also preserve Premium License features, controller IP addresses, LUN mapping etc. So, in essence the new array has adopted almost all of the old array's configuration. It is also the subject of some restrictions that may not be apparent.

    1.  Existing array must be running 7.x firmware on its controllers.

    2.  The controller port WWNs will change - this can affect zoning.

    3.  Older arrays running 6.x firmware cannot utilize the adoption process.

Occurrence

This issue can only occur when attempting the following array hardware upgrade:

• Sun Storage 6x40 Arrays with Firmware 07.xx.xx.xx

when upgrading to:

• Sun Storage 6x80 Arrays with Firmware 7.80.xx.xx

using the upgrade instructions in either the "Sun Storage 6000 Series Hardware Upgrade Guide" (Part No. 820-7003-11, December 2010, Revision A):

    PDF:  http://docs.oracle.com/cd/E19537-01/820-7003-11/820-7003-11.pdf
    HTML: http://docs.oracle.com/cd/E19537-01/820-7003-11/index.html

or, in the case of a 6140 to 6180 upgrade, as outlined in CAM's Service Advisor.

In either case, any new controllers that have 7.80.xx.xx firmware on them will encounter this problem.

Symptoms

Following a hardware upgrade as described in the "Sun Storage 6000 Series Hardware Upgrade Guide", you may observe that upon powerup of the new 6x80 controller tray all the drives are listed with a status of "Incompatible". The following is an example of the "vdmShowDriveList" output that is found in the 'stateCaptureData.dmp' file bundled within the supportData dataset:

       -> vdmShowDriveList
       Total Drives: 23

       DriveAddr  Devnum         T/S   Secure  PI Med State                          Ord/VG# Vols WWN
       ====================================================================================================
       0x04cde680 0x00010100  0/1  No       0 HDD Inc/UnA/Opt              2000001d38ad1cc70000000000000000
       0x04cf3550 0x00010300 10/1  No       0 HDD Inc/UnA/Opt              2000001d38ad1cef0000000000000000
       0x04cf3b50 0x00010304 10/5  No       0 HDD Inc/UnA/Opt              2000001d38ad1d3c0000000000000000
       0x04cf36d0 0x00010301 10/2  No       0 HDD Inc/UnA/Opt              2000001d38ad1db80000000000000000
       0x04cf32c0 0x00010103  0/4  No       0 HDD Inc/UnA/Opt              2000001d38ad1dc40000000000000000

Notice that the Role of all the drives is Unassigned (UnA) and the status is Incompatible (Inc).

From the Browser Interface, you will see something similar to the following:

Workaround

There is no workaround for this issue at this time.

If a hardware upgrade from Sun Storage 6140 to a 6180 or a 6540 to a 6580/6780 is currently being scheduled, please contact Oracle support so that we can provide you with an action plan to successfully complete the upgrade.

If the upgrade has already been attempted and the system is displaying the drives as incompatible, please call Oracle Support immediately for additional technical assistance.

A final resolution is pending completion.

History

29-Jun-2012: Date of Preliminary release
17-Jul-2012: Updated Title, Impact, and Likelihood sections for clarification
07-Aug-2012: Maintenance update; no change in content, update pending
03-Oct-2012: Modifications in all sections for clarity, new information, Image, etc.

This is being tracked as a bug in the firmware 07.80 - CR 7175521 includes additional details.

ATTENTION SUPPORT PERSONNEL
Corrective actions:

For L1:

Please request a supportData from the customer and open a collaboration with L2. If
the customer has not yet performed the upgrade (ie: you know in advance that the
customer will do it), please ask the customer to hold for further instructions from
Oracle support and then open a collaboration with L2.

For L2:

1. Perform a situation appraisal and confirm that the issue matches CR 7175521 before
   moving to step 2. For upgrades that have been attempted and failed, you will see
   all the drives in an incompatible state. For upgrades that have not yet taken place,
   it will be necessary to determine the firmware version on the new controllers. You
   should also verfiy that none the drives currently in the array have a 4.2 DACstor
   version.

   The steps needed to verify the controller firmware version depends on the hardware you have
   to work with. If the upgrade is to a 6180, you will need to utilize an empty CSM200 tray.  
   Since this upgrade requires an outage to begin with, you should be able to utilize the
   customer's existing 6140 controller tray (minus the disks). This is not needed for upgrades
   to a 6580 or 6780 as there is already a complete controller tray in the upgrade.

   To determine the firmware level set up a controller tray itself (no drives attached) and register to your CAM host and use one of the following methods:

   A) with CAM BUI (Browser User Interface):

       1) Open CAM
       2) Ensure the array in question is registered
       3) Select "Storage System" in the left pane (default screen when CAM comes up)
       4) Check the "Firmware Revision" column in the main screen

   B) with CAM CLI:

       # sscs list -a <arrayname> -t ctrl firmware

       Where 'sscs' is under:

       /* Solaris: /opt/SUNWstkcam/bin/
       /* Linux: /opt/sun/cam/bin/
       /* Windows: C:\Program Files\Sun\Common Array Manager\bin

   Example:

       # sscs list -a myarray -t ctrl firmware
       Analyzing array myarray,(myarray.domain.com),200400a0b8326764

       Controller: All FRUs at baseline
       Name                 Model        Current     Baseline
       Tray.85.Controller.A FLEXLINE 380 07.60.56.10 07.60.56.10
       Tray.85.Controller.B FLEXLINE 380 07.60.56.10 07.60.56.10

   If the controller firmware version is not 7.80.xx.xx, you either have a version that is
   not affected (< 7.77) or a version that has the fix (>= 7.84 when released).

   To verify the DACstor version of the drives currently in the array, you need to access the controller shell and run the command 'dsmShow': 

   -> dsmShow
   Current Drives (64):
   ptr       Devnum     Drv Cap       Size(Mb) Rev   Lo   MT  WWN
   0x26e02f0 0x00010609 0x00011174b81 512      (4.1) ( 0) 256 20000014c3f4b1f50000000000000000
   0x26dfee0 0x0001060e 0x00011174b81 512      (4.1) ( 0) 256 20000014c3f4b8700000000000000000
   0x26e2c60 0x00010706 0x00011174b81 512      (4.1) ( 0) 256 20000014c3f4ba800000000000000000
   0x26e3070 0x00010701 0x00011174b81 512      (4.1) ( 0) 256 20000014c3f4bbfe0000000000000000

   All drives should be Rev 4.0 or 4.1 in order for the adoption process to work with 7.80 controller firmware.


2. You have identified the issue described in CR 7175521. Depending on the current state of  the array, you have the following options:

   A. The H/W upgrade has not taken place:
 
   At this time it is necessary to downgrade the firmware on the new controllers to 7.60 code
   where the bug does not exist. This will allow a successful completion of the HW upgrade.
   There are several methods of doing this (serial port and ftp), this document will restrict
   itself to the one below for brevity as it is viewed as the most commonly available method.
   In order to do downgrade the firmware, you will need to create a temporary array using the new
   controllers and a tray with an unused drive. This drive can either be an unused drive from the
   existing array (unassigning a standby hot spare drive will work) or ordering a new drive from
   Logistics (drive type or capacity is not important so long as the drive works in the given tray).

   With the new controllers set up with a single tray containing an unused disk, power on the array
   and then register it. Then execute the following commands to downgrade the NVSRAM and controller
   firmware:

      csmservice -i -a <array_name> -t system -p <NVSRAM_firmware_file> -c system
      csmservice -i -a <array_name> -t ctrl -p <Controller_firmware_file> -c Tray.XX.Controller.Y

      Where 'csmservice' is under:

      /* Solaris: /opt/SUNWsefms/bin/csmservice
      /* Linux: /opt/sun/cam/private/fms/bin/csmservice
      /* Windows: C:\Program Files\Sun\Common Array Manager\Componetn\fms\bin\csmservice.bat

   Example:

      csmservice -i -a <array_name> -t system -p /tmp/fw/N7091-760843-004.dlp -c system
      csmservice -i -a <array_name> -t ctrl -p /tmp/fw/RC_07605310_09q2_apollo_7091.dlp -c Tray.99.Controller.A

   These firmware files can be found on the TSC web page in the private section, search for the Alert # of this document 1471865.1.  

   Once the firmware downgrade is complete, power off the controller module and remove the drive.
   Do NOT put this drive back into the original array at this time!

   Power off the controller tray and restore the cabling configuration to the new controllers or
   controller tray. Power on all expansion trays and power then on the controller tray.

   If the adoption process completed successfully, upgrade the array to 7.80 (or higher). If you
   used a customer drive to downgrade the controller firmware, that drive can now be put back into
   the array after the upgrade to 7.80. If not, the drive can be returned to Logistics.

   B. The H/W upgrade has already taken place and you have now the 6580 or 6780 which reports all the drives incompatible:

       b1. Attempt to reverse the upgrade:
           a. Power off the new controller tray.
           b. With original controller tray also powered off (swap back the 6140 controllers for 6180
              upgrades), recable the expansion trays to it.
           c. Power on original controller tray.
           d. Verify that all volumes are optimal and implement the above workaround as if the upgrade
              had not been attempted.
       b2. If that fails, engage NetApp 24x7, with a current supportdata for analysis.
       b3. Use Bugster to attach the SR to the CR.

   C. If you have found drives with 4.2 DACstor version on them in the original array or have
   further questions or problems, contact your following GEO lead for backup, tracking and
   additional assistance:

      APAC: [email protected] (backup: [email protected])
      EMEA: [email protected] (backup: [email protected])
      AMER: [email protected] (backup: [email protected])

   Any array found to have a mixture of 4.2 and other 4.x DACstor versions needs to be handled on a
   case by case basis at this point in time. As specific instructions on how to over come this issue
   are beyond the scope of this document.

-------------------------------------------------------------------
Questions regarding this document should be addressed to:
[email protected]
and copy the Responsible Engineer/Contributor listed

Internal Contributor/Submitter: [email protected]
Internal Eng Responsible Engineer: [email protected]
Internal Services Knowledge Engineer: [email protected]
Internal Eng Business Unit Group: Storage Systems - Disk

References

This solution has no attachment