You are correct about *why* it occurs. If the serial number, uuid, etc are matching, then Discovery assumes that the two instances are the same Host.
Differing IP addresses are not sufficient to decide that the Host is different.
What else is different? mac addresses?
Use this query to see what is different that could contribute to uniqueness ... change the 'abc' to your own host name.
Or, for two host names, you can do this: where name in ["host1", "host2"]
Search FLAGS(include_destroyed) Host where name matches 'abc'
show name, key, uuid, serial, partition_id, zone_uuid, hostid, zonename, os_type, type, hostname, __all_mac_addrs, virtual,
destroyed(#) as 'Destroyed?', friendlyTime(destructionTime(#)) as 'DestructionTime', last_update_success, age_count, friendlyTime(creationTime(#)) as 'CreationTime'
This search won't work as Disco is not creating the 2 hosts.
As noted in my original post though, the unique identifier is Instance UUID. That is what should be used.
Yes, I see my answer didn't make sense ..
So, UUID is unique. But, serial# is the same. And, I guess the host name and uuid keep flip-flopping as each VM is discovered.
Since UUID is different, and serial number is the same ... if nothing else was the same, then you would get 2 Hosts.
This topic gets into the nitty gritty of our identity algorithm.
Tell me about these attributes. Do they match, or are they different:
If any of those things are matching in addition to serial#, then I think you will get a new Host.
Use the query above once in the current state.
Then, scan the other IP address so that the attributes flip-flop. Then, run the query again.
Compare the attribute lists.
Or, you can "Show History" for the host to see which attributes change between scans.
You should open a case, IMO, for deeper analysis / and discussion about the problem... so we can see why it occurs and determine if we can do something to correct the problem.
UUID is NOT unique. Instance UUID is. Serial # appears to be built from UUID of the discovered virtual machine and that is what vmWare has said can be identical. But Instance UUID which is different than UUID, is in fact unique regardless of the vCenter a VM is deployed in.
UUID = same
Instance UUID = different
Serial # = same
IP Address = different
hostname = different
Can't see hostid, zone_uuid, or poartition_id and compare because Discovery is not creating 2 hosts. The data above is what I can see when looking at the Discovered Virtual Machine node.
So, what happened is someone 'cloned/copied' the vm WITHOUT changing the UUID.
In this case, the two VMs APPEAR to be the same machine because they ARE the same machine.
To resolve this, you need to change the UUID on one of the machines.
In the future, whenever vm's are 'cloned/copied'....make sure the 'cloning' process changes the UUID of the 'new' vm OR the UUID is manually changed before starting the 'new' vm.
The process to do this (alter the UUID) is different, depending on the virtualization technology used.
Bob, I don't disagree the machine was most likely cloned but it doesn't make it the same machine. They both live on the network under their own name and own IP and have their own set of software installed on them. From a inventory and security standpoint, they are absolutely their own entities. So, I have to be able to account for that.
The question, as originally posted was whether or not anybody else has run into this and if they've figured out a way around it.
I think everyone knows the problem when VMs are cloned. We have adapted the clone process and change the UUID on the fly.
Thanks Stefan. It sounds like that will have to be our fix. The good news is this only seems to be impacting a couple dozen VM's at our site so should not be a big problem to have the teams address.
Thanks for the feedback.
I find your information interesting. If BMC adapts the detection of new VMs to the VMware idea, we could do without our adaptation. Wouldn't be bad either.
1 of 1 people found this helpful
So, "Instance UUID" is unique. Discovery doesn't even discover that, correct?
In order for Discovery to allow your situation:
First, Discovery would have to discover "Instance UUID", and second, Discovery would have to utilize "Instance UUID" as an important attribute when deciding on Host Identity for a virtual host.
What kind of node are you showing in your screenshot?
I searched for instance_uuid attribute in the patterns, and it is set by TKU patterns on a SoftwareInstance.
And, I see instance_uuid in the Taxonomy as an attribute of a DiscoveredVirtualMachine node.