Tag: Cluster

The OneFS cluster inventory request API  enables automated workflows to query detailed hardware and infrastructure inventory information from a PowerScale cluster. This capability, which was introduced in OneFS 9.12, is particularly useful for orchestration and discovery use cases, functioning in a manner similar to how LLDP is used within networking environments to collect device and topology data.

The new REST API provides comprehensive inventory details at both the node and backend fabric levels. Node‑level inventory includes general system information, baseboard management controller (BMC) data, network interface details, and attached storage drives. In addition, the response includes backend switch inventory information for supported Ethernet switches running firmware versions later than 10.5.2. InfiniBand switches are not currently supported by this feature. The API also returns the last known inventory state for any component that is offline at the time of the request, such as during upgrades or maintenance, allowing visibility into previously collected data even when a component is temporarily unavailable.

The inventory collection mechanism uses a producer‑consumer design model. On the producer side, cron jobs periodically query cached node and switch information and store the results as inventory cache files within the /ifs filesystem. For node‑level inventory, OneFS collects system and hardware details and saves them to the node information cache. For backend switches, inventory data is retrieved from the switch information cache. The cluster inventory request API also leverages the existing OneFS FlexNet service and its data store to collect network interface details such as IP addressing and interface configuration.

On the consumer side, a new platform API handler reads these cached inventory files from /ifs and assembles them into a consolidated inventory report, which is then returned to the requesting client. This design avoids real‑time polling of hardware during API requests, improving both performance and reliability.

Here are some details regarding the new cron jobs and event triggers:

Several periodic and event‑driven mechanisms are used to keep the inventory data current. A scheduled cron job updates the node‑level inventory cache every twelve hours, while a separate cron job refreshes the backend switch inventory cache every fifteen minutes. For example:

# cat /etc/crontab | grep inventory

# run the gather inventory switches info every 15 minutes

*/15    *       *       *       *       root    isi_ropc /usr/bin/isi_gather_inventory -t switches

# run the gather inventory node cache info every 12 hours

0       */12    *       *       *       root    /usr/bin/isi_gather_inventory -t node

In addition to these scheduled updates, OneFS uses event‑driven triggers to refresh inventory data when relevant system changes occur. For example, when the /ifs filesystem is mounted, OneFS automatically triggers a node‑level inventory update to ensure the latest data is captured. Network‑related inventory data is updated in response to IP configuration changes via the FlexNet database.

The inventory cache data is stored in three locations within /ifs, consisting of the node inventory cache, the switch inventory cache, and the FlexNet database for network interface information. Customers access the inventory data through a single REST API endpoint provided by the OneFS platform API at /platform/<version>/cluster/inventory:

http://<x.x.x.x>:8080/platform/26/cluster/inventory

Or with python:

# python -c 'import isi.papi.basepapi as papi; resp = papi.get("/cluster/inventory");print(resp.body)'

Note that access to this inventory endpoint requires the requesting user to possess both the ‘ISI_PRIV_DEVICES’ and ‘ISI_PRIV_NETWORK’ RBAC privileges.

Here’s an example of this substantial inventory report from an F210 cluster:

When queried, the API returns a structured inventory report comprising two primary sections: a

• Nodes array
• Switches array

For example:

Specifically, each ‘nodes’ object represents an individual node in the cluster and includes nested objects for its drives, BMC details, and network interfaces. The ‘switches’ array represents the entire backend fabric, and may include multiple backend switches, with each switch object containing its corresponding port‑level information.

If a backend switch query fails, the behavior depends on whether valid inventory data was previously collected. If historical data exists, the API returns the last known switch inventory state. If the backend switch has never been successfully queried, the switches section of the response will be empty. This behavior ensures that the inventory report remains consistent and informative even when transient connectivity issues occur.

The PowerScale OneFS cluster inventory request API (`isi.papi.basepapi`) allows native Python integration for cluster inventory operations, offering more robust error handling and authentication management compared to direct HTTP requests. This native API approach is particularly well-suited for DevOps automation workflows, enabling seamless integration with configuration management tools, CI/CD pipelines, and infrastructure-as-code frameworks.

The fundamental approach to accessing cluster inventory through the OneFS cluster inventory request API involves importing the `isi.papi.basepapi` module and using the `get()` method to retrieve inventory data. This method provides automatic session management, authentication handling, and response parsing, simplifying the development of automation scripts. For example, here’s a basic python script to perform a node and drive inventory on a cluster:

#!/usr/bin/env python3

import isi.papi.basepapi as papi

try:

    resp = papi.get("/cluster/inventory")

    if resp.status == 200:

        inventory = resp.body

        nodes = inventory.get("nodes", [])

        drive_count = sum(len(node.get("drives", [])) for node in nodes)

        print(f"Cluster contains {len(nodes)} nodes")

        print(f"Total drives: {drive_count}")

    else:

        print(f"Error: {resp.status} - {resp.body}")

except Exception as e:

    print(f"API Error: {e}")

The script’s output is along the following lines:

# python3 inventory.py

Cluster contains 228 nodes

Total drives: 4342

From a troubleshooting perspective, OneFS also includes an internal ‘isi_gather_inventory’ command line (CLI) utility that can be used to manually initiate inventory collection.

Note that the ‘isi_gather_inventory’ CLI tool can only be run by root.

Separate commands are available to gather node inventory data or backend switch information, and related messages are written to the system log. The utility does not generate standalone log files, but inventory cache contents can be collected using standard OneFS support log packages, which include archived copies of the node and switch inventory cache data.

PowerScale inventory monitoring can be readily integrated into modern DevOps and infrastructure automation workflows. Within CI/CD pipelines—such as those implemented in Jenkins—the OneFS cluster inventory API enables automated pre-deployment validation, ensuring cluster health and configuration integrity before changes are applied. This approach supports continuous change detection and compliance verification as part of the delivery lifecycle.

Configuration management tools such as Ansible can leverage the cluster inventory API for dynamic inventory generation and real-time state validation. By querying current cluster conditions during playbook execution, automation workflows can enforce guardrails that ensure configuration changes occur only when predefined operational criteria are met. Similarly, Terraform can consume inventory data via external data sources, enabling adaptive infrastructure-as-code patterns that align deployments with the actual cluster state and reduce configuration drift.

GitOps workflows further benefit from PowerScale inventory integration by embedding automated validation checks into controllers and operators. Infrastructure changes are applied only when cluster conditions are healthy and compliant, providing a reliable mechanism for policy-driven storage management at scale.

