Skip to main content
ONTAP tools for VMware vSphere 10

Understand igroups and export policies in ONTAP tools for VMware vSphere

Contributors netapp-jani
PDFs

Initiator groups (igroups) are tables of FC protocol host World Wide Port Name (WWPNs) or iSCSI host qualified node names. You can define igroups and map them to LUNs to control which initiators have access to LUNs.

In ONTAP tools for VMware vSphere 9.x, igroups were created and managed in a flat structure, where each datastore in vCenter was associated with a single igroup. This model limited flexibility and reuse of igroups across multiple datastores. ONTAP tools for VMware vSphere 10.x introduces nested igroups, where each datastore in vCenter is associated with a parent igroup, while each host is linked to a child igroup under that parent. You can define custom parent igroups with user-defined names for reuse across multiple datastores, enabling more flexible and interconnected management of igroups. Understanding the igroup workflow is essential for managing LUNs and datastores effectively in ONTAP tools for VMware vSphere. Different workflows generate varying igroup configurations, as shown in the following examples:

Note The names mentioned are for illustration purposes only and do not refer to real igroup names. ONTAP tools managed igroups use the prefix “otv_”. Custom igroups can be given any name.

Term

Description

DS<number>

Datastore

iqn<number>

Initiator IQN

host<number>

Host MoRef

lun<number>

LUN ID

<DSName>Igroup<number>

Default (ONTAP tools-managed) parent igroup

<Host-Moref>Igroup<number>

Child igroup

CustomIgroup<number>

User-defined custom parent igroup

ClassicIgroup<number>

Igroup used in ONTAP tools 9.x versions.
Example 1:

Create datastore on a single host with one initiator

Workflow: [Create] DS1 (lun1): host1 (iqn1)

Result:

  • DS1Igroup:

    • host1Igroup → (iqn1: lun1)

A parent igroup DS1Igroup is created on the ONTAP systems for DS1, with a child igroup host1Igroup mapped to lun1. LUNs are always mapped to child igroups.

Example 2:

Mount existing datastore to an additional host

Workflow: [Mount] DS1 (lun1): host2 (iqn2)

Result:

  • DS1Igroup:

    • host1Igroup → (iqn1: lun1)

    • host2Igroup → (iqn2: lun1)

A child igroup host2Igroup is created and added to the existing parent igroup DS1Igroup.

Example 3:

Unmount a datastore from a host

Workflow: [Unmount] DS1 (lun1): host1 (iqn1)

Result:

  • DS1Igroup:

    • host2Igroup → (iqn2: lun1)

The host1Igroup is removed from the hierarchy. Child igroups are not explicitly deleted. Deletion occurs under these two conditions:

  • If no LUNs are mapped, the ONTAP system deletes the child igroup.

  • A scheduled cleanup job removes the dangling child igroups with no LUN mappings. These scenarios only apply to ONTAP tools-managed igroups, not custom-created ones.

Example 4:

Delete datastore

Workflow: [Delete] DS1 (lun1): host2 (iqn2)

Result:

  • DS1Igroup:

    • host2Igroup → (iqn2: lun1)

Parent and child igroups are removed if another datastore does not reuse the parent igroup. Child igroups are never explicitly deleted

Example 5:

Create multiple datastores under a custom parent igroup

Workflow:

  • [Create] DS2 (lun2): host1 (iqn1), host2 (iqn2)

  • [Create] DS3 (lun3): host1 (iqn1), host3 (iqn3)

Result:

  • CustomIgroup1:

    • host1Igroup → (iqn1: lun2, lun3)

    • host2Igroup → (iqn2: lun2)

    • host3Igroup → (iqn3: lun3)

CustomIgroup1 is created for DS2 and reused for DS3. Child igroups are created or updated under the shared parent, with each child igroup mapping to its relevant LUNs.

Example 6:

Delete one datastore under a custom parent igroup.

Workflow: [Delete] DS2 (lun2): host1 (iqn1), host2 (iqn2)

