A Few Links
kb.netapp.com is a fantastic resource, unfortunately, if you Google stuff, it will never appear in the list of answers (because kb.netapp.com requires a login, so Google’s anonymous searches cannot scan it’s pages - at least that’s my guess.) The three links below all point to kb.netapp.com.
If, when you run “igroup show” the -
“HP-UX Host Bus Adapters (HBAs) will only appear as logged in if there is I/O activity on the path.”
To check if I/O is on the partner path:
lun stats -z (zero’s the statistics)
lun stats -o (displays extra statistics including whether I/O is from the partner path)
If host Multipathing (HP pvlink Multipathing, Veritas DMP) is not configured on the HP-UX host, it is possible you will see this.
If you have NetApp’s FC Host Utilities Kit (HUK) for HP-UX installed:
sanlun lun show
sanlun lun show -p
Some things to consider with a HP-UX SAN Migration
Credits: The below is mostly excellent advice given by awesome people who know something about HP-UX (not me)
If you’re migrating LUNs for HP-UX hosts, you need to be aware of whether they are currently using the Agile or Legacy naming standard (Legacy DSF.) The Agile naming scheme was introduced in HP-UX 11i v3 (read here HP-UX 11i v3 Mass Storage Device Naming) so anything older and it’s Legacy. The discussion below considers only the Legacy naming scheme.
If you’ve got a migration plan like the below (you could also consider a no-downtime online migration using LV mirroring):
1) Applications get shut down
2) HP-UX hosts get shut down
3) Final SnapMirror update
4) SnapMirror break
5) Re-serial mirrored LUNs with old serials (not totally necessary with HP-UX but we’ll do it anyway)
6) Map LUNs to igroups using same LUN ID as before
7) HP-UX hosts are patched into a new fabric
8) HP-UX hosts get powered up
9) Applications get restarted
With Legacy naming, at the highlighted step 7, your device ids are likely to change. This is because when HP-UX detects a path change, such as a new fabric, it will assign new legacy device file names to the disk devices when the ioscan command is run.
Before the Migration
Before migration you should document the:
ioscan –fnkC disk
lvdisplay -v /dev/vgxx/lvxx (for each logical volume)
ls -l /dev/*/group
sanlun lun show (if the HUK is installed)
sanlun lun show -p (if the HUK is installed)
Note: You can also collect all the config data using NetApp’s nSANity tool.
What to Expect During the Migration
The “ioscan -fnkC disk” run on the HP-UX hosts will give you the FC_ID, as highlighted in an extract from an output below (basically the 3 entries after the first dot.)
Whether this will change or not, depends on how your Fabric Switches are configured. If your Fabric switches are the same make, have the same domain ID’s (Fabric A will have a different domain ID to Fabric B), and you’re using the same ports for connecting your HP-UX hosts too, then the FC_ID might just stay the same (don’t quote me on this). If not then your device file names will change from say (doesn’t actually matter what the FC_ID changes too, just that it changes):
Completing the Migration
And this is where you will need a Unix Administrator/Expert on hand who’s comfortable with with page 49 and section “5 Disruptive migration” of the following link: