Your input on physically locating a component on a system

[marie-noelle jeanson_1]

Hi,

HP would like to hear from your experience about locating physically a component on an HP9000 system (integrity server or PA-RISC server).

What process do you use:
Do you use the ioscan output? olrad -q output? Others?
Do you get information from the hw path?
What are the main difficulties encountered?
What could make your life easier?

Points will be distributed to reward your feedback. Thanks,

Marie.

[Patrick Wallek]

I generally start with the HW path from ioscan. Then I will attempt to determine the physical location from there.

Some servers (K-series, D-series, I believe L-series) have the I/O slots labeled with the appropriate path. That is extremely helpful.

If the slots aren't labeled I'll look for documentation on the machine that includes an I/O path diagram and go from there.

I have not used any of the olrad commands, but what would be helpful is if all cards had some sort of light that you could make blink via some command to locate the appropriate card.

Or, possibly better, put some sort of light on/above/below each slot so that a particular path can be located even if the card in it is dead.

[Steven W. Illgen]

The processes for physically locating a component normally used here are ioscan, and xstm, in that order.

I used to rely on the HW path alone for locating equipment on older systems like the D- and K-series; however, with increasingly complex systems and the use of disk arrays, the number and length of HW paths on an average system has grown more numerous and complex as well. It would be great if, somehow, the HW paths, themselves, could be replaced by a simpler method of location identification. For example, use PCI:1 to define the PCI card in slot 1 or MEM:1:2 to define the memory board in Cell 1, Slot 2.

Thanks for taking the time to ask this.

Steve Illgen

[A. Clay Stephenson]

I close my eyes and I hear a voice saying "Use The Force, Clay". I then just know the c2 or lan1 is in a given slot. It might just be that I actually read the techical documentation beforehand that comes with each model so that I understand the correspondence between the H/W path and the physical location of the device. In that case, it only seems as though I'm using "The Force".

I do use ioscan, olrad and lanscan. The real trick is to have that data while the box is in a "good" state to compare with when the box is in a "bad" state.

I also make it a practice to label every card, disk, tape drive, ... on my machines so that I know what is SCSI c2 without having to do anything.

I really don't have any difficulties in the areas you describe.

I suppose the only improvement I might find useful would be an ioscan option that actually mapped a hardware path to a physical slot and possibly the port on the card itself. That might be a rather challenging task given that the command would have to work across a spectrum of models / cards.

[Steven E. Protter]

Shalom Marie,

The voice in my head says, "Use the cron Steve".

Basically, I automate the output from these tools, preferring to route it to a mail box my operations department(help desk) are required to read.

I also try and mimimize the output so that I can scan it visually without going blind.

I generally get my hardware path information from ioscan or a script automated cstm script.

I definitely use the ioscan output, especialy when I'm looking for things that should be there and are not there.

What would make my life eaier?
Les users, making outlandish requests they don't understand, less help desk calls.

Bascially, forums make my life easier. I read regularly, take good script ideas, download and read documents posted and use the tricks to make systems run better.

Some of the best systems administrators are the laziest. They let their slave cron do the work, up to and including sending sms messages to their cell phone when there really is something wrong.

SEP

[marie-noelle jeanson_1]

Hi,

Thank you for your feedback, no big surprise here, but I just wanted to make sure about the reality of things for you users and see if you have any smart tricks or major issues to report. Your ideas all make sense.

What I would love to see myself happen is that one day you no longer need to refer to these I/O path diagrams but can use some tool omline to replace them.
What additional info from cstm do you use that is not provided by ioscan?

I also had the idea of LEDs (but you want to make sure that you do not have several admins playing around with the lights at the same time!).
Providing more clear slot # information in ioscan may be also a way to go.
Of course all of the above works well when the system is up. Stickers and IO path diagrams will remain useful when the system is down.

Steve, by minimizing the ioscan output, do you mean that you filter some infor that you are not interested in?

You are right that hw paths get longer and more complex. This is why I am looking into this.

Marie.

[A. Clay Stephenson]

The LED display method suffers from an obvious flaw. The bad hardware might not be able to flash the LED or it might flash it continuously. I would not encourage any of my admins to use methods that might (usually) work. The far better answer is to give them the tools that work everytime -- labels and ioscan beforehand. Long H/W paths don't seem to be any impediment and I would always want too much data rather than too little. I suppose I am old school but servers ain't PC's; as an admin you are expected to know a little more than "replace board with winky-blinky light".

