VMware

Has anyone migrated from NSX-V to NSXT?

Our client wants to put their DR on VMC on AWS. VMware told them they must migrate their on-premise NSX-V to NSX-T. What is the best way to do this? I have seen the Migration Coordinator [https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.4/nsxt_24_migrate.pdf](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.4/nsxt_24_migrate.pdf) but have been told that to goto VMC on AWS, the NSX-T is somewhat different.

Can anyone point me to a script or guide or whatever for this type of migration?


View Reddit by gonzoflickView Source

Related Articles

3 Comments

  1. Must is a strong word. What features of NSX are they using?
    A migration to T is needed at some point anyway so it’s not wasted effort. If the environment is simple the migration assistant will do its thing with just some minor human validation required. If they’re doing anything complicated though then engage someone from VMware or a partner who has done it before…

  2. The insertion point of the two products is similar, but discrete. I was able to move an environment over seamlessly when I was using it without overlay networking. With overlay networking at some point the ESG/DLRs will have to go silent and replacement T0/T1 routers will take on that role, so you **will** take an outage.

    So look at the big things:

    NSX-V uses VDS to implement, NSX-T uses N-VDS, so your planning requires you to focus on that meaning you will have to peel off one NIC from your VDS and put it into the N-VDS, and then pull the other one over once the VDS or that host is evacuated. If your hypervisors have additional uplinks (VNICs/NPAR), you can easily peel a host off a cluster into a new cluster, add the two additional NICs to the N-VDS. This may get a little more complicated in the planning if you still have VLAN attached workloads. Be sure to understand that when you fill out the “NVDS Name field” during deployment you should use the same string for both overlay and VLAN backed transport, otherwise unique uplinks are required.

    I imagine to reduce downtime to as small a window as possible, you would have to implement some kind of bridging between the VXLAN backed overlays to the Geneve based overlays, and that is some serious planning and temporary traffic pinning.

    It looks like the migration tool really does ease the pain here, but I’d definitely be having support at the ready, and even build a nested test environment because running this tool without having done it before would be a recipe for a not so fun evening.

    ******

    I have been recommending my customers only deploy NSX-V for security until NSX-T hit some maturity and I believe 2.4 and 2.5 releases are finally ready for overlay consumption, though I am pretty annoyed that there is a “new GUI” and “old GUI” and that some things can only be done in one or the other.

  3. Well they use SDN now for VXLan switching and DFL. They have edges as well. They want to stretch layer to to VMC on AWS and we hear NSX-T is the requirement but might require a different implementation than the migration assistant provides.

Leave a Reply

Your email address will not be published. Required fields are marked *

Close