System Operations

Caution: Do not change any BIOS settings on your system.

This section describes how to perform common operations on the H2000, including configuring and changing configuration settings using the H-Series UI.

  1. Open a browser and access the H-Series UI log in page using the management IP address for the controller you want to log in to (you can log in to either controller's UI):

  1. Enter admin for the user, and the password for the admin user.

    2. Note: The admin user is currently the only user account in the H-Series UI.

  2. Click LOGIN.
  • If disconnected, connect both system power cables. Both controllers should power on.
  • If the system has been powered off, but the power cords are still connected, push the power button on the control panel ear on the front of the system for the desired controller.

    • Caution: When powering on the system when both controllers are in a powered off state, push the power button on one controller, and then immediately push the power button on the other controller (within 30 secs of each other) so that the NVDs for both controllers are properly recognized by the system and prevents a fenced controller state. (See BLK-4627 in the H2000 Release Notes.)

    Note: Do Not use the IPMI/BMC Web UI to power on a controller.

(See BLK-4627 in the H2000 Release Notes.)

Note: Do Not use the IPMI/BMC Web UI to power on the controllers.

Note: Do Not use the IPMI/BMC Web UI to power on a controller.

To power on a single controller:

  • If a controller has been powered off, but the power cords are still connected, push the power button on the control panel ear on the front of the system for the desired controller.
  • If a controller is unseated, seating the controller in the system chassis will start the controller. If the controller did not start, attempt a re-seat of that controller to attempt another controller power on.
  • Log into and open the BMC Web UI, if you already have the IPMI cabled and configured for network access.

Note: Do Not use the IPMI/BMC Web UI to power off the controller.

Method 1: Controller power off

Push and hold the power button on the front of the system for the desired controller. It will take 15-20 seconds until the controller is completely powered down:

Method 2: Controller power off

  1. Log in to the CLI of your system:
    1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

      2. Use the admin user name and the password for the admin account on the system.

      Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

      #ssh admin@(IP or hostname)

    Connect using a console session on a client that supports ssh (for example, PuTTY on Windows systems, the Windows command line on Windows 10 or later, or the Terminal on MacOS systems).

    1. The first time you log into the CLI, you will need to enter "yes" to accept the ECDSA security key for this system connection when prompted:

      2. The authenticity of host '10.65.184.225.mycompany.com' can't be established.

      ECDSA key fingerprint is SHA256:HDCZP/C3ZrIFWONrbl/9s/KCR8g/WXrOXe0V9qbiLbM.

      Are you sure you want to continue connecting (yes/no)? yes

      You should see a prompt adding the security key to the list of known hosts.

      Warning: Permanently added '10.65.184.225' (ECDSA) to the list of known hosts.

    2. Enter the password for the admin account:

      3. admin@(IP or hostname)'s password:

      The CLI prompt for the system you are connected to displays.

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      One moment, loading command sets...

      Welcome to the QBSP shell! Software version: Quantum CSP 2.4.0-Build89

      For available commands and usage, type help.

      (IP or hostname)>

  2. Enter the power_off command:

    3. (IP address or host name) > power_off

    Powering off this controller may disrupt I/O! Are you sure you want to continue (yes/no)? yes

    The system is going down for system halt NOW!

    Connection to (IP address or host name) closed.

  1. Log into and open the BMC Web UI, if you already have the IPMI cabled and configured for network access.
    1. On a laptop computer, open a supported web browser and enter the IP address for the BMC UI in the address box, and press Enter.

      2. For direct BMC/IPMI port connections ONLY, use https://192.168.17.1.

      Note: You must use “https://” the first time you access the BMC UI through the IPMI/BMC port.

      The log in dialog displays:

      (click image to enlarge)

    2. Log in to theBMC Web UI.

      Login credentials:

      • Username: ADMIN

      • Password: Use the password set for the BMC UI. For new systems not yet configured, or that have been re-imaged, reference the passwords for each node shown on the pullout tab located on the left rear corner of the H2000 chassis:

        • (click image to enlarge)

      The BMC UI displays:

      (click image to enlarge)

    If you do not currently have the IPMI configured on the network, and will access directly from the IPMI/BMC port:

    1. Connect a laptop to the IPMI/BMC port on one of the controllers:

      2. Item

      Description

      1

      IPMI/BMC port on Controller B

      2

      IPMI/BMC port on Controller A
    2. Access the IPMI/BMC using the IP address assigned to the IPMI/BMC port. To configure this address, see .
      Otherwise, to connect directly to the IPMI/BMC port on the back of the system for the first time (default IP address still assigned to this port), configure you laptop network settings. Complete one of the following two procedures, depending on whether you are using a Windows or Mac notebook computer:

      3. Configure the IPv4 network settings for the ethernet connection on the computer you will use to access the system while directly-connected to the IPMI/BMC port if the IP settings have not yet been changed.

      IPv4 network settings:

      • IP Address - 192.168.17.10
      • Subnet Mask - 255.255.255.0
      • Router (MacOS)/Gateway (Windows) - blank

      These steps apply to macOS Mojave. They may differ slightly for your version of macOS.

      1. Click an open area of the Mac desktop, and select Apple menu> System Preferences> Network or click the System Preferences icon from the Dock:

      2. Click the Network icon in System Preferences:

      3. Select the Ethernet connection being used.
      4. In the Configure IPv4 drop-down list, select Manually.

        5. Pro Tip!

        Quantum recommends that you record the settings in this dialog box before you change them. You can refer to this information later when you set the settings back to their original values — after you are finished using this network connection

      5. Enter the IP address and subnet mask values (leave router blank):

      IPv4 network settings:

      • IP Address - 192.168.17.10
      • Subnet Mask - 255.255.255.0
      • Router (MacOS)/Gateway (Windows) - blank

      Example (Mojave)

      1. Click Close.

        2. It may take a couple minutes to enable the network connection.

      1. Access the Network Connections dialog:
        • For Windows 10 (method 1), right-click the Start menu icon, click Network Connections and click Change Adapter Options in the right pane of the dialog.
        • For Windows 10 (method 2), open the Cortana search, and enter View network status and tasks, and click Change adapter settings in the left pane of the dialog.
        • From older Windows versions, click the Start menu, search for and open the View Network Connections dialog.
      2. Right-click the network connection that corresponds to the Ethernet port on the compute being used, something like Ethernet or Local Area Connection, and select Properties:

      3. From the list of connections, select Internet Protocol Version 4 (TCP/IPv4), and then click Properties to display the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box.

        Note: We recommend writing down the settings in this dialog box before you change them. You can refer to this information later when you set the settings back to their original values — after you are finished using this network connection.

      4. Click the Use the following IP address radio button, and enter the appropriate IP address and Subnet mask values (leave gateway blank) and click OK:

        IPv4 network settings:

        • IP Address - 192.168.17.10
        • Subnet Mask - 255.255.255.0
        • Router (MacOS)/Gateway (Windows) - blank

        Example:

        1. Click OK.
        2. Close the Network dialog.

          3. It may take a couple minutes to enable the network connection.

      1. On a laptop computer, open a supported web browser and enter the IP address for the BMC UI in the address box, and press Enter.

        2. For direct BMC/IPMI port connections ONLY, use https://192.168.17.1.

        Note: You must use “https://” the first time you access the BMC UI through the IPMI/BMC port.

        The log in dialog displays:

        (click image to enlarge)

      2. Log in to theBMC Web UI.

        Login credentials:

        • Username: ADMIN

        • Password: Use the password set for the BMC UI. For new systems not yet configured, or that have been re-imaged, reference the passwords for each node shown on the pullout tab located on the left rear corner of the H2000 chassis:

          • (click image to enlarge)

        The BMC UI displays:

        (click image to enlarge)

  2. On the IMPI/BMC Web UI main page, click Power Down in the Power Control section of the page (if power is currently On):

    3. This should perform a orderly (or graceful) power off of the system. The system status should change to "Host is currently off.":

    If you see an error message and the power is not off, or if you'd like to use an alternate method:

    1. Open the Remote Control > Power Control page:

    2. Click Power Off Server - Orderly Shutdown and then Perform Action:

      3. This should perform a orderly (or graceful) power off of the system. The system status should change to "Host is currently off.":

      If you see an error message and/or the power is not off, attempt to do an immediate server power down. Click Power Off Server -Immediate and then Perform Action:

      This should perform an immediate power off of the system. The system status should change to "Host is currently off.":

Note: Do Not use the IPMI/BMC Web UI to reboot the controller.

For systems running QBSP 2.0.1 and later software:

  1. Log in to the CLI of your system:
    1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

      2. Use the admin user name and the password for the admin account on the system.

      Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

      #ssh admin@(IP or hostname)

    Connect using a console session on a client that supports ssh (for example, PuTTY on Windows systems, the Windows command line on Windows 10 or later, or the Terminal on MacOS systems).

    1. The first time you log into the CLI, you will need to enter "yes" to accept the ECDSA security key for this system connection when prompted:

      2. The authenticity of host '10.65.184.225.mycompany.com' can't be established.

      ECDSA key fingerprint is SHA256:HDCZP/C3ZrIFWONrbl/9s/KCR8g/WXrOXe0V9qbiLbM.

      Are you sure you want to continue connecting (yes/no)? yes

      You should see a prompt adding the security key to the list of known hosts.

      Warning: Permanently added '10.65.184.225' (ECDSA) to the list of known hosts.

    2. Enter the password for the admin account:

      3. admin@(IP or hostname)'s password:

      The CLI prompt for the system you are connected to displays.

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      One moment, loading command sets...

      Welcome to the QBSP shell! Software version: Quantum CSP 2.4.0-Build89

      For available commands and usage, type help.

      (IP or hostname)>

  2. Enter the reboot command:
    3. (IP address or host name) > reboot
  3. Exit the ssh session:
    4. (IP address or host name) > exit

Prerequisite

To update the QBSP platform software to 2.2 or later, QBSP 2.0 or later must be installed on your system. Direct updates to 2.2 and later ARE NOT supported for systems running QBSP 1.x software.

For systems running QBSP 1.x, you MUST first update to 2.0, then update to 2.2 or later.

Caution: The QBSP upgrade process will result in multiple reboots of your controller(s) if you need to update the system BIOS, network, or FC card firmware. The firmware updates could add approximately 10-20 minutes of additional time to the overall QBSP upgrade process.

Use this procedure to update your H2000 software if your system HAS an active internet connection.

Note: You will update Controller A from the user interface on Controller B, and update Controller B from the user interface on Controller A.

Quantum recommends you update the system to the latest version of H2000 software. Note the following:

Update the software

  1. Verify which version of software is running on the system.
    1. Log in to the H-Series UI.
    2. Click the 3-dot icon on the upper right-hand corner of the CLUSTER page:

    3. Click About:

    4. View the "About" page and look for the software version currently running on the controllers:

    To update to a newer version the software:

  2. Click CONFIGURATION in the top navigation (item 1 above).
  3. Click Update Platform Software in the left navigation (item 2 above).
  4. Make sure the radio button next to Remote Repository in the Source section is selected (item 3 above).
  5. Click CHECK FOR UPDATE (item 4 above).

    6. You will see a confirmation that the system is checking the online repository for an update:

     

    If the latest version of the software is not currently installed, and an update is available from the online repository, you will see a confirmation that it can be updated, and the update version that is available for download to the system.

    Note: The UPDATE NOW button for the controller you are logged into will be grayed-out and not functional, while the controller you are not logged into will allow you to update it.

    If the latest software is installed, you will see an indication similar to one of the following messages, the UPDATE NOW button is gray (disabled). Skip the remainder of these update steps, since you cannot, and do not need to update the H2000 software.

  6. Click UPDATE NOW for the controller whose user interface you are NOT logged into:

    7. The software will download to the controller, and update the software.

    When the software is being updated, the metadata arrays on both boot drives are recovered. Because of this:

    1. Controller A UI will present degraded and rebuilding drive alert tickets similar to the following:

      2. These types of alerts are expected and can be ignored during the software update, and can be deleted after the update is complete.

    2. The Controller B UI will display degraded RAID device health similar to the following:

      3. The system should return to a healthy state after the software update is complete.

    3. Before the controllers have finished updating the H2000 software and rebuilding drives, you may not be able to log into the UI on either controller.

      4. Wait until the H2000 software update has finished, and log in again.

    Note: It may take up to 20 minutes to download the update file, so be patient while the software downloads.

    The H2000 software will begin the update process. While you will see the following confirmation indicating that the update was successful, it's just confirming that the update is valid and can begin. At this point, the update process is not 100% finished, see note below:

    Note: The update will reboot the controller, and will also require an additional 15-30 more minutes before the update of this controller can be initiated from the other controller's user interface. If you initiate an update before the first controller update is complete, that update will fail and you will see a failure notification.

    Once the update of the other controller is complete, it will take about 10 min for both controllers to sync.

  1. If you have not yet updated the controller you are logged into, launch the user interface of the other controller:

    2. To launch the Controller A user interface, when logged into the Controller B user interface, click this, in the panel for Controller A:

    To launch the Controller B user interface, when logged into the Controller A user interface, click this, in the panel for Controller B:

  2. Log in to the user interface of the other controller:

    1. Enter admin for the user, and the password for the admin user.

      2. Note: The admin user is currently the only user account in the H-Series UI.

    2. Click LOGIN.
  1. Complete steps 6-10 from the other controller to update this controller.

    2. The platform software update is complete.

  1. Verify the CatDV VM is running. Do the following, if you need to restart the CatDV VM:

    1. From the H-Series UI, scroll down to the CatDV VM section of the page.
    2. Click the Stop/Start CatDV VM icon in the Controller A panel:
    3. Click Stop CatDV.
    4. Click STOP to confirm stopping the CatDV VM. A task to stop the CatDV VM will display and the CatDV VM will stop.
    5. Verify the CatDV VM is fully stopped. It should look like this:
    6. When the CatDV VM is in a "stopped" state, click the Stop/Start CatDV VM icon:
    7. Click Start CatDV.
    8. Click START to confirm starting the CatDV VM. A task to start the CatDV VM will display and the CatDV VM will start.
    9. Verify the CatDV is in a "Running" state once again. Make sure both items under CatDV are "Running":
  2. After you update the H2000 to 2.0 (or later), update NVD firmware to 011222V1. See the section below: Update NVD Firmware.

Use this procedure to update your H2000 if your system DOES NOT HAVE an active internet connection.

Quantum recommends you update the system to the latest version of H2000 software. Note the following:

Note: You will update Controller A from the user interface on Controller B, and update Controller B from the user interface on Controller A.

Updates to QBSP 2.0.2 and later software are supported from:

  • QBSP 2.0.1
  • H-Series 1.6.1
  • H-Series 1.6.0
  • H-Series 1.5.3
  • H-Series 1.5.2

For 1.5.1 and earlier systems, review the following update steps:

  1. Update to H-Series 1.5.2 (see the update steps below).
  2. Update NVD firmware to 081321V1 Contact Quantum support or your Quantum Service Provider to update the NVD firmware to 081321V1 if this has not yet been done. For Quantum support or your Quantum Service Providers, see Update H-Series NVD Firmware to 081321V1 (requires CSWeb log in).
  3. Update to QBSP 2.0.2 (see the update steps below).
  4. After you update the H2000 to 2.0.2, update the NVD firmware to 011222V1:
  1. Verify which version of software is running on the system:
    1. Log in to the H-Series UI.
    2. Click the 3-dot icon on the upper right-hand corner of the CLUSTER page:

    3. Click About:

    4. View the "About" page and look for the software version currently running on the controllers:

    Leave your browser open.

    1. Open a browser tab.
    2. Navigate to the online form:

      3. https://mysoftware.quantum.com/forms/h2000

      https://mysoftware.quantum.com/forms/f2200

    3. Fill out the form and click Submit to access the software update downloads for your H2000.

    4. After you submit the form, you will receive an email with a link to the update download page for the H2000.

      5. The following is an example of the software download page, (update link highlighted):

      The following is an example of the software download page (conversion link highlighted):

  2. Download the correct H2000conversion or update file:

    3. IMPORTANT! If you are updating from H-Series 1.x software to QBSP 2.0.2, download the file called 2.0.2 Conversion Package. For systems already running QBSP 2.0.1 software, download the file called 2.0.2 Update Package, instead.

    The file will be downloaded to the system your browser is running on. For updates from QBSP 2.x software, the file name will be similar to qcsp-2.xx-update.tar, and for conversion/updates from 1.x software, the file name will be similar to qcspconv-vsxx.tar.

    Note: Download time depends on the speed of your internet connection, but the file size is about 2 GB.

  3. Transfer the file to both controllers:

    4. SCP the file to the system From the laptop you downloaded the file to, use SCP to copy the file to Controller A and Controller B. Use the management IP address of the controller, the admin user name, and the password for the admin account in the file transfer utility.

    Note: Use either a drag-and-drop SCP or FTP utility (like Transmit or Filezilla for MacOS, or WinSCP or Filezilla for Windows), or a command-line utility (like Terminal for MacOS, or the Windows 10 or later command prompt or PuTTYSCP.exe for Windows) to manually copy the files.

    1. Open a terminal window.
    2. scp the file from your local download location to the /mnt/data/scratch/ directory on Controller A.

      3. Example:

      scp qcsp-2.x-update.tar admin@10.20.223.218:/mnt/data/scratch/

      OR (for conversion/updates) from 1.x software:

      scp qcspconv-vsxx.tar admin@10.20.223.218:/mnt/data/scratch/

    3. Enter the admin account password. You will see the file begin to transfer to the system, with an estimate of the percent of the file transferred (in green for clarification):

      4. qcsp-2.x-update.tar    80%    651MB    482.0KB/s    05:27 ETA

      OR (for conversion/updates) from 1.x software:

      qcspconv-vsxx.tar 80% 651MB 482.0KB/s 05:27 ETA

    1. Open a Windows command prompt.
    2. scp the file from your local download location to the /mnt/data/scratch/ directory on Controller A.

      3. Example:

      C:\Users\<user name>\Downloads>scp qcsp-2.x-update.tar admin@10.20.223.218:/mnt/data/scratch/

      OR (for conversion/updates from 1.x software):

      C:\Users\<user name>\Downloads>scp qcspconv-vsxx.tar admin@10.20.223.218:/mnt/data/scratch/

    3. Enter the admin account password. You will see the file begin to transfer to the system, with an estimate of the percent of the file transferred (in green for clarification):
      4. qcsp-2.x-update.tar    80%    651MB    482.0KB/s    05:27 ETA

      OR (for conversion/updates) from 1.x software:

      qcspconv-vsxx.tar    80%    651MB    482.0KB/s    05:27 ETA

  4. Log in to the H-Series UI:
    1. Open a browser and access the H-Series UI log in page using the management IP address for the controller you want to log in to (you can log in to either controller's UI):

    1. Enter admin for the user, and the password for the admin user.

      2. Note: The admin user is currently the only user account in the H-Series UI.

    2. Click LOGIN.

  5. From the browser for the H-Series UI on Controller Node A, click CONFIGURATION in the top navigation (item 1 above).
  6. Click Update Platform Software in the left navigation (item 2 above).
  7. Click the radio button next to Local File in the Source section (item 3 above).

  8. Enter the path and the complete file name in the Path field (item 1 above).

    9. Example:

    /mnt/data/scratch/qbsp-2.1.0-Build123-update.tar
  9. Click CHECK FOR UPDATE (item 2 above).
  10. Once the local update file is confirmed, click UPDATE NOW:

    The H2000 software will begin the update process. While you will see the following confirmation indicating that the update was successful, it's just confirming that the update is valid and can begin. At this point, the update process is not 100% finished, see note below:

    Note: The update will reboot the controller, and will also require an additional 15-30 more minutes before the update of this controller can be initiated from the other controller's user interface. If you initiate an update before the first controller update is complete, that update will fail and you will see a failure notification.

    Once the update of the other controller is complete, it will take about 10 min for both controllers to sync.

  1. If you have not yet updated the controller you are logged into, launch the user interface of the other controller:

    2. To launch the Controller A user interface, when logged into the Controller B user interface, click this, in the panel for Controller A:

    To launch the Controller B user interface, when logged into the Controller A user interface, click this, in the panel for Controller B:

  2. Log in to the user interface of the other controller:

    Additional step is required when using the conversion file ONLY:

  1. Manually copy the file to controller you just updated one more time.
  2. Complete Step 4 through Step 10 to update the other controller.

    3. Wait for the software update to complete.

    Note: The local metadata RAIDs on controller will need to re-sync after the update. This takes approximately 40 minutes.

    When finished updating Controller Node A and Controller Node B, determine if you need to repeat this procedure to update to a more recent version of H2000 software. If your system is now running the latest software available, the H2000 software update is complete.

  1. Verify the CatDV VM is running. Do the following, if you need to restart the CatDV VM:

    1. From the H-Series UI, scroll down to the CatDV VM section of the page.
    2. Click the Stop/Start CatDV VM icon in the Controller A panel:
    3. Click Stop CatDV.
    4. Click STOP to confirm stopping the CatDV VM. A task to stop the CatDV VM will display and the CatDV VM will stop.
    5. Verify the CatDV VM is fully stopped. It should look like this:
    6. When the CatDV VM is in a "stopped" state, click the Stop/Start CatDV VM icon:
    7. Click Start CatDV.
    8. Click START to confirm starting the CatDV VM. A task to start the CatDV VM will display and the CatDV VM will start.
    9. Verify the CatDV is in a "Running" state once again. Make sure both items under CatDV are "Running":
  1. After you update the H2000 to 2.0.2, update NVD firmware to 011222V1. See the section below: Update NVD Firmware.

This applies to H2000 systems running QBSP 2.x and later software ONLY.

Note: If you have already updated your system to 2.0.1, and NVD firmware has already been updated to 011222V1, you DO NOT need to update the NVD firmware again. Your system is already running the latest NVD firmware.

Note: Although the NVD upgrade process is non-disruptive, it’s recommended to run the NVD update utility during a maintenance window with low I/O usage.

Prerequisites:

  1. The system must first be running NVD Firmware 081321V1 BEFORE you attempt to update to QBSP 2.0.2 or update the NVD firmware 011222V1. Quantum support or a Quantum Service Provider must update the NVD firmware to 081321V1 if this has not yet been done. For Quantum support or your Quantum Service Providers, see Update H-Series NVD Firmware to 081321V1.

    2. Determine the NVD firmware version running on the system (for systems running H-Series 1.x software ONLY):

    1. Log into the CLI as the admin user:
      1. Open a PuTTY/Terminal session using the management IP of the controller.

        2. Example (macOS Terminal, Unix, Linux)

        #ssh admin@10.20.85.71

        Example (Windows 10 command prompt)

        c:\>ssh admin@10.20.85.71

        Example (macOS Terminal, Unix, Linux)

        #ssh admin@10.20.85.72

        Example (Windows 10 command prompt)

        c:\>ssh admin@10.20.85.72
      2. Log in to the command line:

        Username: admin

        Password: <password>

    2. Determine the NVD firmware version from the QCSP/ESOS CLI:
      1. Ping the QCSP/ESOS running on Controller A:

        2. [admin@hSeries-1 ~]$ ping <service port IP address>

      2. Once it is pingable, ssh from the CLI on Controller A into the QCSP VM:

        3. [admin@hSeries-1 ~]$ ssh 10.17.21.10 -l root

      3. Enter the following command to list the NVD software version:

        4. [root@hSeries-d501e2-1 ~]# nvme list

        Example output:

        The entries under the FW Rev column will be listed as "081321V1" when running that version of NVD firmware (in green below).

        Node           SN                   Model          Namespace  Usage                    Format           FW Rev  
-------------- -------------------- -------------- ---------- ------------------------ ---------------- --------
/dev/nvme0n1   00000000000000000001 IPM-NVMe FHW   1           17.18  GB /  17.18  GB   4 KiB +  0 B    081321V1
/dev/nvme0n2   00000000000000000001 IPM-NVMe FHW   2           17.18  GB /  17.18  GB   4 KiB +  0 B    081321V1
/dev/nvme1n1   00000000000000000000 IPM-NVMe FHW   1           17.18  GB /  17.18  GB   4 KiB +  0 B    081321V1
/dev/nvme1n2   00000000000000000000 IPM-NVMe FHW   2           17.18  GB /  17.18  GB   4 KiB +  0 B    081321V1

      Quantum support or a Quantum Service Provider must update the NVD firmware to 081321V1 if this has not yet been done. For Quantum support or your Quantum Service Providers, see Update H-Series NVD Firmware to 081321V1.

  2. BEFORE you attempt to run the NVD update, update the H-Series platform software to QBSP 2.0.2 on BOTH Controller A AND Controller B. The update script is included as part of the update to 2.0.2 software.

Note: This update will take up to 1 hour to complete. While I/O is not stopped during the NVD update, I/O performance may be impacted. Because of this, Quantum recommends this be done during a time of low system use.

The firmware update is copied to the system during the update to QBSP 2.x or later platform software, and is ready to be run after the system is updated to QBSP 2.x on both controllers.

Initiate the NVD firmware update on Controller A ONLY

  1. Once H-Series platform software has been updated to QBSP 2.0.2 on BOTH Controller A AND Controller B, enter the command to run the NVD update utility:

    2. (IP or hostname)> nvd_update

    The NVD firmware will begin to update.

    ("...." means output will display, but is not shown here)

    NVD Update Utility (nupu.py) 2.0.4.2
Firmware needs update on hSeries-1. Current FW Ver: 081321V1; New FW Ver: 011222V1
Firmware needs update on e15a89-2. Current FW Ver: 081321V1; New FW Ver: 011222V1
QCSP Cluster appears healthy: CLUSTER OK: 2 nodes online, 15 resources configured
Update NVD Firmware using '/opt/quantum/firmware/NVD/NVD_FW_011222V1.bin'
This may take a few minutes ... 
*************************************************************************
	WARNING!
	All I/O to this server WILL BE IMPACTED
	Consider upgrade during a less active window
*************************************************************************
*************************************************************************
Beginning NVD firmware upgrade for host 'hSeries-1'
*************************************************************************
...

    If there is not enough space on your /root partition to update NVD firmware, you will see an error message similar to the following:

    "Hostx does not have sufficient space in the directory for the upgrade."

    If you see the above message:

    1. Run the NVD file cleanup command:

      2. (IP or hostname)> nvd_update --remove-nvd-dumps

    2. Re-run the NVD firmware update:

      3. (IP or hostname)> nvd_update

    When the NVD is being updated, the controller UI will:

    1. Open alerts (multiple alerts will be opened; a sample of some of them is shown here):

      2. The alerts are expected and can be ignored during the NVD update.

    2. Show degraded component health:

      1. Show degraded software RAID devices similar to:

        2. The software RAID devices should return to a healthy state after the NVD firmware update is complete.

      2. Show degraded NVD RAID drive health similar to the following:

        3. The NVD RAID drives should return to a healthy state after the NVD firmware update is complete.

    *************************************************************************
Beginning NVD firmware upgrade for host 'hSeries-1a'
*************************************************************************
Removing /dev/disk/by-id/nvme-eui.304e3100000000000000000000000000-part1 from RAID 
/dev/md122 on hSeries-1
|Starting dump of /dev/nvme2n1 (nvme-eui.304e3100000000000000000000000000) on hSeries-1
|Starting dump of /dev/nvme2n2 (nvme-eui.304e3200000000000000000000000000) on hSeries-1
|Begin upgrade on hSeries-1 using /opt/quantum/firmware/NVD/NVD_FW_011222V1.bin
|'fw-download' executed. Sleeping for 15 seconds to let /dev/nvme2 settle.
\'fw-commit' executed. Sleeping for 30 seconds to let /dev/nvme2 settle.
/Waiting '60' seconds for devices to settle
/Starting restore of /dev/nvme2n1 (nvme-eui.304e3100000000000000000000000000) on hSeries-1
-/mnt/data/FW_upgrade/nvme-eui.304e3100000000000000000000000000.img successfully restored 
to /dev/nvme2n1 on hSeries-1
Starting restore of /dev/nvme2n2 (nvme-eui.304e3200000000000000000000000000) on hSeries-1
\/mnt/data/FW_upgrade/nvme-eui.304e3200000000000000000000000000.img successfully restored 
to /dev/nvme2n2 on hSeries-1
/Sleeping 60 for udev rules to settle on 'hSeries-1'
|Sleeping 60 for udev rules to settle on 'e15a89-2'
|/dev/md122 rebuilding on host e15a89-1 (0% complete.  Sleeping '30')
|/dev/md122 rebuilding on host e15a89-1 (18% complete.  Sleeping '30')
|/dev/md122 rebuilding on host e15a89-1 (36% complete.  Sleeping '30')
|/dev/md122 rebuilding on host e15a89-1 (54% complete.  Sleeping '30')
|/dev/md122 rebuilding on host e15a89-1 (72% complete.  Sleeping '30')
|/dev/md122 rebuilding on host e15a89-1 (90% complete.  Sleeping '15')
*************************************************************************
Beginning NVD firmware upgrade for host 'e15a89-2'
*************************************************************************
Removing /dev/disk/by-id/nvme-eui.314e3100000000000000000000000000-part1 from RAID /dev/md122 
on hSeries-1
-Starting dump of /dev/nvme2n1 (nvme-eui.304e3100000000000000000000000000) on e15a89-2
\Starting dump of /dev/nvme2n2 (nvme-eui.304e3200000000000000000000000000) on e15a89-2
\Begin upgrade on e15a89-2 using /opt/quantum/firmware/NVD/NVD_FW_011222V1.bin
/'fw-download' executed. Sleeping for 15 seconds to let /dev/nvme2 settle.
|'fw-commit' executed. Sleeping for 30 seconds to let /dev/nvme2 settle.
/Waiting '60' seconds for devices to settle
\Starting restore of /dev/nvme2n1 (nvme-eui.304e3100000000000000000000000000) on e15a89-2
|/mnt/data/FW_upgrade/nvme-eui.304e3100000000000000000000000000.img successfully restored to 
/dev/nvme2n1 on e15a89-2
Starting restore of /dev/nvme2n2 (nvme-eui.304e3200000000000000000000000000) on e15a89-2
-/mnt/data/FW_upgrade/nvme-eui.304e3200000000000000000000000000.img successfully restored to 
/dev/nvme2n2 on e15a89-2
-Sleeping 60 for udev rules to settle on 'e15a89-1'
|Sleeping 60 for udev rules to settle on 'e15a89-2'
|/dev/md122 rebuilding on host e15a89-1 (0% complete.  Sleeping '30')
|/dev/md122 rebuilding on host e15a89-1 (18% complete.  Sleeping '30')
|/dev/md122 rebuilding on host e15a89-1 (36% complete.  Sleeping '30')
|/dev/md122 rebuilding on host e15a89-1 (54% complete.  Sleeping '30')
|/dev/md122 rebuilding on host e15a89-1 (72% complete.  Sleeping '30')
|/dev/md122 rebuilding on host e15a89-1 (90% complete.  Sleeping '15')
-/dev/md122 rebuilding on host e15a89-1 (99% complete.  Sleeping '10')
**************************************************************
Beginning Environment Validation
**************************************************************

    If the NVD firmware update cannot continue, due to cluster issues, you will see output similar to the following (errors shown in red):

    **************************************************************
Beginning Environment Validation
**************************************************************
QCSP Cluster Health degraded or not running: CLUSTER WARN: offline node: 11bc3c-2
SBD daemon is not running on '<service port IP address>'.
Cluster appears unhealthy
RAID status for H2024_11bc3c_C01 (on local host) is active
/dev/nvme2 (011222V1) on local is healthy
RAID status for H2024_11bc3c_C02 (on remote host) is OK
/dev/nvme2 (011222V1) on remote is healthy
Errors detected updating NVD Firmware

    If you see errors like this, contact Quantum support.

    If the NVD firmware installs correctly, you will see output similar to the following indicating the cluster and NVD drives are healthy, and (NVD firmware version now installed shown in green):

    QCSP Cluster appears healthy: CLUSTER OK: 2 nodes online, 15 resources configured
Cluster is healthy
RAID status for H2012_e15a89_C01 (on local host) is active
/dev/nvme2 (011222V1) on local is healthy
RAID status for H2012_e15a89_C02 (on remote host) is clean
/dev/nvme2 (011222V1) on remote is healthy
Removed '*.img' files from /mnt/data/FW_upgrade on e15a89-2
Removed '*.img' files from /mnt/data/FW_upgrade on e15a89-1
NVD Update Utility  successful.

    The output above indicates that the NVD firmware update completed successfully.

  2. Close the PuTTY/Terminal SSH session.

    3. (IP or hostname)> exit

At this point the update to 011222V1 NVD firmware is complete.

The PERFORMANCE page provides system-level performance data. It is comprised of several pages with multiple panels displaying various individual performance components.

Pro Tip!

Click the button to display an individual panel full-screen.

The panels on this page graph the statistics of the overall system components:

(click image to enlarge)

CPU Utilization

Provides statistical data on CPU usage. View options: 1.) Combined - displays data for both Controllers (default view), 2.) data for Controller A only, or 3.) data for Controller B only.

