Flagging a device as "VCM" menas that this special device will be visible from every host zoned to an FA even if the device isn't explicitly masked. ESX does not NEED to see the VCM (since there is no Solution Enabler for ESX) and in old days the VCM device was usually write disabled. This may give some pain to ESX trying to "own" the device but being unable to write to it.
Since DMX3 the VCM is a GateKeeper and due to its small size the device is supposed to be ignored from ESX. Again with DMX3 you can use any given gatekeeper to manage VCM so you can even unmap the VCM from ESX FAs. With older boxes there was however a flag that rendered the VCM just like any other device (I.E. needs to be masked before being seen).
I think that you CAN hide the VCM from your ESX server
..
BTW the VCM does not require to be at lun 0 .. it can be "relocated" elsewhere .. Or you can even choose to use lun-offset to hide the VCM to your ESX host..
Message was edited by:
Stefano Del Corno
Since DMX3 the VCM is a GateKeeper and due to its small size the device is supposed to be ignored from ESX. Again with DMX3 you can use any given gatekeeper to manage VCM so you can even unmap the VCM from ESX FAs. With older boxes there was however a flag that rendered the VCM just like any other device (I.E. needs to be masked before being seen).
I think that you CAN hide the VCM from your ESX server
BTW the VCM does not require to be at lun 0 .. it can be "relocated" elsewhere .. Or you can even choose to use lun-offset to hide the VCM to your ESX host..
Message was edited by:
Stefano Del Corno
This has some very good information, but I guess my question still stands.
Is it a problem if VMWare sees the VCM device? I think you are saying it probably is not a major issue.
I think I am going to research how we could nicely hide the VCM device to avoid any confusion, but unfortunately VMWare is sharing an FA port with some other servers so I can not just disable this completely.
Bonus points if you know offhand how to hide the VCM device from just a single host on a given FA port
Is it a problem if VMWare sees the VCM device? I think you are saying it probably is not a major issue.
I think I am going to research how we could nicely hide the VCM device to avoid any confusion, but unfortunately VMWare is sharing an FA port with some other servers so I can not just disable this completely.
Bonus points if you know offhand how to hide the VCM device from just a single host on a given FA port
You have options as I said 
.. But I first need to know what model of storage we are talking about .. Are you using a DMX3, a DMX 1/2 or a Symmetrix ??
VMWARE (as per emc71378) does not requires a lun at address 0.
If you want to hide the VCM we can work in that direction .. But however remember that ESX does not need LUN 0
In older Symmetrix (with codes up to 5671 AFAIK) you can ask your local friendly customer engineer to enable flag FF2_VCM_DV_Restricted on your boxes .. This means that PRIOR to enabling the flag you have to explicitly GRANT access to the VCM to the hosts that will still need to access the VCMDB becouse when enabling the flag, the device will become a volume just like any other and will require you to mask it before being able to see it.
With DMX3/4 (codes 5771 and later) the VCMDB is simply a gatekeeper so you can simply avoid mapping the VCMDB itself on the FA ports, resolving the issue at its root.
If you want to hide the VCM we can work in that direction .. But however remember that ESX does not need LUN 0
In older Symmetrix (with codes up to 5671 AFAIK) you can ask your local friendly customer engineer to enable flag FF2_VCM_DV_Restricted on your boxes .. This means that PRIOR to enabling the flag you have to explicitly GRANT access to the VCM to the hosts that will still need to access the VCMDB becouse when enabling the flag, the device will become a volume just like any other and will require you to mask it before being able to see it.
With DMX3/4 (codes 5771 and later) the VCMDB is simply a gatekeeper so you can simply avoid mapping the VCMDB itself on the FA ports, resolving the issue at its root.
