• Preetam Zare

NSX 6.4 Upgrade Process

Upgrading NSX with (()) cannot be made simpler than this. This is controlled and you can decided when and which component to upgrade. There are some terminology which are released as part of this feature

  1. Upgrade Unit

  2. Upgrade Group: Here you select clusters when you are in Plan Host Clusters section and when you are on Plan NSX Edges you get to choose Edges. Similiarly when you are Plan Service VMs page you get to select service VMs. In all these 3 sections you have following choices

Upgrade Group order: Parallel or serial. The order in which they should be upgraded i.e. Serial or parallel.

Create/Edit/Delete/Disable/Enable/Disable Upgrade group. The elements in the Upgrade group are available based on the tab you are.

In the upgrade you can select single unit (e.g. cluster/Edges/Service VMs) or multiple cluster. You can create Group and attach cluster to it. You can also select which group goes first using moveup and move down button.

  1. Upgrade Plan

  2. Upgrade Workflow

  3. Component Tier: Here you choose which components to upgrade. You can select all of them in Single Unit or select as per your requirements.

Each needs to be understood before you proceed to use this tool. But it is not very difficult to understand after you come to right point. I will cover/update these definition after some time.

Upgrade sequence as such has not changed. To repeat

First NSX Manager

Today this is not part of (()). So this is still manual but in the entire upgrade process NSX manager upgrade manager is the most simplest one.

Note: In Cross VC, you must upgrade primary and secondary controller first but before proceed to next step i.e. NSX Controllers upgrade

Second NSX Controllers

These controllers are upgraded as single task i.e. when you upgrade controllers, you cannot decide which one to upgrade first, it is tool which decides. And this is the reason it needs to do prechecks.

When you upgrade from 6.2 or earlier

If you are upgrade from 6.2 or earlier your controllers needs to be deleted. But thes are done automatically without any impact. The reason for this is, NSX controller OS starting 6.4 is getting replaced from Ubuntu to Photon. So this is rip and replace operation but behind the scene. In case of 6.3 and above, no change is required

Third ESXi Host's NSX VIBs

You upgrade NSX VIBs, here you must remember you must have DRS enabled. The host must be evacuated. Host evacuation is dependent on DRS. Most of us have DRS enabled but Host Affinity rules spoils the game. So keep this in mind. Other than that, there is nothing much to worry in this case

Fourth Universal DLR (When you have one deployed)

This is case when you have cross VC enabled. This component gets upgraded in parallel and not in serial. Similiarly same approach is configured for NSX Edges. Of course you can change this. But more details are required to be updated here.

It is worth note Universal DLR both in primary and secondary NSX environment are upgraded at the same time.

NSX Edges

Except for the fact that these are the last to get updated and these get updated in parallel these is not much to mention here. In case you do not know, Edges are always deleted and deployed as new appliance. To me it is not upgraded but rip and replace approach behind the scene. So in other words you always get new VMs. So it is always clean

Service VMs

These are introspection VMs. They get upgraded.


©2019 by virtual2Cloud. Proudly created with