Click on a specific parameter at the bottom of the panel for usage data for that item.

Memory Utilization

Provides statistical data on system memory (RAM) usage. View options: 1.) Combined - displays data for both Controllers (default view), 2.) data for Controller A only, or 3.) data for Controller B only.

Interface Throughput

Provides statistical data on interface usage. View options: 1.) Combined - displays data for both Controllers (default view), 2.) data for Controller A only, or 3.) data for Controller B only.

Click on a specific parameter at the bottom of the panel for usage data for that item.

The panels on this page graph the statistics of the system's block storage:

(click image to enlarge)

CPU Usage

Provides statistical data on CPU usage for the block storage VMs. View options: 1.) Combined - displays data for both Controllers (default view), 2.) data for Controller A only, or 3.) data for Controller B only.

Click on a specific parameter at the bottom of the panel for usage data for that item.

Disk Throughput

Provides statistical data on disk I/O. View options: 1.) Combined - displays data for both Controllers (default view), 2.) data for Controller A only, or 3.) data for Controller B only.

Click on a specific parameter at the bottom of the panel for usage data for that item.

Disk Average Service Time

Provides statistical data on Read/Write speeds. View options: 1.) Combined - displays data for both Controllers (default view), 2.) data for Controller A only, or 3.) data for Controller B only.

