I’m going to try and do a Camtasia video walkthrough of this process to accompany this post. Will post it in the coming weeks.
I ran into a known Catch-22 tonight when migrating infrastructure VM’s over to a new cluster of UCS blades for our vCloud Director lab.
Anyway, here’s the story…
You’ve moved all your VM’s over to the new cluster with the vDS, and you’ve powered down your vCenter VM and SQL VM. Connect your VIC client directly to the host they reside on and unregister them (Right click, Remove from Inventory). Connect another VIC client directly to the new host you’re adding them to and register them (Browse Datastore, find VM folder, right-click on .vmx file, Add to Inventory). Now, right-click on the VM, and Edit Settings. Select your vnic and look in the bottom right dropbox. In most cases, this will be empty (barring any kooky configuration you’ve done) meaning you cannot associate the vCenter VM with a portgroup in the vDS because….you guessed it….it’s controlled/housed by vCenter and the vCenterDB.
Hmm…now what the heck are we supposed to do?!
Here’s the workaround.
Open the VIC client connected to the host housing your vCenter VM.
Select Host > Configuration > Networking > vNetwork Distributed Switch button > Manage Physical Adapters…
This is of course assuming that you have more than 1 vmnic uplink in your dvSwitch. If you only have 1 dvUplink associated with your dvSwitch, but have more Unclaimed adapters freely available, you can skip this step.
Select vmnic# and Remove. Doesn’t matter which one, as long as there is more than one, and both are active.
Now, what we’re going to do is create a temp standard vSwitch on this particular host ONLY, associate this vmnic to it, and IP it as a vSwitch service console, the same way we used to do before the dvSwitch existed.
Go back to the VIC client connected directly to the new host that now houses your vCenter and vCenterDB server. (If you’re using the SQL Express version, your vCenterDB is on the same server as your vCenter, so you’ll only be worrying about the vCenter server’s connectivity in this case). Make sure your vCenter and SQL VM’s are powered down at this point. Select the ESX Host itself in the left column, and then…
Configuration tab > Networking > Add Networking… > VMkernel > “Create a vSwitch1” with the unclaimed adapter > set the IP/Subnet/Gateway to the same as it is in the dvSwitch > Finish
Click Properties above vSwitch1 > Click Add in the bottom left > VM Network > Next > Finish
Now, right click on your vCenter VM, Edit Settings, select Network Adapter, and then choose the “VM Network” in the dropdown box in the bottom right. Double-check and make sure the checkbox for “Connect at Power On” is checked and Click OK.
Repeat this step for your SQL server VM as well (if your DB is hosted on a separate VM/instance).
Power on SQL server VM and let it boot all the way up.
Power on vCenter VM and let it boot all the way up.
Load a NEW VIC client and connect to vCenter using the IP you added to vSwitch1. You should be able to connect to vCenter at this point. But we’re not done yet…
Verify that you can see your dvSwitch setup by clicking Home > Networking in the breadcrumbs at the top. If you can, continue. If not, go back over the steps above to insure you didn’t miss anything.
Once you can see your dvSwitch, go back to Hosts & Clusters view, right-click on your vCenter VM, Edit Settings. Select Network Adapter again, and drop the dropbox on the bottom right. You should now see all of your dvSwitch port groups, as well as the current “VM Network” assignment. Choose the dvSwitch portgroup associated to the same LAN, and click OK. You should see the Summary tab info of the VM update to the portgroup.
Repeat this same process for the SQL VM.
Once both are correctly associated to the dvSwitch, we’re good to go. We just need to go back and clean house.
Select the ESX host housing vCenter > Configuration > Networking > vSwitch1 Properties > Network Adapters tab > select vmnic > Remove.
This will remove the uplink that we “borrowed” from the dvSwitch earlier.
Go back to the General tab, and Select VM Network > Remove. This removes the VM port group for vSwitch1.
Now click Remove above vSwitch1.
You should now be at the original condition, with your vCenter and SQL VM’s successfully moved over to your dvSwitch.
Go back to the ESX host > Configuration > Networking > vNetwork Distributed Switch button > and re-add the borrowed vmnic back as an additional dvUplink in “Manage Physical Adapters.”
I found an old post over on @jasonboche‘s blog from back in 2009 talking about this, and it’s something I think we’re all hoping they fix with the next release. I could potentially see running the vDS as an OVF appliance, but the reliance of the vDS on vCenter being up and running is a big problem, and I think they’re aware of that. With all of the searching I did, I found explanations as to what the problem was, but was unable to find any step-by-step walkthroughs, so I thought I would post one up myself.
Hope this helps in the future as people continue to run into this problem.