We just started the implementation of Commvault in a brand new VMware environment. Now I'm seeing already an increased amount of duplicate client computers in our environment causing some administrative nightmares and management challenges.
So I started investigating it and discovered the UUID registration to differ from what I'm used to when comparing it to AWS. It appears the registered UUID in Commvault is actually the so called PersistentID/InstanceUUID and this one can't be tracked back from within the VM itself. The UUID that is shown from the OS corresponds to the VMware BIOS UUID.
We installed some client agents first followed by the configuration of the VSA agent. Both are being used actively.
Fixing duplicate client names is an annoying tasks, especially in MSP environments and I'm puzzled this hasn't been fixed by Commvault. Because when you would use the combination of Commvault client name + BIOS UUID and the name that can be read by the client including UUID than matching them together to perform auto-merges could be made possible or at least offer some ways to influence the merging process.
So can someone explain why Commvault is using the PersistentID/InstanceUUID?
Are there any developments around this topic that we can expect?
Can you influence the behavior from a platform administration point-of-view?
Would it be possible to also track the VMware BIOS UUID?
I know the BIOS UUID might changes when the VM is moved or cloned but in the case it is moved you will also pick up the change from an OS perspective. When the VM is cloned than the client name will also change.
VMWare suggests to use Instance UUID for determining the uniqueness of VMs within the vcenter.
- can you please escalate the case with the DB staged to see why we end up creating duplicate clients?
- This is the script to correct duplicates, but we need to analyze why we are ending up in duplicates in the first place.
https://kb.commvault.com/article/63652
Hi
Yes, I understand VMware recommend to use the instance UUID and t.b.h. it's also not a VMware issue but something Commvault should be able to fix without the use of workaround through scripts and reports.
If the instance ID is used than you should be able to talk to vCenter and leverage the instance UUD to extract the BIOS UUID which than can be matched automatically using the Commvault by requesting the UUD from the OS. This can be matched using the name of the VM.
Running post scripts is not really user-friendly imho and especially in MSP environment it just raises questions in addition it results in lots of added complexity for example if you want to setup billing as instances are counted twice (VOIprotected VMs).
If it happens again which it will than I'll open a ticket for it.
Onno
Hi all,
Not sure it is the same behaviour or use case, but I’m just discovering the VSA on Azure now (I almost always operated it with VMWare).
Had an intellisnap Azure VSA backup of multiple VMs. Ran backup copies.
Tried to restore IN PLACE one VM from its backup (I mention it : from the Azure snap, not the backup copy), all went fine. Next backups went fine.
Had a look at my Commvault Azure VM inventory, then for the same VM in the inventory, I had 2 VMs. One from before my restore, and a new one with same name (of course) from the backups after my restore operation.
I had to navigate through Command Center to find the subclient containing the VM, then navigate, navigate, navigate (yes I forgot the so multiple steps..) then managed to delete the ‘old’ VM from Commvault’s inventory of my Azure Hypervisor, confirming with a Delete manual typing.
If this tasks could be eased a bit (there’s a lot of potential progress, IMHO), then my backup administrative tasks would also be a lot ! 
Hi all,
Not sure it is the same behaviour or use case, but I’m just discovering the VSA on Azure now (I almost always operated it with VMWare).
Had an intellisnap Azure VSA backup of multiple VMs. Ran backup copies.
Tried to restore IN PLACE one VM from its backup (I mention it : from the Azure snap, not the backup copy), all went fine. Next backups went fine.
Had a look at my Commvault Azure VM inventory, then for the same VM in the inventory, I had 2 VMs. One from before my restore, and a new one with same name (of course) from the backups after my restore operation.
I had to navigate through Command Center to find the subclient containing the VM, then navigate, navigate, navigate (yes I forgot the so multiple steps..) then managed to delete the ‘old’ VM from Commvault’s inventory of my Azure Hypervisor, confirming with a Delete manual typing.
If this tasks could be eased a bit (there’s a lot of potential progress, IMHO), then my backup administrative tasks would also be a lot !
Unfortunately I have no idea when this CMR is picked up.
Yes
I approve this time saving CMR 
Thanks
Hi Mike, the CMR number is 310541. It is still set as on roadmap. I also added an addition request to add information that shows instance creation date/time (from a hypervisor perspective) and discovery date/time which corresponds to the time in where it was discovered for the first time.
Some information has been added already like the UUID. You will have to expand the information that is displayed in the overview screen. But again…….. so annoying is that you can't search for a UUID.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.