Click on a specific parameter at the bottom of the panel for usage data for that item.

Disk Average Queue Length

Provides statistical data on storage queue length. View options: 1.) Combined - displays data for both Controllers (default view), 2.) data for Controller A only, or 3.) data for Controller B only.

Click on a specific parameter at the bottom of the panel for usage data for that item.

Interface Throughput

Provides statistical data for the storage interfaces. View options: 1.) Combined - displays data for both Controllers (default view), 2.) data for Controller A only, or 3.) data for Controller B only.

Click on a specific CPU component at the bottom of the panel for usage data for that component.

The TASKS page displays all active tasks that the system is currently performing (example: creating a batch of log files - "collect logs" or status of certain system commands being performed, like backups, or the state of virtual machines on the system):

(click image to enlarge)

The ALERTS page provides access to all currently reported RAS tickets on the system that have not yet been cleared:

(click image to enlarge)

View alert details

Click on the alert you want to see expanded details for.

Example:

(click image to enlarge)

Sort alerts

You can sort alerts by several parameters, including date, affected controller, type, etc. To sort alerts, open the drop-down for the specific parameter you'd like to sort by, and choose your desired option.

Clear an alert

  1. To clear an alert, click on the (trashcan/delete) button for the alert you want to clear.
  2. Click CLOSE on the confirmation dialog:

