What's New in StorNext 7.2

Purpose of this Release

The StorNext 7.2 release provides new features and enhancements, and also provides software fixes listed in the section Fixed Issues and Enhancements Addressed in StorNext 7.2.

This release also includes a significant upgrade to the underlying operating system of the Quantum appliances; specifically, the operating system is upgraded to Rocky 8.7 from CentOS 7.9.

Note: Upgrades are only allowed from StorNext version 7.1.0 (or later) to StorNext version 7.2.0.

Important Information about StorNext Xcellis systems connected to F-Series and H-Series RAIDs using iSER

A performance issue exists with StorNext version 7.2.0 Xcellis appliance platform when storage targets are configured with iSCSI RDMA (iSER). The issue can cause a significant degradation in performance as compared to previous releases of the StorNext 7 Xcellis appliance platform and only affects StorNext Xcellis systems connected to F-Series and H-Series RAIDs using iSER. Customers configured with NVMe-oF RDMA, NVMe-oF TCP, iSCSI TCP, or Fibre Channel storage targets are not affected by the issue and can be safely upgraded. If iSCSI RDMA (iSER) is configured, and (a) an upgrade to StorNext version 7.2.0 is required and (b) your environment contains an F2100 system, Quantum recommends you contact Quantum Support (see Contacting Quantum Support) for a software patch before you upgrade to StorNext version 7.2.0.

Information about Pre-Upgrade Checks

Beginning with StorNext version 7.2.0, the pre-upgrade check validation process also checks for RPM files that cannot be upgraded. Upon validation failure, an Admin Alert containing a list of RPMs found that are not expected on the node(s), is generated. You must manually remove these RPMs from the node(s) before you activate the upgrade. If the system you are upgrading includes the lin_tape RPMs, you must manually remove the RPMs before you start the upgrade process, and then install the RedHat 8 version of the RPMs after the upgrade process is complete.

Information About StorNext Unified Connector Upgrades

If your system is running StorNext version 7.1 (or later), you must upgrade the StorNext Unified Connector on non-MDC based clients.

Note: The StorNext Unified Connector is automatically upgraded on MDC based clients as a part of the StorNext software upgrade process.

Caution: Only the latest version of the StorNext Unified Connector properly displays performance metrics and statistics in the UUI.

To upgrade your StorNext Unified Connector, see Unified Connector Tasks.

Information About StorNext Firmware Upgrades

If your system is running StorNext 7.0.1.1 (or earlier) and you use the StorNext GUI to upgrade your firmware, do the following to upgrade to StorNext 7.0.2 (or later).

Caution: Due to a known file size limitation, if you attempt to upgrade your firmware using the StorNext GUI, the upload of the second firmware file fails with the following error:

File upload failed. The request was rejected because its size exceeds allowed range.

Do the following to workaround this issue:

  1. Modify the com.icesoft.faces.uploadMaxFileSize parameter in the web.xml file (located in /usr/adic/tomcat/webapps/ROOT/WEB-INF/web.xml) to a value of 10737418240.

    Example

    <!--  Max. file size to upload (10 GB)  -->
    <context-param>
    <param-name>com.icesoft.faces.uploadMaxFileSize</param-name>
    <param-value>10737418240</param-value>
    </context-param>
  2. Save your changes to the web.xml file.

  3. Open a root UNIX shell window on your appliance, and run the following command to restart the StorNext GUI:

    Note: Wait a few minutes before you try to access the StorNext GUI, and then retry the command if it fails.

    # service stornext_web restart

New Operating Systems Supported Effective with StorNext 7.2

Operating Systems No Longer Supported Effective with StorNext 7.2

New Features and Enhancements to the Quantum Unified User Interface (UUI)

Features No Longer Supported Effective with StorNext 7.2

Information about FlexSync Support

