masking issue with Hp-UX

Question

I have four LUNs masked to a particular HP-UX(11.11) host and 'symdev -sid xxx show abcx" shows the following where abcx is diffrent LUN numbers. As you can see the first one is showing visble while rest three are not.. While loking at the GUI all those luns showing "granted".

Any sugetions.. I am planning to umask&umap & and try again..

Also here the status for the paths.

150 0/0/10/0/0.97.10.19.0 000190101854 FA 14dA 18 0
235 0/0/8/0/0.98.10.19.1 000190101854 FA 3dA 93 0

Front Director Paths (2):
{
----------------------------------------------------------------------
POWERPATH DIRECTOR PORT LUN
--------- ---------- ---- -------- ---------
PdevName Type Type Num Sts VBUS TID SYMM Host
----------------------------------------------------------------------
/dev/rdsk/c235t15d7 PARENT FA 03D:0 RW 001 0F 007 007
/dev/rdsk/c234t15d7 CHILD FA 14D:0 RW 001 0F 007 007
}

Front Director Paths (2):
{
----------------------------------------------------------------------
POWERPATH DIRECTOR PORT LUN
--------- ---------- ---- -------- ---------
PdevName Type Type Num Sts VBUS TID SYMM Host
----------------------------------------------------------------------
Not Visible N/A FA 03D:0 RW 002 00 000 N/A
Not Visible N/A FA 14D:0 RW 002 00 000 N/A
}

Front Director Paths (2):
{
----------------------------------------------------------------------
POWERPATH DIRECTOR PORT LUN
--------- ---------- ---- -------- ---------
PdevName Type Type Num Sts VBUS TID SYMM Host
----------------------------------------------------------------------
Not Visible N/A FA 03D:0 RW 002 00 001 N/A
Not Visible N/A FA 14D:0 RW 002 00 001 N/A
}

Front Director Paths (2):
{
----------------------------------------------------------------------
POWERPATH DIRECTOR PORT LUN
--------- ---------- ---- -------- ---------
PdevName Type Type Num Sts VBUS TID SYMM Host
----------------------------------------------------------------------
Not Visible N/A FA 03D:0 RW 002 00 002 N/A
Not Visible N/A FA 14D:0 RW 002 00 002 N/A
}

xe2sdc · Accepted Answer

I am still not clear abou the Controller/X number.
I am not sure why it is picking Vbus2 and would that
cause to this problem.

it would be due to the mapping done on symmetrix.
while mapping devices on cli, you can, rather need
to, specify the vbus tid parameters and those are
visible to host.

HPUX have a very complex behaviour when it comes to disks .. The target and lun part of the special file name is almost self explanatory. The controller part is a little more complex since HPUX will create a different cX (controller instance = ext_bus in ioscan) for every different vbus seen from every different FCID where it can see some kind of storage device.

The same complex behaviour is the root cause for the strange behaviour that HPUX shows if you unplug the storage from the switch and plug it again in a different port. If you change the port on the switch where the STORAGE is connected, the host will LOOSE the "moved" path to the storage. You have to issue ioscan and insf to re-create brand new devices and -since the controller is a combination of FCID and VBUS- you'll find brand new controllers with the same targets and luns as before.

Look at the following fake hardware path:

root/of.host/path.to.fc-controller.ww.kk.hh.xx.yy.zz

If you look at the rightmost part of ioscan output for a "disk" instance, you'll find (from right to left) the lun(zz), the target (yy), the vbus (xx), three numbers (ww.kk.hh) that form the FCID of the port where the storage is connected and if you keep on moving left you'll find the FC controller itself (ioscan -fnkC td i suppose). If you merge in a single blob (ww.kk.hh.xx) you'll have the so-called ext_bus. If you change any value in the "blob" HPUX will allocate a brand new ext_bus = a brand new controller. That's why you have different controllers when devices have different vbusses

SKT2 · Answer

what those values meansVBUS TID SYMM Host

xe2sdc · Answer

When you map symdevs for your hpux hosts, you have to assign three different nibbles .. the first one (VBUS) is a mysterious one

and will be explained better later. The values you choose for Target and Lun are exactly what you'll see in your /dev/dsk/cXtYdZ

The value you choose for Target will be the Y while the value choosen for Lun is the Z in the above template.

HP choose the so called Volume Set addressing (that maps to the V-bit when configuring a FA port) so when you configure your storage, it will show up on your host like a complex infrastructure of different controllers, targets and luns .. We already talked about luns and targets .. I must only add that legal values for Lun are from 0 to 7 (so even if it's a full hex nibble you can't use the upper bit) and for Target are from 0 to 15 (a full nibble). The third value you configure when you map devices on the frontend of a FA configured for HPUX (the mysterious vbus) becomes part of the controller (the X in cXtYdZ) with the FCID of the port where the storage is connected.

Please have a look at http://docs.hp.com/en/A6795-90006/ch01s11.html if you want to understand how to "decode" an hardware path

The symm-lun and host-lun are new in 6.4 to support the dynamic lun addressing. If you are NOT using DLA, look only at the symm-lun.

Message was edited by:
Stefano Del Corno

xe2sdc · Answer

/dev/rdsk/c235t15d7 PARENT FA 03D:0 RW 001 0F 007 007
/dev/rdsk/c234t15d7 CHILD FA 14D:0 RW 001 0F 007 007

