VCMDB device showing up on Hosts as /dev/sda

you could unmap VCM from those FAs but now that they have seen it you have to make sure it does not cause problems on the host. Make sure there are no hosts on those FAs that need to do any kind of masking commands ( ECC, SMC, symcli)

In order to elimante hosts other than mgmt hosts from seeing the VCM device I would have to dedicate an FA just to management hosts?   I am not sure that is a reasonable solution.   Don't get me wrong in theory it could work, just not what I was hoping to do.

i understand, we can't afford to dedicate FAs for management hosts either so all of our hosts do see VCM device. System admins never have any issues with that, they are aware what that is and they don't mess with it.

I believe that the vcmdb does not need to be mapped anymore for the symmask command to work as the masking information is no longer stored on the vcmdb volume but instead on the internal filesystem on the Symm.

are you sure about that ? Even on my VMAX i have to have ACLX enabled on FAs to do any type of symcli work.

AFAIK ... since DMX 3 & 4 the VCMDB is located in the SFS (unlike the older versions where it was on a separate device that would appear to host masked to the same dirs) and here comes handy the gatekeepers which help host to send commands to the array..anyone care to confirm this

this explains it for DMX3/DMX4 - emc204637

I am still confused by this article emc219429 regarding the VMAX.  The way i am reading this you have to have ACLX enabled on FAs that will be doing symcli commands, which at the same time presents ACLX devices one every host zoned to that FAs ..just like VCM.

My issue is that the VCMDB device is not even mapped to the hosts an it is still seen by the OS.

Thanks I will just tell the server admins that is the way it is.

if it's mapped to FA it will show up on every host.

Did the replies to your post answer your questions? If so, please mark the helpful and correct posts and also mark the post as answered. Doing so helps others identify the most useful posts. Thank you.

It really depends on the enginuity level you are running.

If you have 5771 or above, then you will need to use Symmetrix Access Control to restrict access to the VCM.

See knowledge article emc104861.

This comment at bottom of article => In Enginuity 5771 code, the VCMDB_restricted_access flag is obsoleted.  In order to restrict access to VCMDB management to particular hosts then Symmetrix Access Controls (ACL's) should be used.

To enable this feature requires a CE to implement.

If this answers your question, please mark my reply as answered or helpful.

many thanks,

but restricting access to VCMDB will not hide it from all the systems on those FAs, you are just setting what certain access id can do with those devices.

Understood, but if we cant hide it, then it might be worth while to protect it from accidental destruction.

Hello All,

I know I am going down rabbit holes here, but after updating https://community.emc.com/thread/110644?tstart=0 I spotted this even older thread and while the responses are correct there seems to be a little confusion about the ACLX gatekeeper volume (and whether is should or should not be assigned to channels) and the ACLX port flag.

Again the solution cited in https://community.emc.com/thread/110644?tstart=0 and the update at the bottom of the thread, will explain about the creation of the ACLX (or VCMDB gatekeeper).

To recap, the ACLX or VCMDB gatekeeper is just a gatekeeper volume (on DMX-3 and Enginuity 5771 and above).It is typically assigned to all ports (by the EMC CE/IDE) and set write disabled by the Enginuity code. The write disabled state is not necessarily true, BUT you cannot impact your device masking operation (or any other ACLX related function) by formatting, labelling, or writing to, a write enabled ACLX or VCMDB gatekeeper volume. The actual database content is safely and securely stored away in the EMC internal SFS volumes, and the content can only be accessed by syscalls (this feature was introduced with DMX). The only problem with a write enabled ACLX or VCMDB gatekeeper is that a write enabled volume is potentially being shared by multiple hosts on multiple FA or SE ports. You can imagine the issues this might cause...

Note that when I refer to the VMAX ACLX gatekeeper this is the same as the VCMDB or VCM gatekeeper on Symmetrix model DMX-3 and above, and if I refer to the VMAX ACLX port flag this is the same as the VCM port flag, again on Symmetrix model DMX-3 and above.

O.K., now for device masking to "work" you must have the ACLX port flag enabled on the FA or SE. This Edit Director port flag tells the Enginuity code that the port is under Solutions Enabler SYMCLI device masking control. This is what is stated in emc219429.

Now, when the ACLX (or VCM flag) is initially enabled on an FA port (to say that device masking is enabled) the Enginuity code will by default "hide" every volumes assigned to that channel - except the gatekeeper with the VCMDB or ACLX device attribute. If you scan, walk, or discover this FA ONLY the assigned ACLX gatekeeper volume will be seen. Again, I am talking about a Symmetrix new installation or initial first time set-up of device masking.

That is why the VCMDB or ACLX gatekeeper is initially assigned to all FA or SE ports. The EMC CE/IDE does not know which FA or SE ports will go to the Admin host (used to initially set up the device masking environment). Also having the VCMDB or ACLX gatekeeper initially assigned to all ports makes discovering the WWN of all HBA's easier in a PowerPath environment (as noted in my solution and in the Solutions Enabler Array Controls Product Guide).

O.K., once you set up device masking AND have given yourself access to ANY standard FBA 3 or 6 cylinder gatekeeper you can issue any subsequent device masking commands via this standard gatekeeper. Through syscalls, any standard gatekeeper on the Symmetrix can be used to access and alter the contents of the ACLX or VCMDB database (residing on the SFS volumes).

So you can, at this point, unassign the VCMDB or ACLX gatekeeeper device from the FA ports. Device masking is completely unaffected.You could now, even disable the ACLX or VCM Edit Director port flag without affecting device masking - but this is a bad practice.

You cannot hide the assigned VCMDB or ACLX gatekeeper device, if it is assigned to a channel, due to the design of the Symmetrix and default operation of the Enginuity code. This may change in future Enginuity but unassigning this special gatekeeper volume is not seen as a major inconvenience.

You can leave the ACLX or VCMDB gatekeeper assigned to all FA ports and ignore it (being aware of the issues a shared write enabled gatekeeper may cause). As per my solution, I recommended the ACLX gatekeeper only remains assigned to the FA ports of the Admin host. This is not necessary, assuming the Admin host has access to a standard gatekeeper, BUT if the device masking database content was accidentally deleted, potentially the Enginuity default access would be re-applied and ONLY an assigned ACLX or VCMDB gatekeeper would be visible on the FA port .

Finally, note that unassigning the ACLX or VCMDB gatekeeper from the channels does not protect the VCMDB or ACLX database from access. Remembering that syscall access is via any standard gatekeeper. Hence the focus on Symmetrix Access Control.

I hope this clears up any confusion and mysteries.

Regards,

Michael.