Breaking enhanced Link mode in vSphere 6.0 and deploying new 6.7

[vmk2014]

Hi All,

We are planning to upgrade the vSphere 6.0  to 6.7 which is currently in ELM. All the vCenter are 6.0, but only 1 vCenter HW supports the upgrade to 6.7, hence we have decided to break the existing vSphere 6.0 from ELM and deploy new VCSA 6.7. Post deployment of VCSA/vCenter 6.7, we are have a challenge to migrate the existing network (DVS) to new vCenter 6.7.  Can anyone advise or suggest how to migrate the existing Distributed network (DVS) to new vCenter 6.7 ? Also, what are the other challenge post new vCenter 6.7 deployment.

Note :- VMware recommendation

            Unfortunately, it is not possible to split an enhanced linked mode environment in vSphere 6.0. This capability is available using the cmsso-util workflow only in 6.7 update 1

          In 6.0, the only supported way to remove a vCenter from enhanced linked mode is to decommission it entirely.

Thanks

Vk

[lucasbernadsky]

Hi, VMK.

You can migrate DVS configuration by exporting the existing DVS config XML. You can achieve this with a very simple PowerCLI script: VDS Export/Import with PowerCLI - VMware PowerCLI Blog

Once the new DVS is imported, you may want to upgrade it to a compatible version 6.6 if I am not wrong. Take a look at this KB VMware Knowledge Base

Regards!

[vmk2014]

Thank you, Lucas. I guess, we need to create standard switch first in new vCenter 6.7.

VMware Knowledge Base

Thanks

Vk

[lucasbernadsky]

Not really. When installing a new fresh vCenter, import the DVS and when adding the ESXi Host it will automatically import their own vSS, so then you can migrate their VMKernels to DVS portgroups

[harry89]

Migrate everything from vDS to vSS .

So that if you decommission old vc host should not have any proxy switch of dvs (any elements on the dvs ) .. once done remove host from dvs and vcenter .

extract the dvs configuration from previous vc

deploy new vc, add the host , import the configuration of vds

move from vss to vds .

[nachogonzalez]

Hello, hope you are doing fine

Have you checked this KB article
VMware Knowledge Base

Please keep in mind that source and destination vDS need to be the same version

Warm regards

[vmk2014]

Lucas,

Sorry for the late reply. I was awaiting for vmware vendor reply. Please find the comments from them.

we do need to migrate all VM networking to standard switches on the hosts that will be moving between vCenters for two reasons. One is that the VMs could lose connectivity after the hosts are removed from the original vCenter environment if they're on distributed switches, but will remain fully operational as long as they are on standard switches.

Additionally, there is the possibility that additional configuration work will need to be done on the new distributed switches that will be imported to the new vCenter. Per the Network team, the dvswitch configuration export process is officially supported as a way to restore switches to their original vCenter, and the outcomes can be unpredictable when importing them into a new vCenter which may require further manual work before they are functionally identical with the originals. Having your VMs running on standard switches will allow you to perform any work that's needed without disrupting VM production.

Thanks

VK

[lucasbernadsky]

Hi, VMK. I understand.

And what about using HCX? That way you can manage your migrations to be vMotion, cold, or bulk with minimum effort.

Maybe it's just me but I try to avoid vSS as much as I can, since a little typo in the standard portgroup could cause vmotion problems at least

[daphnissov · Accepted solution]

Your migration questions as fairly straightforward and quite common. Convert your vDS to vSS on all hosts, disconnect and remove them from the source vCenter, and add them to the destination vCenter. Reverse the process and re-deploy a vDS, then join hosts. Unless you're using solutions like NSX, vSAN, or some others, this "swing" style migration should not impact VMs. Do keep in mind that if you're using backup, monitoring, replication, or other external tools that integrate with vCenter that, once you do this, typically it will see those same VMs on the other vCenter as "new" and will treat them as such.

_____________________________________________________________

"Did you find this helpful? Let us know by completing this survey (takes 1 minute!)"