NSXT DFW V2T migration - part 1

Submitted by Robin van Altena on Mon, 12/20/2021 - 14:17
 
 
Follow your favourite author

Leave us your email address and be the first to receive a notification when Robin posts a new blog.

NSXT DFW V2T migration - part 1
Mon 20 Dec, 2021
During this year’s edition of the VMUG NL I was granted the opportunity to present a session about migrating NSX-V to NSX-T. I was one of the fortunate ones to present via a live stream in a bar in Hillegom (NL). After my presentation I received several questions about more in-depth information on the DFW objects and the Edge migration part. Those requests have lead to a small blog series, from which this is the first part.
Textarea

Since I put a lot of information into my session, I decided to split the information into 3 smaller blog posts. When the recorded session becomes available, I will update this blog with a direct link.

  1. Introduction (current blog)

  2. DFW objects (link)

  3. Edge migration (link)

Information on Host Migration, as discussed in my VMUG session, can be found in these previous NSX V2T migration blog posts:

Okay, so much for the introduction. Let’s get started.

NSX V2T/DFW Migration Intro

The main reason we are talking about the subject of migrating from NSX-V to NSX-T is because NSX-V has been declared End-of-General Support on January 16th 2022. Which is only a few weeks from now. So, if you haven’t considered starting with a migration, read this blog series and start making some plans.

NSX-V End of General Support
Textarea

In one of the previous blog posts I already wrote about the 'Distributed Firewall' option, which is one of the Advanced migration modes in the Migration Coordinator. In my VMUG session I showed the 'NSX for vSphere' option, which is also known as the 'Migrate All' option. If you want to know more about the other option available in the NSX-T migration coordinator, check out this documentation.

Preparations

Before you can start using the NSX-T migration coordinator, there are some necessary preparations. Both NSX-V and vSphere need to be supported. For NSX-T 3.1 the requirements are:

  • NSX-V versions 6.4.4, 6.4.5, 6.4.6, 6.4.8 and later are supported
  • The version of ESXi used in your NSX-V environment must be supported by NSX-T
  • vSphere Distributed Switch versions 6.5.0, 6.6.0 and 7.0 are supported

See the VMware Product Interoperability Matrixes for required versions of vCenter Server and ESXi.

To migrate the Distributed Firewall, the DFW Export version needs to be 1000. In version 3.1 this must be done manually, in version 3.2 this will probably be done by the migration coordinator. The procedure on how to update the export version can be found here.

Of course, the environment should be free of issues, pending reboots or upgrades. And no changes should be done in NSX-V or NSX-T once the import of the configuration has started.

Though before you start the migration, you should already consider things like scripts that run against NSX-V, monitoring NSX and especially knowledge about NSX-T. Because although V and T share a lot, there are some major differences in the way they need to be operated.

Assessment

If the environment can be migrated to NSX-T the first step should be to perform an Assessment. This can be done in several different ways. The NSX-T migration coordinator documentation already provides a lot of information. But the migration coordinator will also analyse the NSX-V configuration before the migration. Because the information is imported into a new NSX-T manager this can be done as a non-disruptive task. If you haven’t started with considering a V2T migration, at least start by performing an analysis with the migration coordinator to get an estimate of the work that needs to be done before or during the migration.

Image
First stages of the migration coordinator
Textarea

To use the migration coordinator in an existing environment, the following steps must be taken:

  • Install one NSX-T manager and add a license
  • Connect a Compute Manager (vCenter)
  • (Optionally) Deploy 2 edges and create TEP IP-pool
    These are only required if you are using Network Virtualization and use the 'Migrate All' option. The edges must be deployed manually, not thru the GUI.
  • Start Migration Coordinator service

A more detailed description on how to import the configuration can be found in the documentation for the migration coordinator or in this blog NSX V2T DFW only migration part one.

Once the configuration is imported and analysed, the migration coordinator shows which configuration can’t be migrated or for which components additional information is required. If you are lucky there are few issues to solve. But if you are not that lucky, the GUI isn’t the easiest way of browsing thru the issues. Check out this blog if you want to export the list to an excel sheet.

In the next blog I’ll go over and give some examples of issues I have found during previous V2T migrations. Thank you for reading and hopefully this was helpful.

Tags

Questions, Remarks & Comments

If you have any questions and need more clarification, we are more than happy to dig deeper. Any comments are also appreciated. You can either post it online or send it directly to the author, it’s your choice.
Let us know  

 
 
Questions, Remarks & Comments

Message Robin directly, in order to receive a quick response.

More about RedLogic