PDITC
Contributor
Contributor

Upgrading NSX-T 3.1.3 to version 3.2.2

Jump to solution

We are considering upgrading NSX-T 3.1.3 to version 3.2.2. Currently we are using an N-VDS to run our workloads on VLAN backed segments. What issues could I run into with this upgrade?

0 Kudos
1 Solution

Accepted Solutions
JaSo2
Enthusiast
Enthusiast

Nope - N-VDS is still supported in 3.2.2 version, it is not supported starting with 4.0.0.1.

View solution in original post

8 Replies
MeenaJ
Contributor
Contributor

If you are using Federation I would definitely not upgrade. There is a pretty serious bug in Global Manager failover. 

prashantpandey1
VMware Employee
VMware Employee

I feel there is no specific answer to this query, best practice is to go though the upgrade guide, which majorly includes

 

1. Prechecks about interoperability. 

2. Going though the target version's known issues & release notes.

 

https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/upgrade/GUID-E35506A7-8050-482A-BABA-F356D2A...

JaSo2
Enthusiast
Enthusiast

I have done this upgrade just recently (on similar configuration which was even in the older Manager API / mode) and it went fine.

(Migrating N-VDS to VDS on that particular infra was completely different story though :), but that's not your case.)

 

Of course follow instructions from Prashant (Interop, RN check and follow the Upgrade guide 🙂 - I have done every 3.2 upgrade with the help of NSX Upgrade Evaluation tool, to be sure the DB is ready, but you can check that in the Upgrade guide / docs).

0 Kudos
ssupraja
VMware Employee
VMware Employee

1. As part of the upgrade process, please plan to migrate Host Switch to VDS (i.e N-VDS to VDS), since N-VDS is not anymore supported with the 3.2.2 version. 

https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.0/administration/GUID-1039A36F-F55E-4A0A-B6C6-...

2. Perform Prechecks through the Evaluation tool 

- Ensure that your transport node profiles have the appropriate transport zones added to them.NSX Manager may not display the list of       transport node profiles if any of the transport node profiles do not have transport zones added to them
- Ensure that you backup the Manager before you start the upgrade process
- Ensure that your host OS is supported, for NSX Manager.
- Disable automatic backups before you start the upgrade process.
- Terminate any active SSH sessions or local shell scripts that may be running on the NSX Manager or the NSX Edge nodes, before you begin the upgrade process.
- Delete all expired user accounts before you begin the upgrade. Upgrade for NSX-T Data Center on vSphere fails if your exception list for vSphere lockdown mode includes expired user accounts. 
 

3. Check the supported upgrade paths and also interoperability with other solutions.

https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/upgrade/GUID-FAFED150-0652-4B7D-9B5E-5F655C2...

 

 

0 Kudos
JaSo2
Enthusiast
Enthusiast

Nope - N-VDS is still supported in 3.2.2 version, it is not supported starting with 4.0.0.1.

PDITC
Contributor
Contributor

Thank you all for the great info. The upgrade went well, the only issue was that the managers took some time to display the configuration in the GUI. After the upgrade it looked like the compute manager, policies, and other items disappeared... but after about an hour or so things looked normal again.

0 Kudos
PDITC
Contributor
Contributor

Migrating back to VDS is our next step JaSo2 ... what issues did you run into during the migration to VDS?

Tags (1)
0 Kudos
JaSo2
Enthusiast
Enthusiast

Basically there are 3 ways how to do it:

  • GUI
  • CLI (from Manager node)
  • API

GUI - I have crossed out this options even in testing phase (lab) - did not work properly for me.

CLI can be ok, but there is a big BUT. For the migration the process is more or less about preparing a VDS according to N-VDS configuration, preparing uplink profile, putting host to MM, migrate the host to VDS and taking it out of MM. The problem is in putting the host to MM - there is a default timer of 300 seconds and if the host is not in MM by that time it moves to next host and it does not care about the state of the cluster from the resource perspective. There is a possibility to prolonger this timer with option maintenance-timeout like "vds-migrate esxi-cluster-name cluster maintenance-timeout 60", but I simply do not like the fact how it works.

I really recommends the API way - it is semi manual - you have to put the host to MM and take it out, but it is much more controlled by you and it have some other possibilities like renaming VDS to a name corresponding with your naming convention at the time of its creation.
Other then that what I have noticed - the NVDS should have the same exact configuration at each host (e.g. LLDP disabled / enabled everywhere), otherwise multiple VDS will be created (but that is noted in the documentation - https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/administration/GUID-1039A36F-F55E-4A0A-B6C6-...).
I had also trouble with IP collision for TEPs - some hosts were assigned IPs that were already in use (in that case do not take out the host out of MM - if you have DRS, VMs will be automatically moved there but won't communicate due to the collision - tunnels will be down for that host). Simple change to DHCP for the IP Pool, saving and assigning the IP Pool back fixed the issue.

0 Kudos