hpux 11.31 and SAN issues

[LynnG]

Hello all -

I have a call into HP Call Center about this issue as well, but thought in the meantime I would chat it up with fellow SAs about it too.

We have a two node cluster of rx4640's running hpux 11.31 both connected to IBM DS8000. I am focusing on the failover node at this time. We originally had 12 LUNs (shared and dedicated) when server was first built. Now an additional 61 dedicated and 31 shared have been added from another DS8000.

The other day, I tried to configure the drives, however, they were not lining up properly and I was getting a ton of NO_HW errors, so I had SAN team relook at their side and all was well with the world.

In my inexperience with ia64 servers and 11.31 I didn't realize there was both the agile and legacy formats when addressing disk drives, I performed an rmsf -a /dev/dsk/c?t?d? and tried to ioscan -f, ioscan -fnC disk, etc and insf -e, however my ctd drives did not come back.

Of course now (in having this ticket opened with HP) I know about the legacy to agile disks, my question is, should I have performed an rmsf -a /dev/disk/disk?? as well?

At this time we are looking at remapping the ioconfig table, but it appears I still show the new LUNs mapped with the multipathing and a starting ext_bus number

0/2/0.106.45.255.1 ext_bus 70
0/2/0.106.76.255.1 ext_bus 77
0/4/2.107.45.255.1 ext_bus 60
0/4/2.107.76.255.1 ext_bus 66

I'm trying to grasp the understanding on how replacing this file will assist me and why I can't just rmsf -a /dev/disk/disk??? of all the new LUNs and rescan with ioscan and insf -e?

The reason I ask this is what would happen if this SAN was deallocated and the server moved to another project, but the OS remained the same (no reload) and new SAN from another DS8000 or even EMC was added, wouldn't I be in the same predicament?

I've been doing this UNIX SA stuff for a bit, but have never run across the issue of going passed the 255 ext_bus limit.

Thanks in advance for reading my long winded thread.

Lynn

[Animesh Chakraborty · Accepted solution]

Hi Lynn,
Some new commands on HP-UX 11.31


insf -L
Restores legacy DSFs and legacy configuration information.
rmsf -L
Aids in migration by removing all legacy DSFs and legacy configuration information.

ioscan â m dsf
Maps persistent DSFs to their equivalent legacy DSFs and vice versa.

We need to read the manuals before working with hp-ux v3 storage stack.
Now it has lot of new features.

http://www.docs.hp.com/en/MassStorageStack/The_Next_Generation_Mass_Storage_Stack.pdf

http://docs.hp.com/en/LVMmigration1/LVM_Migration_to_Agile.pdf


http://www.docs.hp.com/en/dsfmigration/persistent_dsf_migration.pdf

[Animesh Chakraborty]

That is

#ioscan -m dsf

[LynnG]

I apologize for not assigning points earlier, our problem was we maxed out the 255 addresses for ext_bus with the way the SAN team assigned paths.

Once we figured out the way the assignments were being done, we were able to then deallocate the SAN space just presented, reboot server to clean up NO_HW, remove any stale paths (rmsf -x), then check the ioconfig file to ensure it was clean, then readd the SAN again the "correct" way.

Problem solved and I appreciate the information I received out here. I will be closing this thread.

[LynnG]

check out the information above, this problem was resolved.

[Duncan Edmonstone]

Lynn,

What I'm not clear on is that 11.31 was supposed to remove the limit of 255 ext_bus instances for agile DSFs at least. Were you having to use the legacy DSFs for some reason?

HTH

Duncan

[LynnG]

Yes, Duncan, again, my apologies, the client was already using legacy pathing and we were going to add in space to an already existing volume group. The client was not prepared (I must admit, nor was I - as I haven't had much of an opportunity to work on 11.31 ia64 servers - they are still fairly new to our environment). Anyway, the client was not prepared to move to the agile addressing, although, that's one of my next things on the agenda to talk with them about) :)

So there's the story, client using legacy drives. The SAN team was utilizing essentially only 1 LSS per LUN address, and dual pathing (4 paths total), so for each LUN, we were issuing a new ext_bus, take 98 LUNs multiply that by 4, and you've already went way pass the ext_bus addressing, not to inclue the LUNs already in place.

So, in all my dilemma, I can honestly say at least I learned a great deal that I will NEVER forget.

Thanks for keeping me honest Duncan!