The Adventures of VMware NSX-v Are Coming To An End – End of General Support (EoGS)
The time has come… It already has been announced for a while, but as from the 16th of January 2022 will NSX for vSphere will be out of general support. Technical guidance expires one year later: the 16 of January 2023. As from then NSX-V is officially out of support.
What does it exactly mean?
As NSX-v is approaching end-of-life, it doesn’t mean that support stops entirely in 2022. As from January 2022, the product will be in a Technical Guidance state. Concretely this means that no Severity 1 cases can be opened and that no patches (bugs, security issues, vulnerability) will be provided.
As from that moment, if you open a service request for NSX-v, it will be more to assist you finding any known issues and refer you to the correct KB/workaround. If the result is not any known issue, support would (most likely) recommend you to migrate to NSX-T.
Help, I’m still on NSX-v! What now?
The answer is simple, migrate! The way to achieve this is a little more complex, but VMware provides many good documents about it. In this blog post, I will just make some highlights and refer you to the official VMware documentation. There are multiple approaches and also some pitfalls
- Minimum required version: 6.4.4+
- Recommended version: VMware NSX for vSphere 6.4.11.
- Recommended version: VMware NSX-T Data Center 3.1.3.x.
- Co-Exist: keep your NSX-v environment in place, but deploy all new workloads on the newly created NSX-T environment. NSX-v will slowly be phased-out.
- Lift and shift: actively migrate your workloads to the newly created NSX-T environment. Similar to the first approach, this method requires new/additional hardware. The whole migration can happen in multiple different ways. The migration coordinator can still be used for DFW configuration migration,…
- In place migration: if new hardware is not an option and your environment matches a predefined topology, then in place migration could be an option. Big advantage here is that the migration is built-in, automated, it will have minimal downtime and it’s fully supported by VMware. If you want to know more about this migration approach, let’s take a look to the Migration Coordinator chapter.
One of the migration methodologies is using the NSX-T built-in migration coordinator. If you could fit your environment into one of these supported topologies, you could make use of the MC.
The list of supported topologies can be found here: https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/migration/GUID-FA5EFF22-B7CA-4FF8-A0D3-C0CB013F10F1.html
Main unsupported-features/limits are:
- Merging into an existing NSX-T environment
- NSX-v environments using non-default VXLAN port (4789)
- Cross-vCenter NSX
- Transport zones which are using multicast and hybrid replication modes
- Port groups/VMkernel interfaces which are attached to VSS are not migrated
- OSPF between Edge Services Gateways and northbound routers. You must reconfigure to use BGP
Full list of (un)supported features: https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/migration/GUID-2A39C982-5BCC-400F-8761-F133F994A2C6.html#GUID-2A39C982-5BCC-400F-8761-F133F994A2C6
- NSX-v manager role should be standalone or primary without a connected secondary
- There must be available capacity to put hosts in maintenance mode if you don’t want any interruption.
- NSX-T management plane + edge nodes must be deployed
- Edge node must be deployed via OVA and NOT via the NSX-T UI
What if I can’t use Migration Coordinator
Until now there are still a lot of limitations the using the Migration Coordinator. If you don’t meet the prerequisites or if you are not in a supported topology, you should take a look at the lift and shift method. There are for example ways to perform the migration for cross-vCenter topologies as well. As these exceptions are all unique to each environment, it’s hard to have one general migration solution.
The migration process from NSX-V to NSX-T is a long(er)-term project. There are multiple requirements to meet and for each customer this migration path will be different. Therefore, I could only recommend to start on time with this whole migration process. And please remember, you shouldn’t walk this road alone. Partners like ITQ and of ofcourse VMware can assist whenever/wherever needed.