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 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 datastores to make igroup management easier. Understand the igroup workflow to manage LUNs and datastores 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 don't 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)

ONTAP creates the parent igroup DS1Igroup for DS1 and maps the child igroup host1Igroup to lun1. The system always maps LUNs 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)

ONTAP tools for VMware vSphere create a child igroup host2Igroup and add it 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)

ONTAP tools for VMware vSphere remove host1Igroup from the hierarchy. The system does not explicitly delete child igroups. It deletes them 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 unless another datastore reuses the parent igroup. Child igroups are not 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 don't 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 NFS datastore access and client permissions in ONTAP tools for VMware vSphere. Export policies are created and managed in ONTAP systems and can be used 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 keeps the host IP address and does not change. 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