Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

1495

June 30th, 2016 13:00

Odd masking view problem

I'm configuring boot luns for 4 new UCS hosts. So I have a boot lun in a storage group and an initiator group, with Consistent LUN flag, and port group configured. When I try to create the masking view, I click Set Dynamic LUNs and Unisphere insists that the first available Host LUN address is 1. It needs to be 0. This worked correctly on one of the hosts but the other 3 insist that the stating LUN address has to be 1 or higher. There is nothing masked to these new hosts at all. The VMAX is a 10k. Any ideas?

7 Posts

July 1st, 2016 05:00

See if ACLX is mapped to any FAs and when you have consistent LUN flag  it will take away 0

1 Rookie

 • 

20.4K Posts

June 30th, 2016 14:00

VMAX uses dynamic LUN masking by default, you should not need to check that option.  If you do not select that option does it let you assign host id 0 ?  Btw your boot LUN does not have to be at host id 0. For example my UCS blades are using FAs that have gatekeepers assigned to them so host id 0 is already taken up, my boot LUN is always host id 1 and that is also what is set in my UCS boot profile template.

5 Posts

June 30th, 2016 15:00

I need to add these IGs to a parent IG for the cluster. The cluster already has lun ID 1 assigned and I have consistent luns set on the IGs. So I'm not sure how that will work.

5 Posts

June 30th, 2016 16:00

Isn't reason the Consistent LUN flag exists because some clusters need to see the luns on each node with consistent host lun assignment? The VMAX doesn't care whether they're mapped or masked the same. Using the Consistent LUN flag and set dynamic LUN  I can ensure the boot lun is host lun ID0 and all the shared luns are mapped and masked identically beginning at host LUN ID 1.When I create a masking view and select the "Set Dynamic LUN" button, I am given an opportunity to specify the starting *host* lun ID. For boot LUNs, I set that to LUN ID 0 by convention. Using a different FA pair for the boot LUNs resolved my issue.

1 Rookie

 • 

20.4K Posts

June 30th, 2016 16:00

consistent_lun ensures "consistent" device mapping on all FAs, should not impact host masking. Device mapped to FF on FA could be host id 0.

1 Rookie

 • 

20.4K Posts

June 30th, 2016 21:00

look at definition of what consistent_lun flag does, nothing to do with masking.

5 Posts

July 3rd, 2016 15:00

From the manual...

Optional: Select Consistent LUNs to specify that LUN values for the host must be kept consistent for all volumes within each masking view of which this host is part. When set, any masking operation involving this host that would result in inconsistent LUN values, will be rejected.

Looks like it has a lot to do with masking.

No Events found!

Top