VMware {code} Community
erikDoesStorage
Enthusiast
Enthusiast

UserSession, Linked Mode, and expirations

Over the past couple weeks our team has encountered a few issues which is impacting our Plugin's usage of UserSession and operation in Linked Mode across multiple VCenter Servers.

The first issue is that we are having the UserSessionService @Autowired injected into our plugin:

    @Autowired    protected UserSessionService userSessionService;

We use the userSessionService to get the UserSession:

  UserSession userSession = userSessionService.getUserSession();

This works fine for a period of time after the user has logged into the VCenter server and entered our plugin.  But after a period of time, say 30 minutes, when we go to get the user session it returns null.  Its like the user session has timed out or something.  The VSphere UI session is still active, it hasn't timed out and you can enter other parts of  the UI to carry out successful actions, so overall things haven't timed out or expired.  But we are no longer getting a valid user session back when we request it from the service.  

Is there something we are doing wrong in our plugin?  Are we supposed to call something or some how trigger the renewal of the user session for our plugin?

----------

The second question has to do with when we are operating in linked mode and need to call from our plugin code running on VCenter A over to VCenter B to perform an action with resources that are controlled by the plugin running over there.  When we call over to our code on B, the UserSessonService isn't returning to us a user session, it is null from the start.  So how are our plugin instances running on the two servers supposed to handle this cross calls and end up with a valid usersession?

--------

The third question is I have a couple of VCenters in linked mode, say A and B.    I reboot the B VCenter server.  I don't log into the VCenter B server.   At this point it seems that with out having logged in, our plugin has not been redeployed on VCenter B.  Thus any cross calls we attempt from our plugin running on A to B will fail with 404 since our plugin isn't running and our REST endpoints are not available.  If you do log into VCenter B, then our plugin does get redeployed.  However the plugin on B will not have have a valid user session (basically the same state as the previous question).

--------

Any help with the above questions would be greatly appreciate.  Is there some calls or other mechanisms we need to be using to get user sessions?  Is there something we need to do to trigger the deployment of our plugin on VCenter B from A when the plugin hasn't been deployed as part of a login to a rebooted system?

Thanks for any help/responses.

 

 
    @Autowired
    protected UserSessionService userSessionService;
0 Kudos
5 Replies
erikDoesStorage
Enthusiast
Enthusiast

Again thanks for any response on this issue,

   -Erik

0 Kudos
erikDoesStorage
Enthusiast
Enthusiast

After doing some additional searches using different combinations of search terms I came across a forum thread posting started in 2017 that addresses part of the issue with us seeing the UserSessionService returning null after a period of time:

https://code.vmware.com/forums/4974/vsphere-web-client-sdk#562940|3754764

There is a mention in a posting to that thread from 2018 :

Hi folks,
  
A keep alive mechanism to resolve this issue is part of vSphere Client (HTML) 6.7. Please check if you can still reproducing it.
Thanks.
  Cheers,
  Vladi

But there is no follow up posting information on that keep alive mechanism and I have not been able to find what is being discussed in the 6.7u1 SDK.    Is there any more information about this mechanism and how to use it, preferebly with an example?

We are using Java on the server side and our client side is in Clarity/Typescript/Angular.  Which side would this keep alive mechanism be applied?


Again thanks for any response on this issue,

   -Erik
0 Kudos
_vladi_
VMware Employee
VMware Employee

Hi Eric,

Good questions. It is not completely clear what vCenter versions you are using in the above setups. In any case please check below.

"This works fine for a period of time after the user has logged into the VCenter server and entered our plugin.  But after a period of time, say 30 minutes, when we go to get the user session it returns null.  Its like the user session has timed out or something.  The VSphere UI session is still active, it hasn't timed out and you can enter other parts of  the UI to carry out successful actions, so overall things haven't timed out or expired.  But we are no longer getting a valid user session back when we request it from the service.  "

This is a known issue that was resolved in 6.5U2 and above. The plugin session is normally assiciated with the Client session and needed to be pinged once before expiring (e.g. once 30 mins)

"Is there something we are doing wrong in our plugin?  Are we supposed to call something or some how trigger the renewal of the user session for our plugin?"

For earlier versions you can do the ping yourself from within the plugin (e.g. via sending a GET request to the view).

-------

"The second question has to do with when we are operating in linked mode and need to call from our plugin code running on VCenter A over to VCenter B to perform an action with resources that are controlled by the plugin running over there.  When we call over to our code on B, the UserSessonService isn't returning to us a user session, it is null from the start.  So how are our plugin instances running on the two servers supposed to handle this cross calls and end up with a valid usersession?"