Acknowledge an alert

  1. To acknowledge an alert, click the (checkmark) button for the alert you want to acknowledge.
  2. Click ACKNOWLEDGE on the confirmation dialog:

The LOGS page provides access to all current log files on the system:

(click image to enlarge)

Sort logs

Click the column on the LOG page to sort log entries by that parameter.

Download a bundle of log files (collect logs)

Click the ("Collect Logs") button on the LOGS page to download a log file bundle.

View log detail

Click on a log entry in the main LOG page to open its details. The LOG page is replaced by the details for the log selected:

(click image to enlarge)

  1. In the top nav, click CONFIGURATION (item 1 above).
  2. In the left nav, click Management Network (item 2 above).
  3. If needed, drop down the option for Boot Protocol and select DHCP.
  4. Make changes necessary for the DHCP connection: MTU speed, Hostname, and Domain for Controller A (items 3-6 above) and Controller B (items 7-10 above).
  5. Click Apply.
  1. In the top nav, click CONFIGURATION (item 1 above).
  2. In the left nav, click Management Network (item 2 above).
  3. If needed, drop down the option for Boot Protocol and select Static.
  4. Make changes necessary for the Static connection: Hostname, Domain, IPv4 Address, Netmask, Default Gateway, and MTU speed for Controller A (items 4-9 above) and Controller B (items 11-17 above).
  5. Click Apply.

