Hi Emmanuel,

The VSA Client should just be a Virtualisation Pseudoclient, The VSA Proxy Machine does the work connecting to the vCenter and performing/requesting the operations.

By any chance did you move from a Windows vCenter to the Linux Virtual Appliance? - If so it could be that the VSA Client OSId is wrong in the CommServ DB.

Kind Regards,

Michael

Hi Michael, 

thanks for the quick reply 

exactly yes
current appliance: linux
previously: windows

can we modify this information in the CommServ DB ?  OSId

thanks for all the support

Best Regards,

Emmanuel

Agreed with @MichaelCapon - I am thinking that there is an edge case where you installed a VSA proxy on your vCenter server, which was the same hostname you were using for vCenter in the pseudoclient, and now it is both a pseudoclient but it has a VSA on it.

From memory, ff the vcenter pseudoclient allows you to create a new instance in the UI under it, then that is the case.

This is a little difficult to figure out without seeing it, but I think that uninstalling the Commvault software from vcenter1, and then reinstalling it with an IP Address or FQDN or a different hostname to what it was before, and then assigning that as a proxy in the (now) vcenter1 pseudoclient may resolve the issue.

Agreed with @Damian Andre on this, Without visually checking the set up its a little difficult to fully figure out. - If the software was previously installed on the vCenter then as Damian mentions, You might need to do the “uninstall” of CV Software from vcenter1 client.

In some cases you can update the OSId of a Client/VM with a Qscript (SetVMOSInfo) but I’d suggest validating that with support first. 

Kind Regards,

Michael

Thank you for your support @MichaelCapon  @Damian Andre

Best Regards,

Emmanuel