VMware Cloud Community
JasonES
Contributor
Contributor

Replacing vCenter

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?

Thanks!

7 Replies
sxnxr
Commander
Commander

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

Reply
0 Kudos
edgarasdjhsa
Contributor
Contributor

Hi Jason,

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.

Reply
0 Kudos
daphnissov
Immortal
Immortal

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).

Reply
0 Kudos
BrettK1
Enthusiast
Enthusiast

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.

Reply
0 Kudos
daphnissov
Immortal
Immortal

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.

Reply
0 Kudos
BrettK1
Enthusiast
Enthusiast

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.
Reply
0 Kudos
sxnxr
Commander
Commander

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

Reply
0 Kudos