Another SSSU Question

[Dave La Mar]

Just some background-
New EVA installation and SA area is new to EVA manipulation.
Upon deleting a VDISK, via sssu, and re-creating the VDISK with the same lun number, we have found the WWN number to be different in Vdisk Active Member Properties display of Command View.
Iniitally, we were told the spmgr display would tie back the WWN to a disk file. Now we find they no longer match on the WWN, but as far as the VG the disk file is o.k.

What we have tried:
1. insf -e
2. ioscan -fnC disk
3. spmgr display

The output of spmgr display continues to show the original WWN and not what is seen in Command View.
We have also attempted and spmgr clean all which outputs "nothing in the stale list".

Now we are confused, as Command View was our way of tying back a VDISK to a device file. Now that is not a matching correlation.

Appreciate any insight that can be offered.

Regards,

dl

P.S. This thread has been moved from Disk array to HP Storage System Scripting Utility (SSSU). - Hp Forum Moderator

[Uwe Zessin]

As long as the virtual disk is not mapped, you can assign it a different
(e.g. the old) LUN WWN.

[Dave La Mar]

Thank you.
But:
1. Why is the octet of the WWN being incremented upon a deletion and creation?
2. Why does spmgr not display this new WWN even after an insf, an ioscan, and a spmgr clean all.
3. Do we need to make the WWN part of our creation script. If so, how is this done?

Regards,

dl

[Mark Grossman]

Dave,
on our eva3000/secure path 3.0c we have to issue spmgr delete /dev/xxxxxx to clean up the old paths.
Also, we were told that our switches had to be set for persistent paths to keep the same device id's. However, after enabling persistence we still sometimes see device files change.

I will be curious to see what others think here.

Mark

[Uwe Zessin · Accepted solution]

1. - a new virtual disk must receive a new identity - it's been standard practice on previous HS controllers.

A virtual disk is a container for your data and has no relation to a particular LUN number. A LUN is created by mapping a virtual disk into the LUN address space of a host.


2. - I haven't got much experience with Secure Path on HP-UX, but I think there is a required order of steps - are you sure you have met this order?


3. - It sounds like this are repetitive tasks, are they? May I ask why you delete and re-create virtual disks? Or did I miss that you are working with snapclones?

Anyway, what I would do is:

- create a number of small virtual disks to obtain the required number of LUN WWNs
---- do NOT try to create them on your own!!
- write these values down and
- delete the virtual disks afterwards


- I can't verify the syntax right now, but I think it is:
---- SSSU> set disk "\virtual disks\family\ACTIVE" WORLD_WIDE_LUN_NAME = 6nnn-nnnn-nnnn-nnnn-nnnn-nnnn-nnnn-nnnn


----------

Mark,

the talk is about 128-bit LUN WWNs, not 24-bit N_Port IDs (also called PIDs, fibre channel adresses, S_ID/ D_ID, ...).

[Dave La Mar]

Last response about hit it.
On our create command the following had to be added-
WORLD_WIDE_LUN_NAME=6005-08b4-0010-3e67-0000-4000-0109-0000

One more hurdle -
The SMA now shows-
World Wide LUN Name:
6005-08b4-0010-3e67-0000-4000-0109-0000
UUID:
6005-08b4-0010-3e67-0000-4000-
04e0-0000

We now need to find the syntax for maintaining the UUID to be synchronized with WW LUN Name.

For those wondering:
1. We use the scripted process to delete previous cloned copies and create new ones (for business copy and backup purposes.).
2 We also are scripting a fail back when the production disk has corrupted data and we wish to go back to the last good copy.

Stay tuned for points and results.

Regards,

dl

[Mark Grossman]

Uwe,
yes youre right - we do use portid's, -duh!

mark

[Dave La Mar]

Just heard back from an EVA CE.
He states the UUID is only internal to the EVA, not referenced by the host and of no concern.
Thus, we have our solution, as adding "WORLD_WIDE_LUN_NAME=" with the appropriate previous number now matches the spmgr display output.

Thanks for the expertise shared.

Regards,
dl