Beyond deployment orchestration, the cluster inventory API supports a wide range of operational use cases. Capacity planning automation can be achieved through periodic collection of node and drive inventory data, combined with trend analysis to forecast growth and trigger proactive alerts as utilization thresholds are approached. Performance monitoring systems, such as Prometheus, can ingest inventory and performance metrics to provide end-to-end observability, enabling threshold-based alerting and long-term performance optimization.

Maintenance workflows can also be automated using the API’s health and hardware inventory data to detect failing components and initiate remediation processes. Integration with IT service management and procurement systems enables automated ticket creation and replacement part ordering, while detailed hardware metadata ensures compatibility and accuracy. Finally, regular synchronization with configuration management databases (CMDBs) ensures inventory accuracy, supporting change management, auditability, and compliance reporting across the storage environment.

In this second article in the series we turn our focus to the configuration and management of the user account lockout functionality.

As discussed in the previous article, OneFS 9.13 adds three new account lockout configuration settings for the file provider. The ‘lockout-threshold’ parameter defines the maximum number of failed authentication attempts allowed before an account is locked. The ‘lockout-window’ specifies the time period over which those failed attempts are counted; if the threshold is not reached within this window, the failure counter automatically resets. Lastly, ‘lockout-duration’ determines how long the account remains locked after the threshold has been exceeded.

In operation, when repeated incorrect password attempts, whether from a legitimate user or a malicious actor, reach the configured threshold within the specified window, the account is locked for the defined duration. During this lockout period, authentication is prohibited even if the correct credentials are provided. Cluster admins can review the account’s lockout status and manually unlock it if desired. Setting the threshold to zero disables the lockout mechanism altogether. Additionally, if failed attempts are spaced beyond the lockout window or a successful authentication occurs before the threshold is reached, the failure counter resets and no lockout is enforced.

So how does user account lockout work in practice?

1. Starting with a PowerScale cluster running a fresh OneFS 9.13 install, a new user (‘testlock1’), is added to the system zone’s file provider.

# pw user add -n testlock1

2. Next, the user ‘testlock1 is added to the ‘AuditAdmin’ role and the password is reset:

# isi auth roles modify AuditAdmin –add-user testlock1

# isi auth users reset-password testlock1

Z,71GGsuw,36l.XK

3. The user’s lockout status can be verified as follows:

# isi auth users view testlock1 | grep -i lock

                  Locked: No

As expected, our new ‘testlock1 file provider user’s lockout status as not locked.

Since this is a fresh 9.13 install, the user lockout parameters are still their default configuration.

# isi auth file view System | grep -i lockout

       Lockout Duration: Now

      Lockout Threshold: 0

         Lockout Window: Now

As such, the lockout threshold value of ‘0’ above indicates that user account lockout is currently disabled.

4. Next, the lockout-threshold is set to ‘3’, the lockout-duration to 60 seconds, and the lockout window 60 seconds too.

# isi auth file modify System --lockout-threshold=3 --lockout-duration=60 --lockout-window=60

Enabling the user lockout function may make the administrator account vulnerable to Denial of Service (DoS) attacks, potentially rendering the entire system unmanageable. Therefore, please choose the configuration values for lockout-duration and lockout-window carefully.

Be cautious when setting these values:

- Avoid setting lockout-duration to 0 (which means indefinitely) or a very long time, as this may result in being locked out for an extended period or even indefinitely.

- Avoid setting lockout-window to 0 (which means the failed attempt count will never be reset) or a very long time, as this may require waiting too long before the failed attempt is reset or may never be reset.

Additionally, to minimize the risk of Denial of Service (DoS) attacks, please configure the accounts that are excluded from the user lockout feature.

Are you sure you want to proceed with this action? (yes/[no]): yes

Before OneFS enables this configuration, it displays the above warning. This message warning that enabling lockout comes with the risk of DoS attacks by rendering the system unmanageable, and suggests excluding admin account(s).

5. The success of the above ‘isi auth file modify’ command can be verified as follows:

# isi auth file view System | grep -i lockout

       Lockout Duration: 60

      Lockout Threshold: 3

         Lockout Window: 60

6. After three attempts to log in as user ‘testlock1 with the wrong password within the lockout window of 60 seconds, this user ‘testlock1 is locked out:

login as: testlock1

Keyboard-interactive authentication prompts from server:

| Password:

End of keyboard-interactive prompts from server

Access denied

Keyboard-interactive authentication prompts from server:

| Password:

End of keyboard-interactive prompts from server

Access denied

Keyboard-interactive authentication prompts from server:

| Password:

End of keyboard-interactive prompts from server

Access denied

Keyboard-interactive authentication prompts from server:

| Password:

This can be verified from a cluster admin account, such as ‘root’, as follows:

# isi auth users view testlock1 | grep -i lock

                  Locked: Yes

7. Since the lockout duration is also set to 60 seconds, after one minute this account will be unlocked.

Alternatively, this account can be unlocked manually by an administrator. For example:

# isi auth users view testlock1 | grep -i lock

                  Locked: Yes

# isi auth users modify testlock1 -–unlock

# isi auth users view testlock1 | grep -i lock

                  Locked: No

If a user is added to the exclusion list, the account, in this case ‘testlock1’ is automatically exempted from this lockout function. For example:

# isi_gconfig registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers=’[“testlock1”]’

Note that OneFS does not check whether a user account name is valid when it is added to the exclusion list.

The lockout duration value can be specified in several ways. For example, a simple numeric value equates to seconds. For example:

# isi auth file modify System --lockout-duration=60

The above configuration will lockout for sixty seconds (one minute).

Other more convenient time period notation can also be used, such as M=minute, H=hour, D=day, W=week, etc.

For example, a two day lockout duration can be expressed as follows:

# isi auth file modify System --lockout-duration=1D

Or:

# isi auth file modify System --lockout-duration=48H

The user account lockout feature provides a configurable exclusion list, which allows certain users (eg. ‘root’ and/or ‘administrator’) to be exempted from lockout. This exclusion list is housed in gconfig, and is configured using the following ‘isi_gconfig’ CLI command permutations:

So, for example, the syntax for adding ‘testlock1’ and ‘testlock2’ system zone user accounts to the lockout exclusion list is as follows:

# isi_gconfig registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers=’[“testlock1”, ”testlock2”]’

# isi_gconfig registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers

registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers (char**) = [ "testlock1", "testlock2" ]

