Solved

Export history Backup client VSA to a new client VSA "VMWARE"

  • 27 January 2021
  • 5 replies
  • 141 views

Hello, 

my configuration : 

Detect configuration from Commserve : 
vsa client vmware  : vcenter1 
OS : Windows Server 2012 R2 
Indexing Version : V1 
Virtual Server : Working behind Proxy MEDIA 
Check Readiness : Not Ok because OS Version isn't Windows
Backups scheduled tasks : working fine

Actual configuration : vcenter1 
OS : LINUX VMWARE 
 

An idea to update os version on Commserve client vcenter1 and keep backup history and configuration subclients  ? 

i try it this solution provide from Commvault : Clone Client Dataset 

https://documentation.commvault.com/commvault/v11/article?p=110180.htm 

But didn't work 
 

Force to deploy a new vsa  client and reconfigure everything and also lose the unified backup history to receive checkreadiness status  OK ? 

icon

Best answer by MichaelCapon 27 January 2021, 16:13

View original

5 replies

Userlevel 6
Badge +14

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

 

 

Userlevel 7
Badge +23

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.

Userlevel 6
Badge +14

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

Reply