It would seem to me tha a mapping of H/W Path (however long) to physical slot works
each and everytime.

[Bill Hassell]

In the good old days (as Patrick laments), hardware paths were labeled (K, D, A, etc) but if they aren't labeled, the hardware paths are very intimidating. The fact that each server product line has a different I/O path layout doesn't help at all. About the only workable solution is to open the docs for each new server, make a physical-to-IO path map and then add labels to the box. A Visio diagram would also be helpful. Put all of this online on a maintenance server. This also applies to multi-device boxes such as tape changers and disk frames.

[Deependra]

Basically the output from ioscan and the label on the I/O slots are enough to find out the information. But if the labels can not be put at the slot then some sticker with the layout of the I/O slot can be put somewhere on the system (this can be additionally provided even if the I/O slots are labeled). There can be some additional copies (2-3) of that sticker so that the sys admins can put at some location on the rack they feel comfortable (may be one copy with their hardware records also). The sticker should include the model of the server and must also have a place to write the serial number so that they can be matched even if the locations are changed.

BR

[Sivakumar TS]

Apart from the above commands, we can use the MP as a powerful tool. We login to MP and using MP>CM commands like,

IO
CP
DF

we can identify the components.

With Regards,

Siva.

[Sivakumar TS]

Apart from the above commands, we can use the MP as a powerful tool. We can login to MP and use MP>CM commands like,

IO
CP
DF

we can identify the components. It gives the details about each and every FRU.

With Regards,

Siva.

[Greg Vaidman]

I recently wrote the following short script to help with this very question (all my systems support rad, I suppose I'll have to update it to choose olrad when necessary)...

#!/sbin/sh
PATH=/usr/bin:/usr/sbin
typeset -R3 slot
typeset -R8 hwpath

rad -q | awk '($1>0&&$1<=999){print $1,$2}' | while read slot hwpath; do
desc1=$(ioscan -kfH ${hwpath}| grep -v "^ba[[:space:]]"| head -3| tail -1)
class=$(print "${desc1}"| cut -d' ' -f1)
count=$(ioscan -kfH ${hwpath}| grep -c "^${class}[[:space:]]")
desc=$(print "${desc1}"| sed 's/[[:space:]][[:space:]]*/ /g'| cut -d' ' -f7-)
print "Slot $slot - HW Path $hwpath - (${count}x) ${desc}"
done

The output looks something like:

Slot 5 - HW Path 0/2/0 - (0x)
Slot 6 - HW Path 0/5/0 - (0x)
Slot 7 - HW Path 0/1/0 - (0x)
Slot 8 - HW Path 0/3/0 - (1x) SCSI C1010 Ultra160 Wide LVD
Slot 9 - HW Path 0/9/0 - (4x) HP A5506B PCI 10/100Base-TX 4 Port
Slot 10 - HW Path 0/8/0 - (1x) HP Tachyon XL2 Fibre Channel Mass Storage Adapter
Slot 11 - HW Path 0/12/0 - (1x) HP Tachyon XL2 Fibre Channel Mass Storage Adapter
Slot 12 - HW Path 0/10/0 - (1x) HP Tachyon XL2 Fibre Channel Mass Storage Adapter

[marie-noelle jeanson_1]

Greg,

This is good, however I just want to point out that not all devices will show up in rad as it reports only info for hot pluggable slots.

Thanks anyways,

Marie.

[Sameer_Nirmal]

Hi,

We all know the importance of Part Model Number or Part Number.
I would like to see Model number appeared in "ioscan" for replacable hardware where-ever applicable. The same should be reflected in "print_manifest" , STM Info Tool alongwith part number etc.
This will help to keep the inventory of those parts ( through script etc ) which would be useful for order and replacement.

Mapping through complex H/W path is tedious job since H/W path is not marked or embossed on the panel on recent servers. In this case,
a document (soft copy) showing system views should be given by HP showing all inside, outside of server alongwith the H/W paths. This document could be attached to the server chassis to easy during any hardware activity. A Visio diagram could be made available.

It will be nice to get a complete snapshot of a server hardware through say HP *Insight* Manager.

[Kent Ostby]

Starting with ioscan is fine.

When it comes to CPUs, the logical to virtual mappings get a bit complex and unless you have block diagrams for the machine, it gets a bit difficult.