We discovered the issue and were able to successfully add the LUN's, but it raised a question.
The issue was that the LUN id needed to add it on the server did not match what we had to use in the past. Past LUN's were added using the LDEV. The problem with that is that duplicates can exist because of multiple host groups within the array. In this case LUN 0x0041 was a duplicate and was recognized as 0x0141 instead. If they were recognized by the assigned Host LUN # that wouldn't be an issue since those can't be duplicated within an array/host group. I assume this is expected behavior when you are not using NPIV? Is there a way to anticipate how they will be recognized on the servers? VR, Justin Sollenberger -----Original Message----- From: Sollenberger, Justin W CIV DISA (US) Sent: Wednesday, July 09, 2014 11:26 AM To: [email protected] Subject: RE: LUN connection problem SLES11 SP3 The LUN's I attempted to add were in a failed state. I attempted to recover them by 'echo 0 > /sys/bus/...../failed' and that did not work. With logging increased I got the following messages: kernel: scsi 0:0:0:66: scsi scan: INQUIRY pass 1 length 36 kernel: scsi scan: INQUIRY successful with code 0x0 kernel: scsi 0:0:0:66: scsi scan: INQUIRY pass 2 length 212 kernel: scsi scan: INQUIRY successful with code 0x0 kernel: scsi 0:0:0:66: scsi scan: peripheral qualifier of 3, device not added Maybe storage firmware? VR, Justin Sollenberger -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Steffen Maier Sent: Wednesday, July 09, 2014 10:24 AM To: [email protected] Subject: Re: LUN connection problem SLES11 SP3 On 07/09/2014 03:47 PM, Rick Troth wrote: > On 07/09/2014 09:15 AM, Sollenberger, Justin W CIV DISA (US) wrote: >> I'm assisting one of our SA's to add some FCP attached LUN's to a >> new server. We have many other servers on this LPAR already using >> LUN's across the same connections with no issues. > > is NPIV involved? > >> I'm able to run 'zfcp_host_configure 0.0.nnnn 1' with no issues. >> Running 'zfcp_disk_configure 0.0.nnnn 0xnnnnnnnnnnnnnnnn >> 0x00nn000000000000 1' produces no errors or log messages but when >> running 'lszfcp -D' it reports 'Error: No fcp devices found.' I've >> also attempted to add it in YaST, but upon clicking next when it >> drops back to the main screen the LUN is not in the list. > > I presume each guest has its own FCP adapter (or pair, recommended). If > NPIV is in play, and the other Linuxen are happy, then I'd suspect the > zoning and masking of this LUN. Check with your storage team. Is the LUN > wired to hit a different guest? (different FCP adapter(s)) If you don't see the necessary target port(s) with # lszfcp -b 0.m.nnnn -P (or the necessary ports are in failed state) then it would be zoning. But I doubt that because zfcp_disk_configure should have complained with "WWPN xyz invalid" and errorlevel 4 about the missing port. I suppose the zfcp unit which zfcp_disk_configure created by means of the unit_add sysfs attribute ended up in failed state: # cat /sys/bus/ccw/drivers/zfcp/0.m.nnnn/0xnnnnnnnnnnnnnnnn/0x00nn000000000000/fai led 1 [book "Device Drivers, Features, and Commands", Section "Configuring SCSI devices", "If there is no SCSI device for this LUN, the LUN is not valid in the storage system, or the FCP device is offline in Linux." After fixing LUN masking (see below), you can dynamically reprobe the LUN as in Section "Recovering failed SCSI devices" http://www.ibm.com/developerworks/linux/linux390/distribution_hints.html] LUN masking is indeed a probable root cause in this case. Zfcp Traces won't help much here, since it just passes SCSI commands from the SCSI midlayer used for LUN probing to the FCP channel, but does not care or interpret the transferred SCSI sense codes. In order to see what happens (or fails) on LUN probing and to see if any SCSI error recovery is involved, you can (temporarily, although the suggested log level won't adversely affect regular good path I/O) increase the scsi logging level: # echo 4605 > /sys/module/scsi_mod/parameters/scsi_logging_level SCSI logging is done with kernel messages (dmesg) and depending on syslogd config kernel messages of certain severity levels end up in syslog (typically /var/log/messages). To undo the loglevel increase: # echo 0 > /sys/module/scsi_mod/parameters/scsi_logging_level -- Mit freundlichen Grüßen / Kind regards Steffen Maier Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschaeftsfuehrung: Dirk Wittkopp Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
smime.p7s
Description: S/MIME cryptographic signature
