Jump Upgrading to Ops Manager v3.0
Page last updated:
This topic describes upgrading to VMware Tanzu Operations Manager (Ops Manager) v3.0 or later directly from Ops Manager v2.5 and later.
Jump upgrading describes the process of skipping minor versions when upgrading Ops Manager. Jump upgrading enables you to upgrade directly to the latest version of Ops Manager, which is v3.0.
Before you jump upgrade to Ops Manager v3.0 or later:
If you are using Ops Manager v2.10.8 or earlier, you must complete any in-progress CA rotation before you can jump upgrade. Failure to complete the CA rotation results in the inability to Apply Changes due to safety violations.
If you are on Ops Manager v2.4 or earlier, you must do standard upgrades for each version up to v2.5 before you can jump upgrade to v3.0.
To upgrade to Ops Manager v3.0, you must ensure that the products you have installed are compatible with Ops Manager v3.0. To create an upgrade path for your product tiles, see the Upgrade Planner.
You must have no changes to any product tile or service instance currently staged.
If you are using vSphere with NSX-T, you must have NSX-T v2.3 or later installed.
In Ops Manager v2.10.9 and later, BOSH DNS leaf certificates are generated to include the subject alternative name (SAN) field. This migration process is required before you upgrade to Ops Manager v2.10.33 and later. If you do not complete this migration before upgrading to v2.10.33 or later, you might experience unexpected BOSH DNS resolution issues until the change is rolled out to all VMs.
When you upgrade to v2.10.9 or later, the BOSH DNS leaf certificates are automatically regenerated to include the SAN field on the next Apply Changes.
To allow DNS certificate regeneration and avoid communication issues between system components:
Run the Upgrade service instances errand on all service tiles.
Apply Changes to all tiles.
After you ensure your deployment meets the requirements described in Prerequisites above, you can upgrade to Ops Manager to v3.0 or later.
To jump upgrade to Ops Manager to v3.0 or later:
Review the table in Breaking Changes below and address any breaking changes that apply to your current Ops Manager version.
Follow the procedure in Upgrading Ops Manager.
The table below describes the breaking changes that affect Ops Manager v2.5 through v2.9 and how to address them before upgrading:
|Upgrading From||Breaking Change||Action Before Upgrading|
|Any prior to v2.10.33||For Ops Manager v2.10.9 and later, BOSH DNS leaf certificates are generated to include the subject alternative name (SAN) field. If you do not distribute the BOSH DNS leaf certificates to all VMs, you can experience downtime caused by communication issues between system components.||When upgrading to Ops Manager v2.10.9 or later, run the Upgrade service instances errand on all service tiles and Apply Changes to all tiles. For more information, see BOSH DNS Certificates Regeneration above|
|v2.5||You can only SSH onto the Ops Manager VM in a vSphere deployment with a private SSH key, not a password. You could get an error when authenticating that causes Ops Manager to shut down and enter a reboot loop.||Add a public key to the OVF template for the Ops Manager VM. Then, use the private key to SSH onto the Ops Manager VM. For more information, see Deploy Ops Manager in Deploying Ops Manager on vSphere.|
||Update any automation scripts that use the
||Update your automation scripts that use the
|v2.5||Trusty stemcells 3541 and earlier are no longer supported. If your deployment is on AWS and using outdated stemcells, Ops Manager fails to boot.||Install Xenial stemcells or Trusty stemcell 3586 or later. For more information, see AWS Deployments Use 5th Generation Instances in Ops Manager v2.6 Release Notes.|
|v2.5 and v2.6||The
||Update your automation scripts to use the
|v2.5 and v2.6||Ops Manager v2.10 installs a later version of the BOSH CLI. This could cause your BOSH CLI automation scripts to stop working.||Update your automation scripts to use BOSH CLI v2. For more information, see Installing the CLI and Commands in the BOSH documentation.|
|v2.5 and v2.6||Certain properties within a collection or selector are no longer configurable in the Ops Manager UI and API.||Update your automation scripts to remove these properties. For more information about the tile properties you can configure in Ops Manager v2.10.2, see the release notes for that tile.|
|v2.5 and v2.6||The
||Update your automation scripts to use the appropriate properties for your deployment. For more information, see Configuring resources for a job in the Ops Manager API documentation.|
|v2.5, v2.6, and v2.7||If TLS is not enabled before upgrade and Windows stemcells are in use, Apply Changes can fail. Ops Manager enables TLS by default when an internal blobstore is configured.||Enable the internal blobstore TLS on the Director Config pane under the BOSH Director tile. To re-create all Windows-based VMs, do one of the following:
|v2.5, v2.6, v2.7, and v2.8||Ops Manager v2.9 is incompatible with vSphere Data Center NSX-T v2.2 and earlier.||Upgrade to NSX-T v2.3 or later. For more information, see Ops Manager v2.9 Incompatible with vSphere Data Center NSX-T v2.2 and Earlier in Ops Manager v2.9 Release Notes.|
|v2.8 and v2.9||Ops Manager v2.10 includes CredHub Maestro v8.0. In this version of CredHub Maestro, the `maestro update-transitional latest` command is removed.||If you have scripts that rely on the `maestro update-transitional latest` command, remove references to the command before you upgrade to Ops Manager v3.0. In CredHub Maestro v8.0, you run `maestro regenerate ca` to regenerate a certificate authority (CA) and mark the latest version of the CA as transitional. This command performs both actions, while previous versions of CredHub Maestro use a separate command for each task.|
For breaking changes between Ops Manager v2.10 and v3.0, see Breaking Changes in Ops Manager v3.0.