HPUX - SAN Change (Zoning)

[Asghar Ghori]

Hi,

We have 55 servers all running HPUX 11i connected to 3 XP1024 storage devices through about 44 Brocade 3900 SAN switches. There are 12 tape libraries connected to SAN as well. There is no zoning in the env. so everybody sees everybody out there. Now we are planning to introduce zoning to control who can see who.

What we are told is that if we introduce zoing and then reboot each hpux server, things will be fine but someone says that there could be issue with /etc/ioconfig and/or /stand/ioconfig files as they will have to be manually updated to reflect what devices HBAs on that particular server are not able to see now.

Please advise a solution.

Thanks

[Sundar_7]

You dont have to reboot the system

1) Introduce zoning

2) execute ioscan and refersh the kernel

3) execute rmsf and remove the device files of those disks the system is no longer going to see

4) If still in doubt

# mv /etc/ioconfig /etc/ioconfig.OLD
# mv /stand/ioconfig /stand/ioconfig.OLD

# ioinit -c

ioinit will recreate the ioconfig files for you

-- Sundar

[Jim Turner]

You'll simply wind up with some "NO HARDWARE" entries in your ioscan. You can safely remove the special files associated with those via rmsf(1M).

[Jim Turner]

There is a caveat to step 4 above. If you have added adapters over time and out of order with numeric hardware addresses, step 4 above will have great risk of assigning instance numbers to devices that do not match what you had before. Your mileage may vary. Proceed with caution.

[Sundar_7]

Yes, Jim has a very valid point there.

# ioscan -fnC ext_bus | egrep -v "H/W|==" | awk '{print $3,$1,$2}' > /root/infile

# mv /etc/ioconfig /etc/ioconfig.OLD

# mv /stand/ioconfig /stand/ioconfig.OLD

# ioinit -f /root/infile

If there are only "line ignored" messages from ioinit, then you are good to go and dont have to reboot the system

If there are any inconsistencies, ioinit will report. But you cannot make the changes without rebooting the system

# mv /etc/ioconfig /etc/ioconfig.OLD

# mv /stand/ioconfig /stand/ioconfig.OLD

# /usr/sbin/shutdown -r -y 0

system will stop at ioinit prompt at bootup

ioinitrc) ioinit -f /root/infile -r

[Todd McDaniel_1]

I think the safe way is to vgexport -s the VGs.

So long as your disks are all only owned by a single host. Then when you zone the disks to specific hosts, and then vgimport -s your disks and filesystems will come back properly.



I am doing a similar thing in a few months were I am vgexporting while we redo our entire switch fabric, when we redo the switches I will vgimport -s and the disks will be read back in just as they were before. then I reboot and good to go.

[Steven E. Protter]

Haveing been through a few rezonings in my shop I recommend the following:


full backup of data prior to the change.

A vgexport is a good idea as well.

ioscan or boot, your choice.

With these steps you should be covered.

SAN administrators are famous for reassuring sysadmins that everything will be fine. Sometimes its true, sometimes not.

SEP

[Paresh]

There is a limitation on the ext_bus class. The max instances for ext_bus is 255. These instances are stored in the /etc/ioconfig file. When zoning is performed these instances are still sitting in the file & will not get removed with the rmsf cmd. Usually with a large SAN installation if the switch domain id changes during build these ext_bus instances are stored in the /etc/ioconfig file & are never released. Due to this whenever a new hrdwr such as a new HBA card or a new tape library is installed in the fabric could cause exceeding this limitation. These device will show as unclaimed & will not be accessible. Also this could sometimes cause the system to panic intermittently. The fix to this would be to perform ioreconfig which is the ioinit -c followed with an ioinit -f /infile where infile is a capture of all the hardware path to ext_bus instance # mappings previous to the process. This will retain the prev disk device files & will also not need the process of vgexport/import & will cleanup the unused instances. It would be a good practise to perform ioreconfig immediately after zoning in large environments where capacity is constantly increasing to avoid running into the ext_bus limitation. The ioreconfig process is well documented in the kmine doc id KBRC00013394. Thx.

[Jim Turner]

Good point, Paresh. That is one of the reasons I use LUN masking (Secure LUN Mgr XP) to limit which HBAs can see what LUNs. I do *some* hardware zoning in the switch on top of that, but LUN masking is my main line of defense.

[Todd McDaniel_1]

I agree, we use lun masking, and it works very well.