Note that the system file provider exclusion list is already present by default, so there is no need for a create option. However, for a non-system zone file provider, the exclusion list needs to be created first, before it can be modified and/or viewed.

To guard against cluster admin accounts becoming inadvertently locked out, a recommended practice is generally to add ‘root’ and/or ‘administrator’ to the exclusion list. For example:

# isi_gconfig registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers='["root","administrator"]'

# isi_gconfig registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers

registry.Services.lsass.Parameters.Providers.File.Instance.System.LockoutExcludedUsers (char**) = [ "root", "administrator" ]

Also, be aware that configuring the ‘lockout duration’ parameter to ‘0’ means the account will never get unlocked automatically, so exercise caution when configuring lockout duration.

As we gear up for next month’s Dell Technologies World, PowerScale is welcoming spring with the debut of the innovative OneFS 9.14 release, which officially shipped today (April 8, 2026).

OneFS 9.14 brings a wave of enhancements across spectrum of the PowerScale platform. As the product continues to evolve, this release focuses on strengthening core functionality, expanding hardware and object support, delivering stronger security capabilities, improving serviceability, and elevating overall usability and customer experience.

Below is an early look at what’s coming, with deeper technical dives on individual features to follow in future posts.

Streamlined Deployment and Automation Enhancements

OneFS 9.14 introduces zero‑touch provisioning DHCP support, enabling nodes to automatically receive their IP addresses during deployment. This capability is designed to simplify large‑scale automated rollouts and reduce the operational overhead associated with manual node configuration.

The release also adds a new REST API for syslog management, giving customers the ability to automate creation and updates of syslog configurations. Instead of navigating the GUI and making manual adjustments, storage admins can now easily script and manage logging settings programmatically, making it ideal for environments with tightly automated and/or DevOps-driven workflows.

Customers who rely heavily on SmartQuotas quota description metadata gain more flexibility as well. The maximum description field size in configuration objects increases from 1 KB to 4 KB and 4095 ASCII characters, allowing for richer metadata that is easier to search, categorize, and align with operational requirements.

SMB and Object Storage Improvements

SMB environments will benefit from SMB2 durable handle support for static network pools, which keeps file handles active on the server briefly after a client disconnects. This means that if a connection drops, users can reconnect without re‑authenticating—improving application resilience while maintaining security boundaries.

On the object storage side, OneFS 9.14 introduces support for S3 CORS buckets, enabling modern web applications to retrieve and display resources without running into browser security restrictions. New S3 lifecycle‑management capabilities also arrive in this release, including automated cleanup of incomplete multipart uploads and rule‑based object deletion. These features help keep buckets clean, reduce storage waste, and simplify long-term data management.

Security Advancements

Security continues to be a critical pillar of the platform. OneFS 9.14 expands authentication capabilities by adding CAC/PIV support for LDAP server hosts, extending the existing HTTPS‑only support. This enhancement allows customers operating in high‑security environments, especially governmental or other regulated sectors, to integrate more seamlessly with their identity infrastructure.

Additionally, CAVA antivirus scanning now supports HTTPS, replacing the older HTTP requirement. As more customers move to encrypted communications by default, this enhancement ensures that antivirus scanning can remain active without compromising network security posture.

Platform & Hardware Enablement Updates

The release introduces backend support for the Dell Z9432 top‑of‑rack switch, enabling higher connectivity density. A second supplier option for Ethernet HB NICs (Broadcom) also enters the portfolio, expanding hardware flexibility and supply-chain resilience.

Serviceability receives a boost as well. A diagnostics tool previously reserved for internal service teams is being productized, providing the ability to capture deeper performance and slow‑processing data on demand. This tool can be activated and disabled by the customer and provides valuable insight during troubleshooting, helping reduce time to resolution.

Finally, there’s also new in‑band automation for upgrading or downgrading backend switch firmware, making infrastructure maintenance significantly easier. Customers gain additional control over their system health workflows with the ability to enable or disable automatic downloads of healthcare definitions—an important feature for environments with strict update governance.

In summary, OneFS 9.14 brings the following new features and functionality to the Dell PowerScale ecosystem:

OneFS 9.14 is shaping up to be a significant release that strengthens the PowerScale ecosystem across automation, object storage, security, serviceability, and hardware support. With a blend of immediate production-ready enhancements and forward‑looking technical previews, this release continues the platform’s momentum toward greater scalability, operational simplicity, and enterprise-grade resilience. Stay tuned for deep-dive articles where we explore each feature in detail and discuss how customers can leverage them in real-world deployments.

We’ll be taking a deeper look at the new OneFS 9.14 features and functionality in blog articles over the course of the next few weeks.

Meanwhile, the new OneFS 9.14 code is available on the Dell Support site, as both an upgrade and reimage file, allowing both installation and upgrade of this new release.

For existing clusters running a prior OneFS release, the recommendation is to open a Service Request with to schedule an upgrade. To provide a consistent and positive upgrade experience, Dell Technologies is offering assisted upgrades to OneFS 9.14 at no cost to customers with a valid support contract. Please refer to this Knowledge Base article for additional information on how to initiate the upgrade process.

OneFS 9.13 introduces a new user‑lockout security mechanism for file‑provider accounts to protect against brute‑force and password‑guessing attacks. While PowerScale has long supported lockout controls for local authentication providers, this release extends equivalent protection to file‑provider accounts.

The OneFS user account security architecture can be summarized as follows:

Within the OneFS security subsystem, authentication is handled in OneFS by LSASSD, the daemon used to service authentication requests for lwiod.

In OneFS Authentication, Identity Management, and Authorization (AIMA) there are several different kinds of backend providers: Local provider, file provider, AD provider, NIS provider, etc. Each provider is responsible for the management of users and groups inside the provider.

OneFS 9.13 introduces three new account lockout configuration parameters  for the file provider. First, the ‘lockout‑threshold’ parameter specifies the number of failed authentication attempts required before the account is locked. ‘Lockout‑window’ defines the time interval during which failed attempts are counted. If the user does not exceed the threshold within this window, the counter resets after the window expires. Finally, the ‘lockout‑duration’ parameter determines how long the account remains locked once the threshold has been exceeded.

In practice, when a legitimate user or malicious attacker enters an incorrect password repeatedly and the number of failures reaches the configured threshold within the defined window, the account is locked for the duration specified. During the lockout period, the account cannot authenticate even with a correct password. Administrators can view the account’s status and manually unlock it as needed. If the threshold is set to zero, the lockout feature is disabled. Additionally, if failed attempts occur but the user either waits longer than the lockout window or successfully authenticates before reaching the threshold, the failure counter resets and no lockout occurs.

