Post-upgrade checks: ONTAP, firmware, DQP and client service

01Define what counts as complete

Separate the update’s completion state, the running version, infrastructure availability and the application’s accepted service. A successful command or idle updater proves only part of this chain. Use the same object names, client identities and transaction before and after the window. If a check does not apply, record why instead of marking an untested row as passed.

1. Prepare the expected target values before the change. Include patch suffixes, model-specific firmware and the DQP package identity.
2. Record observation time, observer, object identity, actual result and evidence location. A green monitoring dashboard alone is insufficient for an unobserved application transaction.

02Verify ONTAP versions and update state

1. Confirm the final phases completed for all intended nodes. If an update remains waiting, paused or failed, identify that stage before declaring the upgrade complete.
2. Compare the running/current build of lab-01 and lab-02 with the approved full version. Do not mistake a stored alternate image for the running release.
3. If versions disagree, preserve the output and inspect the current orchestration state. Do not begin a second image update or generic revert while the original state is unresolved.

cluster image show-update-progress
cluster image show
set -privilege advanced
system node image show -version
system node upgrade-revert show
set -privilege admin

03Verify cluster membership, HA and quorum

All intended nodes should be healthy and eligible, and the HA relationship should be back in its normal ready state. Compare each RDB ring across nodes: matching epochs and consistent primary/master membership for that ring are the relevant evidence. Different rings can use different primaries. An unexpected quorum condition requires diagnosis, not a database reset or another reboot.

1. Compare HA readiness with the precheck baseline and verify there is no unexpected takeover or pending giveback.
2. For SAN, confirm the relevant services remain operational and in quorum, then validate actual host access in the SAN section.
3. If a node is unhealthy, identify its new EMS/hardware/network condition and keep the change open until it is resolved or an explicitly accepted recovery plan is active.

cluster show
storage failover show
system health status show
system health alert show
set -privilege advanced
cluster ring show -unitname mgmt
cluster ring show -unitname vldb
cluster ring show -unitname vifmgr
# SAN clusters:
cluster ring show -unitname bcomd
cluster kernel-service show
set -privilege admin

04Verify LIF state and correct only the intended NAS interface

Example: nas_lab_01 remains on lab-02 after lab-01 returns, and lab-01’s home port is healthy. A scoped revert can restore the intended placement. If that home port is down, forcing placement is not a fix; repair the port/path issue first.

1. Compare administrative/operational state and home/current placement with the precheck record. Validate actual reachability from the representative clients, not just the storage management session.
2. For a NAS LIF that should return home, verify the home node/port and VLAN/broadcast domain are available. A non-home placement may be an approved exception, so review its reason first.
3. Enable only an interface that the approved plan says should be enabled. Preserve intentionally disabled interfaces. Revert the specific eligible NAS LIF and inspect it afterward. SAN interfaces follow their protocol-specific design and should not receive a blanket NAS migration correction.

network interface show -fields home-node,home-port,curr-node,curr-port,is-home,status-admin,status-oper
network interface show -service-policy *data* -failover
network port show
network port broadcast-domain show

# Conditional corrections for the named NAS LIF only:
network interface modify -vserver svm_lab -lif nas_lab_01 -status-admin up
network interface revert -vserver svm_lab -lif nas_lab_01
network interface show -vserver svm_lab -lif nas_lab_01

05Compare storage inventory, RAID and hardware paths

1. Confirm the intended aggregates and volumes remain available with the expected ownership, state and capacity. Compare against saved object counts and identifiers rather than assuming that an empty error list covers every object.
2. Check for newly broken disks, RAID degradation/reconstruction, module faults and missing storage connections. Existing acknowledged conditions should remain separately documented.
3. After a shelf or disk change, observe until required redundancy and normal operation are restored. Client I/O through one surviving path is not the same as full path acceptance.

storage aggregate show
volume show
storage disk show -broken
storage shelf show
storage shelf show -module
storage shelf show -connectivity
storage shelf show -errors
system health alert show

06Verify active firmware and DQP independently

1. Select only the component checks that apply. BIOS boot-media commands must be supported by the actual release/platform; use the firmware guide’s version-specific branch.
2. Keep staged, installed and running values distinct in the change record. Explain any no-change result by showing that the device was already at the accepted target.
3. A failed/pending component update remains a follow-up condition even if the ONTAP software upgrade itself succeeded.

storage disk show -fields model,firmware-revision
storage shelf show -shelf 1.2 -module
system service-processor image show -instance
system service-processor show
storage dqp show -instance
set -privilege advanced
storage disk firmware show-update-status -instance
storage shelf firmware show-update-status -instance
set -privilege admin
system service-processor image update-progress show
# Supported BIOS/LOADER workflow only:
system node firmware bootmedia show

07NFS client postcheck as the intended user

Run these Linux examples from an authorized client using the application identity and its existing approved mount. Confirm the mounted protocol, endpoint and expected dataset first. Use a dedicated test folder and a unique temporary file so cleanup cannot remove another user’s data. This transaction verifies current file service, not the full integrity of every application dataset.

1. Confirm identity, mount version/options and target path match the precheck. A mount still listed by findmnt can have a broken data path, so execute the transaction.
2. Verify create, write, readback and delete. Retain return codes and observed latency. If it fails, identify whether transport, export evaluation or file identity/permissions changed.
3. Have the application owner run its normal integrity/transaction check against known data. Compare a previously recorded read-only checksum or application marker when available.