It doesn't matter where you login. In both cases the Client will download both versions and deploy the higher plugin version of the two registered in A and B (they cannot operate together, only one is chosen). This plugin version should be able to talk to both your backends and both vCenters. Normally it would get the UserSession which contains serversInfo that has the session info of both vCenters. We need to look into the details if that still fails on your side.

-------

"The third question is I have a couple of VCenters in linked mode, say A and B.    I reboot the B VCenter server.  I don't log into the VCenter B server.   At this point it seems that with out having logged in, our plugin has not been redeployed on VCenter B.  Thus any cross calls we attempt from our plugin running on A to B will fail with 404 since our plugin isn't running and our REST endpoints are not available.  If you do log into VCenter B, then our plugin does get redeployed.  However the plugin on B will not have have a valid user session (basically the same state as the previous question)."

Not sure if I understand you correctly but it seems like you are trying to serve endpoints from within the plugin to external parties (like your other plugin). That is not supported in linked mode. You can have 10 vCenters and the active plugin will always be a single one and the same one: the plugin with the highest version. It should be talking to all your backends (but not to your other plugin instances which will never be deployed even if you start the Client on all vCenters).

Let's see an example: VC1 has plugin v1 registered, VC2 has plugin v2 registered

When you login to the Client on VC1 it will download v1 and v2, discard v1 and deploy v2 (the version is higher).

When you login to the Client on VC2 it will download v1 and v2, discard v1 and deploy v2 (again).

=> v1 will never be deployed.

If v2 needs operations from the backend attached to VC1 it needs to talk directly to it, not to the v1 plugin.

 

Hope that makes sense. Let me know with further details so we can clarify.

Cheers,

Vladi

0 Kudos
_vladi_
VMware Employee
VMware Employee

The keep alive mechanism is internal implementation that requires no action from the plugin writer.

For old versions (pre 6.5U2) you need to send dummy HTTP GET request to your view once in 30 mins or less to keep it alive.

Cheers,

Vladi

0 Kudos
erikDoesStorage
Enthusiast
Enthusiast

Hi Valdi, thanks for your responses.

For the first question:

We are using 6.5u2 or 6.7, I would double check to be sure but our lab is down.  Either way we would need to support the older 6.5 versions and possibly even 6.0.  So we would need to do the ping then.  So when you say do a ping, do you mean sending a GET request to one of our endpoints.  For example doing something like this in our Angular code:

constructor(private http: HttpClient, private locationStrategy: LocationStrategy,
            @Inject(DOCUMENT) private document: Document) {
    super();
}
  
private getBaseUrl(): string {
    return this.locationStrategy.prepareExternalUrl('rest/myController/');
}
  
getServers(): Observable<VsphereServer[]> {
    console.log('Ping the server side ' + this.getBaseUrl());
    return this.http.get(`${this.getBaseUrl()}/pingIt`, this.httpOptions).catch(this.handleError);
}

Where we have a server side plugin code running on the vsphere server that is the @RequestMapping("/myController") and handles the REST endpoints.   Is that all we need to do, just periodically hit our endpoint from the client and it will magically keep the user session alive?  Or is there some specific endpoint/controller that is defined by VSphere that we need to ping?

For the second question:

First a word on what we do:  We are a storage system company.  Some of our storage may be attached to one of the VCenter servers and the ESX hosts on that server, while other storage may be attached to another VCenter server and its ESX hosts.  

Given that situation, when we we have to deal with a storage system that is hanging off of VCenter server B from VCenter server A, we need to transfer the request from our plugin running on server A over to server B.  This means that from our plugin running on server A we do a REST call over to our REST endpoint being served by our plugin running on server B.  All of our versions of the plugin running on the vcenter servers are the same version.

Our situation is that the same version of the plugin has been successfully deployed on both Linked Mode vcenters.  But what we have encountered is that if we do a REST call from our plugin on server A over to our REST endpoint served by the plugin running on server B, we don't have an active user session (the UserSessionService.getUserSession() returns null on sever B).  

For the third question:

We have found that if vcenter server B is power cycled and not logged into, our plugin will not be redeployed.  It would get redeployed until a user logs into the B vcenter server.  That means if things are in that state, a user trying to do an action on A intended for one of our storage systems on B, it will not be able to reach our REST endpoint.    If a user does log into sever B, then our plugin does get deployed on server B and then we can make a REST call from our plugin running on server A to our endpoint on server B successfully.

Thanks again for any responses.  This is very helpful.

0 Kudos