Upgrade Information
This section provides key information about upgrading to this software version.
When upgrading to this release from a release older than the previous release, read all intermediate Release Notes documents for notification of incremental changes. See the Upgrade Information in this document's Introduction chapter for upgrade paths to S-CZ8.2.5.
Supported Upgrade Paths - Hitless
The following in-service (hitless) upgrade and rollback paths are supported by the OCCSM. For hitless upgrades from version 8 software to version 8 software, ensure that you have the configured number of F cores set to 1, and D cores set to zero:
- For VMWare, the OCCSM supports
the following hitless upgrade and rollback paths:
- S-CZ7.3.5 to S-CZ8.2.5m1
- S-CZ8.2.5p2 to S-CZ8.2.5m1
- S-CZ8.2.5p3 to S-CZ8.2.5m1
- S-CZ8.2.5p4 to S-CZ8.2.5m1
- For KVM, Hyper-V or XEN platforms, the OCCSM
supports the following hitless upgrade and rollback paths:
- S-CZ8.2.5p2 to S-CZ8.2.5m1
- S-CZ8.2.5p3 to S-CZ8.2.5m1
- S-CZ8.2.5p4 to S-CZ8.2.5m1
Supported Upgrade Paths - Non-Hitless
Upgrade paths differ based on platform:
- For KVM, Hyper-V or XEN platforms, the OCCSM supports the following
non-hitless upgrade and rollback paths:
- S-CZ7.3.5 to S-CZ8.2.5m1
- S-CZ8.2.5 to S-CZ8.2.5m1—Rollback is not hitless
- S-CZ8.2.5p1 to S-CZ8.2.5m1—Rollback is not hitless
You cannot upgrade a KVM, Hyper-V or XEN-based OCCSM virtual machine from S-CZ7.3.5 release to S-CZ8.2.5 because the platform code does not support an in-place upgrade of a virtual machine hard disk from one OS version to another. This is due to bootloader support, as follows:- 7.x is based on OL6 and uses grub bootloader
- 8.x is based on OL7 and uses grub2 bootloader
Follow these steps to perform these non-hitless upgrades:- Stop the standby node
- Deploy a new 8.x based virtual machine as standby.
- Configure the original standby IP and machine name to be the same as the former standby in the boot parameters.
- Set licenses and entitlements to be the same as the former standby.
- Perform an acquire-config from the active 7.x based node.
- Once it is in sync, fail over and repeat for the other VM.