'detected hardware change' to 'not ready'

HI,

      Once there is a hardware change detected the library goes into 'Not Ready' state. Please check if the SCSI port of the Autochanger has changed. Run inquire -lc and that will give you the current port of the Library robot and drives. if it has only changed for the Library robot then you can disable the library and change the control port under properties to the right value and re-enable the library. This will bring back the library to ready state.

Don't forget to enable persistent binding/naming to avoid this in future.

Hi Gautam,

thanks for your answer but there are no change. That is the problem.

We get an "not ready" message but there are no change.

Hi,

      Please upload the output of "inquire -lc" and screenshot of Jukebox properties from NetWorker GUI.

Hi Gautam,

I'm not sure I'm autorize to post such information.

But, do you think it is possible that the problem could be relied to the fact that le SN OS is Linux ?

It seems that we got many problems since SN are under Linux OS than when they were Solaris OS.

Here is one of the inquire :

--More--77662:inquire: CDI warning: Using old-style passthrough via st driver

77662:inquire: CDI warning: Using old-style passthrough via st driver

77662:inquire: CDI warning: Using old-style passthrough via st driver

77662:inquire: CDI warning: Using old-style passthrough via st driver

1 Disk, 42 Tape, 1 CD-ROM, 3 Autochanger (Jukebox), 1 RAID Controller, Total: 48

And the nsradmin of the jukebox controlled by this SN :

type: NSR jukebox;

                        name: "rd=currentSN:site_currentSN_L5_LEG01";

                     comment: ;

                 description: ;

                       model: Standard SCSI Jukebox;

                     enabled: Yes;

                control port: \

"rd=currentSN:/dev/tape/by-id/scsi-3500308c002bba800";

                     devices: "rd=currentSN:/dev/drive90",

                              "rd=SN1:/dev/drive90",

                              "rd=SN2:/dev/drive90",

                              "rd=currentSN:/dev/drive91",

                              "rd=SN1:/dev/drive91",

                              "rd=SN2:/dev/drive91";

              number devices: 6;

               number drives: 2;

  SmartMedia update interval: 12;

             bar code reader: Yes;

       match bar code labels: Yes;

       jukebox serial number: WWNN=500308C002BBA800;

             max parallelism: 2;

                STL barcodes: 409353L3, 409516L3, 409737L3, 411284L3,

                              408983L3, 410736L3, 407769L3, 409142L3,

                              411642L3, 411654L3, 411652L3, 405900L3,

                              410408L3, 408981L3, 406405L3, 409024L3,

                              405646L3, 410284L3, 410070L3, 400201L3,

                              408962L3, 400187L3, 400398L3, 411655L3,

                              411716L3, 407030L3, 400048L3, 400335L3,

                              411352L3, 411255L3, B18815L4, B22575L4,

                              B22577L4, B19064L4, 400115L3, B22571L4,

                              400055L3, B20696L4, 400827L3, 400457L3,

                              B00416L4, B00018L4, B19950L4, 402432L3,

                              B20649L4, 400268L3, 402619L3, 403469L3,

                              403443L3, 400595L3, B16404L4, B21663L4,

                              B13568L4, B15151L4, B16395L4, B17493L4,

                              B21631L4, B17387L4, B12998L4, B14468L4,

                              B13360L4, B12608L4, B13802L4, B16164L4,

                              B17880L4, B12550L4, B17733L4, B16630L4,

                              B14432L4, 410851L3, 411280L3, 410537L3,

                              412730L3, 412149L3, 413246L3, 413024L3,

                              413127L3, 411452L3, 406471L3, 411013L3,

                              410693L3, 801569L3, 413276L3, 413272L3,

                              411551L3, 407122L3, 408771L3, 413168L3,

                              413045L3, "", "", "", "", "", "", "";

            RSM Library GUID: ;

              RSM Media Type: ;

             RSM Drive GUIDs: ;

             RSM Media GUIDs: ;

            STL device names: ;

          STL device sharing: ;

      STL device reservation: ;

           STL interface lib: ;

              STL identifier: ;

                  auto clean: No;

      verify label on unload: No;

              cleaning slots: ;

           default cleanings: ;

       auto media management: No;

            application name: ;

             application key: ;

               read hostname: ;

                NDMP jukebox: No;

               NDMP hostname: ;

         NDMP jukebox handle: ;

                       ready: Yes;

             virtual jukebox: No;

     virtual jukebox frameid: ;

(I've changed names about the current SN, the other SN that share the drives and the installation site which is used in the name of the jukebox)

Hope you have all the information you like to have.

Rgds,

B.

As an initial check, I'd swap the CDI Used/Not Used on this library (assuming that the control port is mounted off a drive).  This will *probably* resolve the issue.  If it doesn't, it would be worthwhile to check you've got the latest drivers provided by the manufacturer.

You've got 3 different autochangers showing up in that inquire output.  The one which is showing the problem has the autochanger mounted directly off a drive (5.6.1).

I expect that the SAN zoning is having an issue with the autochanger control when the shared drive is in use.  Check and confirm that the only system able to access the robot arm is the storage node that you got the inquire output from.

"Linux" is no different from "Solaris" in this regard - it's all down to patching and drivers, and in this case I expect external zoning.  Yes, some problems exist on Linux that don't exist on Solaris, but that goes both (all?) ways for all operating systems.  There's nothing wrong with a decent Linux installation.

Sorry i'm wrong : the problem is on the physical library where the arm is shared with a drive, which is a shared drive. In the inquire, this is the i6000.

I've checked : the problem is on the L180 which is a DD VTL. The arm is not shared and only seen by the storage node and is not shared with a drive.

We have reduced the drive number and modified the zoning and since then, it seems the problem did not reproduce.

Thanks StuartWhitby.

This sounds right. I'll check with my colleagues.

This looks like what I've heard : change detected while another storage node accesses a drive.