Your opinion on the usefulness of displaying devices WWN in ioscan

[marie-noelle jeanson_1]

Hi,

HP is looking at making some changes to the hw path used by HP-UX for SAN devices in future releases. We would like your opinion on the following.

Today, the hw path of SAN devices contains domain/ara/port and bus/target/lun information. For instance, with a Fibre Channel attached device, the hw path would look like 0/1/2/0.1.19.255.15.4.0

In the future, we would like the hw path of SAN devices to become agile, by replacing the location info in the hw path (domain/area/port and bus/target/lun) by something independent of the location, for instance, the device WWN and LUN-id. So the hw path would look like 0/1/2/0.0x.0x.

Problem is, this hw path becomes fairly long as the WWN has 64 digits, so as a result, such hw paths may not display well in ioscan (lines too long) and it will not be easy to type commands including a hw path parameter as the string will be very long to type (can only imagine it to be ok if cut/paste is possible).

The question is:
How useful is it to include the WWN itself in the hw path? (note: this is not the WWN of the HBA in the system, but the WWN of the SAN attached device). It seems that in reality, the device WWN is not used to locate the device, but rather, the Port_id and lun info are used. So would it be better to use some indexation instead of including the WWN in the hw path, if we provide also another command to map that index to the WWN/LUNid info?

Any comments??? Thanks! Points will be assigned to the best answers!
Not sure I should have posted this under SAN?

Marie.

[A. Clay Stephenson]

1) Make sure that there is an option to change the behavior; otherwise the existing convention is used by default. UNIX persons hate fixing scripts that have run for years because a command has been "improved".

2) The length of the line is of no concern unless it exceeds LINE_MAX (run getconf LINE_MAX). It's very common to have commands that wrap 80-column lines.

3) The length of the string itself doesn't matter. If one can't type correctly, that's called an error but no one is going to type it anyway. No UNIX person ever uses cut and paste; cut and paste is for wimps. UNIX persons use scripts.

4) I would avoid indexing; that simply adds a layer of obfuscation and indirection that makes scripting less obvious and more complex.

[Mel Burslan]

Considering the number of interfaces with unique WWNs are considerably low when you look from the perspective of the host system, and their low failure rate (requiring les and less replacements causing WWN changes) added to the fact that almost every shop with SAN nowadays have an almost dedicated SAN administrator to track these changes, I do not see a great benefit adding WWN into the ioscan output, myself.

And totally agree with Clay's first point of view: if this "enhancement" is inevitable, make sure to include a command line switch to display information in the "classic" mode

[A. Clay Stephenson]

No, no, no. The command-line switch displays the "improved" format; the classic format, by definition, is the default. Any other conventions breaks existing scripts.

[Marc Ahrendt]

a suggestion may be to just put the WWN and/or LUN ID info in the "Description" column (or append to it) instead of tweaking the "H/W Path" column ...at least in my environment the "Description" column for disk and tape drives is useless information

[Devesh Pant_1]

I can see that the changes will help improve the wwid based device mappings as was/is the case in Tru64 unix.

It would be excellent to have the classic ioscan the way it is and have something like ioscan -A switch which will provide the wwids associated to the device

thanks
Devesh

[Patrick Wallek]

I vote for the way Clay suggests. Leave the default behavior of ioscan as is and just add an option to provide the WWN.

I'm really not sure how much I would use the WWN option. At this point, I don't think I would find that very useful.

[marie-noelle jeanson_1]

Hi all,

Thanks for your input. I am sorry, I forgot to mention that the change will be part of a new option, we are keeping the existing ioscan output backward compatible in order not to break your scripts! Thanks for bringing this up.
Also, the change really only affects SAN environments, so hw paths for other devices (LAN, ...) will not change.
Just wanted to clarify,

Marie.

[Duncan Edmonstone]

Marie,

As far as I can see, we already have a precedent here. An option was added to ioscan on Itanium systems to display the EFI hardware path ('-e' I think). So a similar option for WWN/LUN combination would make sense. As to actually putting the WWN in the hardware path, I agree that some sort of index value that can be translated would be more useful than putting the whole WWN in.

That said, its good to hear we are finally going to get away from the nightmare that is hardware paths based on FCIDs!

I take it this will be for 11iv3 rather than any patch for 11iv2?

HTH

Duncan

[Duncan Edmonstone]

Marie,

while we are on the subject of new IO features in HPUX, can we expect to see an 'online LUN resize' otion in 11iv3? SO we can resize an EVA vdisk and not have to reboot to see the new disk size?

Thx

Duncan

[Alexander M. Ermes]

Hi there.
Marie, trust Clay Stephenson. He forgot more about UNIX than i will ever learn.
I am an absolute fan of his solutions, because they simply work.
Rgds
Alexander M. Ermes

[Donald Kok]

Hi Marie,
I would be happy to have an option not seeing the WWN.
Greetzz
Donald

[Thayanidhi]

Hi,
The current H/W path looks OK for me, but issue is if any SAN component changed (even the port connection changed) hp-ux see the disks as new and creates new device file. This behaviour renders lots of unix admin work to re-import the VGs. I think HP is working on this already to bind target wwwn into device file names (like what secure path does). But I would like to see the LUNs/disks as legacy device names(cxtxdx).

Good topic!

Regds
TT

[Armin Kunaschik]

Just to be curious:
If the WWN of the switch/box changes, do I get new disk devices?
This would break the current lvmtab and every SAN VG needs to be re-imported.

If this is true, the WWN should not be included in the HW path.
You could add ADDITIONAL new devices (or links) which include the WWN. This might be usefull.

But I think it's not necessary at all to include the WWN in the HW path.

my 2 cents,
Armin

[Uwe Zessin]

Armin,

I expect the system to use the WWPN of the storage array, not the fibre channel switch's port. The WWPN is not supposed to change when you replace the controller of a storage array. The binding to a fibre channel address even when in fabric mode is a big pain!

And I'd like to have an option to display the LUN WWN from VPD page 83(16) - similar to what is shown in Secure Path (# spmgr display).


And please do change the default output so that all scripts of our bored system administrators blow up ;-)

[marie-noelle jeanson_1]

Hi all,

Thanks for the great input. Your comments/questions are well taken and we are working on some of the improvements you mentionned.

Marie.