Not Visible N/A FA 03D:0 RW 002 00 000 N/A
Not Visible N/A FA 14D:0 RW 002 00 000 N/A

The first strange thing I can notice is that you have a lot of controllers

The second thing that I can notice is that the last volume you can see have a VBUS=1 while the first one that's giving you PITA have a VBUS=2 .. This means that HPUX have to allocate another virtual bus controller for the volumes with vbus=2. Maybe you are out of virtual controllers

Forgive the silly question .. Did you run insf -e ??

Message was edited by:
Stefano Del Corno

SKT2 · Answer

you observation is right..we have reached the ext_bus usage from 1-255 which is the limit in HP-UX. we will be freeing up some unused ne during the next outage.as of now we are able to allocate LUN though existing ext_bus instaces like 234, and 235 or which ever,I am still not clear abou the Controller/X number.I am not sure why it is picking Vbus2 and would that cause to this problem.Some correction to old post234 0/0/10/0/0.97.10.19.1 000190101854 FA 14dA 93 0235 0/0/8/0/0.98.10.19.1 000190101854 FA 3dA 93 0disk 2890 0/0/8/0/0.98.10.19.1.15.7 sdisk CLAIMED DEVICE EMC SYMMETRIX /dev/dsk/c235t15d7 /dev/rdsk/c235t15d7disk 2889 0/0/10/0/0.97.10.19.1.15.7 sdisk CLAIMED DEVICE EMC SYMMETRIX /dev/dsk/c234t15d7 /dev/rdsk/c234t15d7why 'HPUX have to allocate another virtual bus controller for the volumes with vbus=2'?

Kiran3 · Answer

I am still not clear abou the Controller/X number.I
am not sure why it is picking Vbus2 and would that
cause to this problem.

Please have a look at a different thread named " mapping ctd's to lun number to symm device number on HPUX" in the Software area of the forums "EMC Support Forums » Host Software" .. Enjoy !!

Message was edited by:
Stefano Del Corno

SKT2 · Answer

1575 /dev/rdsk/c235t15d7 (M) 1 0F 007 157D Not Visible (M) 2 00 000 1585 Not Visible (M) 2 00 001 158D Not Visible (M) 2 00 002

Kiran3 · Answer

since you have vbus set to 2, host will see the same.
i am not a HP guy but choosing different vbus id for luns shouldnt have any impact.

are there any free IDs on this FA? it will be indicated by * in the output of same command.

xe2sdc · Answer

I am still not clear abou the Controller/X number.I
am not sure why it is picking Vbus2 and would that
cause to this problem.

Please have a look at a different thread named " mapping ctd's to lun number to symm device number on HPUX" in the Software area of the forums "EMC Support Forums » Host Software" .. Enjoy !!

Message was edited by:
Stefano Del Corno

xe2sdc · Answer

HP have 2 different drivers for FC cards .. they are called FC ant TD .. I never used option 'u' with ioscan .. but I can tell you a secret .. option 'k' will save you time and pain

SKT2 · Answer

That a was 'goal' response'ioscan -funC fc' it is...

SKT2 · Answer

Also about mapping by CLI..(finding the next available Vbus, TID, or LUN ; and use map command)

Is it really possible to still map to VBUS0/VBUS1? Because we have already covered the possible TID(00-0F) and LUN(000-007)for both VBUS0 as well as VBUS1

So i guess we will be defaulted to VBUS2..

xe2sdc · Answer

Santhosh I don't really know how you map devices on the FA .. I usually find available "slots" and map my devices using available luns. I use the "symcfg -sa xx -p w -address -available -sid 123 list" to find slots .. In the output you'll have lines marked with an "*" .. This is where begins the next available gap (if we call "gap" a contiguous set of free "slots"). I don't have hp-ux ports to show you .. But I hope the following example is clear enough.

star1_prod/root> symcfg -sa 4a -p 0 -sid xxx -address -available list

Symmetrix ID: 000287890xxx

Director Device Name Attr Address
---------------------- ----------------------------- ---- --------------
Ident Symbolic Port Sym Physical VBUS TID LUN
------ -------- ---- ---- ----------------------- ---- --- ---

FA-4A 04A 0 - AVAILABLE 0 00 000 *
0185 Not Visible (M) 0 00 025
0191 Not Visible (M) 0 00 026
019D Not Visible (M) 0 00 027
01A8 Not Visible (M) 0 00 028
- AVAILABLE 0 00 029 *
0653 Not Visible (M) 0 00 03D
- AVAILABLE 0 00 03E *
0659 Not Visible (M) 0 00 03F
0365 Not Visible (M) 0 00 040
...

If you look at the output, you'll notice that LUN 000 (it's a Solaris port) is marked with an "*". So I can say that there is a gap of available slots that begins with lun 000 and goes to lun 024 (since lun 025 is mapped).

If you find available "slots" with the above mentioned command, you can still map on already working controllers. If you don't have "*" for vbus=1 or vbus=0, you can only clean up the HPUX host and use vbus=2

BTW note that from DMX point of view, you can map your devices on all available different vbusses (obviously while keeping in mind all other limits when mapping devs on the FAs) .. It's only your hp-ux host that needs some clean-up

dynamox · Answer

is this a brand new host on that FA ?

SKT2 · Answer

No. We had this issue for a logn time. These are the DR LUNs so not given that much priority

Symmetrix

masking issue with Hp-UX

Was this post helpful?