The NSX for vSphere upgrade process can take some time. It is important to understand the operational state of components during an upgrade, such as when some but not all hosts have been upgraded, or when NSX Edges have not yet been upgraded.
You should upgrade all NSX for vSphere components in a single outage window to minimize downtime and reduce confusion among NSX users who cannot access certain management functions during the upgrade. However, if your site requirements prevent you from completing the upgrade in a single outage window, the information below can help your NSX users understand what features are available during the upgrade.
An NSX for vSphere deployment upgrade proceeds as follows:
NSX Manager —> NSX Controller Cluster —> Host Clusters —> Distributed Logical Routers —> Guest Introspection
Edge Services Gateways can be upgraded at any time after the NSX Manager upgrade.
Before you start the upgrade, read Preparing for the NSX Upgrade and the NSX for vSphere Release Notes for detailed information about upgrade prerequisites and upgrade known issues.
NSX Manager Upgrade
Planning the NSX Manager upgrade:
In a cross-vCenter NSX environment, you must upgrade the primary NSX Manager first, and then upgrade secondary NSX Managers.
In a cross-vCenter NSX environment you must upgrade all NSX Managers in the same maintenance window.
Impact during the NSX Manager upgrade:
NSX Manager configuration using the vSphere Web Client and API is blocked.
Existing VM communication continues to function.
New VM provisioning continues to work in vSphere, but the new VMs cannot be connected to or disconnected from logical switches during the NSX Manager upgrade.
During the NSX Manager upgrade in a cross-vCenter NSX environment, do not make any changes to universal objects until the primary and all secondary NSX Managers are upgraded. This includes create, update, or delete of universal objects, and operations involving universal objects (for example, apply a universal security tag to a VM).
After the NSX Manager upgrade:
All NSX configuration changes are allowed.
At this stage, if any new NSX Controller appliances are deployed, they will be deployed with the version matching the existing NSX Controller cluster until the NSX Controller cluster is upgraded.
Changes to the existing configuration are allowed. New logical switches, logical routers, and edge service gateways can be deployed.
For distributed firewall, if new features are introduced after the upgrade, you cannot use them until all hosts are upgraded.
Depending on the NSX for vSphere release, once the NSX Manager has been upgraded, the Communication Channel Health status will display as Unknown for the control plane. You must complete the controller and host upgrades to see a status of Up.
NSX Controller Cluster Upgrade
Planning the NSX Controller upgrade:
You can upgrade the NSX Controller cluster after NSX Manager is upgraded.
In a cross-vCenter NSX environment, you must upgrade all NSX Managers before upgrading the NSX Controller cluster.
VMware highly recommends upgrading the NSX Controller cluster in the same maintenance window as the NSX Manager upgrade.
Impact during the NSX Controller upgrade:
Logical network creation and modifications are blocked during the upgrade process. Do not make logical network configuration changes while the NSX Controller cluster upgrade is in progress.
Do not provision new VMs during this process. Also, do not move VMs or allow DRS to move VMs during the upgrade.
Do not allow dynamic routes to change during the upgrade.
If you are upgrading from NSX 6.3.3 or later, existing virtual machines do not lose networking during the controller upgrade.
If you are upgrading from NSX 6.3.2 or earlier, north-south layer 3 traffic experiences a brief outage while routes are synchronized by the controllers.
After the NSX Controller upgrade:
Configuration changes are allowed.
Planning the host cluster upgrade:
You can upgrade host clusters after NSX Managers and the NSX Controller cluster are upgraded.
You can upgrade your host clusters in a separate maintenance window from the NSX Manager and NSX Controller cluster upgrades.
You do not need to upgrade all host clusters in the same maintenance window. However, if Distributed Firewall is enabled, there is a limitation on migrating VMs between clusters with different NSX for vSphere versions:
Migrating VMs from clusters with a later version to clusters with an earlier version might cause the VMs to lose network connectivity.
Migrating VMs from clusters with an earlier version to clusters with a later version is supported.
New features of the NSX for vSphere version installed on NSX Manager appear in the vSphere Web Client and the API, but might not function until the host VIBs are upgraded.
To take advantage of all the new features of an NSX for vSphere release, upgrade the host clusters so that the host VIBs match the NSX Manager version.
Impact during the host cluster upgrade:
Configuration changes are not blocked on NSX Manager.
Controller-to-host communication is backward compatible, meaning that upgraded controllers can communicate with non-upgraded hosts.
Upgrade is performed on a per-cluster basis. If DRS is enabled on the cluster, DRS manages the upgrade order of the hosts.
Hosts currently undergoing upgrade must be placed in maintenance mode, so VMs must be powered off or evacuated to other hosts. This can be done with DRS or manually.
Additions and changes to logical network are allowed.
Provisioning of new VMs continues to work on hosts that are not currently in maintenance mode.
NSX Edge Upgrade
Planning the NSX Edge upgrade:
You can upgrade NSX Edges in separate maintenance windows from other components.
You can upgrade Logical Routers after NSX Managers, NSX Controller cluster, and host clusters are upgraded.
You can upgrade an Edge Services Gateway even if you have not yet upgraded the NSX Controller cluster or host clusters.
You do not need to upgrade all NSX Edges in the same maintenance window.
If an upgrade is available for NSX Edge but you have not upgraded, changing size, resources, datastore, enabling advanced debugging, and enabling HA on the appliance will be blocked until the NSX Edge is upgraded.
In a cross-vCenter NSX environment, upgrade the universal distributed logical routers (UDLR) from the primary NSX Manager. The UDLRs associated with the secondary NSX Manager are upgraded automatically.
Impact during the NSX Edge upgrade:
On the NSX Edge device currently being upgraded, configuration changes are blocked. Additions and changes to logical switches are allowed. Provisioning new VMs continues to work.
Packet forwarding is temporarily interrupted.
In NSX Edge 6.0 and later, OSPF adjacencies are withdrawn during upgrade if graceful restart is not enabled.
After the NSX Edge upgrade:
Configuration changes are not blocked.
Guest Introspection Upgrade
Planning the Guest Introspection upgrade:
You can upgrade Guest Introspection after NSX Managers, NSX Controller cluster, and host clusters are upgraded.
See the partner documentation for partner solution upgrade information.
Impact during the Guest Introspection upgrade:
There is a loss of protection for VMs in the cluster when there is a change to the VMs, such as VM additions, vMotions, or deletions.
After the Guest Introspection upgrade:
VMs are protected during VM additions, vMotions, and deletions.