2 of 2 people found this helpful
For P2V you probably have a different serial number, so reconciliation can't uniquely identify the server if nothing else changes and you don't include this value. I think the merge operation wouldn't work if you were less specific and just wanted the new virtual system to update the old Asset record as there would be 2 records in BMC.ADDM (and the physical record is still tied to the Asset record).
For the original EOL system, maybe have as part of your change management ticket for the P2V process, one task to set the old record to End of Life or perhaps some other meaningful status, maybe MarkAsDeleted after you see both records if you want it out of your Asset Dataset. Add another change task to scan the new virtual system which hould get your new record in. Another consideration here is that any relationships you've made from the old CI to other tickets, changes, people, etc wouldn't be on the new record.
If you wanted to keep all that, you'd probably want to set the MAD flag in BMC.ADDM and manually identify the new virtual record with the same Recon ID as the one in Asset, so then the new system updates the old record. Set the reconID for the old physical one to 0. This isn't meant as a blueprint on how to do this, just some thoughts.
For the SI keychange - this is a bit more difficult because you may not be expecting this to happen necessarily, so you'd just end up with duplicate data and an Asset record that stops updating since we no longer have a unique match for the ID criteria in BMC.ADDM.Monitoring the CMDB reconciliation logs for Identification errors about non-unique records would help you find these.
Thanks for taking the time to respond to this post. We've discussed internally and come to a similar conclusion - that there is no easy way to avoid temporary duplication in the asset dataset where one CI has become superseded. As you suggest, we could fast-track MAD by manually destroying nodes as part of the CR workflow, but that doesn't resolve the actual challenge we have: an SI in Asset that has federated data linked to it should retain its federated data in a P2V event (or any event that triggers SI key change). That said, I've forwarded your suggestion on setting the reconID to 0 to our CMDB guys.
I feel that we will have to rework the CMDB/federation workflow simply because Discovery CI's are ephemeral - however much we would rather they were not. Another example on expectations: the team would like a DR SI failover to happen transparently with no impact to the existing SI CI in Asset - only a relationship change from SI to Host. It probably needs a different approach.
Anyway, thanks again for your reply.