You can use the command-line interface (CLI) to install software updates.
Follow these steps to update
automatically by using the CLI to version 7.5 or later from version
7.4 or later. If you are updating from a release previous to
version 7.4.0, follow the instructions in that previous release. You
are required, however, to confirm the update, which is not included
in those steps. After you follow the instructions for your release,
return here and continue with step 8 in
the procedure.
Important: Before you start an update, you must check for offline
or degraded volumes. An offline volume can cause write data that was modified
to be pinned in the system cache. This action prevents volume failover and causes a loss of input/output
(I/O) access during the update. If the fast_write_state is empty, a volume can be offline
and not cause errors during the update.
To update the system, follow these steps.
- Download, install, and run the latest version
of the test utility to verify that there are no issues with the current
system.
- Download the latest code from the http://support.lenovo.com/us/en/products/servers/lenovo-storage site.
- If you want to write the code to a CD, you must download the
CD image.
- If you do not want to write the code to a CD, you must download
the installation image.
- Use PuTTY scp (pscp) to copy the update files to
the node.
- Ensure that the update file was successfully copied.
Before you begin the update, you must be aware of the following
situations:
- The installation process fails under the following conditions:
- If the code that is installed
on the remote system is not compatible with the new code or if an
intersystem communication error does not allow the system to check
that the code is compatible.
- If any node in the system
has a hardware type that is not supported by the new code.
- If the system determines
that one or more volumes in the
system would be taken offline by rebooting the
nodes as part of the update process. You
can find details about which volumes would be affected by using the lsdependentvdisks command. If you are prepared to lose access to data during the update,
you can use the force flag to override this restriction.
- The update is distributed to
all the nodes in the system by using internal connections between
the nodes.
- Nodes are updated one at a time.
- Nodes run the new code concurrently with
normal system activity.
- While the node is updated, it does not participate
in I/O activity in the I/O group . As a result, all I/O activity for the volumes in the I/O group is directed to the
other node in the I/O group by the host multipathing software.
- There is a thirty-minute delay between node
updates. The delay allows time for the host multipathing software
to rediscover paths to the nodes that are updated. There is no loss
of access when another node in the I/O group is updated.
- The update is not committed until all nodes
in the system are successfully updated to the new code level. If all
nodes successfully restart with the new code level, the new level
is committed. When the new level is committed, the system vital product
data (VPD) is updated to reflect the new code level.
- Wait until all member nodes are updated
and the update is committed before you invoke the new functions of
the updated code.
- Because the update process takes some time, the installation command
completes as soon as the code level is verified by the system. To
determine when the update is completed, you must either display the
code level in the system VPD or look for the Software update
complete event in the error/event log. If any node fails
to restart with the new code level or fails at any other time during
the process, the code level is backed off.
- During an update, the version number of each node is updated when
the code is installed and the node is restarted. The system code version
number is updated when the new code level is committed.
- When the update starts, an entry is made in the error or event
log and another entry is made when the update completes or fails.
- Issue this CLI command to start the update process:
applysoftware -file software_update_file
Where software_update_file is the name
of the code update file in the directory you copied the file to in
step 3.
If the system identifies
any volumes that would go offline
as a result of rebooting the nodes as part of the system update, the
code update does not start. An optional force parameter can be used to indicate that the update continues regardless
of the problem identified. If you use the force parameter, you are prompted to confirm that you
want to continue. The behavior of the force parameter
changed, and it is no longer required when you apply an update to
a system with errors in the event log.
- If you
are updating from a release before version 7.4.0, issue the following
CLI command to check the status of the code update process:
svcinfo lssoftwareupgradestatus
This command displays inactive when the update is complete. Note: If a status of stalled_non_redundant is displayed, proceeding with the remaining set of node updates
might result in offline volumes. Contact a service representative to complete the update.
- If you are updating from version
7.4.0 or later, issue the following CLI command to check the status
of the code update process:
lsupdate
This command
displays success when the update is complete. Note: If a status of stalled_non_redundant is displayed, proceeding with
the remaining set of node updates might result in offline volumes. Contact a service representative
to complete the update.
-
If you updated from a release before version 7.4.0, you receive
the status message system_completion_required.
To complete the update process, issue the command applysoftware
-complete. After that command is run, you can run lsupdate to see the progress of the update completion.
- To verify that the update successfully
completed, issue the lsnodecanistervpd CLI command
for each node that is in the system.
The code version field displays the new code level.
When a new code level is applied, it is automatically installed
on all the nodes that are in the system.
Note: An automatic system
update can take up to 30 minutes per node.