10
HOW NDM HANDLES MASKING GROUPS AND VIEWS
When NDM sessions are created, NDM configures storage groups (SGs), initiator groups (IGs), port groups (PGs), and masking views
(MVs) on the target array that exactly match the group names on the source array. Both initiator groups and port groups can exist in
multiple masking views, so these groups will be reused when applicable.
When the first SG on the first array is migrated to the target array, a SG will be created on the target with the same name that contains
the migration target devices, an IG will be created on the target with the same name that contains the host initiators, and a PG will be
created on the target based on which ports the host HBAs are logged into.
When an SG on the second source array is migrated to the target array, the SG name must be different. If necessary, the SG can be
renamed before it is migrated. The IG must have the same name because an initiator can only exist in one IG. If the PG on the second
array has the same name as the PG on the first array, then the PG built by NDM during the first migration will be reused. If it has a
different name, a new PG will be created with the same ports used in the PG created during the first migration.
NDM also supports migration of a Parent IG which has child IG’s.
RULES REGARDING MASKING GROUPS AND VIEWS
All migrations are performed against a Storage Group (SG), which is the data container that is migrated with NDM. The following rules
must be met:
Only SGs contained in masking views can be migrated. If the device is mapped to a port that it is not masked to for this SG, the
create operation will not be permitted.
A SG will not be able to be migrated using NDM if it contains devices that have been added to a second SG that belongs to a
masking view.
Multiple masking views on the SG using the same IG are not allowed unless PGs on the target array already exist for each view
and the ports in the PGs are selected to avoid duplicate host paths.
Only parent SGs and standalone SGs with masking views can be migrated. A child SG with a masking view on the child SG is not
supported.
If the SG is a parent, its child SGs will also be migrated.
Devices in the SG which are considered to be GKs (20 cylinders or less) will not be migrated to the target array.
Devices must not be masked to FCoE ports.
Devices must not be masked to iSCSI ports.
Devices must not be mapped to ports where the ACLX is not enabled.
There are restrictions on the entities that might already exist on the target array.
If a Storage Resource Pool (SRP) on the target array is specified for the migration, that SRP must already exist on the target array.
The names of the SGs (parent and children) that are being migrated must not exist on the target array.
The names of the masking views that are being migrated must not exist on the target array.
The names of the initiator groups that are being migrated may exist on the target array, provided that the groups on the target array
have the exact same initiators, child groups and port flags as the groups on the source array with the same names. Port flags that
are not supported on the VMAX3 are ignored. One exception to this is if the source IG was a parent IG that contained both group
names and initiators. With SE 8.4 on the target array, the IG will only need to have the same group names since when SE migrates
this IG; it will move all the initiators to a separate IG and will make it a child of the parent.
To Next Page
Loading...