Quantcast
Channel: All Data Protector Practitioners Forum posts
Viewing all articles
Browse latest Browse all 10494

Re: D2D library confused. Drives "not ready" and media "Data Protector Foreign medi

$
0
0

Re Ann,

 

first, I don't know the specifics of using FC with a StoreOnce appliance based VTL. That being said, I cannot imagine the VTL would change the serial numbers of the virtual drives (if it does, that would IMO be a reason to open a support case for the appliance). This doesn't happen with any physical drives I've ever seen (pSCSI, SAS, FC), and neither with iSCSI connected virtual drives. That's actually the crucial part - the S/N mapping to the drive (aka "data transfer element") numbering in a library has to be stable, else everything would break apart. The problem is also not Data Protector, as it has a feature to realign its internal drive mapping with reality using the serial numbers in question (which is controlled by said check box). The only issue is the OS is naming the drives differently on every reboot, so on Windows what was Tape23 may be Tape42 after a reboot. Given DP first tries to access the names it knew before, it might hit the wrong drives initially, but checking the box in question will automaticly detect that and cause it to figure out the name which has to be used today to connect to a certain drive (based on the stable serial number).

 

Have a look at the output of "devbra -dev", specifically the Exch device:

Exch    HP:D2DBS  Path: "Changer1:0:32:0"  SN: "CZJ03919BS"
        Description: CLAIMED:HP StorageWorks D2D Virtual Tape Library
        Revision: EL01  Flags: 0x0016  Slots: 1024  Drives: 32
        Drive(s) SN:
                "CZJ03919B0"
                "CZJ03919B1"
                "CZJ03919B2"
                "CZJ03919B3"
                "CZJ03919B4"
                "CZJ03919B5"
                "CZJ03919B6"
                "CZJ03919B7"
                "CZJ03919B8"
                "CZJ03919B9"
                "CZJ03919BB"
                "CZJ03919BC"
                "CZJ03919BD"
                "CZJ03919BF"
                "CZJ03919BG"
                "CZJ03919BH"
                "CZJ03919BJ"
                "CZJ03919BK"
                "CZJ03919BL"
                "CZJ03919BM"
                "CZJ03919BN"
                "CZJ03919BP"
                "CZJ039198N"
                "CZJ039198P"
                "CZJ039198Q"
                "CZJ039198R"
                "CZJ039198S"
                "CZJ039198T"
                "CZJ039198V"
                "CZJ039198W"
                "CZJ039198X"
                "CZJ039198Y"

 These serial numbers, and their ordering, should never change. If they change, your VTL is broken. The only way in the physical world for such S/N to change is replacement (new hardware, or replaced defective parts). AFAIK, in a StoreOnce VTL, only creating a new device or messing with an existing one through the WebUI may change the S/Ns. They shall never move on their own. Persistent binding used to be useful to get certain WWNs to always appear on the same emulated SCSI bus/target/lun those HBAs presented to the OS which helped to make the names more stable, but given DP can sort that out based on the S/Ns, I don't see it necessary here. Unless, of course, you really observe the VTL playing S/N roulette, but does it really?

 

HTH,

Andre.


Viewing all articles
Browse latest Browse all 10494

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>