Hi Amit! No, ls -l shows the port WWN of the attached device, not of the switch port. Compare the port WWN listed by ls with the name server entries on your FC switches. If you are using Brocade switches use the switchshow or nsshow command. switchshow tells you the port WWN of the attached devices and nsshow also lists the node WWN and the WWN of the switchport.
I always use port WWNs, not node WWNs. Dirk Am 01.07.2009 um 17:57 schrieb Kumar, Amit H.: > Hi Dirk, > > This is really helpful. > > From what I understand, PWWN seen on the path output of "ls -l /dev/ > rmt/0" > is WWN of the actual port on the FC switch, to which the tape drive > is plugged into. > And not the WWN on the Tape drive nor the WWN on HBA on the host. > > Is this correct? > > I also notice node WWN(NWWN) any idea if this can be used here or if > used anywhere at all? > > Thank you, > Amit > > > -----Original Message----- > From: Dirk.Nitschke at Sun.COM [mailto:Dirk.Nitschke at Sun.COM] > Sent: Wednesday, July 01, 2009 3:03 AM > To: Kumar, Amit H. > Cc: 'mselway000 at comcast.net'; 'sam-qfs-discuss at opensolaris.org' > Subject: [Spam: 5.0] Re: [sam-qfs-discuss] Did not become ready, > check log > > Hi Amit! > > One thing I have found very useful is to use what is typically called > "persistent binding" for (fibre channel) tape drives. You define > which /dev/rmt/# entry is associated to which tape drive (which > (PWWN,LUN) tupel to be accurate). This makes it easy to use some > numbering scheme like "/dev/rmt/1[0-9] belong to library stk8500-01, / > dev/rmt/2[0-9] belong to stk8500-02". And you are sure that the drive > with a given WWPN always gets the same /dev/rmt entry in case it has > to be recreated. > > Setting up persistent binding on Solaris using the Sun fire channel > driver stack is easy and available for years but not commonly known. > Take a look at Sumit Gupta's original blog from 2005 > > http://blogs.sun.com/hbainsights/entry/persistent_bind_solution_creating_consistent > > or the latest version of the "Solaris Fibre Channel and Storage > Multipathing Administration Guide" > > http://docs.sun.com/source/819-0139/ch_8_persist_binding.html > > Important: You have to use a [TAB] before the rmt entry in /etc/ > devlink.tab . > > If you have more /dev/rmt/*[0-9] entries than tape drives, check if > your SAN zoning is correct. If you have n HBA ports seeing the same > tape drive port, you'll get n /dev/rmt/*[0-9] entries. No multipathing > for tape drives in Solaris 10, yet. For every /dev/rmt/*[0-9] entry > there are additional ones ending with b, c, h, l, m, n, u which define > to use the drive in a special manner. "cbn" means that compression > should be used, Berkeley style, do not rewind. > > MPXIO for tape is part of Open Solaris (I guess build 93 and later), > see > > http://www.opensolaris.org/os/project/mpxio/ > http://blogs.sun.com/danmas/entry/multipathing_for_tape > > Dirk > > Am 01.07.2009 um 00:12 schrieb Kumar, Amit H.: > >> Hi Mike, >> >> I got this to work. With the help of a 'Sun Tier 2 Engineer'. Like >> Judy Leach pointed out it was the tape drive ordering. Thank you >> for responding though. >> >> I will try to summarize the way I understand this and how we fixed >> it, in the hope that others can benefit from this. This is >> definitely not a technical documentation, more like a story writing >> style description. >> >> Tested on OS: Solaris 9 and SAM version 4.6 >> >> Tape drive order as seen by the OS and as listed in the mcf file is >> crucial to SAM-QFS. >> >> OS sees the tape drives under the device tree /dev/rmt/#. For every >> tape drive seen by the OS you should see a any entry under the /dev/ >> rmt directory tree. I am not sure why I see more entries than the >> number of tape drives I have. May be someone can explain this, >> probably OS related. >> >> Suppose you have 4 tape drives in your library, and let us say for >> the sake of the argument we number the first physical drive in the >> library as drives 0, then the next as drive 1, similarly for drive >> 2, and drive 3. Now if you manually load a tape into the First tape >> drive(drive 0) then you can check to see which one of the /dev/rmt/ >> # corresponds to which drive number. >> >> Q) How to check the above? Use the "mt" command as follows: >> >> If the above command on /dev/rmt/0 returns something similar to the >> following then you have found that the drive 0 corresponds to /dev/ >> rmt/0; If not continue with other devices /dev/rmt/1, ...etc until >> you >> find one. >> >> #mt -f /dev/rmt/0 status >> HP Ultrium LTO tape drive: >> sense key(0x0)= No Additional Sense residual= 0 retries= 0 >> file no= 0 block no= 3 >> >> Now you will have the actual drive order list as follows: >> >> Drive 0 = /dev/rmt/1 >> Drive 1 = /dev/rmt/0 >> Drive 2 = /dev/rmt/3 >> Drive 3 = /dev/rmt/2 >> >> Use the above list to correctly configure the mcf list. >> >> Suppose the configurations in the current mcf file appears as below: >> >> # Equipment Eq Eq Family >> Device Additional >> # Identifier Ord Type Set >> State Parameters >> #----------- --- ---- ------ >> ------ ---------- >> >> /dev/samst/c3t500104F0007C4EACu0 50 s9 SunL500 >> on /etc/opt/SUNWsamfs/SunL500_cat >> /dev/rmt/0cbn 51 li SunL500 on >> /dev/rmt/1cbn 52 li SunL500 on >> /dev/rmt/2cbn 53 li SunL500 on >> /dev/rmt/3cbn 54 li SunL500 on >> >> >> From the above drive order list and mcf file it is evident that the >> drive orders are not right. It is required that the drives Equiment >> Ordinal number be listed in the ascending order in the mcf file. >> >> Corrected oder of the drives in the mcf files are as follows: >> ----------------------------------------------------------------------- >> # Equipment Eq Eq Family >> Device Additional >> # Identifier Ord Type Set >> State Parameters >> #----------- --- ---- ------ >> ------ ---------- >> >> /dev/samst/c3t500104F0007C4EACu0 50 s9 SunL500 >> on /etc/opt/SUNWsamfs/SunL500_cat >> /dev/rmt/1cbn 51 li SunL500 on >> /dev/rmt/0cbn 52 li SunL500 on >> /dev/rmt/3cbn 53 li SunL500 on >> /dev/rmt/2cbn 54 li SunL500 on >> >> Now restart your sam-qfs and most likely you will not see the "Did >> not become ready, check log" error. >> >> Please correct me if I am wrong. >> >> Thank you, >> Amit >> >> From: mselway000 at comcast.net [mailto:mselway000 at comcast.net] >> Sent: Monday, June 29, 2009 8:48 PM >> To: Kumar, Amit H. >> Subject: Re: [sam-qfs-discuss] Did not become ready, check log >> >> Hello, >> Did you hear back on this? >> >> regards, >> Mike >> >> >> Mike Selway >> 301-332-4116 >> >> >> >> ----- Original Message ----- >> From: "Amit H. Kumar" <AHKumar at odu.edu> >> To: "Judy.Leach at Sun.COM" <Judy.Leach at Sun.COM> >> Cc: "sam-qfs-discuss at opensolaris.org" <sam-qfs- >> discuss at opensolaris.org> >> Sent: Monday, June 29, 2009 3:25:19 PM GMT -06:00 US/Canada Central >> Subject: Re: [sam-qfs-discuss] Did not become ready, check log >> >> >> I used the CAP and manually imported using the import command. I >> did not use FSMGR. >> >> I don't understand what you mean by "out of order" My mcf is >> untouched all along. Only archiver.cmd was modified to remove any >> references to old LTO2 tapes drive labels and replaced with LTO4 >> labels in the section describing vsn's for tape archives. >> >> Can you please elaborate "out of order" with mcf and with reference >> to unlabelled(new) tapes. >> >> Also I am using tapes that are already barcode labeled hence not an >> issue of wrong labeling. >> >> Thank you, >> Amit >> >> From: Judy.Leach at Sun.COM [mailto:Judy.Leach at Sun.COM] >> Sent: Monday, June 29, 2009 4:19 PM >> To: Kumar, Amit H. >> Cc: 'sam-qfs-discuss at opensolaris.org' >> Subject: Re: [sam-qfs-discuss] Did not become ready, check log >> >> Check your tape drive ordering. >> >> If the tape drives are out of order in the mcf file, then although >> the tape drive will load, it will actually be in the wrong tape >> drive. >> >> Watchout, because having them out of order with unlabelled(new) >> tapes, can cause wrong label to be written to wrong tape and then >> you will have an additional problem. >> >> Did you try using FSMGR to add in the tape drives, or manually add?? >> >> .... Judy >> >> >> On Mon, 2009-06-29 at 15:45, Kumar, Amit H. wrote: >> Hello Everyone, >> >> OS: Solaris 9 >> Version: SAM-4.6 >> >> After upgrading IBM LTO2 drives to HP LTO4 drives on SL500. >> Completely got rid of LTO2 tape drives. >> I see the following error while mounting any LTO4 tapes on to LTO4 >> drives. >> "Did not become ready, check log" >> >> SAMU utility recognizes the drives and everything looks, except when >> I try to test archiving or loading the tapes in the drive.. >> >> Any idea what could be going on? >> >> Thank you, >> Aimt >> >> >> >> >> _______________________________________________ >> sam-qfs-discuss mailing list >> sam-qfs-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/sam-qfs-discuss >> -- >> * Judy Leach * >> >> *Sun Microsystems, Inc.* >> Tampa, FL US >> Phone 813-840-4985 x67004 >> Mobile 813-787-9225 >> Email Judy.Leach at Sun.COM >> >> "Looking for the miracles in life" >> >> Spread the word: Sun's Infinite Archive System: >> >> IAS onestop / sunspace page >> <https://sunspace.sfbay.sun.com/display/Onestop/Infinite+Archive >> +System >>> >> >> IAS Mysales Page >> <http://mysales.central.sun.com/public/storage/infinite_archive.html> >> >> IAS Partner Page >> <http://partner.sun.com/products/storage/infinite_archive.html> >> >> IAS Product Page <http://www.sun.com/servers/cr/ias> >> >> >> _______________________________________________ sam-qfs-discuss >> mailing list sam-qfs-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/sam-qfs-discuss >> _______________________________________________ >> sam-qfs-discuss mailing list >> sam-qfs-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/sam-qfs-discuss > > -- > Sun Microsystems GmbH Dirk > Nitschke > Nagelsweg 55 Storage > Architect > 20097 Hamburg Phone: > +49-40-251523-413 > Germany Fax: > +49-40-251523-425 > http://www.sun.de/ Mobile: +49-172-847 62 > 66 > > Dirk.Nitschke at Sun.COM > ----------------------------------------------------------------------- > Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, > D-85551 Kirchheim-Heimstetten - Amtsgericht Muenchen: HRB 161028 > Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel > Vorsitzender des Aufsichtsrates: Martin Haering > -- Sun Microsystems GmbH Dirk Nitschke Nagelsweg 55 Storage Architect 20097 Hamburg Phone: +49-40-251523-413 Germany Fax: +49-40-251523-425 http://www.sun.de/ Mobile: +49-172-847 62 66 Dirk.Nitschke at Sun.COM ----------------------------------------------------------------------- Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten - Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering
