NSX V2T DFW only migration – part one

Submitted by Robin van Altena on Tue, 07/20/2021 - 07:03
 
 
Follow your favourite author

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

NSX V2T DFW only migration – part one
Tue 20 Jul, 2021
The migration coordinator has been around for several NSX-T versions, but with the 3.1 release some advanced features have been introduced that may help you with the migration from NSX-V to NSX-T. One of those features is the in-place migration of the Distributed Firewall configuration. This feature can come in handy if you don’t want to migrate the networking part with the migration coordinator and you don’t want to use external tooling to migrate the Distributed Firewall configuration. For example, if the NSX-V environment uses OSPF, which is not supported by the migration coordinator in NSX-T version 3.1 or if you want to change the network topology to something different than the migration coordinator supports.
Textarea

With the End of General support for NSX-V approaching, now is the time to start looking at migrating from V2T. Besides looking at the vSphere version, the migration coordinator is also a good starting point to analyze what can and can’t be migrated directly or automatically to NSX-T. In this blog I will show one of the advanced features of the migration coordinator, the option for migrating the Distributed Firewall Configuration only. This first part will provide an overview of the process and in the next one I will show a migration using this method.

Before you can use the migration coordinator, you need to install an NSX-T manager in the environment and connect it to the vCenter environment to which the NSX-V manager is connected. If you don’t want to do this directly in production, an option can be to restore the vCenter and NSX-V manager in a test environment and do the analysis there. There are some requirements before the migration coordinator can be used, for example the NSX-V version must be at least 6.4.4. A complete list can be found here.

After installing the NSX-T manager and connecting it to the Compute Manager (vCenter), the Migration Coordinator can be started. Because the Migration Coordinator isn’t started by default, you need to start it from the console on a NSX-T manager, by using ‘start service migration-coordinator’.

Starting the migration coordinator for the command line
Textarea

Once started the migration coordinator can be found under System > Lifecycle Management > Migrate

Image
Migration coordinator modes
Textarea

The advanced migration mode that I’m discussing in this blog can be found by scrolling down:

Image
Migration coordinator advanced modes
Textarea

For this and the next blog I’ll use the ‘Distributed Firewall, Host and Workload’ option on the right. This option can migrate an existing distributed firewall configuration from NSX-V to NSX-T including the hosts and workload. So, all objects like Firewall rules, IP-Sets, Services and Security groups can be migrated. The Network or Guest introspection is not migrated.

After clicking on the ‘Get Started’ button, the first task is to connect to the NSX-V manager and the vCenter server.

Image
Migration coordinator connecting vCenter and NSX-V manager
Textarea

Once the NSX-V manager and vCenter server have been connected the existing configuration can be imported.

Image
Migration coordinator importing existing configuration
Textarea

Importing and translating the existing configuration usually only takes a few minutes. This stage only handles an import of the configuration into the migration coordinator, it does not set or create any configuration in NSX-T yet.

Image
Migration coordinator imported and translated the configuration
Textarea

The imported and translated configuration can now be checked for issues or configuration items that cannot be directly imported into NSX-T. The migration coordination will probably show that it can’t convert all Layer-7 Service configuration, since the APP-ids in NSX-V and the context profiles in NSX-T are not 100% the same. Or it can ask for some input regarding the teaming policy it needs to set in NSX-T during the migration.

Migration coordinator requesting input
Textarea

But in my opinion the main reason you should at least use the migration coordinator once is to see the configuration items that can’t be migrated to NSX-T. One of those configuration items can be a security group based on a vSphere component like the vSphere datacenter or a vSphere cluster, those objects are not available in NSX-T.

Migration coordinator showing unsupported configuration items
Textarea

In the screenshot you can see that the vSphere Datacenter object is not supported in NSX-T. For microsegmentation purposes the Datacenter object was sometimes used to create an IP-Set of all virtual machines in the vSphere environment. The screenshot already shows a group named Datacenter-NSX-Proof, for which I will show an option to migrate this group and how it can be set for usage after the migration.

So, even if you are not using the migration coordinator to migrate the configuration, it may be very useful to see if there are any non-compliant configuration items in the NSX-V environment that might have been missed.

At this stage the import can be cancelled and the configuration in NSX-V can be adjusted. On this point the migration coordinator also has been improved, because in previous versions some configuration would be left causing errors on future imports. In the current NSX-T 3.1.x versions I didn’t encounter these issues.

In this case the best solution is to change the Datacenter group into a group based on an IP-Set for the addresses in the environment. There are some down sides to this, if there are also physical or bare-metal servers within the range of the IP-Set. Then they are also included, as with the Datacenter object they are excluded. Therefore these should be excluded from the IP-Set.

For this example, I’m changing the group from a group based on a vSphere object.

NSX-V security group based on a vSphere object
Textarea

Into a more static group based on an IP-Set, that will be accepted by the import and translation of the migration coordinator.

NSX-V security group based on an IP-Set
Textarea

Once al the required configuration changes have been made the NSX-V configuration can be imported and translated again, to see if the configuration is now supported by NSX-T.

In the next blog post I will show how the configuration is transferred into NSX-T and what actions are required after the migration. If you have any question or remarks please feel free to contact me or leave your remarks below.  

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