I have an existing vSphere environment with a VSOM appliance attached. Currently vCenter is running on Windows, and we're planning to just build a new PSC and vCenter appliances from scratch, and then import the old ESX hosts. I've done this a number of times, but never in an environment with VSOM. What implications are there here that I should consider? I'm wondering if it's a simply matter of just attaching vSOM to the new vCenter since all the objects inside will be the same otherwise?
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.
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