commvault.com commvault.com
Solved

socket licensing dilemma

  • 27 May 2021
  • 2 replies
  • 213 views
I
Rank
Badge +5

Hello all,

the topic at hand is well discussed here in parts.

Other that discussed there, we have a slightly different situation. Here, VMs which consume socket licenses from old / non-existing Hypervisor hosts are decomissioned as well. Hence a Full / Synth Full, which would release the license, is not possible.

So deleting the jobs would be the only way? For yearly backups of those VMs this is not an option. What would be the best way resolve this? Would creating a new subclient and moving the VM to that be a good way? 

Any other ideas? All help is appreciated.

Thanks.

icon

Best answer by Stuart Painter 27 May 2021, 14:12

View original

2 replies

S
Rank
Userlevel 7
Badge +15

Hi @Ingo Maus 

Thank you for the question.

The only method I am aware of for a VM to release a socket license is to perform a new Full backup with that VM hosted on a different hypervisor host.

Only once all VMs with backups attributed to a hypervisor host have new Full backups on other hosts will the socket license be released.

Synthetic Full job isn’t enough as this is purely a backend process, the latest Full backup is the one that hold the socket license and only a Full backup will interact with the VM client and hypervisor host.

If you have a situation where a VM has been decommissioned - so no new jobs can be run - please raise a support case so that we can thoroughly investigate and check to see what action can be taken.

Thanks,

Stuart

Customer Support
I
Rank
Badge +5

Hi, here’s another way: once you have identified the VMs that are hooked to the old hypervisor host (license-wise), you can disable Backup Activity manually and individually. That is done from within the vCenter object under Client Computer in the VSA Instance.

The report used here to identify the VMs is the “VM Backup” report (Cloud download)

 

Reply


Terms & ConditionsCookie settings