Because some file‑provider accounts, such as root and administrator, are essential for cluster maintenance, misconfiguration or malicious use of this feature could create operational or denial‑of‑service risks. To mitigate this, OneFS 9.13 introduces an exclusion list that prevents designated accounts from being subject to lockout. Administrators can configure and modify this gconfig-based exclusion list  via the OneFS CLI. Modifying the exclusion list requires elevated operating‑system privileges, as it is intended to act as a safeguard rather than a routine configuration tool.

The lockout feature becomes available only after a OneFS 9.13 upgrade has been fully committed. Removing the upgrade also removes the associated configuration. No licensing is required to enable the feature. Three corresponding options are now available through the OneFS 9.13 CLI—lockout‑threshold, lockout‑window, and lockout‑duration—and can be set during provider creation or modified afterward.

Configuration is accessible through the WebUI under the Access, Membership, and Roles section, where password policies for local or file providers can be adjusted. Administrators can specify the threshold, window, and duration values, and may manually unlock accounts if needed. Setting the lockout duration to zero results in a permanent lockout until an administrator intervenes. The exclusion list for the system file provider is managed using the isi_gconfig interface, while non‑system file‑provider exclusion lists must first be created and then modified individually.

For troubleshooting, a new SQL‑backed IDDB file has been introduced to store user‑lockout data. This DB file is located at /ifs/.ifsvar/modules/auth/file/filelockout.db. While typically not required for routine administration, it can assist in diagnosing unexpected lockout behaviors.

OneFS also support an exclusion list for user lock-out functionality. In OneFS, certain local system accounts, such as root and administrator, are critical to cluster management and system access. If the account lockout mechanism is unintentionally enabled for these accounts, or if repeated failed login attempts occur (whether accidental or malicious), the resulting lockout could render the system unmanageable. This also presents a potential denial‑of‑service (DoS) vector, since an attacker could intentionally trigger lockouts on privileged accounts.

To mitigate this risk, OneFS introduces a configurable exclusion list. Any account added to this list is exempt from the lockout mechanism and will not be disabled, regardless of failed authentication attempts. The exclusion list can be configured and modified through the CLI, WebUI, or Platform API. Because this mechanism functions as a safety measure and last line of defense, it is exposed only through privileged configuration interfaces (for example, via gconfig), requiring elevated OS‑level permissions.

The lockout feature is controlled by the lockout threshold. When this threshold parameter is set to a non‑zero numerical value, the feature is activated. Conversely, when the threshold is set to 0 (the default), the lockout function is disabled.

A user will be locked out if they repeatedly enter incorrect credentials within the configured lockout window and reach the specified threshold. Immediately after lockout, the user cannot authenticate, even with a correct password, until an administrator reviews the account status and manually unlocks it.

Alternatively, if the user waits longer than the defined lockout window between failed attempts, the failure counter is reset to zero. At this point, an access attempt with the correct password entered will be successful.

In a scenario where a user does become locked out, there are two recovery methods:

Additionally, accounts may be added to the exclusion list, preventing them from being locked out in the future. OneFS distinguishes between the system file provider and non‑system file providers, and the procedure for adding accounts to the exclusion list differs slightly between the two.

Three new options have been added to the ‘isi auth file create/modify’ CLI command in OneFS 9.13 in support of this functionality:

The currently configured lockout parameters can be viewed as follows:

# isi auth file view System | grep -i lockout

Lockout Duration: 10m

Lockout Threshold: 0

Lockout Window: 5m

Alternatively, the user lockout configuration can also be accessed from the OneFS WebUI by navigating to Access > Membership and roles > Password policy, and selecting the desired provider:

After selecting ‘FILE:System’ from the ‘Providers’ drop-down menu, the threshold lockout parameters are displayed and can be configured to specify how many unsuccessful login attempts within what length window (in minutes), and lock out for what duration. Alternatively, an option to ‘Unlock manually’ is also provided, if preferred. Note that the manual unlocking of a user account must be performed from the CLI or platform API since there is no WebUI support for this currently.

In the next article in this series, we will turn our focus to the configuration and management of the user account lockout functionality.

Auditing plays a critical role in identifying potential sources of data loss, fraud, inappropriate permissions, unauthorized access attempts, and other anomalous behaviors that indicate operational or security risk. Its value increases significantly when access events can be correlated with specific user identities.

To support strong data‑security practices, OneFS implements comprehensive ‘chain‑of‑custody’ auditing by recording defined activity across the cluster. This includes OneFS configuration changes as well as client operations over NFS, SMB, S3, and HDFS.

OneFS 9.13 introduces the auditing of NFS mount‑denial events, enabling organizations to easily detect unauthorized access attempts and meet corporate and Federal auditing and intrusion‑detection requirements. This new NFS functionality complements the SMB access‑denial auditing introduced in OneFS 9.5, allowing administrators to enable protocol auditing, configure audit zones, and integrate intrusion‑detection systems that analyze audit logs for suspicious behavior. Although the lack of logging  does not permit unauthorized access, it does allow such attempts to go unnoticed, which violates auditing guarantees required for certain compliance standards. All resulting events can be reviewed using the isi_audit_viewer tool.

When an NFS client issues a mount request, the request is processed by the NFS protocol head on the PowerScale cluster.

Successful mount operations return a success response to the client. When a mount request is denied, the protocol head explicitly invokes the Audit Filter APIs, which generate a share-access-check audit event. SMB and NFS share this same event type, although each protocol populates different subsets of fields. NFSv3 audit entries include the full path requested by the client, whereas NFSv4 may contain only a partial path due to the protocol’s directory traversal design. These events are visible only through isi_audit_viewer and are not exported via syslog or CEE.

A new ‘protocol’ field has been added to the ‘share-access-check’ event so that administrators can differentiate between NFS (including NFSv3 and NFSv4.x) and SMB access‑denial events. For example:

[3: Wed Feb  4 06:53:12 2026] {"id":"f1c21718-2b0f-11f0-8905-005056a0607c","timestamp":1746600792901821,"payloadType":"c411a642-c139-4c7a-be58-93680bc20b41","payload":{"protocol":"NFS","zoneID":1,"zoneName":"System","eventType":"create","detailType":"share-access-check","isDirectory":true,"desiredAccess":0,"clientIPAddr":"10.20.30.51","createDispo":0,"userSID":"S-1-22-1-0","userID":0,"userName":"","Domain":"","shareName":"\/ifs\/nfs_1","partialPath":"","ntStatus":3221225506}}

