1. I’d say that the “best approach” (very subjectively) would be to use cloud client in batch mode and migrate everything over.
2. It shouldn't. You may want to pause Data Collections while you are doing this so that it doesn't spew a bunch of errors to the logs. vRA uses the “vc.uuid” value to identify a VM, which is mapped to VirtualMachine.Admin.UUID, and doesn't change on migration to a new vCenter.
3. Not vRO, but let me see if I can throw something together for you with cloud client.
Great - thanks very much Grant
I think the Cloud Client script/function (or going forward a working vRO workflow that remaps all the applicable reservation attributes in both IaaS and vRA 7 postgres DBs in a VMware-supported manner) would be would be useful to a number of customers ...
Yep, that's now officially in my tooling backlog It likely won't be available in time for your migration but you will be (somewhat) pleased to know that your pain will lead to a lot less for others!
Just wondered if you'd had a chance to progress this bit of functionality?
No sure about vRA 7, but in vRA 6 all you have to do is to:
- create a new vSphere Endpoint for your new vCenter - both vCenters have to have the same ID set
- check if the new Compute Ressource is recognized correctly in vRA
- move your hosts & vms to the new vCenter.
- edit reservations, so they point to the new compute resource. Check network profile - network path assignment.
I did this when I had to move all hosts and vm's to a new vCenter and it was done without downtime for clients owning vms in vRA. It was a bit of manual work, but nothing really demanding or risky.
I'd be interested to see if anything has change regarding them method above, with vRA7.
Not yet Justin, tied up on our next release testing at the moment. I'll be starting on this early September, by which time I suspect (hope) you'll be wrapped up.
I'm very new to vRA and am now having to do this same thing and was wondering by the "same ID set", did you mean the two vCenters have to use the same endpoint name, or use the same credentials, or something completely different?
We currently have our new vCenter up, and have moved everything outside of vRA to it. I'm hoping this weekend to try this move.
- I'll have to move my hosts/VM's into the new vCenter.
- Once they are in I'd have to add the fabric group/compute resource
- Edit reservations/verify network
Does this sound right?
Would it be easier/possible to just change the existing endpoint's address to the new vCenter after the hosts are moved? If I didn't have to reuse the existing hosts I could have it mostly up before hand.
We are facing the same issue, and I found this question, I thought i'd follow up and see if there has been any work done on this? If so could you share some details with us?
Just some backstory for our scenario, we were at vCenter 5.5. We had attempted to upgrade to 6.5 using the vCenter migration tool which bombed, subsequent repair attempts left our PSCs broken, our web client inaccessible, inventory service broken etc. We've more or less gotten back to our old, functional 5.5 state now. Now we have decided to just stand up a 6.5 vCenter in parallel and migrate hosts to the new vCenter. As part of that we need to make sure our vRA, vRO and vROM states are successfully transferred over to the new environment. Any help in getting that done would be appreciated.
Hi Grant, we too need to migrate one of our live clusters with approx 700 VMs to a new vCentre and need to ensure the change is transparent to vRA and our customers.
Is there a VMware supported set of work instructions we can follow? I don't mind using the cloud client or the vRO workflow if its available.