SUMMARY: 3510FC: LUN does not show up on host

Hi there,

MANY THANKS TO:
---------------

p.richards@gmx.net, juwa@triplestor.com, smorris@eds.com,
woolsey@jlw.com, peter.bauer@itserv.de, kevin.m.smith@siemens.com,
joe_fletcher@btconnect.com, frero@swip.net, jhorwitz75@yahoo.com, and
melanie.humphrey@ualberta.ca for your suggestions and inputs.

Special thanks to kevin.m.smith@siemens.com and peter.bauer@itserv.de.
I then asked Sun to come to clear the problem once for all and make
sure the solution was the right one and explain to me why this occures!

THE PROBLEM WAS:
----------------

The problem I have is as follows: a V880 connected, 2 Silkworm 3800,
3510FC with 2 controllers in redundant mode. Solaris 9 installed. The
problem is that configured and mapped LUNs do not show up in format.

3510 FC have been configured with on Raid5 LUN, controllers are
configured in redundant mode, point-to-point fiber connection, Logical
Drive has been partitioned and partitions have been mapped to host on 
channel 0. Both controllers are connected to switches, links are up
and speed is ok, switches show F-ports which is correct, HBA are
QLogic cards single 2Gb.

Everything has been installed on the host, Solaris 9, Recommended
Patches, SES packages for the 3510 FC, SAN 4.4 with drivers etc ...,
patches for HBAs according to release notes, sccli updated to v1.5
along with other SES packages. The only thing that has not been done
yet is to upgrade firmware on the 3510 FC to 3.27R but this won't
help anyway (talked to Sun). Everything else is "default".

Probe-scsi-all shows 3510 FC and LUNs correctly, BUT, after booting
no LUN can be found using format !? the only thing that format reports
are internal FC-disks in the V880. Using sccli shows "no device to
managed" !? Everything looks/seems fine using ssconsole (out-of-band).

THE SOLUTION IS:
----------------

Solution: configure the QLogic controllers. Controllers are actually
not auto-configured in a SAN environment. The best part is that it is
meant to be so ! another good one is that there is nothing about this
in any documentation (not in the release notes, not in the installation
guide for the card or the array, nothing in service manuals, nothing !)
Such a step is never mentioned :( So drivers are found but nothing is
indeed activated because the controller is waiting for you to in some
ways autorize opening the access to the SAN area.

How to do that: use "cfgadm -al" or "cfgadm -al -o show_FCP_dev" to
get a list of your controllers. On the left side you will see things
like "c3" or "c4" ... and "unconfigured" on the right side for those
controllers. Then use "cfgadm -c configure c3" for example and all
of a sudden, things show up (no reboot). Use format, and it's all
there (if you do not get everything in format rerun the command, it
may take a few more seconds to bring all you have up).

OTHER COMMENTS:
---------------

I just want to group different comments I got and thinks I found which
I think is worth gathering in the same mail for the archive.

Some people recommended to "boot -r". This has of course to be done
and we had done it, but the problem was there. Thanks anyway !

from (frero@swip.net):

"Qlogic controllers do not support dynamic mapping of LUNs, you have
do enter the static mapping info in the conf files for the controllers.
Sadly enough I don't know how to do that since I use JNI controllers
whenever possible for just this reason... ;)"

Actually the latest Qlogic card, according to Sun, do not have such a
problem, and they recommend using QLogic because, they said, less things
need to be configured and configuration is much easier. The one we have
here runs ISP2300.

from (juwa@triplestor.com):

"We had a similiar problem with a system based on the same contoller, 
after a boot -r all luns (18TB ) had disappeared. The problem was for 
which reson ever (we never found the solution why), the devices were 
mapped to targetid's above 130 (130 to 139), so we had to modify 
/kernel/drv/sd.conf to get this running that it was possible for the OS 
to discover the LUN's. After this we changed the .conf file of the 
ql2300  to persistent bindings for this LUn's."

from (kevin.m.smith@siemens.com) (thanks):

"Some pointers:
cfgadm -la -o show_FCP_dev [Look for unconfigured API's]
cfgadm -c configure API [If above is true]
luxadm -e port [Check that ports are connected]
devfsadm"

from (peter.bauer@itserv.de):

"You have to configure the LUNs using:
cfgadm -c configure [AttachmentPoint].

You'll find the APs by using:
cfgadm -la

Even though I don't think thats the problem, you might run in trouble
when trying to use Arbitrated Loop for the V880 internal storage but P2P
for external devices. Take care for this if cfgadm -la does not show the
3510."

from (jhorwitz75@yahoo.com):

"have you added the appropriate LUN entries in /kernel/drv/sd.conf?"

One actually can also consider checking /kernel/drv/ses.conf.

from (smorris@eds.com):

"Assuming you are expecting them to turn up as LUNS (i.e. cxtxd2 cxtxd3
cxtxd4 etc) and not separate targets, have you changed your sd.conf
file? By default Solaris is only configured to see LUN 0, so I would
expect you to see one disk in the array, but you aren't so maybe this is
a bit off track. Anyway just thought I would offer it as another idea."

While troubleshooting I also found the following line that I thougt was
a pointer to the problem, but no. In the /var/adm/messages file:

ndi_devi_online: failed for ses: target=dc lun=0 ffffffff

I found the following on SunSolve:

"The ses driver fails to attach at the time the message is produced
because the framework to attach ses is not yet in place as the system is
still booting. We only see this message on systems which use fiber
channel to boot and have a SES chip, of which a V880 is the most common.
SES does get attached a few seconds later in the boot process."


Again, if you read that far, many thanks to those who replied. It has
been two long days but the problem is solved. Now I have another one,
but I am about to write another mail for that issue.

Regards,
/Pascal
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers