Hi Scott,
with RHEL(5), the persistent zfcp lun configuration is in the simple
text file /etc/zfcp.conf. I don't know of any tools to manage this file
except during the installation (with anaconda). Hence, any text editor
will do.
See also
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-s390info-zfcp.html
which does describe post-installation configuration despite being part
of the install guide.
Steffen
Linux on System z Development
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
On 05/20/2011 09:55 PM, Shumate, Scott wrote:
Sorry. Im running red hat version 5.4
-----Original Message-----
From: Mark Post
Sent: Friday, May 20, 2011 3:49 PM
On 5/20/2011 at 02:59 PM, "Shumate, Scott"<[email protected]>
wrote:
I ran into something interesting today with zFCP disk. I've assigned
a LUN to a linux server and it worked great. I did the following.
1. Set the adapter on line with chccwdev -e command
2. Added target port to FCP adapter by echoing port_add into wwpn.
ex. echo 0x50060e800571f007> port_add
3. I cd to new port directory and added FCP LUN to that port by
echoing unit_add into new port directory.\
ex. Echo 0x000b000000000000> unit_add
4. SCSI disk was available. I validated it with lsscsi command.
I noticed that the LUN size was incorrect so I wanted to change the
adapter to use a different LUN. In this case 0x0007000000000000. I
removed the old LUN and changed added the new LUN with the following
script.
#!/bin/bash
OLD_PWD=`pwd`
DIR=/sys/bus/ccw/drivers/zfcp
DROP=0x000b000000000000
ADD=0x0007000000000000
PORT1=0x50060e800571f007
PORT2=0x50060e800571f017
PORT3=0x50060e800571f006
PORT4=0x50060e800571f016
echo 1> /sys/bus/scsi/devices/0\:0\:0\:1/delete
echo 1> /sys/bus/scsi/devices/1\:0\:0\:1/delete
echo 1> /sys/bus/scsi/devices/2\:0\:0\:1/delete
echo 1> /sys/bus/scsi/devices/3\:0\:0\:1/delete
echo $DROP> $DIR/0.0.dc00/$PORT1/unit_remove echo $DROP>
$DIR/0.0.dd00/$PORT2/unit_remove echo $DROP>
$DIR/0.0.de00/$PORT3/unit_remove echo $DROP>
$DIR/0.0.df00/$PORT4/unit_remove echo $ADD>
$DIR/0.0.dc00/$PORT1/unit_add echo $ADD>
$DIR/0.0.dd00/$PORT2/unit_add echo $ADD>
$DIR/0.0.de00/$PORT3/unit_add echo $ADD>
$DIR/0.0.df00/$PORT4/unit_add
It shows the new LUN. I validated it with the lszfcp -D command.
Output below:
0.0.dc00/0x50060e800571f007/0x0007000000000000 0:0:0:1
0.0.dd00/0x50060e800571f017/0x0007000000000000 1:0:0:1
0.0.de00/0x50060e800571f006/0x0007000000000000 2:0:0:1
0.0.df00/0x50060e800571f016/0x0007000000000000 3:0:0:1
So you can see that the lun is now 0X0007. When I reboot, it goes
back to 0x000b. What am I missing? To get around this issue, I had
to move LUNs around on the disk subsystem side. Can someone give me a
good process of removing LUNs and then readd them or tell me what I'm
missing.
You didn't say what distribution you're running. That's not relevant to
why you're seeing this happen, but it is relevant to how you fix it.
Essentially, every command you issued is a dynamic change to the system.
Nothing was done to tell the system to do anything different on the next
boot. If you are running SLES, then the answer is to either:
1. Use YaST to do this work.
2. Use zfcp_host_configure and zfcp_disk_configure 3. Manually update
all the necessary configuration files yourself.
I would pick option #1 or #2. :)
----------------------------------------------------------------------
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/
