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/failed
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 lists...@vm.marist.edu 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/
