Snap clone luns not getting CLAIMED from second time onwards

[Prasanth V Aravind]

Hi,

I am creating snap-clones for our production env using sssu utility. On the first time the BC vdisks got detected on server successfully. But from the second time onwards the luns are not getting in claimed mode.


If i take a reboot of this server these vdisks are coming in CLAIMED mode. Or if i create the snap clones using different lun-id , they are get detecting on OS.

Let me know, anybody experience same issue ???
This is the first time, i m using SSSU for BC. May be the problem can be with my script...

Regards
Prasanth V Aravindakshan.

[Duncan Edmonstone · Accepted solution]

Prasanth,

I'm guessing you are on HP-UX11iv3? (11.31)

You are probably running into a security protection mechanism in the HP-UX11iv3 mass storage stack.

This is an excerpt from the scsimgr man page:

To prevent accidental data corruption, the SCSI stack
implements an authentication mechanism based on the LUN
WorldWide Identifier (WWID). When a LUN with a
different WWID is discovered through a previously
discovered LUN path, further access to the device
through that LUN path is prevented. The LUN path is
put in "Authentication Failure" state. Then, HP-UX
logs a message in syslog which informs the user that
the replace_wwid operation needs to be performed.


Now this state is actuallu cleared by a reboot, which is why things then work OK.

The best solution here is to extend your SSSU script to look at the old WWID of your snapclone and the re-use it, so it doesn't get an entirely new WWID every time you create a new snapclone(note if the vdisks you create the snapclone off are also presented to this host make sure you _don't_ use the WWIDs of those, as that will seriously confuse things)

I haven't used SSSU in a long time, but I seem to recall the command would be something like:

ADD SNAPSHOT VDISK= WORLD_WIDE_LUN_Name=

So remember, before you get rid of the old snapclone, interrogate it via SSSU to get its WWID and then use that again when you re-create it.

The other alternative is to run the

scsimgr replace_wwid -D

on the DSF of the snap-clone...

But I don't like that option as you end up churning through lots of WWIDs unnecessarily

HTH

Duncan

[Prasanth V Aravind]

Yes ..

We are using hpux 11.31. I hope these suggestions will resolve issue. Let me try this on today night business copy. Closing this case now.

Thanks for your gr8 advise

Rgds
Prasanth

[Prasanth_VA]

Hi

I have  created  snapclones using old WWID. but i am getting  below error when i m presenting this vdisk to server. See the below logs... 

DR_EVA>  ADD COPY HPBC_sssutest_0 VDISK=sssutest DISK_GROUP="Disk Group 2" WORLD_WIDE_LUN_NAME=6005-08b4-0007-52fb-0001-7000-33c2-0000

DR_EVA> ADD LUN 102 HOST=BC_11v3 VDISK=HPBC_sssutest_0

Error: Error the call to present the virtual disk has failed. [Duplicate Lun WWID]
C:\Program Files\Hewlett-Packard\Sanworks\Element Manager for StorageWorks HSV\Bridge>

It will be very helpful, if you can provide the procedure to perform "scsimgr replace_wwid " , which going to save server reboot time ..

:)

Regards

Prasanth V Aravindakshan

[Duncan Edmonstone]

So can you be clear on the order you did things? Did you actually un-present and delete the old copy before attempting to present the new copy? And are you sure you used the WWID of the copy rather than the WWID of the original Vdisk?