To VDS and Back: Migrating a VDS Host to a New vCenter

By | November 22, 2014

One of the requirements for Site Recovery Manager is to have a vCenter in protected and recovery sites. As part of my project I found that two sites that were a recovery pair were both hosted out of the same vCenter in site A: In order to deploy SRM I needed to move the site B hosts into a new vCenter. Moving a host is typically not something very difficult (though there are some administrative tasks to take care of), what complicated this task is the fact that all of the hosts were using distributed switches (VDS).

I was aware of a KB article that gave the steps (involving going to Standard switch and back).

I then saw a tweet from William Lam about how easy it was to move a half at on VDS by just connecting it to the new VCenter.

I then got into a discussion with @lamw and @mattheldstab around the topic and opened a case with support to get the final word.
Supports’s stance is that you can move the host via “yanking”, but the KB is the official way and if you run into issues you will be asked if you followed the KB.

I found a blog post talking about the yank method plus recreating the dvswitch from the backup. If done in the correct order the host will reconnect with little fuss. Note that a comment on this post is SPOT ON. Reconnecting to an imported VDS in this manner will cause issues for OVFs. Changing the order of the steps (recreate VDS then yank host over) over results in the guests not showing the original port groups (making changing them difficult).

I wasn’t comfortable with the yank method and at the time I didn’t know how to work around it so I basically followed the KB article. . I apologize for not having pictures and more details, but some of the steps are similar to my blog post The Safest Way to Convert to LACP

Migration Steps Version A (VDS to VSS to VDS)


  1. Convert templates to VMs (this helps with various scripting around VM location and portgroups
  2. Export folders and roles from vCenter A
  3. Import folders and roles into vCenter B
  4. Create local portgroups on standard switches of all VDS hosts in vCenter A
  5. Validate host ACCESS BY ROOT
    1.  You can use this PowerCLI code to do so
  6. Export VM locations
  7. Export VDS from vCenter A
  8. Import VDS into vCenter B (do not check the “maintain portgroup names” box)
  9. Create Clusters in vCenter B that match HA/DRS/EVC modes of those in vCenter A, disable HA and DRS


  1. Disable HA and DRS on all clusters in vCenter A
  2. Move a single uplink on each host from the VDS to the standard switch (I use the wizard, see my other blog post)
  3. Run script to move vms to standard switch portgroups (make sure that there are NO VMs on VDS portgroups)
  4. Move vmkernels to standard switch (I have had to do this by hand)
  5. Remove host form VDS (this is optional)
  6. Disconnect Hosts from vCenter A
  7. Connect Hosts in vCenter B NOT in their final cluster but just under the datacenter (this is needed because adding directly to a cluster runs into EVC issues sometimes)
  8. Move hosts to their clusters
  9. Add uplink from all hosts to VDS in vCenter B (this should be the uplink that is NOT in use by the standard switch)
  10. Move vmkernels to dvs (I have had to do this by hand)
  11. Run script to move vms to VDS portgroups (make sure there are NO VMs on standard switch portgroups)
  12. Move last uplink to VDS
  13. Import vm locations
  14. Enable HA and DRS on all clusters in vCenter B
  15. Cleanup vCenter A (remove disconnected hosts, remove clusters, etc).

I had some ideas around using the yank method and then doing a VDS to VDS migration, but I seemed to remember having issues with the portgroup names on the VMs.

Leave a Reply

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