The duration for the NSX upgrade process depends on the number of components you have to upgrade in your infrastructure. It is important to understand the operational state of NSX components during an upgrade.

The upgrade process is as follows:

NSX Edge cluster > Hosts > Management plane.

Starting NSX 4.0.1.1, you have the flexibility to change the order of upgrade for your edge clusters and hosts. You can alternate between groups of hosts and groups of edge nodes during upgrade. The NSX Manager is upgraded only after all the edges and hosts have been upgraded.

NSX Edge Cluster Upgrade

During Upgrade After Upgrade
  • During the NSX Edge upgrade, you might experience the following traffic interruption:
    • North-south datapath is affected if the NSX Edge is part of the datapath.
    • East-west traffic between tier-1 routers using NSX Edge firewall, NAT, or load balancing.
    • Temporary Layer 2 and Layer 3 interruption.
  • Configuration changes are not blocked on NSX Manager but might be delayed.
  • Configuration changes are allowed.
  • Upgraded NSX Edge cluster is compatible with the older versions of the Management plane and the hosts.
  • New features introduced in the upgrade are not configurable until the Management plane is upgraded.
  • Run post checks to make sure that the upgraded NSX Edge cluster and NSX do not have any problems.

Hosts Upgrade

During Upgrade After Upgrade
  • For standalone ESXi hosts or ESXi hosts that are part of a disabled DRS cluster, place hosts in maintenance mode.

    For ESXi hosts that are part of a fully automated DRS cluster, if the host is not in maintenance mode, the upgrade coordinator requests the host to be put in maintenance mode. The vSphere DRS tool migrates the VMs to another host in the same cluster during the upgrade and places the host in maintenance mode.

  • For ESXi host, for an in-place upgrade you do not need to power off the tenant VMs.
  • During an in-place upgrade:
    • For VMs attached to an NSX logical switch or VMs connected to the distributed portgroup of a VDS prepared for NSX for vSphere, vmotion of VMs is not supported from and to the host on which an upgrade is in progress.
    • Creating new VMs is also not supported on hosts on which an upgrade is in progress.
    Note: NSX In-place Upgrade for vSphere Lifecycle Manager baseline clusters is supported with VMware Cloud Foundation 5.2.1 and later. For more information, refer to "Upgrade NSX for VMware Cloud Foundation 5.2.x" in the VMware Cloud Foundation Lifecycle Management guide.
  • Configuration changes are allowed on NSX Manager.
  • You may experience brief disruption in traffic during in-place upgrade of the ESXi hosts. For critical applications that cannot handle packet loss, maintenance mode upgrade is recommended.
  • Power on or return the tenant VMs of standalone ESXi hosts or ESXi hosts that are part of a disabled DRS cluster that were powered off before the upgrade.
  • New features introduced in the upgrade are not configurable until the Management plane is upgraded.
  • Run post checks to make sure that the upgraded hosts and NSX do not have any problems.

Limitations on In-Place Upgrade

For ESXi hosts with version 7.0 and later, when upgrading from NSX 3.2 or later, in-place upgrade is not supported in the following scenarios:

  • You are upgrading a vLCM-enabled cluster.
  • More than 1000 vNICs are configured on the ESXi host and the VM's vNICs connect to a single VDS. If the host has multiple VDS for NSX, this vNIC limit is per VDS.
  • Layer 7 firewall rules or Identity Firewall rules are enabled.
  • Service Insertion has been configured to redirect north-south traffic or east-west traffic. See Security in the NSX Administration Guide for information on uninstalling service insertion.
  • A VProbe-based packet capture is in progress.
  • The nsx-cfgagent service is not running on the host.
  • IDS/IPS or distributed malware prevention is enabled for your NSX environment.

For ESXi hosts with versions earlier than 7.0, in-place upgrade of a host is not supported in the following scenarios:

  • You are upgrading a vLCM-enabled cluster.
  • More than one N-VDS switch is configured on the host.
  • More than 1000 vNICs are configured on the ESXi host and the VM's vNICs connect to a single VDS. If the host has multiple VDS for NSX, this vNIC limit is per VDS.
  • ENS is configured on the host N-VDS switch.
  • vSAN(with LACP) is configured on the host N-VDS switch.
  • Layer 7 firewall rules or Identity Firewall rules are enabled.
  • VMkernel interface is configured on the overlay network.
  • Service Insertion has been configured to redirect north-south traffic or east-west traffic. See Security in the NSX Administration Guide for information on uninstalling service insertion.
  • A VProbe-based packet capture is in progress.
  • IDS/IPS or distributed malware prevention is enabled for your NSX environment.
For vSAN clusters:
  • NSX in-place upgrade does not check vSAN health. The absence of a check means that in the event of a failure, you may experience a breach of vSAN FTT and/or some data loss.
  • When upgrading to NSX 4.1.0 using in-place upgrade, serial upgrade within the cluster is recommended.
  • When upgrading to NSX 4.1.1 and later using in-place upgrade, serial upgrade within the cluster is required.

Management Plane Upgrade

During Upgrade After Upgrade
When upgrading from NSX 3.2, or 3.2.0.1:
  • Do not make any configuration changes during the Management plane upgrade.
  • API service is momentarily unavailable.
  • User interface is unavailable for a short period.
  • Configuration changes are allowed.
  • New features introduced in the upgrade are configurable.
  • You need a valid license to use licensed features like T0, T1, Segments, and NSX intelligence.
  • From the Upgrade Coordinator, verify that the upgrade process has completed. Perform configuration tasks only after the upgrade process is complete.