I have never used vSOM but i am guessing this is just a bundled version of vrops.
If this is the case the main thing is all objects will be classed as new when you move them to the new vcenter and you will have duplicates until the history and deleted items time set in the golbal settings expire the object
depending on how your custom groups are created will determine if your policies will get applied
We just when through this but we have all our groups set as relationship, descendent of the CDC. All we had to do was remove the old vcenter cluster object from the CDC and add the new vcenter cluster object and the clusters, hosts, VMs and datastores got there correct policy without any further configuration
It's still vROPS, vsom just gives bundled licenses.
I went from 5.5 windows vc to VCSA deployment. I left same IP's and name so I didn't have to re-target, just kind of reconfigure due to certificate mismatch.
Anyhow, yes, no issues and 100% continuity on data for vcenter collector.
To answer your question, if you build a *new* vCenter and just swing the hosts, this will throw vROps (regardless of how that came purchased and packaged in vSOM or stand-alone, or vRealize Suite, or etc.) into disarray. This is due to those VMs getting all new reference IDs owing to them being managed by a new, different vCenter. If you don't want this to occur, you should upgrade your vCenter instead (yes, an upgrade/migrate to the vCSA counts as an upgrade here).
To follow onto this, as we will be doing something similar soon:
I'm relatively green to all of this, so please forgive me going in the wrong direction.
I read about a utility for doing something similar with veeam, where morids on objects get changed due to various reasons (such as building a new vCenter in this thread), and importing the pre-existing VMs. https://www.veeam.com/kb2136 Obiously this utility is veeam specific, and likely rewrites old morids in the veeam database to match the new morids in the new vcenter.
So the question is, what might this script (I don't have access to this if it's a plaintext thing I could read) use to determine the old morid is related to the new ID (such as possibly bios_uuid), and is there write access against the vROps database to be able to change the references for each VM to point to the new morid? Knowing ahead of time, it would at least be easy to dump a list of morids and whatever other uuid would be necessary (or easily usable) prior to the VMs being moved between vCenters (and NOT migrated, which would presumably preserve the morids for us if that method were used).
I'll keep digging on my own, but starting from scratch I may be barking up the wrong tree.
The operative piece of information here is that utility is specific to Veeam and can't be modified to point to vROps. There is no supported way that I've ever seen to perform the same type of thing for vROps, so it's either build a new one and let old data age out of the existing one or upgrade the existing one.
Certainly didn't expect to be able to modify their script, but was just curious as to what information they were using to say 'VM with ID-X used to be VM with ID-Y'
Let's assume then that there is no access to editing things in vROps. What information does vROps use to identify the object it is tracking?
If it is ONLY the MORID, then it wouldn't be able to track objects across multiple vCenters (as uniqueness is only guaranteed per vCenter)
If we can edit morids by hand on a vCenter (maybe not possible?), we could manually reset all objects to their original morids from the old vCenter. Then we would just need to know whatever else is used by vRops to make it appear as the old one. This would be performing no operations against vROps itself, and only modifying the new vCenter and its objects. Obviously just ideas (I did not see many threads releated to this here to see what anyone has even attempted at this point).
Thanks for the super quick reply too.
My understanding is that this is being addressed for a future release.
This means a vm being moved from one vcenter to another ( vmotion or clean migration) the vms will retain there IDs. If you think about it they will have to do something now there is a cross vcenter vmotion and VMware on AWS.
No idea on when this will be in