There are three ways to reconcile entities within TrueSight Capacity Optimization (TSCO):
  (A) (10.7.01 and later) VMware Automated Reconciler
  (B) The TSCO Reconciliation UI
  (C) The "On Demand Entity Reconciler" using the "mass reconciliation" process.

Unfortunately there is no "one size fits all" solution when it comes to entity reconciliation -- it is very important to consider the reasons that two entities are being reconciled together and to understand whether those two entities really represent the exact same thing in TSCO.

The VMware Automated Reconciler system task can be used to quickly reconcile VMware entity duplication created due to vCenter migrations or VMware cloning. For VMware host and guest entities this should be the first place to consider for VMware entity reconciliation.

Information regarding the VMware Automated Reconciler can be found here. For newer TSCO versions visit the documentation that correspond to the version that you are looking for.
  
In general, when doing an entity reconciliation, you want to make sure of a few things:

1. Make sure that both the 'source' and the 'target' entity have the same "Entity Type".  These are exceptions to this rule for Generic CSV or SQL extractor ETLs (which may create an entity of type 'Generic', but that entity really should be mapped to another entity that already exists in TSCO and was imported by an out-of-the-box ETL).  But for all of the out-of-the-box ETLs if the "Entity Type" is different, then those entities really shouldn't be reconciled together
2. Make sure that there is no overlap between metrics being imported concurrently by the two different ETLs before reconciling the entities together.  So, if an entity is being reported by the SCOM ETL or the OEM ETL and an entity with the exact same hostname is being reported by the vCenter Extractor Service, those entities should not be reconciled together because all of those ETLs import the CPU_UTIL metric.

The most typical scenarios where entity reconciliation is required are:

1. Migration of vCenter from one host to another
2. VMware guest entities that have been "cloned" and replaced.

In the vCenter migration scenario, all of the entities will be duplicated as the vCenter UUID is part of the unique key that defines an entity.  So, whenever entities are moved from one vCenter to another that will result in that entity being duplicated in TSCO and a reconciliation will need to be run.

The VMware guest "clone" scenario is something we see a lot in the field as well.  When looking at the "Lookup" table for the two VMware guests the "NAME", "HOSTNAME", and "UUID" are all the same, but the VMW_VMREF (VMware Managed Object Reference ID) has changed between the two entities (and this is part of the unique key for an entity in TSCO). If you see that data stopped being reported for the original entity and then started being reported for the new entity, that is a good sign that the VMware Administrators "cloned" the VM, stopped the old one, and started the new clone.

The following KA describes the process to use the Reconciliation UI to reconcile VMware entities:
  000120932: In TSCO 10.5 how can I reconcile VMware data that is moved from an old vCenter to a new vCenter? (https://bmcsites.force.com/casemgmt/sc_KnowledgeArticle?sfdcid=000120932)

There is a process to do a 'mass reconciliation' of entities based upon a SQL query that maps the two entities together based upon a rule.  Contact Technical Support for more information on this SQL based reconciliation process.

For example, one important consideration is which entities can, and should, be reconciled together into a single entity.  For example, sometimes there will be two entities in TSCO that have the same display name but one entity comes from the Microsoft SCOM ETL and the other comes from the vCenter Extractor Service ETL.  Those are entities that should _not_ be reconciled together because they have different entity types.  So, the SCOM ETL is going to import data for entity of type 'Generic' and that data is going to be a view of the VMware entity from within the guest OS (a virtual view) but the vCenter Extractor Service is importing an entity of type 'Virtual Machine - VMware' and that is a physical view of the system from vCenter.  So, although those computers have the same name in TSCO they should not be reconciled together into a single (a single sysid) within TSCO.

In general the recommendation is to use the "Entity Reconciliation" UI to execute the reconciliation.  In general one of the safest ways to do a reconciliation is:
 

Note

• It is impossible to reverse an entity reconciliation -- so, once those entities have been merged there is no way to split them back out.
• VMware Automated Reconciler system task does not reconcile VMware Cluster entities.  This can generally best be done via the Entity Catalog Reconciliation UI.

Additional Information

Q: Will data be reconciled from the newer sysid back to the older sysid?

Reconciliation always reconciles data from the new entity (higher sysid) back to the old entity (lower sysid).  That behavior is outside of the user's control.  Once the reconciliation is complete there will be a single entity in TSCO that represents both the historic entity and the new entity as a single entity.  So, all the data and the lookups should have been merged together to a single entity.

Q: How does reconciliation affect workspace domain relationships?

The reconciliation process takes two separate entities and merges them together into a single entity.  That means that all of the data will be consolidated (from the two previously separate entities) together into that single combined entity, but also everything else about the two entities will be merged as well (the lookups, the relationship).  What that means is that when you are done with an entity reconciliation if you previously had two separate entities that each resided somewhere in a workspace domain then when you are done you’ll have a single combined entity that still has both of those previous relationships within the workspace domain.

So, if before you had:

Domain A
  - Entity 1 [sysid:123]
Domain B
  - Entity 1 (new) [sysid:456]
 
When you are done with a reconciliation you’ll have:

Domain A
  - Entity 1 [sysid:123]
Domain B
  - Entity 1 [sysid:123]
 
So, the reconciliation will merge the two entities into a single entity and the relationships defined for the entity will continue.

One potential problem seen historically is where the relationship for the ‘new’ entity has been lost during the reconciliation.  That would mean in the above example the combined entity would end up only existing visibility in ‘Domain A’ in the tree (where it had been previously).  If that happens if it necessary run a “Restore Relations” to make the combined entity visible again in ‘Domain B’ (all relationships are supposed to be maintained but the reconciliation sometimes ‘hides’ the relationship that exists for the entity being reconciled away).

Q: If the name of the current entity is different from the name of the historic entity, which name will the reconciled entity have?

It is uncommon for the name of the current version of the entity to be different than the historic name of the entity, but it is possible.

Since the historic entity is the target of the reconciliation (that is the entity that will remain when the reconciliation completes) the name of the older historic entity will persist.  If it were desired to have the name of the combined entity match the name of the newer entity in TSCO the best workaround option would be to correct the name of the reconciled entity after the reconciliation has been completed.  This could be done via the TSCO UI.  Alternately, a custom process could likely be developed, particular for a SQL based reconciliation that could update the name of the combined entity after the reconciliation has completed.