Question & Answer
Question
This technote answers some of the common questions asked before performing a software upgrade of a Storwize V7000 or SAN Volume Controller system.
Cause
Pre-Upgrade Checklist:
Frequently Asked Questions:
Preparing For An Upgrade
Q: Is the upgrade procedure able to be run by customers?
A: Yes, the upgrade procedure is a relatively simple operation to perform, involving an upload of a code package and a small set of commands to commence the upgrade. Once begun, the upgrade procedure will automatically upgrade each node or node canister in the cluster separately, without the need for further user input.
Q: Which fixes are in the latest PTF update?
A: The list of fixes in the latest PTF update can be found in the Release Note. See the Useful Links section for URLs for the latest release notes.
Q: Does this update contain any enhancements or new functionality, or does it contain fixes / patches only?
A: There may be some enhancements or new functionality included in this update. Please refer to the Release Note for this update for more information.
Q: Can a code update be performed concurrently?
A: Yes, the code upgrade process is concurrent. Each node or node canister in the cluster will be upgraded independently, with an appropriate wait period in between each to allow for host multipath drivers to recover their paths.
Q: How can I be confident that the latest PTF updates have enough machine time to prove the code is robust?
A: Each PTF update is an incremental improvement on the previous PTF, rather than a completely new version of the code. A full and comprehensive suite of testing is performed on every PTF before it is released.
Q: Are there any specific upgrade path restrictions that I need to be aware of?
A: Please refer to the Concurrent Compatibility and Code Cross Reference page for details of supported upgrade paths. The URLs can be found in the Useful Links section below
Q: What is the Software Upgrade Test Utility?
A: This lightweight, fully concurrent utility will perform a check on the configuration and current code level of the system, and report on any known issues to be aware of before commencing the upgrade. This utility will not check the error log for any unfixed errors - this task should always be performed manually prior to commencing an upgrade.
Q: Is it important to have configured the system with SSH keys to allow for CLI access before starting the upgrade?
A: It is very important that SSH keys have been configured to provide CLI access, because in the event of an issue mid-upgrade, IBM Support may require access to CLI commands in order to resolve the issue.
Q: What should I be aware of if I am planning to perform a remote upgrade of a system in a dark site?
A: In the unlikely event of an issue during the software upgrade process, it may be necessary to perform a visual inspection of the hardware, or to perform a collection of debug data using a USB flash key. In extremely rare cases it may also be necessary to attach a keyboard and monitor to a SVC node.
Q: Is the FlashSystem/Storwize disk drive firmware updated during the standard upgrade process?
A: No, the FlashSystem/Storwize disk drive firmware is upgraded using a separate procedure, details of which can be found in the IBM Documentation for your product.
Q: Is the FlashSystem/Storwize expansion adapter and other hardware components firmware upgraded during the standard upgrade process?
A: Yes, these components will be upgraded as part of the standard upgrade process.
Q: Should I upgrade the FlashSystem/Storwize/SAN Volume Controller system first, or the host and fibre channel/ethernet switch code?
A: If your hosts and switches are at recent code levels then you should upgrade the FlashSystem, Storwize or SAN Volume Controller code first.
Q: How do I stay informed about known issues?
A: IBM will publish a Flash alert if a critical issue is discovered. All customers are strongly recommended to subscribe to the My Notifications service on the ibm.com website, to receive an email whenever a Flash alert or a new code level is published. See the Useful Links section for URLs to subscribe to this service.
Performing The Upgrade:
Q: How long will the upgrade process take?
A: A software upgrade will typically take between 10-20 minutes per node or node canister, with a 30 minute wait period after half of the node or node canisters have been upgraded, to allow for full multipath rediscovery. 2145-CF8 nodes are an exception and have been known to take up to two hours per node in extreme cases, so customers should make allowance in their upgrade schedules for this behaviour.
Q: Do I need to pay attention to anything during the code upgrade process?
A: As with any upgrade, the system should be monitored for upgrade progression and to enable action to be taken in the event of any errors being logged. In the event of any unexplained errors, please contact IBM Support for further assistance.
Q: What should I do if something goes wrong during the upgrade process?
A: If the upgrade process stalls for any reason, it is very easy to make the situation worse by attempting to perform recovery actions such as node reboots or removals. Please contact IBM immediately for assistance.
Q: Are there any known issues in this code release that could cause an impact during or after the upgrade?
A: IBM will publish Flash alerts for any critical issues in a particular code release. The Release Note for the code update will also list any known issues, including non-critical ones, for consideration before deciding to upgrade.
Q: What is the difference between a software and a firmware upgrade for FlashSystem/Storwize products?
A: The software upgrade process upgrades the storage virtualisation, clustering and advanced features engine on each of the cluster nodes. On occasion, a software upgrade package may also contain a number of firmware update packages for select hardware components (e.g. battery module driver code) which are applied as a background task after the software upgrade process has completed.
Firmware updates may sometimes take several hours to complete, for example due to batteries requiring conditioning cycles to be complete before their firmware can be applied, but this should not be cause for any concern as these updates only take place once the main software upgrade process has completed and the cluster is running in a fully operational and fully redundant state.
Q: Are there any configurations that are unsuitable for using the standard upgrade process?
A: Stretched SVC clusters consisting of four nodes, where two nodes exist in one geographical site and two in another and where volume mirroring is not being used, are susceptible to a race condition relating to rediscovery of backend storage that may result in the standard upgrade process becoming stalled and possibly needing to be aborted. IBM recommends upgrading SVC clusters in this configuration using the manual software upgrade procedure as documented in the online IBM Knowledge Center.
Useful Links:
- Check the ibm.com website for the latest available software release.
Refer to the Spectrum Virtualize Family of Products Upgrade Planning page for advice on choosing a release. - Ensure that all errors in the event log have been addressed via their associated Directed Maintenance Procedures and marked as fixed.
- Ensure that the system has been configured with SSH keys to provide CLI access.
- Run the Software Upgrade Test Utility (see Useful Links to download this utility).
- Ensure that all host multipathing drivers are at supported levels and are correctly configured.
- In the case of older Storwize and SVC systems, where nodes have been online for more than 6 months, consider performing a full reboot using the Service Assistant to identify any potential latent hardware issues prior to performing the upgrade. Leave at least 30 minutes between rebooting each node in an I/O Group to allow time for host multipathing drivers to failover and failback.
- Ensure there is sufficient filesystem space on each node to accept the upgrade package, by using the GUI to delete old upgrade packages from the /upgrade directory on each node.
Frequently Asked Questions:
Preparing For An Upgrade
Q: Is the upgrade procedure able to be run by customers?
A: Yes, the upgrade procedure is a relatively simple operation to perform, involving an upload of a code package and a small set of commands to commence the upgrade. Once begun, the upgrade procedure will automatically upgrade each node or node canister in the cluster separately, without the need for further user input.
Q: Which fixes are in the latest PTF update?
A: The list of fixes in the latest PTF update can be found in the Release Note. See the Useful Links section for URLs for the latest release notes.
Q: Does this update contain any enhancements or new functionality, or does it contain fixes / patches only?
A: There may be some enhancements or new functionality included in this update. Please refer to the Release Note for this update for more information.
Q: Can a code update be performed concurrently?
A: Yes, the code upgrade process is concurrent. Each node or node canister in the cluster will be upgraded independently, with an appropriate wait period in between each to allow for host multipath drivers to recover their paths.
Q: How can I be confident that the latest PTF updates have enough machine time to prove the code is robust?
A: Each PTF update is an incremental improvement on the previous PTF, rather than a completely new version of the code. A full and comprehensive suite of testing is performed on every PTF before it is released.
Q: Are there any specific upgrade path restrictions that I need to be aware of?
A: Please refer to the Concurrent Compatibility and Code Cross Reference page for details of supported upgrade paths. The URLs can be found in the Useful Links section below
Q: What is the Software Upgrade Test Utility?
A: This lightweight, fully concurrent utility will perform a check on the configuration and current code level of the system, and report on any known issues to be aware of before commencing the upgrade. This utility will not check the error log for any unfixed errors - this task should always be performed manually prior to commencing an upgrade.
Q: Is it important to have configured the system with SSH keys to allow for CLI access before starting the upgrade?
A: It is very important that SSH keys have been configured to provide CLI access, because in the event of an issue mid-upgrade, IBM Support may require access to CLI commands in order to resolve the issue.
Q: What should I be aware of if I am planning to perform a remote upgrade of a system in a dark site?
A: In the unlikely event of an issue during the software upgrade process, it may be necessary to perform a visual inspection of the hardware, or to perform a collection of debug data using a USB flash key. In extremely rare cases it may also be necessary to attach a keyboard and monitor to a SVC node.
Q: Is the FlashSystem/Storwize disk drive firmware updated during the standard upgrade process?
A: No, the FlashSystem/Storwize disk drive firmware is upgraded using a separate procedure, details of which can be found in the IBM Documentation for your product.
Q: Is the FlashSystem/Storwize expansion adapter and other hardware components firmware upgraded during the standard upgrade process?
A: Yes, these components will be upgraded as part of the standard upgrade process.
Q: Should I upgrade the FlashSystem/Storwize/SAN Volume Controller system first, or the host and fibre channel/ethernet switch code?
A: If your hosts and switches are at recent code levels then you should upgrade the FlashSystem, Storwize or SAN Volume Controller code first.
Q: How do I stay informed about known issues?
A: IBM will publish a Flash alert if a critical issue is discovered. All customers are strongly recommended to subscribe to the My Notifications service on the ibm.com website, to receive an email whenever a Flash alert or a new code level is published. See the Useful Links section for URLs to subscribe to this service.
Performing The Upgrade:
Q: How long will the upgrade process take?
A: A software upgrade will typically take between 10-20 minutes per node or node canister, with a 30 minute wait period after half of the node or node canisters have been upgraded, to allow for full multipath rediscovery. 2145-CF8 nodes are an exception and have been known to take up to two hours per node in extreme cases, so customers should make allowance in their upgrade schedules for this behaviour.
Q: Do I need to pay attention to anything during the code upgrade process?
A: As with any upgrade, the system should be monitored for upgrade progression and to enable action to be taken in the event of any errors being logged. In the event of any unexplained errors, please contact IBM Support for further assistance.
Q: What should I do if something goes wrong during the upgrade process?
A: If the upgrade process stalls for any reason, it is very easy to make the situation worse by attempting to perform recovery actions such as node reboots or removals. Please contact IBM immediately for assistance.
Q: Are there any known issues in this code release that could cause an impact during or after the upgrade?
A: IBM will publish Flash alerts for any critical issues in a particular code release. The Release Note for the code update will also list any known issues, including non-critical ones, for consideration before deciding to upgrade.
Q: What is the difference between a software and a firmware upgrade for FlashSystem/Storwize products?
A: The software upgrade process upgrades the storage virtualisation, clustering and advanced features engine on each of the cluster nodes. On occasion, a software upgrade package may also contain a number of firmware update packages for select hardware components (e.g. battery module driver code) which are applied as a background task after the software upgrade process has completed.
Firmware updates may sometimes take several hours to complete, for example due to batteries requiring conditioning cycles to be complete before their firmware can be applied, but this should not be cause for any concern as these updates only take place once the main software upgrade process has completed and the cluster is running in a fully operational and fully redundant state.
Q: Are there any configurations that are unsuitable for using the standard upgrade process?
A: Stretched SVC clusters consisting of four nodes, where two nodes exist in one geographical site and two in another and where volume mirroring is not being used, are susceptible to a race condition relating to rediscovery of backend storage that may result in the standard upgrade process becoming stalled and possibly needing to be aborted. IBM recommends upgrading SVC clusters in this configuration using the manual software upgrade procedure as documented in the online IBM Knowledge Center.
Useful Links:
- Spectrum Virtualize Release Notes
- 740_releasenotes.html
- 750_releasenotes.html
- 760_releasenotes.html
- 770_releasenotes.html
- 771_releasenotes.html
- 780_releasenotes.html
- 81_releasenotes.html
- 811_releasenotes.html
- 812_releasenotes.html
- 813_releasenotes.html
- 82_releasenotes.html
- 821_releasenotes.html
- 83_releasenotes.html
- 831_releasenotes.html
- 84_releasenotes.html
- 841_releasenotes.html
- 842_releasenotes.html
- Software Upgrade Test Utility
https://www.ibm.com/support/pages/node/651127 - Concurrent Compatibility and Code Cross Reference for Spectrum Virtualize
https://www.ibm.com/support/pages/node/5692850 - IBM Documentation products
https://www.ibm.com/docs/en/products - IBM Products Support Notifications
https://www.ibm.com/support/pages/node/688691
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"ST3FR7","label":"IBM Storwize V7000"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"Version Independent","Edition":"","Line of Business":{"code":"LOB26","label":"Storage"}},{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"STPVGU","label":"SAN Volume Controller"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"Version Independent","Edition":"","Line of Business":{"code":"LOB26","label":"Storage"}},{"Type":"MASTER","Line of Business":{"code":"LOB26","label":"Storage"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"STHGUJ","label":"IBM Storwize V5000"},"ARM Category":[{"code":"a8m0z000000bqPqAAI","label":"Documentation"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
28 March 2023
UID
ssg1S1004067