ONTAP upgrades and firmware: nondisruptive updates
Sooner or later every cluster you look after needs a new ONTAP release or a patch. Done well, users never notice, because each node hands its work to its partner while it reboots on the new image.
This deep dive covers how NetApp releases ONTAP, what to check before you touch anything, how an automated nondisruptive update runs, what happens to firmware, and what to do when the update stops halfway.
Where this page fits
Deep dive in NetApp ONTAP Storage Administration · Phase 3, Data protection and enterprise integrations · Before this: ONTAP security deep dive · Next: Lesson 47, The troubleshooting workflow
| Time | You need | By the end you can |
|---|---|---|
| 60 minutes | The practice shell 1.1 (cluster image commands and the lab web server) | Plan an upgrade, download and validate a package, run a rolling update, read its progress, and recover from a paused update |
What it is, in one line
An ONTAP upgrade installs a new release on every node, one HA partner at a time, so data stays online while each node reboots.
In Simple Words
Changing tyres at a pit stop
A racing team doesn’t stop the race to change tyres. One car comes into the pit while its teammate keeps the team’s place on the track, then they swap.
A rolling ONTAP update works the same way: one node goes into the pit for its new software while its HA partner carries both nodes’ work, then the partner takes its turn.
Engineer's View
How ONTAP releases and updates work
Since ONTAP 9.8, NetApp has aimed for two releases a year, in Q2 and Q4. A new release usually ships first as a Release Candidate (RC) and becomes General Availability (GA) once it has run widely at customers; P releases such as 9.18.1P2 are patch releases with fixes for that release. At the time of writing, 9.19.1 (July 2026) is the newest release; this course’s labs use 9.18.1.
Each release gets full support for 3 years from its release date, limited support in years 4 and 5, and self-service documentation in years 6 to 8. NetApp’s advice is to apply non-critical patches every 3 to 6 months and critical ones as soon as you can.
The normal method is the automated nondisruptive update (ANDU), run from System Manager or with cluster image update.
Clusters with fewer than 8 nodes get a rolling update, one node of each HA pair at a time. Clusters of 8 or more nodes get a batch update by default, in two halves, unless you add -force-rolling. A single-node cluster can only be updated disruptively.
How it works, step by step
1Plan: pick the release and the path
Start in Digital Advisor (formerly Active IQ). Its Upgrade Advisor reads your cluster’s AutoSupport data and builds a plan for the target release, with known issues and the exact steps for your configuration.
Then check three things it can’t fully decide for you.
The Hardware Universe must list your platform, shelves and adapters for the target release. The Interoperability Matrix Tool (IMT) must list your host OS, HBAs, multipath and backup software with that release. And your SnapMirror and SnapVault partners must be on releases that can still talk to the new one; when two clusters differ, upgrade the destination side first.
2Pre-checks you do yourself
| Check | Command or place | Why |
|---|---|---|
| Cluster and HA healthy | cluster show; storage failover show | Takeover must be possible on every node |
| No degraded aggregates or failed disks | storage aggregate show; storage disk show -broken | A reboot during a rebuild adds risk |
| LIFs home and failover targets on both nodes | network interface show -is-home false; -failover | A NAS LIF with nowhere to go drops its clients |
| SAN hosts have paths through both nodes | On each host: multipath -ll or MPIO | SAN I/O moves paths during takeover |
| SMB shares | Continuously available shares for apps that need it | Non-CA SMB sessions reconnect during takeover |
| Long jobs | snapmirror show; volume move show | Let big transfers and moves finish first |
| AutoSupport working | system node autosupport history show | NetApp support sees what happened |
Book a quiet time, tell the application and host teams, and send an AutoSupport with -type all -message "Starting_NDU" so NetApp has a before picture.
3The update itself
The package is a file like 9181P2_q_image.tgz that you download from the support site and serve from an HTTP or FTP server the node management LIFs can reach. cluster image package get copies it to every node as the alternate boot image, so each node now holds two images: the one it runs and the new one.
cluster image validate runs the automated checks, then cluster image update starts the rolling update. For each node, its partner takes over, the node boots the new image, waits until it’s stable (8 minutes by default) and takes its storage back; then the same happens to the partner. cluster image show-update-progress shows every phase and pauses the update on any error, and cluster image resume-update continues once you have fixed it.
4Firmware, reverting and the GUI way
The ONTAP package carries firmware too. BIOS updates while a node boots, the Service Processor or BMC after the reboot if its auto-update is on, shelf firmware after the reboot if shelf auto-update is on, and disk firmware in the background during quiet I/O after the update finishes. The Disk Qualification Package (DQP), which teaches ONTAP about newly qualified drive models, is downloaded and updated separately from the support site.
Going back is possible, but a revert has limits and its own procedure, so plan it with NetApp support rather than in a hurry; keep the old image on the nodes until you’re sure. In System Manager the whole update lives under Cluster › Overview › ONTAP update, where you upload or point to the package, validate and update.
Hands-on lab: run a rolling ONTAP update
Before you run any command, double-check it
Read every command twice before you press Enter. Check the target: the server name, the user, the disk or device name, the path and the sizes. These commands are for learning and were tested in our lab, not on your system. At work, run the read-only commands first, follow your change process, make sure a backup exists, and ask a second person to check anything that changes or deletes data. You run them at your own risk.
This lab uses the SaatVedha ONTAP practice shell, our own learning tool. It is not NetApp software: real ONTAP output looks like this but is not identical.
The practice shell 1.1 has a pretend web server on linux1 holding two patch packages, and it runs the update one step per simctl tick, about 10 minutes of real time each.
1Build a small lab
Create setup-upg.txt with the same seven lines as the REST deep dive’s setup-rest.txt (two aggregates, svm1, two NAS LIFs, NFS and an export rule), then run:
python ontapsim.py -c "simctl reset"
python ontapsim.py --run setup-upg.txt✅ Checkpoint: No line of the output starts with Error.
2Look before you change anything
Log in to the shell and run:
version
cluster image show
system node image show
storage failover showYou should see this:
saat-cluster::> version
NetApp Release 9.18.1: Sat Nov 07 2026 (SaatVedha practice shell 1.1, not NetApp software)
saat-cluster::> cluster image show
Current Installation
Node Version Date
---------------- --------------------------- -------------------
saat-cluster-01 9.18.1 10/1/2026 09:12:44
saat-cluster-02 9.18.1 10/1/2026 09:13:44
2 entries were displayed.
saat-cluster::> system node image show
Is Is Install
Node Image Default Current Version Date
-------- ------- ------- ------- ------------------------- -------------------
saat-cluster-01
image1 true true 9.18.1 10/1/2026 09:12:44
image2 false false 9.17.1P5 6/12/2026 11:02:10
saat-cluster-02
image1 true true 9.18.1 10/1/2026 09:13:44
image2 false false 9.17.1P5 6/12/2026 11:03:10
4 entries were displayed.
saat-cluster::> storage failover show
Takeover
Node Partner Possible State Description
--------------- --------------- -------- -------------------------------------
saat-cluster-01 saat-cluster-02 true Connected to saat-cluster-02
saat-cluster-02 saat-cluster-01 true Connected to saat-cluster-01
2 entries were displayed.Each node holds two boot images: image1 runs 9.18.1 and image2 still holds the previous release. Takeover is possible on both nodes, which is the first condition for a nondisruptive update.
✅ Checkpoint: Both nodes run 9.18.1 and Takeover Possible is true.
3Download the package
cluster image package get -url http://192.168.56.99/ontap/9181P2_q_image.tgz
simctl web list
cluster image package get -url http://192.168.56.21/ontap/9181P2_q_image.tgz
cluster image package show-repositoryYou should see this:
Error: command failed: Package download failed: unable to download http://192.168.56.99/ontap/9181P2_q_image.tgz. Check the URL and that the web server is reachable from the node management LIFs.
saat-cluster::> simctl web list
Lab web server on linux1 (http://192.168.56.21/ontap/):
9181P2_q_image.tgz
9181P3_q_image.tgz
saat-cluster::> cluster image package get -url http://192.168.56.21/ontap/9181P2_q_image.tgz
Software get http://192.168.56.21/ontap/9181P2_q_image.tgz started on node saat-cluster-01
Downloading package. This may take up to 20 minutes.
100% downloaded
...
Package download completed.
Package processing completed.
saat-cluster::> cluster image package show-repository
Package Version Package Build Time
---------------- -------------------
9.18.1P2 11/7/2026 08:40:11The first address was wrong on purpose: nothing at 192.168.56.99 serves the file. simctl web list plays the part of you checking your own web server.
✅ Checkpoint: show-repository lists 9.18.1P2.
4Validate
cluster image validate -version 9.18.1P2
cluster image show-update-progressYou should see this:
It can take several minutes to complete validation...
WARNING: There are additional manual upgrade validation checks that must be performed after these automated validation checks have completed successfully. Refer to the Upgrade Advisor Plan or the "What should I verify before I upgrade with or without Upgrade Advisor" section in the "Upgrade ONTAP" documentation for the remaining manual validation checks that need to be performed before update.
Validation checks started successfully. Run the "cluster image show-update-progress" command to check validation status.
saat-cluster::> cluster image show-update-progress
Pre-update Check Status Error-Action
------------------------ ---------- --------------------------------------------
Aggregate Health OK N/A
Aggregate Status OK N/A
CIFS Status OK N/A
Cluster/HA Health Status OK N/A
Disk Status OK N/A
LIF Status OK N/A
SnapMirror Status OK N/A
Volume Status OK N/A
Manual checks Warning Read the ONTAP upgrade guide and the release notes before you update.
Overall Status Warning Warning
10 entries were displayed.Every automatic check is OK. The one warning is a reminder that some checks, like host compatibility, are yours to do. Any Error here must be fixed before the update will start.
✅ Checkpoint: Every line except Manual checks shows OK.
5Start the update and watch the first takeover
cluster image update -version 9.18.1P2
cluster image show-update-progress
simctl tick
storage failover show
network interface show -is-home falseAnswer y to the warning question.
You should see this:
Warning: Validation reported warnings. Do you want to continue? {y|n}: y
Starting update...
Info: Run the "cluster image show-update-progress" command to check update status. In the practice shell, each "simctl tick" is about 10 minutes of update time.
saat-cluster::> cluster image show-update-progress
Estimated Elapsed
Update Phase Status Duration Duration
-------------------- ----------------- --------------- ---------------
Pre-update checks completed 00:10:00 00:02:31
ONTAP updates in-progress 01:23:00 00:00:00
Details:
Node name Status Status Description
-------------------- ----------------- ----------------------------------------
saat-cluster-01 waiting -
saat-cluster-02 waiting -
Status: In progress
saat-cluster::> simctl tick
simctl: time moved forward (1 step).
saat-cluster::> storage failover show
Takeover
Node Partner Possible State Description
--------------- --------------- -------- -------------------------------------
saat-cluster-01 saat-cluster-02 false Waiting for giveback (HA mailboxes)
saat-cluster-02 saat-cluster-01 false In takeover
2 entries were displayed.
saat-cluster::> network interface show -is-home false
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ --------------- ------- ----
saat-cluster
cluster_mgmt
up/up 192.168.56.100/24 saat-cluster-02 e0M false
svm1
svm1_nas1 up/up 192.168.56.130/24 saat-cluster-02 e0c false
2 entries were displayed.Node 02 has taken over node 01’s storage, and node 01’s NAS LIF and the cluster management LIF now run on node 02. NFS clients of 192.168.56.130 see a short pause and carry on. This is the moment to be watching, not drinking tea.
✅ Checkpoint: saat-cluster-02 shows In takeover and svm1_nas1 is on saat-cluster-02.
6Let it finish and check the result
simctl tick 2
cluster image show-update-progress
simctl tick 4
cluster image show-update-progress
cluster image show
version
system node image showYou should see this (the middle progress table trimmed):
Node name Status Status Description
-------------------- ----------------- ----------------------------------------
saat-cluster-01 completed -
saat-cluster-02 waiting -
...
saat-cluster::> cluster image show-update-progress
Estimated Elapsed
Update Phase Status Duration Duration
-------------------- ----------------- --------------- ---------------
Pre-update checks completed 00:10:00 00:02:31
ONTAP updates completed 01:23:00 01:00:00
Post-update checks completed 00:10:00 00:01:12
Details:
Node name Status Status Description
-------------------- ----------------- ----------------------------------------
saat-cluster-01 completed -
saat-cluster-02 completed -
Status: Completed
saat-cluster::> cluster image show
Current Installation
Node Version Date
---------------- --------------------------- -------------------
saat-cluster-01 9.18.1P2 11/7/2026 08:37:11
saat-cluster-02 9.18.1P2 11/7/2026 08:37:11
2 entries were displayed.
saat-cluster::> version
NetApp Release 9.18.1P2: Sat Nov 07 2026 (SaatVedha practice shell 1.1, not NetApp software)
saat-cluster::> system node image show
Is Is Install
Node Image Default Current Version Date
-------- ------- ------- ------- ------------------------- -------------------
saat-cluster-01
image1 false false 9.18.1 10/1/2026 09:12:44
image2 true true 9.18.1P2 11/7/2026 08:37:11
saat-cluster-02
image1 false false 9.18.1 10/1/2026 09:13:44
image2 true true 9.18.1P2 11/7/2026 08:37:11
4 entries were displayed.Both nodes now boot image2 with 9.18.1P2, and image1 still holds 9.18.1 in case you ever need it. version changes only once the whole cluster has finished, because a cluster runs at the level of its oldest node.
✅ Checkpoint: cluster image show lists 9.18.1P2 on both nodes.
7Check firmware and send the closing AutoSupport
storage disk show -fields firmware-revision -disk 1.0.0|1.1.0
system node service-processor image showYou should see this:
disk firmware-revision
----- -----------------
1.0.0 NA02
1.1.0 NA54
2 entries were displayed.
saat-cluster::> system node service-processor image show
Is Is Update
Node Image Current Version Primary Status
-------- -------- -------- -------------------------- -------- ----------
saat-cluster-01
primary true 13.4 true installed
backup false 13.2 false installed
saat-cluster-02
primary true 13.4 true installed
backup false 13.2 false installed
4 entries were displayed.On a real cluster, disk firmware keeps updating in the background for a while after the upgrade, so check it again the next day. Close the job with system node autosupport invoke -node * -type all -message "Finishing_NDU" so NetApp has the after picture.
✅ Checkpoint: You can name the disk firmware revisions and the SP version on each node.
Try it yourself: Run the cluster health check before and after your update.
Break It, Then Fix It
Updates stop for real reasons: a busy partner refuses to give back, a check fails, or a file isn’t where you said. Here you’ll make an update pause halfway and bring it home.
1Start an update with a hidden problem
Reset and rebuild the lab, then run these commands. simctl break giveback-veto makes a process on the partner refuse the giveback, as a busy subsystem sometimes does.
cluster image package get -url http://192.168.56.21/ontap/9181P2_q_image.tgz
simctl break giveback-veto
cluster image update -version 9.18.1P2
simctl tick 3
cluster image show-update-progressAnswer y to the warning question.
You’ll get this:
saat-cluster::> cluster image show-update-progress
Estimated Elapsed
Update Phase Status Duration Duration
-------------------- ----------------- --------------- ---------------
Pre-update checks completed 00:10:00 00:02:31
ONTAP updates paused-on-error 01:23:00 00:30:00
Details:
Node name Status Status Description
-------------------- ----------------- ----------------------------------------
saat-cluster-01 failed Giveback vetoed.
saat-cluster-02 waiting -
Error: Giveback of node saat-cluster-01 was vetoed. Fix the cause, then run "cluster image resume-update".
Status: Paused - An error occurred
Node 01 has rebooted on the new image, but its partner still holds node 01’s aggregates. Data is still online, served by node 02 alone, so nothing is down; you just have no HA protection until this is fixed.
✅ Checkpoint: Status says Paused – An error occurred.
2Find what is stuck
storage failover show
storage failover show-givebackYou’ll get this:
Takeover
Node Partner Possible State Description
--------------- --------------- -------- -------------------------------------
saat-cluster-01 saat-cluster-02 false Waiting for giveback (HA mailboxes)
saat-cluster-02 saat-cluster-01 false In takeover
2 entries were displayed.
saat-cluster::> storage failover show-giveback
Partner Giveback
Node Aggregate Status
-------------- ------------------------- ------------------------------
saat-cluster-01
No aggregates to give back
saat-cluster-02
aggr0_saat_cluster_01 Not attempted yet
saat-cluster-02
aggr1_01 Not attempted yet
3 entries were displayed.On a real cluster, storage failover show-giveback and the event log name the subsystem that vetoed, such as a busy lock manager or a disk check. Most vetoes clear by themselves once that work finishes; forcing past one with -override-vetoes true is a decision to make with NetApp support, not a reflex.
✅ Checkpoint: You can say which node is waiting and which aggregates are still with the partner.
3Clear the cause and resume
In the shell, simctl fix giveback-veto plays the part of the busy process finishing. Then let ONTAP carry on:
simctl fix giveback-veto
cluster image resume-update
simctl tick 5
cluster image show-update-progress
versionYou should see this:
Update Phase Status Duration Duration
-------------------- ----------------- --------------- ---------------
Pre-update checks completed 00:10:00 00:02:31
ONTAP updates completed 01:23:00 01:10:00
Post-update checks completed 00:10:00 00:01:12
Details:
Node name Status Status Description
-------------------- ----------------- ----------------------------------------
saat-cluster-01 completed -
saat-cluster-02 completed -
Status: Completed
saat-cluster::> version
NetApp Release 9.18.1P2: Sat Nov 07 2026 (SaatVedha practice shell 1.1, not NetApp software)Resume carries on from where it stopped, gives node 01 its storage back and updates node 02. Don’t mix manual takeover or giveback commands into an automated update you plan to resume; fix the cause and let ANDU drive.
✅ Checkpoint: The update completes and version shows 9.18.1P2.
This happened at work
The warning nobody read
A tractor parts maker in Jalandhar planned a patch upgrade on a Saturday evening. Validation came back with one Warning on LIF Status, which said a NAS LIF had no failover target on the partner node. The engineer had seen warnings before that meant nothing, answered y and went for dinner.
When node 01 was taken over, that LIF had nowhere to go. It served the design team’s SMB share, and the CAD workstations on the night shift lost their drawings folder for about ten minutes until the giveback brought the LIF home. Two half-saved drawings had to be redone.
The cause was a VLAN port that had been added to the broadcast domain on node 01 only, months earlier. The team fixed the failover group, re-ran validation until it was clean, and changed their runbook: every Warning gets read and either fixed or written down with a reason before anyone types y.
Common mistakes and troubleshooting
| Mistake | What happens | Do this instead |
|---|---|---|
| Skipping the Interoperability Matrix check | A host, HBA or backup tool stops working after the upgrade | Check every host OS, HBA and backup product in the IMT for the target release |
| Upgrading the SnapMirror source before the destination | Replication can stop if the releases can’t talk | Upgrade the destination cluster first when the two sides will differ |
| Answering y to warnings without reading them | A LIF or path drops during takeover | Read every Warning and fix it or record why it’s safe |
| Starting during a big transfer or volume move | The update waits or takes much longer | Let long jobs finish, or pause the schedules first |
| Mixing manual takeovers into an automated update | ANDU loses track and the resume fails | Fix the cause and use cluster image resume-update |
| Forgetting firmware after the upgrade | Old disk or SP firmware with known bugs stays in place | Check disk, shelf and SP firmware the next day |
Interview questions
Click a question to open it. Each one is written the way an interviewer would ask it. Under it you will see why they ask it and one way you could answer, in your own words.
Fresher level
1. What does a nondisruptive ONTAP upgrade mean in simple words?
Why they ask this: They want to see you understand how HA makes upgrades possible without downtime.
How you might answer: It means users keep working while we upgrade. Each node’s partner takes over its storage, the node reboots on the new release and takes its storage back, then the partner does the same.
NAS clients see a short pause and SAN hosts move to their other paths.
2. Which command shows you how far an upgrade has got?
Why they ask this: They’re checking you’ve actually run an upgrade or at least know the main commands.
How you might answer: cluster image show-update-progress. It lists the pre-checks, each node’s status and any error, and if the update has paused it tells you why. After it finishes I check cluster image show and version on every node.
2–5 years experience
3. An automated update has paused with “giveback vetoed”. What do you do?
Why they ask this: They want a calm, ordered response, not a forced giveback.
How you might answer: First I’d confirm data is still served by the partner, so there’s no outage, just no HA. Then storage failover show-giveback and the event log tell me which subsystem vetoed; usually it’s busy and clears once its work ends.
When the cause is gone I run cluster image resume-update. I’d only override vetoes with NetApp support on the line.
4. What would you check before upgrading a cluster that replicates to a DR site?
Why they ask this: They’re testing that you think beyond the one cluster in front of you.
How you might answer: I’d check that both clusters’ releases can still replicate after the change and plan to upgrade the destination first. I’d also look at snapmirror show for lag and running transfers, let them finish, and make sure the upgrade window doesn’t clash with the replication schedule.
Senior level
5. How would you plan upgrades for 30 clusters across the country?
Why they ask this: They want to see planning at scale: standards, risk and automation.
How you might answer: I’d pick one target release and patch level, test it on a lab cluster and one low-risk site first, and use Digital Advisor’s Upgrade Advisor plans for each cluster. Then I’d batch the rest by region with a fixed runbook and pre-check script, upgrading DR destinations before their sources.
I’d track every cluster’s release and support end date in one place so none slips into limited support.
6. Your manager asks why you can’t stay on the current release for five more years. What do you tell them?
Why they ask this: They’re checking you understand the support lifecycle and can explain risk to non-engineers.
How you might answer: I’d explain that a release gets full support with patches and security fixes for 3 years only. After that we can still call support for 2 years, but no new patches come, so a security bug found later stays open on our cluster.
Planning an upgrade every year or two keeps us inside full support and makes each upgrade smaller.
Quick quiz
Q1. How many years of full support does a new ONTAP release get?
- 1
- 3
- 5
- 8
Show answer
B — full support lasts 3 years, then limited support in years 4 and 5.
Q2. Which update method is the default for a 4-node cluster?
- Batch
- Rolling
- Disruptive
- Manual only
Show answer
B — clusters with fewer than 8 nodes use a rolling update by default.
Q3. What does cluster image package get do?
- Starts the update
- Copies the new image to the nodes as the alternate boot image
- Checks the Interoperability Matrix
- Updates the disk firmware
Show answer
B — it downloads the package to each node’s alternate image.
Q4. An update pauses on an error. Which command continues it after you fix the cause?
- cluster image update
- storage failover giveback
- cluster image resume-update
- system node reboot
Show answer
C — resume-update continues the automated update from where it stopped.
Q5. When do disks get their new firmware after an ONTAP upgrade?
- Before the upgrade starts
- In the background during quiet I/O after the upgrade
- Never automatically
- Only after a revert
Show answer
B — disk firmware updates in the background after the nodes reboot.
Quick recap
- ONTAP ships about twice a year; P releases carry fixes, and each release has 3 years of full support.
- Plan with Upgrade Advisor, Hardware Universe and the Interoperability Matrix; upgrade DR destinations first.
- ANDU: package get, validate, update; partners take over one node at a time.
- show-update-progress tells you where you are; resume-update continues after a fix.
- Firmware for BIOS, SP, shelves and disks follows the upgrade; check it the next day.
Next lesson
Lesson 47: The troubleshooting workflow (EMS, event log, AutoSupport) → You’ll learn a repeatable way to find what broke: symptom, where to look, and how to check.
Further reading: ONTAP upgrade
Want to go deeper into ONTAP upgrade? NetApp’s ONTAP upgrade methods and automated nondisruptive upgrade steps are the official reference for every command on this page. You can also see the full plan for this course on the NetApp ONTAP Storage Administration course page.