Upgrading by using OS reload

To upgrade your vSRX by using OS reload, follow these steps:

Stand-alone environment only: Export the vSRX configuration.
Access the gateway details page.
Run a Readiness check for “Version upgrade” and address any errors that are found.

Run your readiness check well before the actual upgrade maintenance to ensure that any outstanding access and configuration requirements are addressed before the upgrade maintenance. Also run another readiness check immediately before the maintenance action, as readiness checks expire after 5 hours.
Perform an OS reload for each bare metal server.

When you upgrade an HA cluster, the process automatically powers off the node not undergoing the OS reload (the first node in the cluster) at the end of the upgrade process. This transitions the cluster’s primary node and any active network traffic to the newly upgraded one from the second node in the cluster. It is critical that the second node in the cluster (the one not undergoing the OS reload) is left unpowered until the process to upgrade the first node in the cluster is submitted and running. Powering on the node before the OS reload causes the cluster to run with mismatched vSRX versions, potentially leading to a “split-brain” scenario where each node tries to claim primary ownership. This generally results in an outage. After the OS reload of the first node completes, the gateway transitions to “Upgrade Active” status.
Stand-alone environment only: Import the vSRX configuration and migrate the settings to the new architecture if necessary.

vSRX configuration migration considerations

For a High Availability environment, the upgrade restores the previous vSRX configuration. No further steps are needed.

For a stand-alone environment, the upgrade does not restore the previous configuration, so you should export and import your configuration. Refer to Importing and exporting a vSRX configuration for more information.

Also, when you migrate from an older version, such as 15.1, your interface mappings might have changed. This requires some modifications to the vSRX configuration after the import. Refer to Migrating 1G vSRX stand-alone configurations for more information.