NSX-v Edge only upgrade with OVF replacement in the same NSX-v release

Products

• VMware NSX

Issue/Introduction

Requirements:
Customer needs to do this in a maintenance window
Verify Edge build is provided for same release (Build # and link provided to download Edge binary in an URL)
Edge redeployment is required to get new edge build #
Root access to NSX Manager is required

Symptoms:
Upgrade steps for Edge OVF binaries in customer environment.

Resolution

Upgrade procedure:

1. First login to NSX Manager as root and SCP the edge OVF tar.gz file to /tmp

Example: nsx-edge-ovf-12481983.tar.gz

2. From root access, take a backup of current Edge binaries to /tmp

# cd /common/em/component/edge/trinity
(using * for all files)
# tar -zcvf /tmp/backup-nsx-edge.tar.gz  *

3. Check backup is successful in /tmp and can remove all Edge files from /common/em/component/edge/trinity

• # rm /common/em/component/edge/trinity/*

4. Copy the new Edge OVF tar.gz to /common/em/component/edge/trinity

# cp /tmp/nsx-edge-ovf-########.tar.gz /common/em/component/edge/trinity
(######## = build number)

5. Untar the Edge OVF in /common/em/component/edge/trinity directory

# cd /common/em/component/edge/trinity
# tar -xvzf nsx-edge-ovf-########.tar.gz

6. Change the files in /common/em/component/edge/trinity for owner/group to 'secureall'

• # chown secureall:secureall *

Check (ls -al) new files extracted properly from the above operation in /common/em/components/edge/trinity directory and owner is ‘secureall’. To check Edge uses newly copied build ########, try to deploy a new Edge appliance to test the deployment goes successful with new files.

7. Once deployment is successful you can delete the tar.gz files in the /tmp and /common/em/components/edge/trinity/

• # rm /common/em/components/edge/trinity/nsx-edge-ovf-*.tar.gz
• # rm /tmp/nsx-edge-ovf-*.tar.gz

8. Now proceed to redeploy all the edge to new build-######## from vCenter UI. Verify from UI all Edges are upgraded to new build-########.

      9) Remove old Edge file backup created in /tmp/
# rm /tmp/backup-nsx-edge.tar.gz 

Additional Information

Impact/Risks:
The approach listed here cannot be used in below cases:

a. For upgrading the edge to next major version/minor version.
 * Like if versions are changing from 6.2.2 to 6.4.4
 * Like if versions are changing from 6.3.2 to 6.4.4
 * Like if versions are changing from 6.4.2 to 6.4.4

b. It’s not advisable to use it to upgrade to next patch version. If it’s done, it should be fully validated in lab.
  * Like if versions are changing from 6.4.3 to 6.4.4

It should be only used for hotpatch application where it is known that only Edge OVFs have changed and no other components are changed. For example in 6.4.4a Hotpatch only Edge changes are there. So when upgrading from 6.4.4 to 6.4.4a it can be used. However, this approach must not be used when upgrade to 6.4.4a from any other patch release like 6.4.2 or 6.3.4 etc.

c. It must not be used for downgrade of edge.
  * If NSX Manager is 6.4.4, OVF must not be replaced to any older versions.
  * It could lead to new deployment, HA enablement or redeploy failures due to version mismatch depending upon what services are configured on edge. And the errors should will be not user friendly. It could fail with "Config failed on edge" or syntax errors on edge side.

d. After OVFs are replaced, reboot of NSX Manager is required before any edge operations so that right build versions are reflected in internal caches. Which gets updated on NSX manager reboot