Solved

Editing two different VSA subclients (Hyper-V or VMware) at the same time


Userlevel 1
Badge +5

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

 

icon

Best answer by Michael Seickert 17 May 2022, 08:34

View original

If you have a question or comment, please create a topic

11 replies

Userlevel 7
Badge +23

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?

Userlevel 1
Badge +5

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

Userlevel 1
Badge +5

Hi Mike,

 

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

Best regards. Michael

 

Userlevel 7
Badge +23

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

I’ll keep an eye on it!

Userlevel 1
Badge +5

Thank you

Userlevel 1
Badge +5

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

Userlevel 7
Badge +23

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.

Userlevel 1
Badge +5

Hi Mike,

i am goning to initiate a CMR.

Regards.

Michael

Userlevel 7
Badge +23

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

Once you get the CMR number, please share here!

Userlevel 1
Badge +5

Hi Mike,

the CMR number is 355921.

Regards.

Michael

 

Userlevel 7
Badge +23

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