We are going through a migration project to move from legacy vCenter 5.5 instances (existing vRA 7 Endpoints) to new vCenter 6 instances and new compute and Storage DRS clusters
Migration will be done via swinging the ESXi 5.5 hosts in the legacy 5.5 vCenters into new vSphere clusters in the v6 vCenters, and recreating the storage DRS clusters.
We are planning on having the new vCenters configured as vRA 7 endpoints in advance
We will also be creating new vRA7 reservations from the new vCenters and new compute/storage clusters, and explicitly mapping the new reservations to the same vRA 7 reservation policies as-per the original reservations that the virtual machines are currently assigned to in vRA.
Once all hosts and VMs are migrated, we will look to decom the existing reservations on the old vCenter 5.5 endpoints, and then decom the endpoints.
Can anyone provide any feedback on this process, specifically the following questions:
1. Will we need to manually run the "Change Reservation" option (under Managed Machines in the vRA web portal) for each VM after it has been migrated from the old vCenter 5.5 to the new vCenter 6?
2. Could the process above cause any impact to vRA functionality?
3. Is there a better or improved process to that described above (e.g. a vRO workflow) available?
Many thanks in advance for any info ....
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!
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.
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.