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:

  1. Stop the standby node
  2. Deploy a new 8.x based virtual machine as standby.
  3. Configure the original standby IP and machine name to be the same as the former standby in the boot parameters.
  4. Set licenses and entitlements to be the same as the former standby.
  5. Perform an acquire-config from the active 7.x based node.
  6. Once it is in sync, fail over and repeat for the other VM.