FC group

Each pool contains its own configuration for FC. It is assigned to a particular pool and can be used on any machine where a pool is imported. However, FC targets are local to a particular machine and each pool contains mapping of FC targets that has to be used on a particular machine. When the pool is imported on a machine where targets are not assigned to a pool configuration, it is possible to specify them after the pool import.

FC configuration consists of groups that define which volumes are available on given ports to configured initiators. Two type of groups are available: a public group and initiator groups. Public group allows any initiator connected to configured ports to access LUNs assigned to this group. Public group is present on a pool by default and cannot be removed or created. Initially, it didn’t have any volumes or ports assigned, so nothing is available until it is configured manually. Because this group allows to connect any initiator, it is not possible to assign initiators to this group. The second type of FC group is an initiator group. By using this group it is possible to define which initiators can connect to LUNs assigned to a group. Initiator that is not assigned to a FC group won’t be able to connect through ports to LUNs. It is possible to configure many initiator groups to have different access configurations to volumes through FC targets. It is possible to define alias for each initiator group that allows easier identification of the group purpose.

In general, groups gather set of: ports, volumes and initiators. LUNs added to a group define which volumes are available in this group. Ports assigned to a group define on which ports it is possible to connect to LUNs in a particular group. Finally, initiators (in case of an initiator group) define which initiators (ports of remote machines) will be able to connect to LUNs in the group using ports that are assigned to the group. For example, to allow initiators Ini0 and Ini1 access volume Vol-01 through ports P0 and P1 it is required to create an initiator group with assigned ports: P0 and P1, next add volume Vol-01 and initiators Ini0 and Ini1 to this group. It is possible to assign the same volume, initiator or port to more than one group. However, there are some limitations to the configuration that the system won’t allow to be applied:

1. The same target cannot be assigned to two groups that share a set of initiators.
2. Due to the rule above, the same initiator cannot be assigned to two groups that share a set of ports.
3. The target assigned in a public group cannot be used by an initiator group and the other way around, the target assigned to an initiator group cannot be used in public group.
4. The target can be assigned to only one pool - the same port cannot be used in two groups that belong to different pools. If the target is used in an active pool and another pool that also uses this target is imported, the group using a conflicting target will be deactivated upon import.

Moreover, a volume used by iSCSI cannot be assigned to any FC group and the other way around.

A created group can be modified at any point in time. It is possible to assign or remove initiators, ports or volumes. Volumes assigned to groups can be modified, however, it is advised to be careful because in some cases the connected initiator may lose access to the volume during this operation.

It is possible to deactivate any FC group. When a group is inactive, configuration that is represented by that group is not applied to ports thus LUNs are not available to initiators from a given group. A group can be deactivated either manually or by the system in case of configuration conflicts. Configuration conflicts are possible mainly during a foreign pool import. A group is deactivated on the imported pool in case of the following conflicts:

1. Target used by the pool is already used by other active pool.
2. One of the LUNs uses SCSI ID that is already used by FC or iSCSI LUN on other pool.

A group that was deactivated due to conflict can be activated manually after resolving that conflict by modifying the configuration.

A bit more explanation is required for the SCSI ID uniqueness. This LUN identifier consists of 16 characters, however two SCSI IDs that have the same first 8 characters are considered conflicting. It is due to the way some initiators read those identifiers. Some initiators honor only those first 8 characters of SCSI ID, which could lead to issues if two LUNs would have this part of SCSI ID the same. However, in most cases you don’t have to worry about this setting because the system assigns a unique SCSI ID to the volume based on it’s name and time stamp of creation. When a SCSI ID is not specified, the one assigned to volume is used for a LUN. It is recommended to use a default (generated by system) SCSI ID. To use the default value simply do not specify any SCSI ID during configuration of LUN.

FC targets assigned to groups require additional configuration to be used in a cluster environment. For detailed description of this configuration please refer to the Edit FC target properties section.

FC groups and encrypted resources

FC Groups can contain a mix of unencrypted and encrypted zvols. However, encryption introduces strict dependency rules that affect the availability of the entire group.

Group locking mechanism

If any encrypted zvol assigned to an FC Group cannot be accessed due to an encryption issue, the system will:

• Automatically set the FC Group status to Locked
• Block access to all zvols in that group, including unencrypted ones
• Prevent initiators from accessing any LUNs assigned to the group

This behavior is intentional and ensures data consistency and security.

In the GUI, encrypted zvols with access issues are marked with an error indicator, and a tooltip may display the cause of the issue (e.g., an incorrect encryption passphrase).

Resolving a Locked FC Group

If an FC Group is locked:

1. Identify encrypted zvols in the group.
2. Check their encryption status.
3. Unlock the affected zvols by providing the correct encryption passphrase.
4. Verify that all encrypted zvols are accessible.

In general, once all encryption issues are resolved, encrypted resources are unlocked automatically and the FC Group returns to Active status.

In rare cases, automatic activation may fail even though encryption issues have already been resolved. In such situations, deactivating and then reactivating the FC Group can be used to trigger the same validation procedures that are executed after resolving encryption-related errors. If encryption issues are fully resolved, the FC Group and all its resources will activate successfully. If not, the system will prevent activation and display an error.

Important:
If the FC Group was manually deactivated while it was locked, resolving the encryption issues will still unlock the encrypted resources, but the FC Group will remain inactive. In this case, the group must be manually activated to make its resources available to initiators.

Detaching blocked zvols as an alternative

As an alternative recovery method, a locked FC Group can be restored to an Active state by detaching blocked zvols (e.g., encrypted and inaccessible ones) from the FC Group.

Detaching blocked zvols removes them from the group configuration. As a result:

• The FC Group becomes Active again
• Initiators regain access to the remaining, non-blocked zvols assigned to the group

Important Notes

After detaching blocked zvols:

• The FC Group operates normally with the remaining zvols.
• Detached zvols remain unavailable until their encryption issues are resolved.

Once detached, encrypted zvols are later unlocked:

• They are not automatically reattached or activated.
• To make them available again, you must manually attach them to the FC Group.

This behavior ensures predictable recovery of FC Groups while preventing unintended exposure of storage resources after encryption-related access issues.

Handling invalid or missing passphrase

If the encryption passphrase is invalid or not configured on the current host, all encrypted datasets and zvols in the affected zpool are locked and cannot be accessed. When a locked zvol is attached to an iSCSI target, FC group, or NVMe-oF subsystem, these objects are effectively blocked as well, and no data can be accessed through them. For an encrypted dataset, all shares configured on it are also blocked.

To restore access, enter the correct passphrase in Configuration → Resource encryption for the zpool. After a valid passphrase is provided, all locked, encrypted resources are automatically unlocked and become active again, provided that the related targets, groups, subsystems, or datasets were not manually deactivated beforehand.

Such situations may occur, for example, when a zpool is imported on a different host or moved between cluster nodes. In a cluster environment, the passphrase is usually synchronized between nodes, so after a failover, the other node already has the required passphrase. However, if the passphrase change operation was interrupted, some encrypted resources may have been updated to the new passphrase while others still use the old one. On the original host, access may still work, but after exporting the zpool and importing it on another host, some or all encrypted resources can become partially locked. In this case, an event is recorded in the Event Viewer indicating that the passphrase change did not complete successfully.

If this happens, first try to unlock the resources by entering the latest passphrase (the one you intended to change to). If this does not unlock all encrypted resources, enter the previous passphrase (the one used before the change), allow the passphrase change process to complete, and then change the passphrase again to the desired new value. This sequence should unify the passphrase across all encrypted resources in the zpool. Always monitor Event Viewer logs when working with encrypted resources and when changing passphrases.