# Linux client — run the transaction as the intended application user:
id
findmnt -T /mnt/projects
testfile=$(mktemp /mnt/projects/upgrade-check.XXXXXX)
printf '%s\n' 'Storage Admin Hub postcheck' > "$testfile"
cat "$testfile"
test "$(cat "$testfile")" = 'Storage Admin Hub postcheck'
sha256sum "$testfile"
rm -- "$testfile"

08SMB client postcheck with Windows PowerShell

Use the actual intended Windows user and UNC endpoint. The following test creates a GUID-named file, verifies its contents and removes only that file. The example share is fictional; replace it with an authorized test location. A successful administrative storage login does not test domain authentication, share permissions or SMB client behavior.

1. Record the connected server/share, user and SMB dialect and compare them with the baseline.
2. Run the controlled transaction and then test the real application’s usual access. If the write succeeds but another identity fails, investigate that user’s authorization rather than widening the share globally.
3. When a test fails before cleanup, retain or remove only its known GUID file through the authorized process. Do not use wildcard deletion in a production share.

# Windows client — PowerShell under the intended test identity:
Get-SmbConnection
$testPath = Join-Path '\\nas-lab.example.net\projects' ('upgrade-check-' + [guid]::NewGuid().ToString() + '.txt')
$marker = 'Storage Admin Hub postcheck ' + [guid]::NewGuid().ToString()
Set-Content -LiteralPath $testPath -Value $marker -ErrorAction Stop
$readback = (Get-Content -LiteralPath $testPath -Raw -ErrorAction Stop).TrimEnd()
if ($readback -ne $marker) { throw 'SMB readback did not match' }
Get-FileHash -LiteralPath $testPath
Remove-Item -LiteralPath $testPath -ErrorAction Stop

09SAN host and application postchecks

Compare LUN identity, size, mapping, host-visible device and expected usable paths with the baseline. Supported ALUA paths can have different access states; do not demand that every path be active/optimized. The acceptable count and state come from the host/protocol design. For NVMe-oF or a hypervisor, use the matching NetApp host procedure and platform tooling.

1. Confirm the correct LUN/device remains accessible to the intended host. Reconcile any missing path with target interface, zoning/fabric, iSCSI session and host multipath state.
2. Read host/application event logs for I/O errors during the window and afterward. A device marked online can still have experienced an application timeout.
3. Have the owner execute an application-native read/write transaction and consistency check. Do not use dd, filesystem formatting or raw block-device writes as a production postcheck.

# ONTAP admin — select the deployed protocol:
lun mapping show
vserver fcp interface show
vserver iscsi session show
# Linux host:
multipath -ll
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS
# Windows host:
mpclaim -s -d
Get-Disk
Get-Volume

10Verify protection, snapshots and recovery-point age

Synthetic RPO example: the accepted destination point is 11:20 and verification occurs at 11:35, so its age is 15 minutes. With a 20-minute objective this may be acceptable; if the next transfer fails and the point reaches 40 minutes, the change’s protection acceptance is no longer met. Evaluate the usable completed point, not just a healthy label.

1. Compare relationship identity, state, health, last completed transfer and policy with the precheck. A transfer merely started is not a completed recovery point.
2. Check any deliberately suspended workflow against the change record and resume only that known relationship or schedule. Do not break/resync a healthy mirror to clear an upgrade notification.
3. Wait for the next expected protection cycle and verify completion. Application-consistent backup integrations also need their application/backup owner’s check.

snapmirror show
snapmirror show -destination-path svm_dr:vol_projects_dr -instance
volume snapshot show -vserver svm_lab -volume vol_projects
# Conditional only: a relationship intentionally quiesced by the approved change:
snapmirror resume -destination-path svm_dr:vol_projects_dr

11Verify special features, monitoring and comparable performance

Compare latency, IOPS, throughput and client errors under a comparable workload. A quiet post-window sample is not proof of unchanged peak-period performance. If latency rises, investigate paths, load and queueing before assuming that the ONTAP build alone caused it. Keep monitoring through the next relevant backup or busy period. Feature-specific checks supplement, rather than replace, the baseline HA/storage/client tests.

event log show -time >1h
system health alert show
set -privilege advanced
qos statistics volume performance show -vserver svm_lab -volume vol_projects -iterations 10
set -privilege admin

12Handle a failed postcheck and retain a usable change record

1. Keep planned suppression from masking a real outage and inform the change/service owner through the normal incident process. Preserve timestamps, identifiers and relevant logs.
2. Use the documented recovery route for the observed state. Canceling an upgrade, restoring a configuration file or running a generic revert is not a universal correction for a client path failure.
3. Create a post-change configuration backup after acceptance and retain it securely off-cluster. Reuse the backup/export procedure in the ONTAP guide with a new post-change filename.
4. Close only when required rows pass or an authorized exception has its impact, owner and deadline recorded.

system node autosupport invoke -node * -type all -message "POSTCHECKS_ACCEPTED"
system node autosupport invoke -node * -type all -message "MAINT=END"

Illustrative acceptance record — replace with observed results:
Change / target: approved ONTAP or component build
Nodes / components covered: lab-01, lab-02, named shelf/modules
Software / firmware / DQP identity: actual before and after values
HA / storage / network: accepted checks with evidence timestamps
NAS / SAN application test: user, endpoint, transaction and result
Protection: last completed usable recovery point and actual age
Monitoring / performance: compared baseline and relevant next-cycle result
Exceptions: specific impact, owner, decision and due date
Accepted by / time: storage and application owners