Skip to main content

Background story:

  • IHAC who upgrade VMware environment (from 6.0 to 6.5), copy VMs from old environment (vCenter/ESX) to new, so need to change Commvault side to change access path to vCenter at client level.
  • Problem here, one VSA client has multiple subclients which contain some VMs as contents, these VMs are not migrated at the same time, so we cannot change vCenter access path until we migrate all VMs to new environment, because of that there's a request to copy subclient information "one-by-one" to new VSA client (how to retain job sequences would be another topic, slightly complicated per Index versions).
  • We can achieve this by creating new subclients on new client one-by-one by specifying all attribures (contents, configurations, etc.), but some of clients have over 100 of subclients each, so requested automated approach, which could be Commvault Workflow.

Major problems on Commvault automation to create subclients,

  • We're not officially provide exact parameter to generate a new VSA subclient.
  • We're not providing functionality to export configuration as XML from VSA subclient ("Save As Script" feature won't work on this type).
    So tweak need to be done.

By referring entire Commvault logs, we can manage to get the format to generate VSA subclients somehow (quite cumbersome), but problem here is to specify "Contents" part. Very simple example as follows (just specifying VM):


Digging more, we can find that this information is stored in CommServ DB like the following:

use CommServ

declare @subclientId int = 98 -- need to identify the specific subclient ID from App_Applicaiton table
declare @xmlbase varchar(max)

set @xmlbase = (select attrVal from app_subclientprop with(nolock)
where componentNameId=@subclientId and attrName='Virtual Server Dyanimc Content')

select @xmlbase -- This is to extract all information for subclient's content data
 

Actual data to specify Contents like the following XML:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<VirtualServer_VMSubClientEntity allOrAnyChildren="0">
<children allOrAnyChildren="1" displayName="Photon 3" equalsOrNotEquals="1" name="528489cc-92c7-33eb-621d-f97cd74d64e2" path="Photon 3" type="9"/>
</VirtualServer_VMSubClientEntity>
 

So, when we craete specific XML parameter to create VSA subclient, we need to include this information in this, need to generate this by ourselves, it's quite difficult to achieve.

So I implemented another way which should not do that (Dont't try this at home, at least full testing on Staging and approval from customer !!), to modify CSDB record itself.

As I mentioned above, we're not providing accurate XML format to generate VSA subclient, but there's a CLI to Clone a subclient which generates clone on the same VSA Client, not different one which we'd like to achieve:

Problem again, this CLI requires Content information in XML parameter file, ... so need to retrieve the information prior to call Clone CLI.

Combining these information, the "Copy Subclient" logic would be something like this:

  • Retrieve Content information from CSDB.
  • Clone Subclient by specifying the Content information in this.
  • Get new subclient ID.
  • Move this subclient to specific VSA Client by changing CSDB record.

 

The first activity like:

declare @subclientId int = ?
declare @xmlbase varchar(max)
declare @xml xml

set @xmlbase = (select attrVal from app_subclientprop with(nolock)
where componentNameId=@subclientId and attrName='Virtual Server Dyanimc Content')
set @xml = (select right(@xmlbase, len(@xmlbase) - CHARINDEX('virtualserver', @xmlbase, 1) + 2))
select @xml.query('/VirtualServer_VMSubClientEntity/children')
 

 

Second one is to call qoperation execute to achieve clone:


After calling Clone CLI, we can retrieve new Subclient ID from Response XML:


Then, change CSDB, with extremely care:

declare @newsubclient int = ?
declare @dest_clientId int = ?

declare @dest_instance int
declare @dest_backupset int

set @dest_instance = (select instance from app_application with(nolock) where clientid=@dest_clientId and subclientName='default')
set @dest_backupset = (select backupset from app_application with(nolock) where clientid=@dest_clientId and subclientName='default')

begin transaction

update app_application
set
clientId=@dest_clientId,
instance=@dest_instance,
backupSet=@dest_backupset,
subclientName=right(subclientName, len(subclientName) - 6)
where id=@newsubclient

commit transaction
 

Note that, it's quite dangerous to modify CSDB (I mentioned in another topic) which would cause catastrophic corruption which won't be officially supported, but sometimes especially at Field we need to do something like this, so this is one of working examples to achieve customers' requests, please have fun 😃

Thanks and regards,

Hello @Takanori ,

Just a thought, had you looked at using the workflow for migrating from a v1 VSA to v2 VSA client?

That effectively clones the subclients from the original pseudo client to a new one. 

I wouldn’t be surprised if it needs some modifications but could be another option.


Hello @Graham Swift , no, this is NOT for migrating V1 to V2 VSA client.
This customer (as you know) is still using V1 VSA client and special demand to migrate subclients one by one to new environment along with the actual VM migration schedule, so needed to copy subclient information one by one.
 


Reply