In the above example, the following fields and corresponding values are logged:

Per the above, the above failed mount request for export ‘/ifs/nfs_1’ came from the ‘root’ user:

# isi auth mapping view UID:0 –zone system

Name: root

On-disk: UID:0

Unix uid: 0

Unix gid: -

SMB: S-1-22-1-0

The following procedure can be used to configure and manage NFS mount‑failure auditing in OneFS 9.13 and later:

1. First, the NFS services must be enabled:

# isi services nfs enable

# isi nfs settings global modify --nfsv3-enabled TRUE

# isi nfs settings global modify --nfsv4-enabled TRUE

Or from the WebUI:

2. Protocol auditing must then be activated and associated with the appropriate access zones:

# isi audit setting global modify --protocol-auditing-enabled TRUE

# isi audit setting global modify --audited-zones <zone name>

# isi audit settings modify --zone <zone name> --add-audit-failure share_access_check

Or from the WebUI:

3. An NFS export can then be created. For example:

# mkdir /ifs/nfs_1

# isi nfs exports create /ifs/nfs_1 --clients 10.20.30.51

Or from the WebUI:

4. In this example, only the client at 10.20.30.51 is allowed to mount the export. If a client outside the allowed list attempts to mount the directory, the request fails on the client side. For instance:

# mkdir -p /mnt/tst/nfs_1

# mount.nfs 10.20.30.252:/ifs/nfs_1 /mnt/tst/nfs_1 -n -o nfsvers=3

# mount.nfs: access denied by server while mounting 10.20.30.252:/ifs/nfs_1

Or for NFSv4:

# mount.nfs 10.20.30.252:/ifs/nfs_1 /mnt/tst/nfs_1 -n -o nfsvers=4

# mount.nfs: mounting 10.20.30.252:/ifs/nfs_1 failed, reason given by server: No such file or directory

5. The corresponding audit entries can be viewed with:

# isi_audit_viewer -t protocol -v

Example output includes records such as:

[4: Wed Feb  4 06:53:29 2026] {"id":"fba69477-2b0f-11f0-8905-005056a0607c","timestamp":1746600809498757,"payloadType":"c411a642-c139-4c7a-be58-93680bc20b41","payload":{"protocol":"NFS4","zoneID":1,"zoneName":"System","eventType":"create","detailType":"share-access-check","isDirectory":true,"desiredAccess":0,"clientIPAddr":"10.20.30.51","createDispo":0,"userSID":"S-1-22-1-65534","userID":65534,"userName":"","Domain":"","shareName":"ifs","partialPath":"","ntStatus":3221225506}}

Note that there is no WebUI equivalent of the CLI-based ‘isi_audit_viewer’ utility.

Because of protocol differences, NFSv3 records contain the full mount path, while NFSv4 records may display only the first directory component where permission checking fails. In some cases, mount attempts do not generate server‑side audit entries at all. This occurs when the client IP is permitted but the user account is not: Linux NFS clients use an ‘ACCESS’ RPC to determine permissible operations on each path component. If ‘ACCESS’ returns insufficient permission, the client fails the mount without sending a ‘LOOKUP’ request. The server therefore sees only a successful ‘ACCESS’ operation and logs no audit event.

This release adds protocol identification to the share-access-check event. Prior to OneFS 9.13, only SMB access denials were audit logged, and without the ‘protocol’ information field. After upgrading, both SMB and NFS access‑denial events now include the new ‘protocol’ field.

Enabling auditing introduces general system overhead. However, the NFS mount‑denial auditing feature introduces no additional cost because it logs only unsuccessful mount attempts.

High-performance PowerScale workloads just gained a substantial new advantage. The all-flash F910 platform, in combination with the new OneFS 9.13 release, now supports next generation 400GbE networking, enabling faster data movement and smoother scalability. Whether powering AI pipelines or high-throughput analytics, 400GbE provides the headroom a high performance cluster needs to grow.

Native support for 400GbE front-end and/or backend networking on the F910, helps deliver next-generation bandwidth for performance-intensive workloads such as AI/ML pipelines, HPC, and high-throughput analytics.

This capability enables data movement and cluster expansion without architectural redesign, leveraging an existing NVIDIA SN5600 switch fabric if needed. The 400GbE implementation supports jumbo frames with RDMA over Converged Ethernet (RoCEv2) for low-latency data transfers, MTU sizes up to 9,000 bytes, and full compatibility with OneFS 9.13 or later releases using Dell-approved QSFP-DD optical modules. Clusters can scale up to 128 nodes while maintaining deterministic performance across Ethernet subnets.

With OneFS 9.13 400Gb Ethernet is supported for the F910 platform using the NVIDIA CX-8 PCIe gen6 network interface controller (NIC).

Under the hood, the 400GbE LNI type and the aggregate type have been added to OneFS, where it is registered as an ‘MCE 0123’ NIC, and works just as any other front-end or back-end NIC does. Additionally, the same driver is used for the CX-8 as the earlier generation of the NVIDIA CX cards, albeit with the higher bandwidth, and reported as ‘400gige’. For example:

# isi network interface list

LNN  Name      Status     VLAN ID  Owners                      Owner Type  IP Addresses

----------------------------------------------------------------------------------------

1    400gige-1 Up         -        groupnet0.subnet1.pool0     Static      10.20.30.51

1    400gige-2 Up         -        -                           -           -

1    mgmt-1    Up         -        groupnet0.subnet0.pool0     -           172.1.1.51

1    mgmt-2    No Carrier -        -                           -           -

2    400gige-1 Up         -        groupnet0.subnet1.pool0     Static      10.20.30.52

2    40gige-2  Up         -        -                           -           -

2    mgmt-1    Up         -        groupnet0.subnet0.pool0     -           172.1.1.52

2    mgmt-2    No Carrier -        -                           -           -

3    400gige-1 Up         -        groupnet0.subnet1.pool0     Static      10.20.30.53

3    400gige-2 Up         -        -                           -           -

3    mgmt-1    Up         -        groupnet0.subnet0.pool0     -           172.1.1.53

3    mgmt-2    No Carrier -        -                           -           -

----------------------------------------------------------------------------------------

Total: 12

Note that, unlike the 200GbE ConnectX‑6 adapter—which supports dual‑personality operation for either Ethernet or InfiniBand on the F-series nodes—the new 400Gbps ConnectX‑8 NIC is currently Ethernet‑only for PowerScale.

