DQP update: download, install and verify every ONTAP node

01Understand what DQP changes and when it is required

DQP contains qualification information used to support drive/device combinations. Updating that information is different from flashing a drive’s firmware or installing an ONTAP software image. It does not replace Hardware Universe checks for the actual system, shelf, drive type and capacity. NetApp calls for a DQP update before drive firmware work or introducing newly qualified drive types/sizes, and after an ONTAP upgrade. The ONTAP upgrade itself does not refresh DQP.

02Record DQP details on each node before changing anything

1. Save package date, file version, filename and record counts for every relevant node. The detailed display can expose differences hidden by looking at only one node.
2. Compare nodes and the approved downloaded package. The file version describes the qualification file format; the package date and identity help distinguish package revisions. Do not use a made-up universal current version or assume that a newer download must change the format version.
3. Record any existing hardware/qualification alert and its device identity before the update. A before/after comparison must separate an existing unsupported device from an actual update failure.

storage dqp show
storage dqp show -instance
storage dqp show -node lab-01 -instance
storage dqp show -node lab-02 -instance
cluster show
storage failover show
system health alert show

03Obtain the supported DQP and preserve its integrity

The ZIP inspection is a useful operator check, not permission to invent an extraction/install sequence. If NetApp supplies a different file or install format, use that actual file and its instructions. Keep the repository path exact so the controller does not receive an HTML redirect or authentication page instead of the package.

1. Sign in to the NetApp Support Site and select the Disk Qualification Package download appropriate to the supported environment. Read the download’s installation notes and any platform/release restrictions.
2. Retain the actual filename, package date/identity, vendor-provided checksum information and a clean copy of the package. Do not choose a random forum attachment or rename an unrelated firmware archive to the DQP filename.
3. Compare the downloaded package’s integrity with the vendor value using the algorithm supplied. Keep an archive as packaged when its instructions require it; do not manually replace qualification files in the ONTAP filesystem.

# Linux staging host; compare with the vendor value using the same algorithm:
sha256sum /srv/netapp/dqp/qual_devices.zip
# If the approved download is a ZIP archive, inspect without altering it:
unzip -l /srv/netapp/dqp/qual_devices.zip

04Prepare a reachable controlled endpoint

1. Make the file available from a supported endpoint reachable from each intended node. Limit access and lifetime according to your maintenance standard. The sample HTTP server is for download, not receiving sensitive configuration backups.
2. Check the exact path, response and byte size. A successful test from your laptop does not prove a controller’s route is permitted; the per-node ONTAP download is the actual transfer test.
3. Use the transfer schemes supported by storage firmware download on your release. Do not assume that every URL scheme accepted by system node image get is also accepted by this command.

# Linux staging host on the maintenance network:
python3 -m http.server 8080 --bind 192.0.2.80 --directory /srv/netapp
# From an authorized operator machine:
curl -I http://192.0.2.80:8080/dqp/qual_devices.zip

05Install the package on the first intended node

Although the command family is storage firmware download, this invocation supplies qualification metadata. There is no additional requirement to run storage disk firmware update to activate a DQP. Doing so would begin a different, potentially disruptive operation.

1. Run the download for the explicit node name. Review completion and any unpacking/copy error rather than accepting a message that transfer merely started.
2. Return to admin privilege and inspect lab-01’s DQP details. Compare with the expected package identity; do not rely on a command exit alone.
3. If the package remains unchanged, determine whether the node was already current or whether installation failed. Preserve the full message and verify the actual served file before retrying.

set -privilege advanced
storage firmware download -node lab-01 -package-url http://192.0.2.80:8080/dqp/qual_devices.zip
set -privilege admin
storage dqp show -node lab-01 -instance

06Repeat for the partner and enumerate any additional nodes

1. Use the same approved file for the partner and confirm its completion independently. An HA relationship does not substitute for checking the qualification information on each node.
2. For clusters with more than two nodes, retain an explicit checklist of all intended nodes and run/verify the corresponding per-node downloads. Do not let a wildcard hide an individual failure.
3. Compare expected package date, file version, filename and appropriate record counts across the intended nodes. Different hardware inventories should not be used as an excuse for an unexplained old package on one partner.

set -privilege advanced
storage firmware download -node lab-02 -package-url http://192.0.2.80:8080/dqp/qual_devices.zip
set -privilege admin
storage dqp show -node lab-02 -instance
storage dqp show -instance

07Complete DQP postchecks before starting drive work

1. Compare postcheck output with the baseline. If the intended scope was DQP only, any unexpected firmware action or availability change requires explanation.
2. When drive firmware or a drive addition follows, confirm qualification acceptance first and then use that separate procedure’s preconditions.
3. Retain the post-update record with node names, package identity, timestamp, download result and exception disposition.

storage dqp show -instance
storage disk show -fields model,firmware-revision
storage disk show -broken
storage aggregate show
storage shelf show -connectivity
storage failover show
system health alert show
event log show -time >1h

08Diagnose transfer, unpacking and package mismatch failures

NetApp documents DQP failures involving unpacking and writes to internal locations. Do not use systemshell deletion, permission changes or manual edits to qualification files as a generic public runbook fix. Those changes require a specific diagnosis and the supported repair procedure. Keep the previous successful node’s evidence while investigating the failed partner.

09Worked mismatch example and final sign-off

Synthetic example: before the change, both nodes report package A. After the first download, lab-01 reports approved package B while lab-02 still reports A. The format version is unchanged on both. This does not mean the update failed on lab-01 or that A and B are identical; compare the package dates and record identity. Install/verify the intended B package on lab-02, then rerun the cluster-wide detailed display.

A clean final record states the real approved package identity, every covered node and whether any separate disk firmware or drive addition was performed. Avoid reporting DQP and drive firmware as one indistinguishable upgrade.

1. Accept the DQP-only change only after the identity and hardware/service postchecks pass.
2. Remove or stop the temporary image service when it is no longer needed under the maintenance plan. Keep the authorized package and installation evidence in the change record.
3. If an ONTAP upgrade was also performed, attach this per-node DQP record to its postcheck acceptance.

storage dqp show -instance
system node autosupport invoke -node * -type all -message "DQP_UPDATE_ACCEPTED"