Solved

VMware UUID / duplicate client computers


Userlevel 7
Badge +19

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. 

icon

Best answer by Onno van den Berg 17 May 2022, 10:41

View original

10 replies

Userlevel 7
Badge +23

@Onno van den Berg , checking with our dev team and will get a reply here (edit: and they did!).

Userlevel 2
Badge +3

VMWare suggests to use Instance UUID for determining the uniqueness of VMs within the vcenter.

  1. can you please escalate the case with the DB staged to see why we end up creating duplicate clients? 
  2. 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

 

Userlevel 7
Badge +19

Hi @Bhama,

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

 

 

 

Userlevel 6
Badge +15

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 ! 😁

Userlevel 7
Badge +19

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 ! 😁

@Laurent short summary if I interpreted it correctly is that it is hard to troubleshoot duplicate VM objects via Command Center, right? I can confirm this as well! To ease this we filled a CMR to pull in much more information from the hypervisor into Command Center like the UUID. But also information like the creation date of the VM and for example offering information. The combination of information like UUID and creation/install date would make it very easy to see which VM was the one that was restored. 

Unfortunately I have no idea when this CMR is picked up.

Userlevel 7
Badge +23

@Onno van den Berg any chance you have the CMR number?  I can take a look 😄

Userlevel 6
Badge +15

Yes @Onno van den Berg that’s my problem, and the suggestion to get all the information at the same page would be a real improvement, as it takes too many clicks/navigations to check the information one VM by one..  

I approve this time saving CMR 👍

Thanks @Mike Struening if you can get it moved closer to the top of the pile of CMRs 😁

Userlevel 7
Badge +19

@Onno van den Berg any chance you have the CMR number?  I can take a look 😄

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. 

Userlevel 7
Badge +19

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. 

 

 

Userlevel 7
Badge +23

@Laurent , if you can pm me a CCID, I can add your name to it 😎

Reply