StorNext 7.2 only supports FlexSync 3.1.0 (or later). If you want to install StorNext 7.2 on your system, or upgrade your system to StorNext 7.2 and want to use FlexSync, then you must install FlexSync 3.1.0 (or later), or upgrade to FlexSync 3.1.0 (or later) on each system using the feature, including the source destination, the target destination, and the managing appliance.

Caution: Mixed versions of FlexSync daemons is not supported and results in a communication error. You must install the same version of FlexSync, or upgrade to the same version of FlexSync on all of the hosts or systems using Flexsync. A newer version of the Flexsync daemon cannot communicate with an older version within a configuration, or on another host or system.

Compatibility and Support

The StorNext 7.2 Compatibility Guide provides the basic compatibility for StorNext 7.2, including the StorNext components supported, operating systems and service packs, libraries and drives, browsers, virtual machines, and appliance support. Listed below are just a few of the types of information available to you in the StorNext 7.2 Compatibility Guide.

Fixed Issues and Enhancements Addressed in StorNext 7.2

ID Description
SNXT-795 frequent lines like crond[216059]: pam_sss(crond:session): Request to sssd failed. Connection refused found in /var/log/secure
SNXT-948 --norequiredmedia description is missleading in fsimport man page
SNXT-1006 sntier relies on mountpoint causing issues when filesystem is stopped /removed but mounted
SNXT-1044 fsaddclass and fsmodclass drive pool name are not checked against the actual drive pools names and naming rules are inconsistent between fs and vs
SNXT-1161 'error 37' during mdarchive restore when 'quotas' is enabled
SNXT-1168 man page in sntier should mention --file to prevent directory affinitty move
SNXT-1234 Health Check (Media) is reporting 'Not enough LTO media' alerts despite there are unused blank tapes assigned to the policy.
SNXT-1408 UUI: Support running UUI on node 1 of MDC HA pair
SNXT-1478 Unprivileged users are not allowed to login after the Leapp upgrade completes and the rest of the platform upgrade is running
SNXT-1489 The grub settings intremap=no_x2apic_optout and nox2apic are not getting set on software RAID based XWD and XWE systems on upgrades to 7.2.0
SNXT-1491 XWEGen1 upgrade failed in ExtraRPMs with missing dependencies
SNXT-1530 Misconfigured snfs_rest_config.json file caused the fsmpm to fail to start without a good error output pointing to the cause.
SNXT-1536 Update the preupgrade check for the free space in /var for OS conversion upgrades from 10GB to 16GB
SNXT-1561 License: Invalid product code 0xB70(=DAE)
SNXT-1583 Consider having configurable use-at-your-own-risk revoke timeout
SNXT-1621 Fresh install of XWD or XWE results in missing /usr/cvfs/config/deviceparams file and system defaults for the I/O scheduler and nr_requests
SNXT-1656 'Balance' allocation strategy does not seem to work with default 'Inode Stripe Width' size
SNXT-1659 Add support for LTO RAO capability
SNXT-1670 XWE upgrade from 6.4.1 through to 7.2.0 fails the MellanoxUpdate checkpoint on 7.2.0 due to missing the kernel-modules-extra RPM
SNXT-1701 Add a new utility script to be used on Gen2 SWRAID based Xcellis systems to map the current boot drives to their physical slot numbers
SNXT-1758 fsmedcopy can write the EOD to the beginning of the tape if the source can't be read.
SNXT-1784 ActiveScale Cold Storage team would like REST API to trigger Audit
SNXT-1799 tracking bug for rdar://140352101 (acfs: heap overflow in dmfs_read_reply)
SNXT-1833 After upgrade to StorNext 7.2.0 the Notification (sl_noti_email_monitor) will not stay started
SNXT-1838 Need instrumented FSM code to resolve NFL issue
SNXT-1846 USBE container log grows to fill/scratch
SNXT-1939 ACLs on NFSv4: the users with read-only access should not be able to modify settings using nfs4_setfacl command
SNXT-1957 xdi crashes with SEGFAULT in SN7.2.0 with RH8 when using the webconsole