While 400GbE support in OneFS 9.13 is limited to the PowerScale F910 platform at launch, support for the F710 nodes and the PA110 accelerator is planned for an upcoming release.

This new NIC family is functionally similar to previous generations, with the primary difference being the increased line rate. It is designed for high‑performance workloads. The NVIDIA Spectrum‑4 SN5600 switch is required for the back‑end fabric, which currently limits cluster scalability to 128 nodes due to the absence of leaf‑spine support.

Support for Dell Ethernet switches will be introduced in a future release, but is not part of the current offering. Additionally, these new 400 GbE NICs cannot interoperate with 100GbE switches such as the Dell S5232, Z9100, or Z9264 series, as the technological differences between 100Gb and 400Gb Ethernet generations are too great to maintain compatibility. In OneFS, the adapters appear like any other NIC, identified simply as 400GbE interfaces.

Deploying 400GbE networking requires an F910 node pool running OneFS 9.13, along with compatible transceivers, cabling, and an NVIDIA Spectrum‑4 SN5600 switch.

Installation of 400GbE networking requires an F910 node pool running OneFS 9.13, plus transceivers, cables, and an NVIDIA Spectrum-4 5600 switch:

Additionally, the F910 nodes need to be running the latest node firmware package (NFP), as the iDRAC needs to support the card properly.

The current PowerScale 400GbE solution continues to use standard multimode optical modules, including the larger twin‑port module for the switch and the smaller QSFP‑112 SR4 module for the network adapter.

The Dell transceiver components are equivalent to the NVIDIA parts, as they are manufactured to the same specifications and differ only in part number.

With the 400 GbE generation, active optical cables (AOCs) are no longer supported. The increasing size and mechanical mass of the optical modules make AOCs unreliable and prone to damage at these speeds, so the architecture shifts fully to discrete optical transceivers and fiber cabling.

A significant consideration for new 400GbE PowerScale deployments is the transition to MPO‑12 APC (Angled Polish Connector) cabling. These connectors are identifiable by a green release sleeve, in contrast to the blue sleeve used on traditional UPC variants. For example:

APC cabling provides improved signal integrity; however, APC and UPC connectors are mechanically compatible.

Note that using a UPC cable in a 400GbE port will result in degraded signal quality or link instability. When installing 400GbE networking, verify that APC‑type MPO‑12 cables are used throughout a PowerScale F910 cluster’s 400Gb Ethernet network.

As mentioned previously, the NIC used in the F910 nodes for 400GbE connectivity is NVIDIA’s ConnectX‑8 PCIe Gen6 adapter with dual QSFP‑112 ports in a standard half‑height, half‑length form factor.

Note that this NIC’s power consumption exceeds 50 Watts, which leads the PowerScale F910 nodes to operate their cooling fans at high speed to manage thermal output. So additional fan noise from these 400GbE F910 nodes, as compared to their 100GbE and 200GbE variants, is not indicative of an issue.

Also note that the onboard hardware cryptographic engine in the CX-8 NIC is enabled by default, although it is not currently utilized by OneFS. However, this may be a relevant consideration for certain regulatory compliance or export‑control scenarios.

Network switching for 400GbE uses the NVIDIA Spectrum-4 SN5600 switch. As mentioned previously, active optical cables (AOCs) are not available at this speed class. However, a 3‑meter direct-attach copper cable (DAC) is qualified for in‑rack connections. For front‑end connectivity, multimode optical transceivers remain the recommended option, consistent with prior generations.

Due to the thermal characteristics of 400GbE optics and NICs, systems should be expected to operate fans at maximum speed under typical workloads.

Regarding compatibility with lower speed Ethernet connectivity, the F910’s 400GbE NIC does support 200GbE optics and cabling, and will happily down‑negotiate to 200GbE. However, it is unable to down‑negotiate to 100GbE.

In the previous article in this series, we looked at configuring Dynamic Licensing from the WebUI and CLI. In this article, we’ll focus on the management and troubleshooting of Dynamic Licensing.

Note that the OneFS 9.13 WebUI only supports the configuration and monitoring of Dynamic Licensing. Additional operations such as license reduction, deregistration, etc, can only be performed via the CLI or WebUI.

A cluster’s product registration may be expanded with additional features, capacity, quantity, or term via an updated registration request, which adds or removes entitlements from the pool, resulting in the intended action.

For example, the following cluster is configured for Dynamic Licensing, and all four nodes are registered:

Next, one of the nodes is SmartFailed, removing it from the cluster:

# isi devices node smartfail –lnn 4
You are about to begin smartfailing node lnn 4. Are you sure? (yes/[no]): yes

However, Dynamic Licensing still reports the cluster as having four registered nodes:

Next, the ‘isi license modify’ CLI command can be used to remove the SmartFailed node’s license:

# isi license modify
Product licensing process initiated.
Use ‘isi license status’ to monitor.
# isi license status
Product update registration completed successfully.

The output above indicates that the product registration has been successfully executed, and the reduced node count is now reflected in the ‘isi license output’:

Note that a Dynamic Licensing runs a cron job to capture licensing updates from cluster changes, but this job is only run once daily. The CLI options can be used for a more timely, on-demand cluster license update.

A similar process can be employed for cluster expansion. For example, re-adding the fourth node to the same cluster:

The licensing CLI now reports four cluster nodes, but only three are licensed:

The ‘isi devices’ CLI command now shows the fourth node up and joined to the cluster:

Next, the ‘isi license modify’ CLI command is used to re-run the registration update process, which reports the ‘perform_expansion’ task as ‘IN_PROGRESS’:

# isi license modify
Product licensing process initiated.
Use ‘isi license status’ to monitor.
# isi license status
Dynamic_license_update_registration is IN_PROGRESS state, sub state : perform_expansion.

Once the registration update process has successfully completed, Dynamic Licensing reports that all four nodes are available and licensed:

For changes to cluster capacity, composition, and/or licensed data service modules, the ‘–lacs=’ argument can be used with the ‘isi license modify’ CLI command. For example:

# isi license modify –-lacs=LACPSA210920250504
Product licensing process initiated.
Use ‘isi license status’ to monitor.
# isi license status
Product update registration completed successfully.

In this case, we’ve added an additional OneFS license to the entitlements, so the ‘Licensed node count’ now reports five nodes, while the ‘Actual node count’ still shows the cluster’s four nodes. This is similarly reported from the WebUI:

