VMware Networking Community
Petersaints
Enthusiast
Enthusiast
Jump to solution

N-VDS to VDS migration

Hello all,

I'm using NSX-T Version 3.1.3.1.0.18504668.
At this moment, all my 4 transport nodes are on version 7.0U3 (build 20328353).
I only have two pnics on each transport node on N-VDS, for overlay traffic. I'm planning running the migration via CLI. After reading the documentation looks like a straight forward procedure, but i have some doubts, that i need some help.

- running via CLI, if i had DRS fully automated, do i need to take any manual action, like put each host in maintenance mode, or only have to wait that the migration on all hosts end?
- After the migration, can i rename the DVS on vSphere and rename the new transport node profile on NSX-T?

Thanks.
Regards.

0 Kudos
1 Solution

Accepted Solutions
JaSo2
Enthusiast
Enthusiast
Jump to solution

Hello,

Yes, it looks pretty straight forward, but it can be tricky:

- If you have DRS fully automated, then nothing else is needed and everything will be done automagically from the maintenance mode (MM) perspective.

- You can rename VDS afterwards - after all it is "just" an object. Mind the fact there will be also an uplink portgroup with the similar automatically generated name.

The tricky part not mentioned in the docs (at least not the last time I checked) that bit me and turned out not to be a bug (support confirmed) is default timeout for leaving MM of the vds-migrate command. It is 300 seconds - meaning if your running VMs are not migrated off your host in 300 seconds you are running into serious problems. There is an option for the migration command to specify MM timeout (switch maintenance-mode) to modify this default behavior - I recommend checking it in the CLI.

If I were you I would go with the API path - it is much more in your control and you can modify the VDS name in the API call along the way.

J.

View solution in original post

0 Kudos
4 Replies
JaSo2
Enthusiast
Enthusiast
Jump to solution

Hello,

Yes, it looks pretty straight forward, but it can be tricky:

- If you have DRS fully automated, then nothing else is needed and everything will be done automagically from the maintenance mode (MM) perspective.

- You can rename VDS afterwards - after all it is "just" an object. Mind the fact there will be also an uplink portgroup with the similar automatically generated name.

The tricky part not mentioned in the docs (at least not the last time I checked) that bit me and turned out not to be a bug (support confirmed) is default timeout for leaving MM of the vds-migrate command. It is 300 seconds - meaning if your running VMs are not migrated off your host in 300 seconds you are running into serious problems. There is an option for the migration command to specify MM timeout (switch maintenance-mode) to modify this default behavior - I recommend checking it in the CLI.

If I were you I would go with the API path - it is much more in your control and you can modify the VDS name in the API call along the way.

J.

0 Kudos
Petersaints
Enthusiast
Enthusiast
Jump to solution

Hello @JaSo2 ,

Already test on my lab migration via API. It worked perfectly.
After the migration i notice new uplink profile and transport node profiles.

- Can i delete the old uplink profile (hosts-up) and rename the PostNvdsMigration-profile?

Petersaints_2-1679350322363.png

About Transport node profiles, can i delete the old one (tnp_hosts), delete the Nvds2Cvds-Migration-tnp-hosts profile and rename MigratedTNP-Nvds2Cvds-Migration-tnp-hosts profile, that is the one that is applied to the cluster?

Petersaints_3-1679350409882.png

 

Thanks.
Regards.

 

 

 

0 Kudos
JaSo2
Enthusiast
Enthusiast
Jump to solution

Hello,

Great :).

Regarding renaming of the profiles - yes, there should be no functional problem with renaming them. You just have to try it, if NSX let you do it while it is already applied somewhere (but with profiles I think it should be possible).

J.

0 Kudos
wcoz
Contributor
Contributor
Jump to solution

Thanks for the tips guys, I had similar questions before starting a migration.   

I have a different, but related question. my migration on a test system has worked fine on all hosts (nsx 3.2.3) , but, I still have all the nsx networks listed outside of the newly created CVDS. it didnt remove the nsx opaque networks as when viewed from the network inventory in vCenter (7.0.3)

instead of using the cluster migrate option I used the "vds-migrate tn-list <file> maintenance timeout 3600"option and specified each server individually (taking them into maint mode as required) - being a HCI environment would never allow the automatic completion of maint mode in our environment, so was easier to control when we did each node. 

any ideas if theres a command that needs to be run? or is potentially that the 3600 timeout hasnt passed/completed yet? I couldn't find any info on any of it after a day or two of googling.

thankyou

0 Kudos