Caution: Quantum recommends leaving the storage configuration unchanged after initial configuration. ONLY change this if absolutely necessary (such as if settings change within your network ecosystem). The system was optimized during initial configuration for your network and storage environment. You could adversely affect efficiency of the H2000 if these settings are changed incorrectly.

 

Note: Make sure all network cables have been connected to the H2000 before changing these settings.

Pro Tip! Use IP addresses that are unique and are NOT currently in use in your environment, or that have been assigned to other components configured within the H-Series UI.

  1. Click CONFIGURATION in the topnav (item 1 above).
  2. In the left nav, click Storage Network (item 2 above).
  3. If needed, change the network type to Single-subnet(item 3 above).

    4. Note: When the setting is selected for one controller, the setting for the other controller (item 7 above) changes to the same network type.

  4. Make changes necessary to the IP interface information: IPv4 Address, Netmask, and MTU for Controller A (items 4-6 above) and for Controller B (items 8-10 above), for single-subnet configurations. All fields marked "Required" must be set before the Apply button is enabled (blue).

    5. Caution: Quantum recommends leaving the storage configuration unchanged after initial configuration. ONLY change this if absolutely necessary (such as if settings change within your network ecosystem). The system was optimized during initial configuration for your network and storage environment. You could adversely affect efficiency of the H2000 if these settings are changed incorrectly.

  5. Click Apply (item 11 above).

Note: Dual-subnet configuration requires 2 network port connections for each controller, each with its own unique IP address. Make sure all network cables have been connected to the H2000 before changing these settings.

Pro Tip! Use IP addresses that are unique and are NOT currently in use in your environment, or that have been assigned to other components configured within the H-Series UI.

  1. Click CONFIGURATION in the topnav (item 1 above).
  2. In the left nav, click Storage Network (item 2 above).
  3. If needed, change the network type to Dual-Subnet (item 3 above).

    4. Note: When the setting is selected for one controller, the setting for the other controller (item 10 above) changes to the same network type.

  4. Make changes necessary to the IP interface information: IPv4 address, Netmask, and MTU for Controller A (items 4-9) and for Controller B (items 11-16 above). All fields marked "Required" must be set before the APPLY button is enabled (blue).

    5. Caution: Quantum recommends leaving the storage configuration unchanged after initial configuration. ONLY change this if absolutely necessary (such as if settings change within your network ecosystem). The system was optimized during initial configuration for your network and storage environment. You could adversely affect efficiency of the H2000 if these settings are changed incorrectly.

  5. Click APPLY (item 17 above).

  1. In the top nav select CONFIGURATION (item 1 above).
  2. In the left nav select SNMP (item 2 above).
  3. Click the gray (disabled) Enable SNMP toggle (item 3 above). It will turn blue (enabled).
  4. Enter the SNMP Community String (item 4 above).
  5. Enter the SNMP Trap Receiver (optional/if needed; item 5 above).
  6. Enter the Port of the SNMP Tap Receiver (item 6 above).
  7. Click Apply to confirm the change (item 7 above).

  1. In the top nav select CONFIGURATION (item 1 above).
  2. In the left nav select SNMP (item 2 above).
  3. Click the blue (enabled) Enable SNMP toggle (item 3 above). It will turn gray (disabled).
  4. Click Apply to confirm the change (item 4 above).

Quantum Cloud-Based Analytics (CBA) software allows customers, and authorized support personnel to remotely monitor the health of their Quantum products. CBA must be enabled for each product in order for that product to send log data securely to the CBA server.

Skip this step if you already have a CBA account. If you do not already have a CBA account, request an account and verify your H2000 is listed in the CBA portal using these steps:

  1. Go to the CBA portal at https://insight.quantum.com.
  2. Click the "Request an Account" link:

    3. (click image to enlarge)

  3. Enter an Email address, Company name and Serial number for your H2000, then click the checkbox next to the text that states "I'm not a robot":

    4. (click image to enlarge)

  4. Quantum will send an email with a user name and password to log in to the CBA portal.

    5. Note: If you already have a CBA account, you will not receive an email. You should use the CBA account you have set up previously, and continue to the next step.

  5. Verify you can view the information for this H2000 within your solution view on the CBA portal at https://insight.quantum.com.

    6. Note: If your solution includes more than one device (such as additional H2000s or Xcellis Workflow Director systems) and you have already received credentials for one of the systems, you can add another device to your account. Send an email to DL-Insight-Admin@quantum.com with information about your additional systems, and the CBA team will add additional devices to the CBA portal view for your account.

  1. Click CONFIGURATION in the topnav (item 1 above).
  2. In the left nav, click CBA (item 2 above).
  3. Click the gray (disabled) Enable Cloud-Based Analytics toggle (item 3 above). It will turn blue (enabled).
  4. Click the gray (disabled) Enable SSL proxy, if you will use an SSL proxy for the CBA internet connection (item 4 above; optional).
  5. Enter the Proxy Server name for the proxy server (item 5 above; optional - if using an SSL proxy).
  6. Enter the Port number for that proxy server (item 6 above; optional - if using an SSL proxy).
  7. Enter a Proxy Username (item 7 above; optional - if using an SSL proxy).
  8. Enter a Proxy Password for the proxy username (item 8 above; optional - if using an SSL proxy).
  9. Click the gray (disabled) Enable Remote Access Support (item 9 above; optional).
  10. Select the access method you prefer for remote access support (item 10; optional).
  11. Enter the remote access support time allowed, in hours (item 11; optional).
  12. Click Apply to confirm the change (item 13 above).

    13. You will see a status bar as the CBA is enabled. When it is enabled, you will see a confirmation of the change in a green box at the top of this page showing it was successful.

  13. If desired, click TEST CBA CONNECTION to ensure the CBA configuration is functioning properly (item 12 above).

  1. Click CONFIGURATION in the topnav (item 1 above).
  2. In the left nav, click CBA (item 2 above).
  3. Click the blue (enabled) Enable Cloud-Based Analytics toggle (item 3 above). It will turn gray (disabled).
  4. Click Apply to confirm the change (item 4 above).

This allows you to set one or more NTP time servers for H2000 timestamps.

  1. Select Configuration in the top navigation menu (item 1 above).
  2. Select Time in the left navigation menu (item 2 above).
  3. Click the Enable Network Time Protocol (NTP) slider to enable NTP (item 3 above). The slider will move to the right and turn blue (enabled).
  4. Select either to use an NTP Hostname, or IP Address (item 4 above).
  5. Enter the NTP Hostname or IP address to use in the NTP Server field (item 5 above).

    6. Another example:

    time.nist.gov

  6. Click the Timezone drop-down item 6 above).
  7. Click Apply to confirm the change (item 7 above).

This allows you to disable using NTP time server(s) for H2000 timestamps.

  1. Select Configuration in the top navigation menu (item 1 above).
  2. Select Time in the left navigation menu (item 2 above).
  3. Click the Enable Network Time Protocol (NTP) slider to disable NTP (item 3 above). The slider will move to the right and turn gray (disabled).
  4. Click Apply to confirm the change (item 4 above).

This allows you to set manual time for the H2000for H2000 timestamps.

  1. Select Configuration in the top navigation menu (item 1 above).
  2. Select Time in the left navigation menu (item 2 above).
  3. If enabled, click the Enable Network Time Protocol (NTP) slider to disable NTP (item 3 above). The slider will move to the left and turn gray (disabled).
  4. Enter the date to use in the Date field in the format <yyyy>-<mm>-<dd> (yyyy=year; mm=month number; dd=day; item 4 above).

    5. Example above:

    2021-05-04

  5. Enter your local time in the Time field in the format <<hh>:<mm>:<ss> (hh=hours [in 24-hour format]; mm=minutes; ss=seconds; item 5 above).

    6. Example above:

    03:05:50

  6. Enter the timezone for your location, or use the Universal Time Clock option (UTC; item 6 above):

    7. Example above:

    UTC

  7. Click Apply to confirm the change (item 7 above).

  1. Select Configuration in the top navigation menu (item 1 above).
  2. Select Email in the left navigation menu (item 2 above).
  3. Enter the Outgoing SMTP Email Server name for the server to use for outgoing email (item 3 above).
  4. Enter the email address to use in the Sender Address for this system (item 4 above). This is the value that will appear for the location where the email originated "From" in your email client.
  5. Enter one or more email adresses in the Local Email Addresses for Alerts (RAS Tickets) field (item 5 above).
  6. Click Apply to confirm the change (item 6 above).

  1. In the top nav select CONFIGURATION (item 1 above).
  2. In the left nav select BMC (item 2 above).
  3. Enter the IP Address for Controller A (item 3 above).
  4. Enter the Subnet Mask for Controller A (item 4 above).
  5. Enter the Default Gateway for Controller A ( item 5 above).
  6. Enter a new password in the BMC Password field (item 6 above) for BMC access.

    7. Pro Tips!

    • When you enter a password for Controller A, the password is auto-populated into the BMC Password field for Controller B (item 10 above). You CANNOT enter a different password for Controller A and Controller B.
    • Enter a unique password. Quantum recommends entering a password that is different from the default password assigned to either controller.
  7. Enter the IP Address, Subnet Mask, Default Gateway, and BMC Password for Controller B. (items 7-10 above)
  8. Click Apply to confirm the change (item 11 above).