Note that Dynamic Licensing’s consumption workflow is not available from the WebUI, CLI, or pAPI. Instead, a cron job is used, which runs hourly to collect the consumption data, and then daily once in a day to upload the aggregated consumption data to the Dynamic Licensing back-end. Based on this consumption data, the Dynamic Licensing back-end performs the license assessment and sends OneFS a compliance report. The PowerScale cluster then process the compliance report, and, if necessary, generates any required events and alerts in case of any feature violations. For example, say a customer has purchased 100TB of capacity and they attempt to exceed that limit. In this case OneFS will generate over-capacity alerts. Additionally, OneFS will attempt to resolve those alerts once the capacity utilization returns below the 500TB limit.

In the event of hardware and software expansion or reduction, gconfig is updated to reflect the licensing changes on the cluster. The existing OneFS license state machine is used, along with a new ‘dynamic_license_update_registration’ sub-task.

In addition to the automated cron process, customers can also initiate expansion or reduction on-demand via the OneFS CLI or platform API (pAPI). For example:

# isi license add

The process to register the product with Dynamic Licensing backend has been initiated.

The ‘isi license’ CLI command set is expanded in OneFS 9.13 with the addition of ‘deregister’ and modify options, plus removal of the legacy ‘activation’ option, resulting in a general syntax as follows:

# isi license -h
Description:
    Manage software licenses.

Required Privileges:
    ISI_PRIV_LICENSE

Usage:
    isi license <action>
        [--timeout <integer>]
        [{--help | -h}]

Actions:
    add           Registers the product with Dynamic Licensing or applies
                  offline registration file
    deregister    Deregister the product from the Dynamic Licensing backend.
    generate      Generate license activation file.
    list          Retrieve license information of all licensable features.
    modify        Update the product registration in the Dynamic Licensing
                  backend.
    status        Check licensing process status.
    view          Retrieve license information of a licensable feature.

 When a PowerScale is deprovisioned, it is necessary to deregister its license registration. This process ensures that the cSWID is removed from the reservation pool and entitlements are returned to the available state. In the process, deregistration removes the license from the cluster’s gconfig configuration store, and post-deregistration, the cluster is unlicensed.

Dynamic Licensing deregistration, say if the cluster is being deprovisioned or reimaged, can be performed from the CLI (or platform API), but not the WebUI. For example:

# isi license deregister
Deregistering product process initiated.
Use ‘isi license status’ to monitor.
# isi license status
Product deregistration completed successfully.

As expected, after successful deregistration, the ‘isi license status’ CLI command now reports zero licensed nodes:

This means that the nodes’ licenses have been reset, and can now be successfully re-registered when the nodes have been reprovisioned.

Correspondingly, the Dynamic Licensing gconfig status now reflects that the cluster is no longer registered (licensing.dl_registered (bool) = false), and the default licensing method is now set to ‘offline’ (licensing.license_method (char*) = offline). For example:

# isi_gconfig -t licensing
[root] {version:1}
(empty dir licensing.features)
licensing.swid (char*) = <null>
licensing.license_method (char*) = offline
licensing.migration_required (bool) = false
licensing.last_send_time (int64) = 0
licensing.interval_hours (int64) = 24
licensing.dl_registered (bool) = false
ignore_signature (bool) = false
last_upgrade_commit_epoch (int64) = -1

If a cluster needs to be reimaged for whatever reason, first the cluster admin must deregister the PowerScale license registration. Failure to do so results in the product registration call failing, as the hardware entitlements are tied to a different cSWID. In cases where the customer fails to deregister the license and proceeds with reimaging the cluster, Dell support will need to remove the older cSWID. Note that a future solution is in progress to handle this scenario without requiring Dell Support’s involvement.

The license topology can be modified at any time, and whenever a topology change occurs the pertinent Dynamic Licensing gconfig settings are updated to reflect the new topology details. When the licensing mode is set to Direct and connectivity is enabled, the system behaves as follows in case of a temporary disconnection:

• The licensing mode remains as ‘Direct’, even if a temporary disconnect occurs.
• The cron job continues to perform its scheduled tasks without interruption.
• As soon as the connectivity is re-established, all workflows resume their normal operation.

Clusters with DTCS/SRS enabled and connected to the Dell backend are automatically migrated to Dynamic Licensing upon upgrade to OneFS 9.13 or later, using the Key-to-Dynamic Upgrade Product Registration. For connected customers, the migration process occurs seamlessly, with the cluster handling the transition to Dynamic Licensing as part of the upgrade process.

Conversely, when a disconnected cluster upgrades to OneFS 9.13 or later, it continues to use the legacy XML-based licensing. However, the option is available to migrate to Dynamic Licensing at a later time, using either the direct-connected’ or offline registration modes.

Under the hood, Dynamic Licensing introduces a new ‘migration_required’ flag, which has a default value of ‘false’. In the event of an upgrade to OneFS 9.13 or later, the value of this flag is set to ‘true’.

In OneFS 9.13 or later with Dynamic Licensing enabled, a ‘cron’ scheduling job runs on an hourly and daily basis. Running as root, this cron job’s primary responsibilities include:

• Collecting consumption data on an hourly basis
• Sending the collected data to the Dynamic Licensing (DL) backend at least once a day, or at intervals defined in the global configuration (gConfig)

The cron job uses the OneFS licensing state machine’s ‘send_consumption’ subtask to send the consumption data to the backend.

The cron job monitors for changes to the node configuration, including additions or removals, and updates the registration in the Dynamic Licensing backend accordingly. This involves registering new nodes or decreasing the registration count when nodes are removed. If no changes are detected during expansion or reduction, the cron job will call the get registration API to retrieve the latest licensing information from the backend. The cron job utilizes the ‘dynamic_license_update_registration’ subtask of the license state machine for expansion, reduction, and get-registration operations.

The cron job uses the following gconfig parameters to send consumption data, and the job typically runs as root to allow it to operate in OneFS compliance mode:

For example:

# isi_gconfig -t licensing | grep int
licensing.last_send_time (int64) = 0
licensing.interval_hours (int64) = 24

Security-wise, Dynamic Licensing is available and supported in the following PowerScale cluster security modes:

• Compliance
• Hardening
• Root Lockdown Mode (RLM)

Additionally, the ‘ISI_PRIV_LICENSE’ OneFS RBAC privilege is required.

When it comes to monitoring and/or troubleshooting Dynamic Licensing, there are several events, alerts, and healthchecks to provide warning, in addition to diagnostic logs. There are also WebUI banners that provide warnings and context for licensing issues. For example, the following will be displayed if the node serial numbers are already registered:

