CI Identifiers - Hardware rule match on Serial Numbers

[cyked]

I noticed two "issues" in our dev instance the other day with the updated identification rules.

Rule 1 is correlation ID

Rule 2 is Serial Number and Serial Number Type

Rule 3 is Serial Number

I swapped priority on Rules 2 and 3.   Here's the issue I ran into.   While we do not expect server names to be reused, they are not unique and are not a key to match on, at least not at a higher priority.   And we have ran into an issue with VMs being built with previously used names.

Situation:   Server engineer is building new VMs, so we are not starting with Asset Management in this example.   Server engineer has reused some previously used names from some retired physical servers.   On discovery of the new VMs all the higher priority rules failed, those serial numbers didn't exist on any Server CI records nor the serial numbers table, but instead of creating a new CI as we would want the existing Server CI records were updated because they Identified on name. This changed the serial numbers on the CI records from a physical to a VMware one, updated every of discovered server detail (like OS version, memory, etc) and updated the asset records which changed the model information (no bueno).

The "fix" would seem to be inactivate the Name rule for Hardware, leaving only correlation ID, SN, SN/SN Type as the actives.   However, we have a few classes/types of devices like SilverPeak WAN Acc devices for example which through SNMP report a non-delimited MAC address as the serial number, which is not the serial number we receive from a seller through asset purchases, so they match on Name when serial numbers fail.   I imagine then I would need to create "sub-hardware" rules for say cmdb_ci_wan_accel_network that would also go through correlation ID, SN, SN/SN Type + Name to ID, yes?

The second "issue" has to do with the Serial Number rule.   Previously, Identification would do the following: source

• If there is no match to an existing configuration item (CI), Discovery creates a new CI.
• If there is match to an existing configuration item (CI), Discovery updates that CI.
• If multiple matches exist based on a complete match, Discovery stops for that IP address and logs the event.

What I see now is that when two servers exist (names can be the same or not) with the same serial number one of the records is "just updated" out of the pair.   I'm not seeing a clear pattern to it.   Are there still scripts behind these new Identification rules or something else going on in the background doing more than just matching on Serial Number?

[adilrathore]

By default it is the Serial Number is the default choice to identify hardware items.   However, in case Serial Number is not present a fallback mechanism for name exists. In case you do not want to use name as a fallback mechanism you may have to create rules for the tables that would still require 'name' as an identifier.

For details you can refer to the below article and discussion on Community blogs:

CMDB Identification and Reconciliation

There is one good video on CMDB Reconciliation as well here:

CMDB Identification and Reconciliation Framework - YouTube

[bluefunelementa]

This is why we decided to use a new field to represent UUID and to add a CI Identifier for that. Now physical servers match on serial and virtual on UUID.

[cyked]

Hi Christian, I want to make sure I follow.   You created two new Identifier with new rules, one for Physicals one for VMs and differentiated which type of serial number on the serial number table to use - UUID for VM and System for Physicals?   Or something else?

[bluefunelementa]

Ha - not going to let me just leave it at that are you 😉

we actually dont separate the ec2 records into both virtual instancar class and windows or UNIX server classes. so for our cloud migrations we end up with an older physical server record we want to decommission and a newly created ec2_instance record we use going forward. While we can target our CI identifiers per class, uuid for virtual and serial for hardware, you might have to order yours right within the hardware rule.