Note: This option enables SED drives for the RAID as a whole, not specific chassis, individual drives, or drive packs.

  1. Click CONFIGURATION in the topnav (item 1 above).
  2. In the left nav, click SED (item 2 above).
  3. Click the gray (disabled) Enable Self Encrypting Drives toggle (item 3 above). It will turn blue (enabled).

    4. If the system does not contain SED drives, you will see the following message

    If you see this message, you will not be able to configure the drives as SED, and can skip the rest of this procedure:

  4. Enter the SED Password to use for drive encryption (item 4 above).
  5. Enter the SED password again in the Confirm SED Password field (item 5 above).
  6. Click Apply to confirm the change.

You will need your H2000 system serial number when you contact Quantum Technical Support. Use one of the following methods to locate the system serial number:

The system serial number is located on a label on a pull-out tab on the rear left corner of the H2000 system:

  1. From the H2000 UI, click the 3 dot icon at the upper right-hand corner:

  2. Click About.

The Serial Number is shown toward the top of the About page:

For QBSP 2.0.2 and later software ONLY

Configure iSCSI storage ports directly in the H-Series UI. You will need to configure those ports as targets for the initiator ports on the host Xcellis or other server. See: System Operations.

For H-Series 1.x software ONLY

Two iSCSI storage ports are currently supported natively supported in the H-Series UI for systems running H-Series 1.x software. System Operations allows you to configure additional iSCSI port connections using Linux iSCSI commands from the ESOS CLI.

Configure iSCSI ports, targets and initiators on the Xcellis host appliance

An alternate method is to use iSCSI v3 commands supported in the Appliance Controller software 3.1.0 or later on the host StorNext Xcellis appliance. To update to Appliance Controller 3.1.0 or later and iSCSI v3 on your Xcellis system, see the Appliance Controller Upgrades page. For iSCSI v3 commands, see the "iSCSI Tasks and Commands for Appliance Controller 3.1.0 and later" section on the iSCSI Tasks and Commands page. You will need to configure both iSCSI initiators and iSCSI targets.

Required tools

  • Laptop with a browser
  • Access to the H2000's management network

Required network information for this step:

  • Determine the system ports required to be configured for the network
  • IPs for the iSCSI network
  • scst targets to use for the IP addresses

Add a JBOD to an array

Note: You will have to remove some cables so the SAS cabling matches the cabling diagrams here.

The following is supported on H2100 systems only; not supported on H2000 systems.

