VM Instance Identifier Question

[Todd_Goodhew]

When running Cloud Discovery on AWS, I've noticed something I'm not understanding when it comes to VM Instances.

This problem occurs out-of-the-box.  Yes, I know this OOTB as I can reproduce in my Personal Developer Instance that is clean.

The Identifier for VM Instance shows ONLY Object ID.

If we have a record in the VM Instance table already and that record only has a value in the Object ID field or the VM Instance ID field, then Cloud Discovery creates a new record.  

If we have a record in the VM Instance table and that record has BOTH Object ID and VM Instance ID field completed, then Cloud Discovery updates the record.

This is where I am confused.  The identifier for the table only requires Object ID, but when Cloud Discovery is running it is matching both Object ID and VM Instance ID.

Why is this occurring?

[Ganesh Bhat]

Hi Todd The reconciliation engine uses two things to decide if it needs to create or update a record 1. Object Id and type of the entity 2. Relationship of that entity to LDC and service account. If these are properly set in the existing record, then only entity will be updated, else new one is created. Can you please elaborate on how the existing record in the table is created? Do you have correct relationship to LDC and Service account from that CO?

[Jayant Kaushal · Accepted solution]

Todd,

the reason is,

Due to legacy reasons, the Provisioning and discovery go through different paths,

The VMWare discovery goes through Probe and Sensor which which are not very strict about Identification rules, thats why you have to populate VM Inst Id too so that discovery can identify right VM,

In case of Provisioning and Day2 operations, all persistance call go through Response Processor which strictly adheres IRE, IRE it not only considers the uniqueness of object_id in a VM but also considers the Hosting relationships with LDC.

Simply saying , Provisioning calls will identify a VM based on the VM(object_id) + LDC(object_id) + SA(object_id) identification. 

[Todd_Goodhew]

Ganesh and Jayant,

Thanks for the insight.  This helped out very much.

Our manually created records did not have a relationship to the LDC + SA.  This was the critical piece I missed.  It does make sense on why it is needed.  I added the relationship and retested, problem gone for this issue.

Now I have a related problem.  When running Cloud Discovery on AWS, do we include just one region or any region we have instances?  The reason I ask is we have all our VMs in us-east-1 and no VMs in us-west-1.  However, when I run a test on us-west-1 I expect to get no results...that LDC is empty.  I get back all the items I already have in us-east-1, but now they show as related to us-west-1.  Which results in more duplicate records because there is no match for that LDC on any existing records.

Any thoughts on this other duplication issue?

[Ganesh Bhat]

Hi Todd,

When running Cloud Discovery on AWS, you are allowed to choose any or all the datacenters it shows. 
You are talking about a case where the CI getting associated with invalid datacenter, this shouldn't happen in typical case.
We will need to see logs and inspect instance to get insights and suggest you the solution.

Have you also manually created Logical Data Center/Location and does it have proper value and relationship?
( This could be the only reason why the IRE engine associate newly discovered CI with improper data center )