Hey @Tom Evans -
Check out this KB: http://kb.commvault.com/article/63652
Causes
There are some tips in there to help prevent it from occurring, but a mismatch between the physical agent and the VM hostname queried from the hypervisor is usually the cause.
Hi @Damian Andre,
I know CommVault believes this is an issue with external factors and there are ways to solve this with manual intervention (kb article), however it is not very (end) user friendly.
I have been thinking about this topic for a very long time already and initially I just didn’t understand why CommVault has not automated the merger of such clients as it is quite easy on any system to find the uniqiue identifier (GUID in VMware, BIOS Serial number on a physical system, instance id in Amazon, etc) and alleviate this very annoying situation for our customer/user base.
I have however been thinking further along with the recent addition of the “display name”. What I simply do not understand is why CommVault still forces a ‘name’ as a unique entry point. It would make our lives as admins, but also end users with no CommVault knowledge, so much easier if CommVault would change their clients to use a truly unique identifier per system like I mentioned above.
That solves the _1 naming issues for 1, but if we then come back to the “display name” idea and make that more powerfull by being a dynamic entity that connects components together (1 to many relation) based on client name, FQDN, ?tags?, etc you get the best of all worlds if you ask me.
Let me know what you think as I am thinking of opening a CMR for this to get this very annoying long standing CommVault created issue gone for good.
Regards,
Mike
Hey @mikevg - it's been a long time since I explored this topic, but there is a chance of data loss if you make a bad assumption and merge histories with an existing client. Many scenarios are automatically taken care of, but the ones remaining which require manual intervention are those that come with some uncertainty.
I’ll raise it internally again to see if there is anything planned - but putting in a CMR is a good starting point in either case.
I understand the client name duplicates with _1 however bit confused about when the host name has a _1; a customer migrated a VM from one cluster to another using a replication product; we were backing up both the clusters so it meant backup ran for both the VMs on old and new cluster; however now although we have 2 duplicate client names; the new host name has _1; the client had SQL agent installed as well; the VM is in shutdown state on the old cluster and running on the new cluster; SQL backups are running however and showing against the old client; the VM backups are showing against the new client with _1 against the hostname.
Is the merge command going to work here as both clients have the same name; also would the history for the powered on VM merged against the switched off VM as it is still showing up in the console and has SQL agent and backups