The NSX upgrade process can take some time, especially when upgrading ESXi hosts, because hosts must be rebooted. It is important to understand the operational state of NSX components during an upgrade, such as when some but not all hosts have been upgraded, or when NSX Edges have not yet been upgraded. VMware recommends that you run the upgrade in a single outage window to minimize downtime and reduce confusion among NSX users who cannot access certain NSX 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 deployment upgrade proceeds as follows:

NSX Manager —> NSX Controller Cluster —> NSX Host Clusters —> NSX Edges

NSX Manager Upgrade

During:

NSX Manager Configuration is blocked. The NSX API service is unavailable. No changes to
the NSX configuration can be made. Existing VM communication continues to function. NewVM provisioning continues to work in vSphere, but the new VMs cannot be connected to NSX logical switches during the NSX Manager upgrade.

After:

All NSX configuration changes are allowed. At this stage, if any new NSX Controllers are
deployed, they will boot with the old version until the existing NSX Controller cluster is
upgraded. Changes to the existing NSX 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, those are unavailable for configuration (greyed out) in the user interface until all hosts are upgraded.

NSX Controllerr Cluster Upgrade

During:

• 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.
• During the upgrade, when there is a temporary non-majority state, existing virtual machines do not lose networking.
• New logical network creation is automatically blocked during the upgrade.
• Do not allow dynamic routes to change during the upgrade.

After:

• Configuration changes are allowed. New logical networks can be created. Existing logical networks continue to function.

NSX Host Upgrade

During:

• Configuration changes are not blocked on NSX Manager. Upgrade is performed on a per-cluster basis. If DRS is enabled on the cluster, DRS manages the upgrade order of the hosts. Adds and changes to logical network are allowed. The host currently undergoing upgrade is in maintenance mode. Provisioning of new VMs continues to work on hosts that are not currently in maintenance mode.

When some NSX hosts in a cluster are upgraded and others are not:

• NSX Manager Configuration changes are not blocked. Controller-to-host communication is backward compatible, meaning that upgraded controllers can communicate with non-upgraded hosts. Additions and changes to logical networks are allowed. Provisioning new VMs continues to work on hosts that are not currently undergoing upgrade. Hosts currently undergoing upgrade are placed in maintenance mode, so VMs must be powered off or evacuated to other hosts. This can be done with DRS or manually.

 

NSX Edge Upgrade

NSX Edges can be upgraded without any dependency on the NSX Controller or host upgrades. You can upgrade an NSX Edge even if you have not yet upgraded the NSX Controller or hosts.

During:

• 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:

• Configuration changes are not blocked. Any new features introduced in the NSX upgrade will not be configurable until all NSX Controllers and all host clusters have been upgraded to NSX version 6.2.x.
• L2 VPN must be reconfigured after upgrade.
• SSL VPN clients must be reinstalled after upgrade

Guest Introspection Upgrade

During an NSX upgrade, the NSX UI prompts you to upgrade Guest Introspection service.

 During:

• There is a loss of protection for VMs in the NSX cluster when there is a change to the VMs, such as VM additions, vMotions, or deletions.

After:

• VMs are protected during VM additions, vMotions, and deletions.

————————————————————————–

Verify the NSX Working State Before beginning and after the upgrade:

Before beginning the upgrade, it is important to test the NSX working state. Otherwise, you will not be able to determine if any post-upgrade issues were caused by the upgrade process or if they preexisted the upgrade process. Do not assume everything is working before you start to upgrade the NSX infrastructure. Make sure to check it first.

 Procedure

1. Note the current versions of NSX Manager, vCenter Server, ESXi and NSX Edges.

2. Identify administrative user IDs and passwords.

3. Verify you can log into the following components:

• vCenter Server
• NSX Manager Web UI
• Edge services gateway appliances
• Distributed logical router appliances
• NSX Controller appliances

• Verify that VXLAN segments are functional.

Make sure to set the packet size correctly and include the don’t fragment bit.

• Ping between two VMs that are on same logical switch but on two different hosts.
  1. From a Windows VM: ping -l 1472 –f <destVM>
  2. From a Linux VM: ping -s 1472 –M do <destVM>

• Ping between two hosts’ VTEP interfaces.
  • ping ++netstack=vxlan -d -s 1572 Notђ To get a host’s VTEP IP, look up the vmknicPG IP address on the host’s Manage > Networking > Virtual Switches page.

• Validate North-South connectivity by pinging out from a VM.

• Visually inspect the NSX environment to make sure all status indicators are green/normal/deployed.

1. Check Installation > Management.
2. Check Installation > Host Preparation.
3. Check Installation > Logical Network Preparation > VXLAN Transport.
4. Check Logical Switches.
5. Check NSX Edges.

• Record BGP and OSPF states on the NSX Edge devices

1. show ip ospf neighbor
2. show ip bgp neighbor
3. show ip route

• If possible, in the pre-upgrade environment, create some new components and test their functionality.

1. Create a new logical switch.
2. Create a new edge services gateway and a new distributed logical router.
3. Connect a VM to the new logical switch and test the functionality.

• Validate netcpad and vsfwd user-world agent (UWA) connections.

• On an ESXi host, run esxcli network vswitch dvs vmware vxlan network list –vds-name=<vds-name> and check the controller connection state.
• On NSX Manager, run the show tech-support save session command, and search for “5671” to ensure that all hosts are connected to NSX Manager.

• (Optional) If you have a test environment, test the upgrade and post-upgrade functionality before upgrading a production environment.