For clustered controllers, updates that are pending are shown only on the primary controller. Therefore, firmware updates displayed on the peer controller do not include firmware updates for the primary controller.
Hardware updates are always applied in a completely safe manner. This means that the system may be in a state where hardware updates cannot be applied. This is particularly important in the context of clustered configurations. During takeover and failback operations, any in-progress firmware updates are completed, and any pending firmware updates are suspended until the takeover or failback has completed. Then the state restrictions are re-evaluated in the context of the new cluster state and, if possible, firmware updates resume.
![]() | Caution - Do not perform takeover or failback operations while firmware updates are in progress. |
The rolling update procedure for clustered controllers meets all of the following best practices and addresses the per-device-class restrictions. It should always be followed when performing updates in a clustered environment. In both clustered and standalone environments, these criteria are also re-evaluated upon any reboot or diagnostic system software restart, which may cause previously suspended or incomplete firmware updates to resume. For more information, see Upgrading Software on Clustered Controllers.
Components internal to the storage controller (such as HBAs and network devices) other than disks and certain SAS devices are generally upgraded automatically during a reboot. These updates are not visible and will have completed by the time the management interfaces become available.
Updating disk or flash device firmware causes the device to be taken offline during the process. If there is insufficient redundancy in the containing storage pool to allow this operation, the firmware update will not complete and may appear "stalled". However, if the storage pools are in an exported state, the disks will update as expected. Disks and flash devices that are part of a storage pool which is currently in use by the cluster peer, if any, are not upgraded.
Updating disk shelf firmware requires that both back-end storage paths be active to all disks within all disk shelves, and for storage in all shelves to be configured. For clusters with at least one active pool on each controller, these restrictions mean that disk shelf firmware updates can be performed only by a controller that is in the owner state. For more information, see Cluster Takeover and Failback in Oracle ZFS Storage Appliance Administration Guide, Release OS8.8.0.