This is a bit of a tricky one. I think you understand the two scenarios here and the different results, depending on whether your target dataset has the CI in question or not.
If it doesn't match in BMC.ASSET, your current identification rule is configured to auto-identify the source dataset CI, which is why the two CIs get assigned a recon. id each and then create duplicates when merged into BMC.ASSET.
If it does match in BMC.ASSET, the recon. id from BMC.ASSET is copied to the first one, and then again to the second one. When this second one gets the same recon. id as another already in the source dataset, you get the error about trying to assign the same recon id etc etc.
You can turn off the auto-identify option for the source dataset in the ID activity. Any non-matches remain unidentified (i.e. they don't get a recon. id, and won't get merged to BMC.ASSET). This will stop your duplicates CIs in BMC.ASSET, but neither CI will get to BMC.ASSET until you manually identify them. The manual ID action would spot the dupes in the source dataset and you can deal with it then.
Or, you can run some sort of pre-validation on the source dataset to find and fix these dupes. In theory, you should not have dupes in the source dataset, in terms of what your identification rule is designed to define. i.e. if you say you will natch of field A and field B, then you should be 100% sure that no two CIs have the same values for A and B. Clearly in your case, they do.
Finally, and probably the most reliable option to make this work no matter what - you need to look at the data more closely, and find one or more additional attributes available to you, to add to the ID matching rule. This is sometimes harder than it should be, but it's the only safe option.
Since these are virtual servers, there will usually be a partition id, or if it's VMware, some unique id (UUID/GUID) that will differentiate the CIs. It's a bit odd that both CI name and host name are duplicated. ADDM would not normally do that. We may need to dig a bit deeper into that side of things to get to the bottom of this one.
I think, What you have explained is expected behavior of Recon activity. All you need to do is to analysis such CIs, You can export both CIs and match their Attribute value. There must be some difference, if these CIs got populated by some discovery tool like Addm. if you find these Cis are really having same every attribute value and not required, Then you can go for duplicate deletion/turn off auto identify/Change identification rule. Also, you need to check why/how 2 CIs got created with same value for every attribute( if such got created by some discovery, then there must be some difference)
Thank you Carey and Anuj.