migrating Cluster protected by NSX to new vCenter

[kwg66]

Our vCenter is running on w2008 and its time to refresh this to a newer build.. we don't trust the in-place upgrade.

Problem is complicated by NSX for vSphere, it protects this environment.  Running NSX 6.2.4

Does anyone have any idea how this could be accomplished non disruptively?   I don't know enough about NSX.

- I do know how to migrate the hosts and clusters into new vCenter non disruptively, done it a hundred times

- I do know perfectly well how to migrate off vDS to standard switch non disruptively, then remove hosts and re-add to new vCenter, done it a hundred times,  but don't know how to do this with NSX in the picture

What happens to VM network connections and DFW rules when migrated off vDS?

Can anyone list out the high level steps for a non disruptive move of NSX cluster to new vCenter?

Thanks in advance

[lhoffer]

The answer to this depends heavily on whether or not you're set up today as a cross-vCenter environment for NSX. 

For the network side of things, you can get pretty close to non-disruptive by establishing layer 2 adjacency between the two clusters (either via a universal logical switch in a cross-vCenter environment with universal logical switch or via L2 bridging with standard logical switch).  Once established, VMs can be moved between clusters and the only minor disruption will occur when you move their default gateway from the old cluster to the new one (in the cross-vC universal DLR scenario, this could get a little tricky as you'd need to migrate controllers and change the NSX Manager designations if the old cluster NSX Manager is primary).  For a non-cross-vC using standard DLR or ESG, you'll have to create a duplicate instance in the new cluster, disconnect the old LIF, and connect the new one so there'll be a slight interruption while that happens.  The VMware® NSX-v Brownfield Design and Deployment Guide - ver 1.1 does a pretty good job of describing the L2/L3 migrations as well (even though it approaches from the perspective of migrating from a legacy physical network to NSX).

Migrating DFW can be a little less friendly depending on how you've established your rules.  The big thing to look out for here is any rules that use vCenter objects as their criteria since VMs on your new cluster won't have visibility into vCenter objects on the old cluster and vice versa (so for example, if you have a rule that has a source/destination of any VM with "web" in its name, the new cluster NSX Manager/vCenter won't have visibility to the old cluster to be able to generate the associated dvfilters).  That said, you will of course need to be very prescriptive about how you group the VMs that will move at any given time based on how they communicate with one another unless of course all of your DFW rules are just based on IP sets.

All in all, I don't think there's a way to do this without at least a small amount of interruption.

[kwg66]

@Lhoffer - love that skull avatar!

Excellent reply but I don't think I provided enough info, this may be easier for you to answer if I provide more detail:

vSphere is at 5.5 u3a including vCenter, and part of this is the upgrade to vCenter and vSphere 6.02.   Not ready for 6.5 yet its not supported by our backup vendor.  no cross vmotion or even linked mode for that matter..

The cluster won't change, networking won't change, VMs won't change.  the only thing that will change is vCenter VM base OS and vcenter version will move up to 6.02,  and of course this will affect NSX because NSX is tied to it.  We will need to tie NSX to the new vCenter during this migration

I'm not an NSX guru so I am not sure what actions can be performed without effecting connectivity and rules enforcement.

I'm guessing that the following must happen:

1) log into NSX manager and remove its connection to the current vCenter first (not sure how this affects NSX DFW rules enforcement, but certainly VMs should continue to run right?  Help!)

2) export vDS config first (no problem)

3) migrate vDS to vSS next  (not sure how this affects NSX DFW rules enforcement, but certainly VMs should continue to run right? Help!)

4) Remove host (no problem when host is on vSS you don't need maintenance mode to remove host from cluster)

5) Add host to new vCenter (no problem)

6) import vDS to new vCenter 6.02 (not sure if this is possible given the different vCenter versions? Help!)

7) migrate all the hosts now in the new vCenter to vDS

😎 log into NSX manager and associate NSX to new vCenter 6.02

Please let me know if this looks right, if I'm missing anything,  and provide some expertise around where I ask the much need and humbling "HELP! 

[lhoffer · Accepted solution]

Ok, that makes sense and also makes it a little scarier if you're not planning to use the migration tool (which maintains all existing certificates, UUIDs, and plugin extensions so that things like NSX don't break) so definitely way this in your decision around whether or not to migrate rather than reinstall vCenter.

That said, here are my comments inline with your questions:

1) log into NSX manager and remove its connection to the current vCenter first (not sure how this affects NSX DFW rules enforcement, but certainly VMs should continue to run right?  Help!)  There's not really a way to remove the current vCenter association in the NSX Manager UI (can edit existing config to re-enter the vC password to force it to re-register to the new vCSA, and as the NSX Manager to vCenter is always a 1:1 relationship that'll clear out the previous registration) but not having NSX Manager will not affect existing DFW rules as long as no changes are made (i.e. vMotion, new FW rules, IDFW logon events if you're using the AD integration, etc.)

2) export vDS config first (no problem)

3) migrate vDS to vSS next  (not sure how this affects NSX DFW rules enforcement, but certainly VMs should continue to run right? Help!)  Big caveat here that NSX is only supported on the vDS.  In the case of NSX network virtualization/VXLAN, definitely needed as the VTEPs get associated with a dvPortgroup.  If you're only using DFW, I've seen it work in the lab and since policy is applied on the vNIC and not in the vSwitch there's really no technical reason that it shouldn't work, however, it's still not supported or officially tested by VMware so you won't get far with support if it breaks something.

4) Remove host (no problem when host is on vSS you don't need maintenance mode to remove host from cluster)

5) Add host to new vCenter (no problem)

6) import vDS to new vCenter 6.02 (not sure if this is possible given the different vCenter versions? Help!)  vDS is backwards compatible so you'll probably just want to upgrade it to 6.0.0 after you've got it up and running in the new vC to get the latest features/bug fixes.

7) migrate all the hosts now in the new vCenter to vDS

😎 log into NSX manager and associate NSX to new vCenter 6.02

[kwg66]

lhoffer - thanks for the assistance!    Much appreciated. 

[stevespike]

Read this thread and I'm keen to know if you tried this method and if so, how did it go?

What other steps (if any) were needed?