Result:

  • CustomIgroup1:

    • host1Igroup → (iqn1: lun3)

    • host3Igroup → (iqn3: lun3)

  • Even though CustomIgroup1 is not reused, it is not deleted.

  • If no LUNs are mapped, the ONTAP system deletes host2Igroup.

  • host1Igroup is not deleted because it is mapped to lun3 of DS3. Custom igroups are never deleted, regardless of the reuse status.

Example 7:

Expand vVols datastore (Add Volume)

Workflow:

Before expansion:

[Expand] DS4 (lun4): host4 (iqn4)

  • DS4Igroup: host4Igroup → (iqn4: lun4)

After expansion:

[Expand] DS4 (lun4, lun5): host4 (iqn4)

  • DS4Igroup: host4Igroup → (iqn4: lun4, lun5)

A new LUN is created and mapped to the existing child igroup host4Igroup.

Example 8:

Shrink vVols datastore (Remove Volume)

Workflow:

Before Shrink:

[Shrink] DS4 (lun4, lun5): host4 (iqn4)

  • DS4Igroup: host4Igroup → (iqn4: lun4, lun5)

After Shrink:

[Shrink] DS4 (lun4): host4 (iqn4)

  • DS4Igroup: host4Igroup → (iqn4: lun4)

The specified LUN (lun5) is unmapped from the child igroup. The igroup remains active as long as it has at least one mapped LUN.

Example 9:

Migration from ONTAP tools 9 to 10 (igroup normalization)

Workflow

ONTAP tools for VMware vSPhere 9.x versions do not support hierarchical igroups. During migration to 10.3 or above versions, igroups must be normalized into the hierarchical structure.

Before migration:

[Migration] DS6 (lun6, lun7): host6 (iqn6), host7 (iqn7) → ClassicIgroup1 (iqn6 & iqn7 : lun6, lun7)

ONTAP tools 9.x logic allows multiple initiators per igroup without enforcing one-to-one host mapping.

After migration:

[Migration] DS6 (lun6, lun7): host6 (iqn6), host7 (iqn7) → ClassicIgroup1: otv_ClassicIgroup1 (iqn6 & iqn7 : lun6, lun7)

During migration:

  • A new parent igroup (ClassicIgroup1) is created.

  • The original igroup is renamed with otv_ prefix and becomes a child igroup.

This ensures compliance with the hierarchical model.

Related topics

About igroups

Export policies

Export policies control access to NFS datastores in ONTAP tools for VMware vSphere. They define which clients can access the datastores and what permissions they have. Export policies are created and managed in ONTAP systems and can be associated with NFS datastores to enforce access control. Each export policy consists of rules that specify the clients (IP addresses or subnets) that are allowed access and the permissions granted (read-only or read-write).

When you create an NFS datastore in ONTAP tools for VMware vSphere, you can select an existing export policy or create a new one. The export policy is then applied to the datastore, ensuring only authorized clients can access it.

When you mount an NFS datastore on a new ESXi host, ONTAP tools for VMware vSphere adds the host's IP address to the existing export policy associated with the datastore. This allows the new host to access the datastore without creating a new export policy.

When you delete or unmount an NFS datastore from an ESXi host, ONTAP tools for VMware vSphere removes the host's IP address from the export policy. If no other hosts are using that export policy, it will be deleted. When you delete an NFS datastore, ONTAP tools for VMware vSphere removes the export policy associated with that datastore if it is not reused by any other datastores. If the export policy is reused, it retains the host IP address and remains unchanged. When you delete the datastores, the export policy unassigns the host IP address and assigns a default export policy, so that the ONTAP systems can access them if required.

Assigning the export policy differs when it is reused across different datastores. When you reuse the export policy, you can append the policy with the new host IP address. When you delete or unmount a datastore that uses a shared export policy, the policy will not be deleted. It remains unchanged, and the host IP address is not removed, because it is shared with the other datastores. Reusing export policies is not recommended, because it can lead to access and latency issues.

Related topics

Create an export policy