Workload migration between VCF2.3 and VCF4.2

[FilipSmeets81]

Instead of upgrading the current VCF2.3 environment to VCF4.2, we went for a VCF4.2 greenfield deployment on new hosts. The only thing left is migrating the workloads from the old environment to the new environment.

Now that the cross vCenter migration tool is integrated in vCenter 7, this should have been an easy task... We use the Import VM option on the new vCenter.

The workloads are all connected to NSX-V with L2 Bridging to their corresponding VLAN. This is because the gateway is running outside NSX and there are no plans to change this in the near future.

We created NSX-T VLAN segments as a destination network for the VMs.

First problem: migrating from vDS 6 to vDS 7 > https://kb.vmware.com/s/article/79446 

Implementing the workaround worked.

Second problem: vMotion between NSX-V and NSX-T > https://kb.vmware.com/s/article/56991

I got the same error as described in the following KB: https://kb.vmware.com/s/article/79350

The vdl2 component is showing status up and we are also using IP Pools so I don't think this is the issue here.

We then created a traditional portgroup on the vDS as a destination which did not resulted in an error. The vMotion worked and completed successful but as soon as the VM was running on the new host, it became unreachable. Having a look on the physical switches showed that they were still thinking that the VM was running on the old host.

Disconnecting and reconnecting fixes the issue.

Migrating the VM back to the old host also makes the VM reachable again, but only for a little while. Again disconnecting and reconnecting the nic of the VM fixes the issue.

So it seems that the network is not informed about the move.

I already opened a support ticket but haven't got any feedback yet.

[shank89]

It sounds like the logical port or VIF isn't being created with a standard vMotion.  This is valid for an NSX-V to T migraiton and is something that needs to be considered.

Previously (not sure with the current version) if you are doing a vMotion as a means of migration, all the VIFs needed to be created manually.  I guess your disconnecting and reconnecting is doing that, which you can verify by checking the VIFs prior to doing it and then after.

I have tested a V2T migration with HCX and have had no outage and VIFs created automatically.  Might be worthwhile considering this to see if this is what is causing you the issue?

[FilipSmeets81]

Hi Shashank

Sorry for the late reply. I finally found the time to further troubleshoot the issue.

HCX would indeed be a nice to have but it would require a license purchase.

As for the XVM vMotion issues, I think I got it working without downtime now.

This is what I did:

Workaround implemented on both source and destination vCenters as described in the following KB: VMware KB79446

Looking at the following KB: VMware KB56991 we can only migrate from DVS to DVS.

So I first migrated the VMs from an NSX-V VXLAN network to a traditional dvPortGroup on the source vCenter.

The second thing I did was adding the VMs to the NSX-V firewall Exclusion List.

Doing the above steps before starting the migration did the trick. Once migrated to the new environment, the last step would be to migrate the VM network to an NSX-T VLAN segment.

In case you want to migrate back, you will again need to add the VM to the NSX-T Exclusion List.

Grtz.

[shank89]

Good stuff, sounds like one heck of a workaround!

Glad you got it sorted though.