application commands
cluster image show-update-progress
Suggest changes
PDFs
Display the update progress
Availability: This command is available to cluster administrators at the admin privilege level.
Description
The cluster image show-update-progress command displays information about the current state of an update. By default, the command displays the following information:
-
Update phase
-
Status
-
Estimated Duration
-
Elapsed Duration
Parameters
- {
[-fields <fieldname>,…] -
If you specify the
-fields <fieldname>, …parameter, the command output also includes the specified field or fields. You can use '-fields ?' to display the fields to specify. - |
[-instance ]} -
If you specify the
-instanceparameter, the command displays detailed information about all fields. [-ndu-phase {validation|prereq-updates|ontap-updates|package-management|default-phase|post-update-checks}]- Update Phase-
Displays information about the specified update phase.
[-phase-status {in-progress|waiting|paused-by-user|paused-on-error|completed|canceled|failed|pause-pending|cancel-pending}]- Phase Status-
Displays information about progress matching the specified phase status.
[-phase-duration <text>]- Phase Duration-
Displays information about progress matching the specified phase duration.
[-phase-comments <text>]- Phase Comments-
Displays information about progress matching the specified phase comments.
[-elapsed-duration {<seconds>|[<d> days] <hh>:<mm>[:<ss>]}]- Elapsed duration of the phase-
Displays information about progress matching the specified elapsed duration.
[-estimated-duration {<seconds>|[<d> days] <hh>:<mm>[:<ss>]}]- Estimated duration of the phase-
Displays information about progress matching the specified estimated duration.
[-phase-description <text>]- Phase Description-
Displays information about progress matching the specified phase description.
[-subsystem-name <text>]- Subsystem Name-
Displays information about progress matching the specified subsystem name.
[-subsystem-status <text>]- Subsystem Status-
Displays information about progress matching the specified subsystem status.
[-subsystem-details <text>]- Subsystem Details-
Displays information about progress matching the specified subsystem details.
[-subsystem-action <text>]- Subsystem Action-
Displays information about progress matching the specified subsystem action.
Examples
The following example shows the cluster image validate progress of two nodes, nodeA and nodeB after executing the cluster image validation command. On the first screen it shows when the pre-update check status is in-progress and on the second screen it shows the pre-update checks status changed to completed .
cluster1::> cluster image show-update-progress
Estimated Elapsed
Update Phase Status Duration Duration
-------------------- ----------------- --------------- ---------------
Pre-update checks in-progress 00:10:00 00:00:13
Details:
Pre-update Check Status Error-Action
-------------------- ----------------- -------------------------------
cluster1::> cluster image show-update-progress
Update Phase Status Duration Duration
-------------------- ----------------- --------------- ---------------
Pre-update checks completed 00:10:00 00:01:09
Details:
Pre-update Check Status Error-Action
-------------------- ----------- --------------------------
Boot Menu Status Warning Warning: bootarg.init.bootmenu is
enabled on nodes: nodeA,
nodeB. The boot process
of the nodes will be delayed.
Action: Set the bootarg.init.bootmenu
bootarg to false before proceeding
with the upgrade.
Manual checks Warning Warning: Manual validation checks
need to be performed. 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 validation checks
that need to be performed before
update. Failing to do so can result
in an update failure or an I/O
disruption.
Action: 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 validation checks that need
to be performed before update.
NFS mounts Warning Warning: This cluster is serving NFS
clients. If NFS soft mounts are used,
there is a possibility of frequent
NFS timeouts and race conditions that
can lead to data corruption during
the upgrade.
Action: Use NFS hard mounts, if
possible. To list Vservers running
NFS, run the following command:
vserver nfs show
Nodes to update list Warning Warning: List of nodes to be
upgraded: "nodeA,
nodeB."
Action: To upgrade all selected nodes,
regardless of their current version,
set the (privilege: advanced)
"-skip-nodes-at-target-version"
parameter to "false".
4 entries were displayed.
The following example shows the cluster image validate progress of two nodes, nodeA and nodeB after executing the cluster image validation command along with option show-validation-details. On the first screen it shows when the pre-update check status is in-progress . On the second screen it shows the pre-update checks status changed to completed .
cluster1::> cluster image show-update-progress
Estimated Elapsed
Update Phase Status Duration Duration
-------------------- ----------------- --------------- ---------------
Pre-update checks in-progress 00:10:00 00:00:13
Details:
Pre-update Check Status Error-Action
-------------------- ----------------- -------------------------------
cluster1::> cluster image show-update-progress
Estimated Elapsed
Update Phase Status Duration Duration
-------------------- ----------------- --------------- ---------------
Pre-update checks completed 00:10:00 00:01:08
Details:
Pre-update Check Status Error-Action
-------------------- ----------------- --------------------------------
AMPQ Router and OK N/A
Broker Config
Cleanup
Aggregate online OK N/A
status and parity
check
Aggregate plex OK N/A
resync status check
Application OK N/A
Provisioning Cleanup
Autoboot Bootargs OK N/A
Status
Backend OK N/A
Configuration Status
Boot Menu Status Warning Warning: bootarg.init.bootmenu is
enabled on nodes: nodeA,
nodeB. The boot process
of the nodes will be delayed.
Action: Set the
bootarg.init.bootmenu
bootarg to false before
proceeding with the upgrade.
Broadcast Domain OK N/A
availability and
uniqueness for HA
pair status
CIFS compatibility OK N/A
status check
CLAM quorum online OK N/A
status check
CPU Utilization OK N/A
Status
Capacity licenses OK N/A
install status check
Check For SP/BMC OK N/A
Connectivity To
Nodes
Check LDAP fastbind OK N/A
users using
unsecure connection.
Check for unsecure OK N/A
kex algorithm
configurations.
Check for unsecure OK N/A
mac configurations.
Cloud keymanager OK N/A
connectivity check
Cluster health and OK N/A
eligibility status
Cluster quorum OK N/A
status check
Cluster/management OK N/A
switch check
Compatible New OK N/A
Image Check
Current system OK N/A
version check if it
is susceptible to
possible outage
during NDU
Data ONTAP Version OK N/A
and Previous
Upgrade Status
Data aggregates HA OK N/A
policy check
Disk status check OK N/A
for failed, broken
or non-compatibility
Duplicate Initiator OK N/A
Check
Encryption key OK N/A
migration status
check
External OK N/A
key-manager with
legacy KMIP client
check
External keymanager OK N/A
key server status
check
Fabricpool Object OK N/A
Store Availability
High Availability OK N/A
configuration
status check
Infinite Volume OK N/A
availibility check
LIF failover OK N/A
capability status
check
LIF health check OK N/A
LIF load balancing OK N/A
status check
LIFs is on home OK N/A
node status
Logically over OK N/A
allocated DP
volumes check
Manual checks that Warning Warning: Manual validation checks
can be done using need to be performed. Refer to the
Upgrade ONTAP Upgrade Advisor Plan or the "What
documentation should I verify before I
upgrade with or without Upgrade
Advisor" section in the
"Upgrade ONTAP" documentation
for the remaining validation checks
that need to be performed before
update. Failing to do so can result
in an update failure or an I/O
disruption.
Action: 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
validation checks that need
to be performed before update.
MetroCluster OK N/A
configuration
status check for
compatibility
Minimum number of OK N/A
aggregate disks
check
Multi-Admin upgrade OK N/A
validation checks
NAE Aggregate and OK N/A
NVE Volume
Encryption Check
NDMP sessions check OK N/A
NFS mounts status Warning Warning: This cluster is serving
check NFS clients. If NFS soft mounts
are used, there is a possibility
of frequent NFS timeouts and race
conditions that can lead to data
corruption during the upgrade.
Action: Use NFS hard mounts, if
possible. To list Vservers running
NFS, run the following command:
vserver nfs show
Name Service OK N/A
Configuration DNS
Check
Name Service OK N/A
Configuration LDAP
Check
Network port OK N/A
reachability check
Node to SP/BMC OK N/A
connectivity check
Nodes to update list Warning Warning: List of nodes to be
upgraded: "nodeA,
nodeB."
Action: To upgrade all selected
nodes, regardless of their
current version, set the
(privilege: advanced)
"-skip-nodes-at-target-version"
parameter to "false".
OKM/KMIP enabled OK N/A
systems - Missing
keys check
ONTAP API to REST OK N/A
transition warning
ONTAP Image OK N/A
Capability Status
OpenSSL 3.0.x OK N/A
upgrade validation
check
Openssh 7.2 upgrade OK N/A
validation check
Platform Health OK N/A
Monitor check
Pre-Update OK N/A
Configuration
Verification
RDB Replica Health OK N/A
Check
Replicated database OK N/A
schema consistency
check
Running Jobs Status OK N/A
SAN LIF association OK N/A
status check
SAN compatibility OK N/A
for manual
configurability
check
SAN kernel agent OK N/A
status check
Secure Purge OK N/A
operation Check
Shelves and Sensors OK N/A
check
SnapLock Version OK N/A
Check
SnapMirror OK N/A
Synchronous
relationship status
check
SnapMirror OK N/A
compatibility
status check
Supported platform OK N/A
check
Target ONTAP OK N/A
release support for
FiberBridge 7500N
check
Upgrade Version OK N/A
Compatibility Status
Verify all bgp OK N/A
peer-groups are in
the up state
Verify if a cluster OK N/A
management LIF
exists
Verify that e0M is OK N/A
home to no LIFs
with high speed
services.
Volume Conversion OK N/A
In Progress Check
Volume move OK N/A
progress status
check
Volume online OK N/A
status check
iSCSI target portal OK N/A
groups status check
Overall Status Warning Warning
78 entries were displayed.
The following example shows the automated nondisruptive update of two nodes, nodeA and nodeB. In this case, nodeA's update is waiting, nodeB's update is in progress. nodeB's giveback operation is in progress.
cluster1::> cluster image show-update-progress Estimated Elapsed Update Phase Status Duration Duration -------------------- ----------------- --------------- --------------- Pre-update checks completed 00:10:00 00:00:02 Data ONTAP updates in-progress 01:23:00 00:32:07 Details: Node name Status Status Description -------------------- ----------------- --------------------------------- nodeA waiting nodeB in-progress Performing giveback operation. 3 entries were displayed. cluster1::>
The following example shows the automated nondisruptive update of two nodes, nodeA and nodeB. In this case, automated nondisruptive update is paused-on-error in "Data ONTAP updates" phase. nodeA's update is waiting, nodeB's update is failed. "Status Description" show nodeB's error and action.
cluster1:> cluster image show-update-progress
Estimated Elapsed
Update Phase Status Duration Duration
-------------------- ----------------- --------------- ---------------
Pre-update checks completed 00:10:00 00:00:02
Data ONTAP updates paused-on-error 00:49:00 00:05:21
Details:
Node name Status Status Description
-------------------- ----------------- ----------------------------------
nodeA waiting
nodeB failed Error: Takeover of node
"nodeB" is not possible.
Action: Use the "storage failover
show" command to view the cause of
the failure.
2 entries were displayed.
Status: Paused - An error occurred in "Data ONTAP updates" phase. The
non-disruptive update cannot continue until the error has been resolved.
Resolve all issues, then use the "cluster image resume-update" command to
resume the update.
cluster1:>
The following example shows that the automated nondisruptive update is paused-on-error in "Post-update checks" update phase and "Status Description" shows the error and action.
cluster1::> cluster image show-update-progress
Estimated Elapsed
Update Phase Status Duration Duration
-------------------- --------------- --------------- ---------------
Data ONTAP updates completed 02:19:00 00:00:03
Post-update checks paused-on-error 00:10:00 00:00:02
Details:
Post-update Check Status Error-Action
-------------------- -------------- -------------------------------------
Cluster Quorum Error Error: Cluster is not in quorum.
Status
Action: Use the (privilege: advanced)
"cluster ring show" command to verify
all replication unit details.
5 entries were displayed.
Status: Paused - An error occurred in "Post-update checks" phase. The
non-disruptive update cannot continue until the error has been resolved.
Resolve all issues, then use the "cluster image resume-update" command
to resume the update.
cluster1::>
The following example shows that the automated nondisruptive update is completed on nodeA and nodeB.
cluster1::> cluster image show-update-progress Estimated Elapsed Update Phase Status Duration Duration -------------------- ----------------- --------------- --------------- Pre-update checks completed 00:10:00 00:00:13 Data ONTAP updates completed 01:23:00 01:15:11 Post-update checks completed 00:10:00 00:00:02 3 entries were displayed. Updated nodes: nodeA, nodeB. cluster1:>
The following example shows the automated update of two-node MetroCluster configuration having clusters cluster_A and cluster_B. In this case, cluster_A's update is waiting and cluster_B's update is in progress. cluster_B's switchback operation is in progress.
cluster_A::> cluster image show-update-progress Estimated Elapsed Cluster Duration Duration Status ------------------------------ --------------- --------------- ---------------- cluster_A 00:00:00 00:00:00 waiting cluster_B 00:00:00 00:06:42 in-progress Details: Switchback in progress. Waiting for partner cluster "sti60-vsim-ucs134f_siteB" to be up. cluster_A::>
The following example shows that the automated update is completed on both cluster_A and cluster_B in two-node MetroCluster configuration.
cluster_A::> cluster image show-update-progress Estimated Elapsed Cluster Duration Duration Status ------------------------------ --------------- --------------- ---------------- cluster_A 00:00:00 00:20:44 completed cluster_B 00:00:00 00:10:43 completed Details: MetroCluster updated successfully. cluster_A::>
