vCAC 6.1 - adding a second vCenter and migrating all vCAC VMs & Hosts to it (Windows -> VCSA)

[Czernobog]

Hello,

due to some network changes in my org I will have to add a second vCenter to the vCAC environment and migrate the Hosts and virtual machines, which were created up until now, to it. Basically I want to do this:

I've currently deployed vCAC in the form of a distributed installation.

Now I want to add a second, Appliance-based vCenter in another network segment and the following challenges arise:

- The ESX Hosts which were hosting the vCAC VMs would have to be connected to and managed from the new vCenter, there would be no configuration changes at the hosts directly. I assume this could be done in the following steps:

     - take old vCenter offline, also stop vCAC services

     - deploy new VCSA with the same DNS name but different IP as old vCenter

     - disconnect the hosts

     - reconnect them to the new vCenter

     - rebuild inventory (folders, cluster etc.)

     - (re)connect this new vCenter to vCloud using the vSphere Agent (the vCenter IP Address changes, but it would retain its DNS name, the DRS Cluster name would stay the same too), so I *guess* the agent would just reconnect to it and there would be no need to create a new vSphere endpoint.

The question is - could it really be that simple, what am I missing? How will that affect the inventory information in vCAC? Will the VMs be still recognized and reachable by the tenants after a data collection? Or is all the information lost during the transfer, when a the agent-vCenter connection will have to be re-established?

- In the context of the above, is there a need to transfer data from the old vCenter Database to the new one? That would mean a migration from MS SQL to Postgre. The permissions and Inventory structure are relatively simple, I could recreate it by hand or just use Inventory Snapshot to recreate the environment. Performance data and events are irrelevant. A potential problem would arise here - when the inventory (Folder structure, Clusters, dvSwitch etc) is recreated, will it still be recognized by vCAC, but that I mean after the compute ressource data collection?

- There is also an Orchestrator instance connected to the first vCenter, I would have to connected the second one to it too, vCO workglows are essential to the functioning of the vCAC environment. I don't expect problems here.

Thank you for any input!!

[SeanKohler]

Just a couple of thoughts...

Will the guest VMs keep their IP addresses?  How are you managing IP addressing in VCAC currently? Are you using Annotations in vCenter for any of your workflows?

You would definitely have to ensure you "keep" your VMIDs in the transfer.  Obviously need to ensure credentials are setup the same.

Can you snapshot your whole environment for backout?  Do you have the ability to secure professional services?  (might be worth it for a short, well defined effort)

[Czernobog]

> Will the guest VMs keep their IP addresses?

They have to. I will not change anything in the hosts or vm's, they have to stay were they are now, "just" the vCenter between vCAC and the ESX Hosts has Information about the IP reservations is held in vCAC intself, in the Network Profile.

> How are you managing IP addressing in VCAC currently?

External Network Profile

> Are you using Annotations in vCenter for any of your workflows?

Yes, but there are no manual entries, only those done by vCAC during provisioning (VRM Owner etc)

> You would definitely have to ensure you "keep" your VMIDs in the transfer.

That is I think the most important issue. After connecting the hosts and vm's again through a new vCenter, will the appliance still recognize the provisioned cloud vm's?

> You would definitely have to ensure you "keep" your VMIDs in the transfer.

By that you mean the vm uuid? It will change, when I change the vCenter... except in the case when, after deploying the VCSA I would set its UUID to the one of the old vCenter. I would have to test this.

> Can you snapshot your whole environment for backout?

I will most certainly if I decide to push the change:)

> Do you have the ability to secure professional services?  (might be worth it for a short, well defined effort)

If the efforts and risk get so big, that I would not see another way than emply professional services, I will back out of the decision to swap out the vcenter for a new appliance, and will have to go the way to transfer the existing vcenter + ms sql database to the new network segment. That is a lot more work but the risk is lower.

[flynmooney]

I'm looking at a similar situation. Did you figure out how to get this done?

[sbeaver]

I am not sure if I am missing something with your question but let me offer these thoughts.  Your current vCenter is connected to vCAC via the vSphere Agent correct?  Deploy the vSphere appliance and install another vSphere agent for that vCenter.  This is where I get my first question.  Do you have a external SSO server or are you running your SSO on the vCenter server?  I guess in the long run that really might not matter.  Once you have both vCenters up and running and added as an endpoint in vCAC.  Make sure the inventory job has been run.  Now vCAC should know when things move and recover just fine.  In my environment we added a few vCenter appliances and moved hosts and VM's to the new vCenter and once the inventory was run after the change vCAC may the updates automatically.  I am not sure if there were any managed machines that were moved this way to be completely honest so test first please.

There are workflows available to migrate VM to another vCenter and just to add this if you are considering going to vSphere 6 you should be able to vmotion between vCenters

Steve