OneFS sends the meter licensed feature consumption/usage across the cluster as regular license health checks, and send it to the Dynamic Licensing back-end in a timely manner (typically at least once per day). The response to a license consumption call provides the latest state of the reservation pool (i.e., what entitlements exist) and compliance events generated after running the license assessment.

The assessment results are provided to the PowerScale cluster, which sends the latest consumption information to the Dynamic Licensing system.

The License Assessment measures result in 5 levels of concern, as mentioned below, with Level 1 being the lowest level of concern (OK) and Level 5 indicating the highest level of concern (critical). These tiers/concern levels need to be mapped to threshold values accordingly in the license policy based on what messaging & enforcement actions the products want to define.

A PowerScale cluster processes compliance events from the consumption response from Dynamic Licensing and will raise the events for Warn, Alert and Critical in the Direct mode. In the offline case, alerting is based on local compliance, which is determined by capacity usage.

The cluster creates events for all licensed features, and based on the compliance response, will raise an event for a particular feature if it fails compliance. Once the customer purchases new entitlements and compliance failures are resolved, the cluster quiesces the pertinent events for those licensed features.

OneFS raises a ‘SW_SUPPORTASSIST_DISCONNECTED’ event whenever connectivity is lost between the PowerScale cluster and the Dell Backend (DTCS/ESE). Additionally, OneFS also raises ‘WARN’ and ‘CRITICAL’ alerts when it is unable to connect to the Dell Backend.

The following diagnostic logs can provide considerable insight into Dynamic Licensing operation and issues, too:

Some additional Dynamic Licensing caveats and considerations that are worth noting include:

If registration with Dynamic Licensing fails, customers may instead manually register their PowerScale cluster through the Dell Software Licensing portal and upload the corresponding license file to the system from there.

Note that the legacy evaluation mechanism remains in OneFS 9.13 and later for enabling limited time trial licenses for specific data services. For example, to enable trial licenses for SmartPools and SyncIQ from the CLI:

# isi license add --evaluation SyncIQ --evaluation SmartPools

As we saw in the previous article in this series, Dynamic Licensing in OneFS 9.13 replaces the legacy, key‑based licensing model used in prior releases. Next, we’ll turn our attention to the configuration of Dynamic Licensing.

This updated Dynamic Licensing workflow supports both directly connected and offline environments, enabling customers to register licenses and manage entitlement reservations based on their connectivity capabilities, while providing real‑time entitlement updates and enhanced operational insight.

Key benefits of Dynamic Licensing include:

• A unified licensing model that spans appliance, hybrid, and cloud deployments through a centralized reservation pool.
• Near‑instant time‑to‑value with a cloud‑like consumption experience.
• Seamless portability of licensed capabilities across clusters.
• Reduced complexity throughout the licensing lifecycle.
• Lower serviceability and support overhead through expanded automation.

Dynamic Licensing supports two operational modes to accommodate varying customer environments:

The currently configured method can be viewed from the WebUI under Cluster management > Dynamic licensing > Settings:

Or from the CLI with the following syntax:

# isi license list | grep -i method

   License Method: Offline

First, we’ll take a look at the direct, or ‘connected’, mode:

The basic process to configure OneFS Dynamic Licensing in ‘Connected Method’ is as follows:

1. From a fresh cluster running OneFS 9.13 or later, navigate to Cluster management > Dynamic Licensing > Overview:

The banner above will be displayed if Dynamic Licensing has not yet been activated on the cluster.

2. Ensure that Dell Technologies Connectivity Services (DTCS) are enabled. This can be accomplished via the WebUI’s connectivity services wizard, under General Settings > Connectivity Services:

This may take some time while the cluster connects to DTCS, during which the following will be displayed:

Once the wizard has completed and connectivity has been established, the DTCS status will report ‘Enabled’, and the Dynamic Licensing status will show as ‘Registered’:

3. From the WebUI under General Settings > Dynamic Licensing > Overview, the cluster now reports its licensed storage and nodes:

4. Under General Settings > Dynamic Licensing > Settings, the connectivity status is now reported as ‘Connected Method (Recommended)’.

Note the ‘+’ icon within the ‘How to update a OneFS license’ text box:

Clicking this plus icon will display the following overview of the two license update option:

5. Changes to a cluster’s license(s) can be easily made any time, by clicking the ‘Update License’ button:

6. This brings up the ‘Update License’ window, which allows the additional OneFS software and data services licenses to be activated. The License Activation Code (LAC) can be added for each licensed entity:

This may take some time, during which the license activation status will be displayed:

7. Once complete, the new license status and entitlements will be displayed on the ‘Overview’ page:

In this case, the total licensed storage has now increased to 400TB.

Alternatively, Dynamic Licensing can be enabled via the CLI in OneFS 9.13 or later, using the ‘isi license add’ syntax. Options for this command include:

 If running Dynamic Licensing in ‘connected’ mode is not feasible or desired, the alternative is to configure ‘offline’ mode.

In this case, the cluster admin has to access the Dell Licensing Portal (SLC), provide the cluster inventory, download the licensing file, and then perform the registration as follows:

1. From a cluster running OneFS 9.13 or later, select Dynamic Licensing ‘Offline Method’ from the WebUI under Cluster management > Dynamic Licensing > Settings:

2. From the Dell Licensing Portal, provide the serial number and all the service tags of the PowerScale cluster that is to be registered offline.

3. Next, download the registration file.

4. Once this registration file is available, upload it to the PowerScale cluster:

5. Next, from the ‘upload license registration file’ window, the JSON file is located, and the ‘upload file’ button clicked to apply the license registration to the PowerScale cluster:

6. From the ‘Overview’ screen, a banner confirms that the license upload was successfully completed:

7. This screen also reports the cluster’s entitlements, indicating that the cluster now has four licensed nodes and licensed capacity of 400 TB:

The Dynamic License gconfig parameters can be queried from the CLI to confirm that the PowerScale cluster is both registered with the dynamic licensing back end, and that the license method is ‘offline’:

This software identifier can also be verified from the Dell Licensing Portal.

In summary, clusters running Dynamic Licensing in offline mode require the administrator to download an updated registration file whenever license changes occur. When additional entitlements are purchased, a new registration file must be created in the Dell Licensing Portal and uploaded to the PowerScale cluster:

In the next and final article in this series, we’ll turn our attention to Dynamic Licensing management and troubleshooting.