Migrating to ownership groups

Edit online

If you want to use ownership groups for objects that exist on your system, you need to reconfigure certain resources if you want to configure ownership groups.

An ownership group defines a subset of users and objects within the system. You can create ownership groups to further restrict access to specific resources that are defined in the ownership group. Only users with Security Administrator roles can configure and manage ownership groups. Restricted users are those users who are defined to a specific ownership group and can only view or manage specific resources that are assigned to that ownership group. Unrestricted users are not defined to an ownership group and can manage any objects on the system based on their role on the system. If you want to use ownership groups, you might need to reconfigure the following objects to implement ownership groups on the system:

  • Child pools
  • Volumes
  • Volume groups
  • Hosts
  • Host clusters
  • Host mappings
  • FlashCopy®® mappings
  • FlashCopy consistency groups
  • User groups
  • Portsets

If these objects are configured on your system and you want to use ownership groups to manage access, identify the objects that you want to assign to ownership groups and determine any dependencies these objects have to related objects outside of the ownership group. For example, if you have a volumes that are used in a FlashCopy mapping ensure that both volumes are assigned to the same ownership group, even if different child pools provide capacity. In this case, two separate child pools are configured with the same ownership group and their volumes inherit the ownership group from the pool. Objects like FlashCopy mappings and host mappings cannot be created with inconsistent ownership. Inconsistent ownership means that either an object is owned by different owners or dependent objects do not belong to the same ownership group. Some of these inconsistencies are can be temporary and resolve when all related objects are assigned to the correct ownership group. However some actions, such as adding a volume copy or migrating a volume can be created with inconsistent ownership intentionally. For example, when adding a volume copy or migrating a volume, you can have these objects be in different ownership groups. In the management GUI, this is done automatically when a volume is copied or migrated to a child pool in a different ownership group and warnings are generated. In the command-line interface, you must specify the -inconsistentownershipgroup parameter on these commands specifically to allow for inconsistent ownership groups. It is not recommended to leave objects, such as FlashCopy mappings or host mappings, in an inconsistent state. To ensure full information, only run system backup operations on the system when objects are in a consistent state.

Migration scenarios that require reconfiguration of these objects can be varied; however, two basic migration scenarios are available: