creating gatekeeper devices in VMAX

i am using VMware native multipathing and path selection is set to Fixed.

Kennedy,

On DMX3/4 it's very easy because you can simply unmask certain devices (gatekeepers) from all HBAs but one but it's not that easy on VMAX. I was thinking that you could create a brand new port group with only one port in it (even though this port could be a member of another port group ..it's ok). Then you could create a new storage group and add just the gatekeepers. Last step would be to create a masking view that would consist of your initiator group, "single-port" port group and your storage group with gatekeeper devices in it.

Cody,

would my scenario work, yes there will be multiple paths because the host has multiple HBAs but the device is only visible from one FA at this point. Better options ?

Now Cody ..please tell me why does it have to be so convoluted (at least until customers upgrade to 76) ?

Yeah you got it--doesnt look like you missed anything. In your case since only one HBA sees 8G:0 there will only be one visible path to the device.

ha ..politically correct answer, only took two versions (74,75) to address this.

All i can say is that we understood the problem and hence the reason we made the change in 5876--with every code release EMC has been driven to make the Symm simpler and easier.

Cody/Dynamox:

Thanks a lot, for your inputs and suggestions. Today I understand the procedure much better. 

KGD.

Thank you for the thorough discussion. But can anyone explain me the concept of GK void file. I have just started in the storage front so this might be little novice query .

Hello

Everything you want to know concerning gatekeepers is documented in EMC KB article emc255976

The specific KB article emc45343 explains the various avoid files including the gkavoid file.

Specifically

gkavoid affects calls to various online type SYMCLI commands that use a gatekeeper to communicate to a Symmetrix unit. A gatekeeper whose PdevName matches any of the entries specified in the gkavoid file, will not be chosen for the online interface. This could be useful to designate certain Symmetrix devices that should not be used as gatekeepers. The gatekeeper avoidance file is formatted with physical device names with one PdevName (/dev/rdsk/c2t0d1s1 for unix or
.\PHYSICALDRIVE1
.\PHYSICALDRIVE1> for windows) per line.

Typical devices that you would put in the gkavoid file would be your data devices. With later versions of Solutions Enabler and assuming that you have sufficient gatekeepers presented to the host running Solutions Enabler this file is commonly not used by customers as the normal/default gatekeeper management is generally far better than earlier versions.

Sam Claret TSE3

Global Technical Support – SSG Windows

Hi Dynamox

Where can we use other types of  GK devices like open, close, thin and unique GK devices.

Thank you

i am not sure i understand what you are asking, gatekeepers are 3MB devices ...can't really use them for anything else.

Typically open/close gatekeeper refers to whether or not the gatekeeper is currently in use

i think in code 76 you can now use thin devices as gatekeepers ( i believe they don't need to be bound to a pool either), where before they were 2-way mirror devices. I am not familiar with open/close gatekeepers.

I have gone through the thread and i see that there was a discussion that went on dedicated and multi-pathing GK devs. Ive came across other types of GK devs which i have mentioned like open, close, thin and unique GK devices, and i was wondering in what instances we can use those types of GK devs.

Bah, the initial bin load should have plenty of GK devices created during the post-sales implementation process.