Add a JBOD:

  1. From the H-Series UI, select CONFIGURATION > Storage.
  2. Click ADD RAID SET.
  3. Select the Host Bus Adaptor ID, the HBA Enclosure ID, the First Drive for the RAID, the Last Drive for the RAID, and the RAID Level (currently only RAID 6 is supported).

    4. Example (RAID array with multiple JBODs):

    (click to enlarge)

    Example: (selecting drives 1-12 for a 10+2 RAID 6 on enclosure 1 of HBA ID 0):

  4. Click APPLY to begin configuring the raidset.
  5. While the raidset is being added, you will see the following confirmation at the center of the screen:

    6. You will see a dialog at the bottom of the screen indicating the task is pending:

    You will see a job successfully started. You can then monitor progress of this task on the Tasks tab on the topnav of the H-Series UI:

    To monitor progress of the configuration, you can click on the TASKS tab in the topnav of the H-Series UI:

    (click to enlarge)

    Note: After configuration, RAID arrays will initialize and complete an initial synchronization. Performance may be impacted for up to 24 hours. To check the status, view the Health > System and Health > Storage pages of the H-Series UI. These pages display information about the RAID status and will list drives and software RAID devices in a "degraded" state. On the Health > Storage page, you can hover over a drive to view the resync status.

    Example (Health > System page showing degraded storage drives and software RAID devices):

    When the job is complete you will see the new raid set added to the JBOD:

    (click to enlarge)

    For this example, with a 24-drive JBOD, since we just configured 12 drives, the border of the array is still dark blue (indicating "unconfigured", or a JBOD that isn't completely configured). As shown above, the 12 configured drives on the left are light blue (indicating they are completely configured) with green circles (indicating healthy drives). The remaining drives (13-24) could be configured as another 10+2 RAID 6 raid set.

    For a 12-drive JBOD, the 12 drives are configured as a single 10+2 RAID 6 array.

    Note: If you attempt to add more than one JBOD raidset at a time, you may begin seeing display anomalies in the user interface. Once the initialization and resynch process on the raidsets, the user interface will once again operate as expected.

  6. Repeat the steps above for additional raid sets on this or other arrays.

If you are experiencing BUSY / QUEUE FULL responses from your SCSI targets, then Quantum recommends you lower the queue-depth (max in-flight commands) on the initiator side. The steps vary by operating system and initiator stack; therefore, contact your hardware and driver vendor for information on how to adjust the queue depth setting.

Note: Auto-unfencing enhancements to the H2000 software as of the H-Series 1.5.1 software release. This enhancement addresses most scenarios where fencing might have occurred previously. Quantum recommends updating the H2000 to the latest software release regularly. See Update Platform Software.

Fencing in H2000 systems isolates a failed or misbehaving controllers in a cluster. In the H2000, Quantum block storage is organized into a two-controller cluster. Clusters comprised of only two controllers are special because they cannot have a quorum when one controller fails. Fencing:

  • Is a way for one node to wall-off, or isolate the other failed (or misbehaving) controller in a cluster.
  • Prevents a split-brain scenario.

    • Imagine the virtual network cable between both H2000 controllers fails. Even though both controllers were still fully-operational when this happens, both controllers would think the other controller went down, and both would attempt to start/own all services from the other controller, creating a “split-brain” situation. Since fencing is in place on the H2000, both controllers would race to fence the other, and only the winner is left standing (the “loser” is fenced). The good thing is that there isn't a split-brain condition, with both controllers fighting about ownership of processes. The down side is that one of the controllers is no longer operational, and the other controller is the only functioning controller with active I/O. In this case, the system will need to be "unfenced" to restore normal H2000 operations.

The following situations can cause the H2000 controllers to fence:

  • Hold down the power button on the front of the array chassis to force an instant power off of one of the controllers
  • A kernel panic in the controller OS (for QBSP 2.x software ONLY)
  • A kernel panic in the hypervisor OS (for H-Series 1.x software ONLY)
  • A kernel panic in the block storage VM guest OS (for H-Series 1.x software ONLY)
  • Remove too many disk drives at once (which exceeds the RAID fault tolerance threshold)
  • Unplug one or more JBOD SAS cables (which exceeds the SAS cabling redundancy tolerance)
  • Remove power to one or more JBODs while the RAID array is running
  • Turn on the RAID array while the JBODs remain powered-off
  • Power on only one controller while the other controller remains powered off (or in a downed state; for 1.x software ONLY)
  • Failure of the controller-to-controller Ethernet communication interface
  • Forcefully turn off the QCSP virtual machine from the system command line (for H-Series 1.x software ONLY)

    • Both controllers must be booted (started up) within 30 seconds of each other.

    If only one controller is powered up while the other remains off, the block storage cluster will fence the controller that is off (for 1.x software ONLY).

H2000 dual-controller storage arrays use a software layer called “SBD” as the fencing device. SBD (aka Storage Based Death, aka STONITH Block Device) uses shared block devices as a medium for exchanging messages between the controllers in the cluster. They use a tiny portion (several blocks) on each “NVD” (Quantum’s high-speed write-back cache storage device). When a controller is to be fenced, the cluster controller that performs the fencing will write to the message slot on the block device indicating controller X should fence. The cluster controllers continually read the messaging slots, and when the controller detects it is to fence, it resets itself (via sysrq-trigger). This mechanism is also known as “poison-pill” fencing. There are two NVDs in the storage array (one per controller) which provide the SBD layer with two shared block devices (for redundancy). If one SBD block device is missing, the cluster is still allowed to start. As of QBSP 2.0.1, for the SBD to fence a cluster controller, at least one SBD storage device must be present, otherwise manual intervention is required. In addition to using the shared block devices, SBD also makes use of a Linux watchdog device – should the SBD daemon crash. The watchdog device will then cause the block storage controller to reset.

As of QBSP 2.0.1 QBSP software, a new feature has been implemented in the SBD service where it will now “auto unfence” on startup. In order to limit the amount of fencing loops that can occur, the software stack will automatically unfence a system on boot (or SBD start) if it has started less than 3 times in the past 20 minutes. If there are more than 3 SBD starts in 20 minutes, then the controller will remain fenced.

  • When a controller is fenced, the H-Series UI will contain an error message across the top of the page:

  • Review RAS tickets
  • Use the CLI to look for a controller node "reset" state, as described here:
  1. Log into the CLI of the system:
    1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

      2. Use the admin user name and the password for the admin account on the system.

      Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

      #ssh admin@(IP or hostname)

    Connect using a console session on a client that supports ssh (for example, PuTTY on Windows systems, the Windows command line on Windows 10 or later, or the Terminal on MacOS systems).

    1. The first time you log into the CLI, you will need to enter "yes" to accept the ECDSA security key for this system connection when prompted:

      2. The authenticity of host '10.65.184.225.mycompany.com' can't be established.

      ECDSA key fingerprint is SHA256:HDCZP/C3ZrIFWONrbl/9s/KCR8g/WXrOXe0V9qbiLbM.

      Are you sure you want to continue connecting (yes/no)? yes

      You should see a prompt adding the security key to the list of known hosts.

      Warning: Permanently added '10.65.184.225' (ECDSA) to the list of known hosts.

    2. Enter the password for the admin account:

      3. admin@(IP or hostname)'s password:

      The CLI prompt for the system you are connected to displays.

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      One moment, loading command sets...

      Welcome to the QBSP shell! Software version: Quantum CSP 2.4.0-Build89

      For available commands and usage, type help.

      (IP or hostname)>

  2. List the SBD status. Enter:

    3. IP or hostname)> sbd_list

    If the system IS currently fenced, you will see results similar to:

    Device '/dev/disk/by-id/nvme-eui.304e3100000000000000000000000000-part2':
    0	1106e9-1	reset	node-1106e92
    1	1106e9-2	clear
    Device '/dev/disk/by-id/nvme-eui.314e3100000000000000000000000000-part2':
    0	1106e9-1	reset	node-1106e92
    1	1106e9-2	clear

    If any node is fenced, the state keyword “reset” (in red) will be shown in the third column (the second column shows the node name that is affected, in the case of the example above, the first block storage device (displayed under the "Device" as "0", in green) or Controller A (the first controller node), is fenced. The fourth column (right-most) shows the node that last wrote to that message block.

  3. Exit the PuTTY/Terminal SSH CLI session. Enter:

    4. exit
  • When a controller is fenced, the H-Series UI will contain an error message across the top of the page:

  • Review RAS tickets
  • Use the CLI to look for a controller node "reset" state, as described here:
    1. Log in to the CLI.
      1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

        2. Use the admin user name and the password for the admin account on the system.

        Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

        #ssh admin@(IP or hostname)

      Connect using a console session on a client that supports ssh (for example, PuTTY on Windows systems, the Windows command line on Windows 10 or later, or the Terminal on MacOS systems).

      1. The first time you log into the CLI, you will need to enter "yes" to accept the ECDSA security key for this system connection when prompted:

        2. The authenticity of host '10.65.184.225.mycompany.com' can't be established.

        ECDSA key fingerprint is SHA256:HDCZP/C3ZrIFWONrbl/9s/KCR8g/WXrOXe0V9qbiLbM.

        Are you sure you want to continue connecting (yes/no)? yes

        You should see a prompt adding the security key to the list of known hosts.

        Warning: Permanently added '10.65.184.225' (ECDSA) to the list of known hosts.

      2. Enter the password for the admin account:

        3. admin@(IP or hostname)'s password:

        The CLI prompt for the system you are connected to displays.

        Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

        Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

        One moment, loading command sets...

        Welcome to the QBSP shell! Software version: Quantum CSP 2.4.0-Build89

        For available commands and usage, type help.

        (IP or hostname)>

    2. Enter the sbd_list shell script to list the SBD status to determine if the controller is fenced:

      [IP or hostname ~]# sbd_list

      If the system IS currently fenced, you will see results similar to:

      Device '/dev/disk/by-id/nvme-eui.304e3100000000000000000000000000-part2':
      0	1106e9-1	reset	node-1106e92
      1	1106e9-2	clear
      Device '/dev/disk/by-id/nvme-eui.314e3100000000000000000000000000-part2':
      0	1106e9-1	reset	node-1106e92
      1	1106e9-2	clear

      If any node is fenced, the state keyword “reset” (in red) will be shown in the third column (the second column shows the node name that is affected, in the case of the example above, the first block storage device (displayed under the "Device" as "0", in green) or Controller A (the first controller node), is fenced. The fourth column (right-most) shows the node that last wrote to that message block.

    1. Log in to the CLI.
      1. Log in to the CLI:
        1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

          2. Use the admin user name and the password for the admin account on the system.

          Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

          #ssh admin@(IP or hostname)

        1. Enter:

        [admin@hseries-2 ~]$ ssh 10.17.21.10 -l root

    2. Enter the sbd_list.sh shell script to list the SBD status to determine if the controller is fenced:

      [root@hseries-2 ~]# sbd_list.sh

      If the system IS currently fenced, you will see results similar to:

      Device '/dev/disk/by-id/nvme-eui.304e3100000000000000000000000000-part2':
      0	1106e9-1	reset	node-1106e92
      1	1106e9-2	clear
      Device '/dev/disk/by-id/nvme-eui.314e3100000000000000000000000000-part2':
      0	1106e9-1	reset	node-1106e92
      1	1106e9-2	clear

      If any node is fenced, the state keyword “reset” (in red) will be shown in the third column (the second column shows the node name that is affected, in the case of the example above, the first block storage device (displayed under the "Device" as "0", in green) or Controller A (the first controller node), is fenced. The fourth column (right-most) shows the node that last wrote to that message block.

  1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

    2. Use the admin user name and the password for the admin account on the system.

    Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

    #ssh admin@(IP or hostname)

Connect using a console session on a client that supports ssh (for example, PuTTY on Windows systems, the Windows command line on Windows 10 or later, or the Terminal on MacOS systems).

  1. The first time you log into the CLI, you will need to enter "yes" to accept the ECDSA security key for this system connection when prompted:

    2. The authenticity of host '10.65.184.225.mycompany.com' can't be established.

    ECDSA key fingerprint is SHA256:HDCZP/C3ZrIFWONrbl/9s/KCR8g/WXrOXe0V9qbiLbM.

    Are you sure you want to continue connecting (yes/no)? yes

    You should see a prompt adding the security key to the list of known hosts.

    Warning: Permanently added '10.65.184.225' (ECDSA) to the list of known hosts.

  2. Enter the password for the admin account:

    3. admin@(IP or hostname)'s password:

    The CLI prompt for the system you are connected to displays.

    Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

    Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

    One moment, loading command sets...

    Welcome to the QBSP shell! Software version: Quantum CSP 2.4.0-Build89

    For available commands and usage, type help.

    (IP or hostname)>

  1. Run the unfence command.

    2. IP or hostname)> sbd_unfence

  2. Enter:

    3. IP or hostname)> cluster_start

  3. Run the sbd_list.sh shell script again, to verify the controller is no longer fenced:

    4. IP or hostname)> sbd_list

    If the controller is no longer fenced, a status of “clear” (in green) is shown in the third column, as shown here:

    Device '/dev/disk/by-id/nvme-eui.304e3100000000000000000000000000-part2':
    0	1106e9-1	clear	node-1106e92
    1	1106e9-2	clear
    Device '/dev/disk/by-id/nvme-eui.314e3100000000000000000000000000-part2':
    0	1106e9-1	clear	node-1106e92
    1	1106e9-2	clear
  4. Exit the PuTTY/Terminal SSH CLI session. Enter:

    5. IP or hostname)> exit

  1. Log in to the CLI:
    1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

      2. Use the admin user name and the password for the admin account on the system.

      Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

      #ssh admin@(IP or hostname)

    1. Enter:

    [admin@hseries-2 ~]$ ssh 10.17.21.10 -l root

  1. Run the unfence command.

    2. For H-Series 1.x, run the unfence script:

    [root@hseries-23bf46-2 ~]# sbd_unfence.sh

  2. Enter:

    3. [root@hseries-23bf46-2 ~]$ cluster_start.sh

  3. Run the sbd_list.sh shell script again, to verify the controller is no longer fenced:

    4. [root@hseries-2 ~]# sbd_list.sh

    If the system is NOT fenced, you will see results similar to:

    Device '/dev/disk/by-id/nvme-eui.304e3100000000000000000000000000-part2':
    0	1106e9-1	clear	node-1106e92
    1	1106e9-2	clear
    Device '/dev/disk/by-id/nvme-eui.314e3100000000000000000000000000-part2':
    0	1106e9-1	clear	node-1106e92
    1	1106e9-2	clear

    If the controller is no longer fenced, a status of “clear” (in green) is shown in the third column, as shown in the example above.

  4. Exit the ssh root session. Enter:

    5. [root@hseries-23bf46-2 ~]# exit

  5. Exit the PuTTY/Terminal SSH CLI session. Enter:

    6. [admin@hseries-2 ~]$ exit

The NVD is Quantum’s high-speed write-back cache device used in the H2000. There are two NVD’s in every H2000controller node - one in Controller A, and the other in Controller B. The NVD storage devices are accessible from both controllers. When looking at the NVD storage devices from a single controller node, we refer to the NVD that resides in the controller we are accessing as the “local” NVD, and the NVD that is in the other controller is referred to as the “peer” or “remote” NVD. There are two RAID1 mirror sets comprised of half the NVD from Controller A and half of the NVD from Controller B. One RAID1 cache array is primarily owned by Controller A, and the second RAID1 cache array is primarily owned by Controller B (along with the backing RAID volumes that the cache volumes are associated with). We achieve cache redundancy by using this RAID1 configuration – if an entire controller (and NVD) is removed from the chassis, we still have the local NVD halves that allow the write-back cache to function on the operating controller.

