Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

9135

December 11th, 2013 09:00

Consistent Lun Violation

I'm getting a consistent lun violation when I try to move a VMware host from one initiator group to another.  I've learned the reason for this is because I have masking views that contains same lun ids.  My problem now is, how do I go about making it so that I can collapse these initiator and storage groups so the luns can live together.  Here is what I have:

T8VgRJoUXMKXyVHWrVLtNlMfk.png

I want to collapse DRG4_MV and DRG7_MV into the same masking view and collapse DRG4_R_MV and DRG7_R_MV into same masking view as well.  The _R masking views contain recoverpoint replicated Devices not sure if anything needs to be taken into account with those when moving things around.

419 Posts

December 12th, 2013 02:00

Duhaas,

I don't think there is an easy way around this.

You have consistent lun on all of your IG.  But obviously there's a clash between lun addresses in your groups.

I guess you have the Host Initiators and RPA initiators in the same Views which is causing the conflict.  Per

See bottom of Page 27 and Top Page 28.  (Paraphrasing here because the doc is locked and can't paste) It's best to have a separate masking view for your RP initiaors view, this give you the advantage of separating host and RPA group flag settings and the ability to use the consistent lun feature.

You should use the same storage group for host and rpa for convenience but different masking view and initator groups.

HostView + RP_SG  + HOST_CLU_IG+HOST_PG

RPView + RP_SG + RPA_CLU_IG+HOST_PG

So how do we get around this in your case...

It's not easy, but it can be done.

You will need to create a staging initiator group for the new host masking view, you need to remove initiators one at a time from the shared view with RP and into the new initiator group.

Since you're using VMware you can vMotion all the VMs off the host and do this with minimal real risk to the production cluster.  Put the host in maintence mode, remove it's initiators from the shared view IG group, rescan etc. Verify it can see datastores/luns etc

Bring host out of maintence mode, verify you can vMotion and run your VMs.  Repeat for other hosts in the cluster.

Hope this makes sense...

31 Posts

December 11th, 2013 11:00

I don't think you can move around(collapse) non-disruptively. You probably will have to take a downtime and modify the init Grps and set the cons_lun flag.

Ricover pt should not have anything to do with the MV's.

31 Posts

December 11th, 2013 11:00

are you sure...can you run the below command on both the IG's and check for the "Consistent Lun" flag?

symaccess -sid xxxx show drg4_IG -type init -detail

if you have this flag set on both the IG's you should not get a cons lun violation.

227 Posts

December 11th, 2013 11:00

Thanks for the feedback, although everything today already has the consistent luns flag set.

UNeFOTg2reg6KZjJXNpDSTZrR.png

31 Posts

December 11th, 2013 12:00

You want to cascade the IG's and set the cons_lun on the parent IG. then add the child IG's, create a SG you can leave the PG as is or rename it, then create the MV.

If that does not work. You should delete the MV's and create them with cons_lun option on the parent IG.

227 Posts

December 11th, 2013 12:00

Here is the output:

SBgJjtqU4AZjMqAtpFBDWEDlG.png

227 Posts

December 12th, 2013 05:00

thanks Paul Martin and tech51 for the great feedback, I'm moving along now, things are getting cleaned up a bit

419 Posts

December 12th, 2013 06:00

Hopefully it will all go to plan,  Good Luck!

419 Posts

March 21st, 2014 01:00

I've since written a KB article on this subject discussing a couple of different scenarios and how to correct depending on the situation..

KB Article 184306

https://support.emc.com/kb/184306

No Events found!

Top