Skip to main content
commvault.com commvault.com

Hi community,

I am running a large Hyper-V and VMware setup and several admins are editing the subclients.

When we edit two different VSA subclients (for the same VSA pseudo client) at the same time, we get an error message:

→ This property sheet is opened by ‘user1’ your changes may be overwritten by ‘user2’

and wenn the second user leaves the subclient after editing the changes are lost and we get the message:

→ There have been changes made to this subclient or backup set. Please refresh Commcell Console and resubmit your changes.

 

From my point s not make sense. If this were two subclients in a File System Agent this would make sense, because these subclients affect each other. But in a VSA setup these subclients are/should be independend.

 

And even more strange: I can edit the two subclients in the Command Center (aka VM-Groups) without an error.

 

Is there any setting to avoid the “locking” of VSA subclients in the Commcell Console?

 

Regards.

Michael

 

Hi @Michael Seickert , thanks for the post!

It sounds like there are more stringent controls in the CommCell console than in Command center (or they are in both, and the VM-Group aspect sneaks in.

I would open a support case and have them look into it (and likely request dev to investigate).

The lockout message is due to some overlapping properties that we can’t allow multiple edits of (i.e. I change the display name, and you would not see that change sent to your screen) so the lockout is to keep things consistent.

Why you’re able to get around it via the CC VM Group requires some investigation.

Can you share the incident number with me so I can track it accordingly?

Hi Mike,

 

thank you for your response. I will discuss your proposal with my colleagues and then I will come back to you.

 

Best regards.

 

Michael

Hi Mike,

 

we opened an incident yesterday: 220419-166. Maybe you can have a look at this.

Best regards. Michael

 

Looks like the original engineer analyzed the issue and moved it to a better suited team.

I’ll keep an eye on it!

Thank you

Hi Mike,

we got an answer to our incident:

Java UI and Command Center follows different approaches. 
 
First, UI is operating at backupset level and expects to refresh the backupset, That's why you see the message to reload before it operates on the next subclient.  Command center is recent and has been improvised to work at sub client level without having to worry about any overwrites. Hope that clarifies the differences.

From my point of view this is “we will not fix it in the Java UI … use command center”.

Unfortunately we cannot see any of our client and subclients descriptions in the command center … and therefore the command center is not the best approach.

Regards.

Michael

I agree, there should be a CMR created for this.

Reply back to your case requesting the engineer ask for a CMR from dev (I read the case and they were already discussing the issue with the dev team.

Hi Mike,

i am goning to initiate a CMR.

Regards.

Michael

Glad to hear it.  It’s definitely worthy of one.

Once you get the CMR number, please share here!

Hi Mike,

the CMR number is 355921.

Regards.

Michael

 

Thanks, @Michael Seickert !  Marking your reply as the answer for anyone else interested.

Terms & ConditionsCookie settings