Both controllers MUST be powered on within 30 seconds of each other to ensure the BIOS on both controllers enumerate the local NVD and the remote NVD properly. NVD write-back cache devices appear to the host systems as PCIe end-points that must both be up for correct operating condition.

Note: A controller can still be powered off / removed at a later point safely as the PCIe enumeration would have already taken place at the prior boot; the operating controller will see PCIe hot-plug down/up events for the NVD. If both controllers are not powered on within 30 seconds of each other, the NVD RAID1 arrays will appear degraded in the GUI health page and RAS tickets will be created.

  1. Ensure the peer controller has been powered on and fully booted, and QBSP software is running.
  2. Reboot the peer controller with the missing NVD:
    1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

      2. Use the admin user name and the password for the admin account on the system.

      Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

      #ssh admin@(IP or hostname)

    Connect using a console session on a client that supports ssh (for example, PuTTY on Windows systems, the Windows command line on Windows 10 or later, or the Terminal on MacOS systems).

    1. The first time you log into the CLI, you will need to enter "yes" to accept the ECDSA security key for this system connection when prompted:

      2. The authenticity of host '10.65.184.225.mycompany.com' can't be established.

      ECDSA key fingerprint is SHA256:HDCZP/C3ZrIFWONrbl/9s/KCR8g/WXrOXe0V9qbiLbM.

      Are you sure you want to continue connecting (yes/no)? yes

      You should see a prompt adding the security key to the list of known hosts.

      Warning: Permanently added '10.65.184.225' (ECDSA) to the list of known hosts.

    2. Enter the password for the admin account:

      3. admin@(IP or hostname)'s password:

      The CLI prompt for the system you are connected to displays.

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      One moment, loading command sets...

      Welcome to the QBSP shell! Software version: Quantum CSP 2.4.0-Build89

      For available commands and usage, type help.

      (IP or hostname)>

    1. Enter:
      2. reboot
    2. Exit the PUTTY/Terminal SSH CLI session. Enter:
      3. exit

    After the OS reboots, both NVD PCIe EP’s will be present.

This applies to systems running H-Series 1.x software ONLY (not QBSP 2.x software).

Both controllers MUST be powered on within 30 seconds of each other to ensure the BIOS on both controllers enumerate the local NVD and the remote NVD properly. NVD write-back cache devices appear to the host systems as PCIe end-points that must both be up for correct operating condition.

Note: A controller can still be powered off / removed at a later point safely as the PCIe enumeration would have already taken place at the prior boot; the operating controller will see PCIe hot-plug down/up events for the NVD. If both controllers are not powered on within 30 seconds of each other, the NVD RAID1 arrays will appear degraded in the GUI health page and RAS tickets will be created.

  1. Power off both controllers:
    1. Log in to the CLI:
      1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

        2. Use the admin user name and the password for the admin account on the system.

        Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

        #ssh admin@(IP or hostname)

      1. Enter:

      [admin@hseries-2 ~]$ ssh 10.17.21.10 -l root

  2. Enter:
    3. poweroff
  3. Close the SSH session for the controller. Enter:
    4. exit
  4. Open an SSH session to the other controller and log in as root.
  5. Enter the poweroff command in the CLI of the other controller:
    6. poweroff
  6. Close the PuTTY/Terminal SSH CLI session. Enter:
    7. exit
  7. Power both controllers back on within 30 seconds of one another for a successful PCIe enumeration. Push both power buttons on the left and right ear on the front of the chassis, or pull both controllers out of the chassis and re-seat theminto the chassis, which automatically powers on each controller.

When power loss occurs (a shutdown) on an H-Series controller, or if the controller is removed from the chassis, the standing controller will see a PCIe hot-plug link-down event for the NVD in the controller that was shut down.

On the standing QBSP controller, the NVD block devices in the cache RAID1 arrays will drop (expected). When the controller that was previously off is turned back on, the controller will see the peer NVD PCIe hot-plug event, and the QBSP 2.x software automatically adds the cache RAID1 array member devices back in and the RAID1 arrays automatically resync.

When power loss occurs (a shutdown) on an H-Series controller, or if the controller is removed from the chassis, the standing controller will see a PCIe hot-plug link-down event for the NVD in the controller that was shutdown.

On the block storage virtual machine the NVD block devices in the cache RAID1 arrays will drop (expected). When the controller that was previously off is turned back on, once it is fully booted and QCSP block storage services are started and are running, the missing NVD on the block storage virtual machine must be fixed.

  1. Make sure the controller with the power loss or was independently shut down is powered back on, is fully booted, and that the QBSP/block storage services have been started.

  2. Power off the QCSP VM:

    1. Log in to the CLI:
      1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

        2. Use the admin user name and the password for the admin account on the system.

        Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

        #ssh admin@(IP or hostname)

      1. Enter:

      [admin@hseries-2 ~]$ ssh 10.17.21.10 -l root

    1. Enter:
      2. poweroff

      The hypervisor cluster stack will then automatically turn that VM back on after a few moments. Once the VM is booted, the NVD block devices will be available, however, the RAID1 cache array(s) will be degraded (due to the previously missing members).

  3. Add the NVD block device back as a cache RAID1 array member device:
    1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

      2. Use the admin user name and the password for the admin account on the system.

      Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

      #ssh admin@(IP or hostname)

    1. Enter:

      2. [admin@hseries-2 ~]$ sudo qsacli --attach_drive auto

      This adds the cache RAID1 array member devices back in and automatically resyncs the devices, which includes the NVD.

  4. Close the PuTTY/Terminal SSH CLI session:

    5. exit

Should you happen to reboot or turn off an H-Series controller while the peer controller is either turned off, or removed from the chassis, you will need to perform an additional reboot of the controller when the peer controller is replaced and/or powered on.

If the peer NVD is not present/accessible when the standing controller is booted, the BIOS will not enumerate that PCIe device.

  1. Open an SSH session to the CLI:
    1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

      2. Use the admin user name and the password for the admin account on the system.

      Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

      #ssh admin@(IP or hostname)

    Connect using a console session on a client that supports ssh (for example, PuTTY on Windows systems, the Windows command line on Windows 10 or later, or the Terminal on MacOS systems).

    1. The first time you log into the CLI, you will need to enter "yes" to accept the ECDSA security key for this system connection when prompted:

      2. The authenticity of host '10.65.184.225.mycompany.com' can't be established.

      ECDSA key fingerprint is SHA256:HDCZP/C3ZrIFWONrbl/9s/KCR8g/WXrOXe0V9qbiLbM.

      Are you sure you want to continue connecting (yes/no)? yes

      You should see a prompt adding the security key to the list of known hosts.

      Warning: Permanently added '10.65.184.225' (ECDSA) to the list of known hosts.

    2. Enter the password for the admin account:

      3. admin@(IP or hostname)'s password:

      The CLI prompt for the system you are connected to displays.

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      One moment, loading command sets...

      Welcome to the QBSP shell! Software version: Quantum CSP 2.4.0-Build89

      For available commands and usage, type help.

      (IP or hostname)>

  2. Reboot the controller. Enter:
    3. reboot

    The PCIe enumeration will occur when the controller rebooted.

  3. Close thePuTTY/Terminal SSH CLI session:
    4. exit

As of the QBSP 2.0.1, there is a known condition where a failed cluster resource action will be present when the peer controller is turned off and/or removed from the chassis. The affected cluster resource is named “p_fence_sbd”, which fails because one of the SBD fencing devices (the peer NVD) is no longer present when it attempts to monitor/start that resource.

  1. Ensure the peer controller has been replaced, is turned on and has completed rebooting.
  2. Open an SSH session to the CLI
    1. Open an SSH session using the management IP address or hostname of the controller using a Terminal/PuTTY client.

      2. Use the admin user name and the password for the admin account on the system.

      Example (macOS Terminal, Linux or Unix command line, or Windows 10 command prompt):

      #ssh admin@(IP or hostname)

    Connect using a console session on a client that supports ssh (for example, PuTTY on Windows systems, the Windows command line on Windows 10 or later, or the Terminal on MacOS systems).

    1. The first time you log into the CLI, you will need to enter "yes" to accept the ECDSA security key for this system connection when prompted:

      2. The authenticity of host '10.65.184.225.mycompany.com' can't be established.

      ECDSA key fingerprint is SHA256:HDCZP/C3ZrIFWONrbl/9s/KCR8g/WXrOXe0V9qbiLbM.

      Are you sure you want to continue connecting (yes/no)? yes

      You should see a prompt adding the security key to the list of known hosts.

      Warning: Permanently added '10.65.184.225' (ECDSA) to the list of known hosts.

    2. Enter the password for the admin account:

      3. admin@(IP or hostname)'s password:

      The CLI prompt for the system you are connected to displays.

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      Last login: Thu Mar 10 10:07:51 2022 from 10.65.188.109

      One moment, loading command sets...

      Welcome to the QBSP shell! Software version: Quantum CSP 2.4.0-Build89

      For available commands and usage, type help.

      (IP or hostname)>

  3. Issue the cluster_cleanup command. Enter:
    4. cluster_cleanup
  4. Close the PuTTY/Terminal SSH CLI session:
    5. exit

See Update NVD Firmware.