The "Mir" part of RDF+Mir means that they are traditionally provisioned (or "disk provisioned") instead of virtually provisioned. This basically means that there is no layer of abstraction between the SymDev/LUN and its underlying disks. Most devices on VMAX today are TDEVs, which means they are virtually provisioned from pools.
There could be a few possible reasons why those RDF+Mir devices aren't in a storage group:
Perhaps someone decommissioned them from a host, but forgot to remove the RDF relationships.
They could be mapped to FA ports without the ACLX bit set. Without ACLX, there is no masking on a particular FA port -- anything mapped to that FA port is visible to any host that is zoned to the port.
Those devices could be clone targets (basically what you were implying with your initial guess of what "+Mir" meant). While the "+Mir" thing doesn't mean that they are clone targets, they still could be clone targets To see if they are participating in clone sessions, run a 'symdev show ' on the devices and look for a section about Clone relationships... check to see if the device is paired with another device in a clone session.
Sean, I apologize for forgetting to mark this question as answered a year ago. Thank you for your thorough explanation and suggestions.
It turns out that all of my RDF1+Mir devices are CKD and mapped to ports on FICON directors. I can't find information about FICON directors and the ACLX bit, but I assume ports on FICON directors must work the same way as FA ports without the ACLX bit, as you describe in your second suggestion: all initiators zoned to the port can see all devices mapped to the port, which is the reason the devices aren't in initiator groups.
This invalidates my original question about listing the initiators that are using RDF1+Mir devices. In my environment, no RDF1+Mir is masked to any initiator.
seancummins
2 Intern
•
226 Posts
0
August 17th, 2015 05:00
Hi Ben,
The "Mir" part of RDF+Mir means that they are traditionally provisioned (or "disk provisioned") instead of virtually provisioned. This basically means that there is no layer of abstraction between the SymDev/LUN and its underlying disks. Most devices on VMAX today are TDEVs, which means they are virtually provisioned from pools.
There could be a few possible reasons why those RDF+Mir devices aren't in a storage group:
Hope that helps,
- Sean
ben_brooks
30 Posts
0
October 19th, 2016 19:00
Sean, I apologize for forgetting to mark this question as answered a year ago. Thank you for your thorough explanation and suggestions.
It turns out that all of my RDF1+Mir devices are CKD and mapped to ports on FICON directors. I can't find information about FICON directors and the ACLX bit, but I assume ports on FICON directors must work the same way as FA ports without the ACLX bit, as you describe in your second suggestion: all initiators zoned to the port can see all devices mapped to the port, which is the reason the devices aren't in initiator groups.
This invalidates my original question about listing the initiators that are using RDF1+Mir devices. In my environment, no RDF1+Mir is masked to any initiator.