Home > vSphere API > The Mythical Sessions in vSphere and VI

The Mythical Sessions in vSphere and VI

February 5th, 2010 Leave a comment Go to comments

In my previous blogs, I talked about session management for scalability and best practices (#9). In this one, I am going to drill down to the bottom.

To your surprises, there are two types of sessions involved in vSphere SDK:

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure

  • HTTP Session. It’s used to identify a client and tracked by the cookie in HTTP header. Once you login the server, all the successive requests have to carry the cookie header similar as follows


  • User Session. It’s used to identify a login session of a particular user. You can use SessionManager to find out more the details of the current user and other login users from the UserSession data object. The key in the UserSession is in the same format as the HTTP session, but you should never confuse them, or use them interchangeably.

When we talk about sessions, we normally mean the user session. In some rare cases like vSphere Client plug-in, you do need to understand and use the HTTP session. We will discuss it in a moment.

Given these two sessions, you may wonder how they relate to each other. The answer is quite simple – they have one-to-one mapping.

But things become a little confusing when users get into the picture. One user, for example, can have multiple concurrent user sessions, each of which has its own session ID. That is one reason why some developers have session related performance problem even during development time. This has been discussed thoroughly in the previous blog.

Even more confusing is when the clients get in. One HTTP session can actually be shared by multiple clients either distributed or not, including vSphere clients. That is why vSphere Client plug-in can work. The vSphere Client sends a URL with HTTP session ID for the plug-in’s web application to connect back to the vCenter server just as if it were the vSphere Client itself.

Because the vCenter server does not track the source IP, all the requests from these applications are taken as from one application. So there is no limit, at least in theory, on how many clients can share one HTTP session, and they do not create extra burden on the server side as would multiple user sessions. Still, you may got problems with other things like the method waitForUpdate() of PropertyCollector, which can be confused when all ask for updates. That is why I deprecated waitForMe() method in VI Java API, which uses waitForUpdate(), in Task managed object.

Well, I hope it helps you better understand the sessions and write better applications. To receive future posts, please subscribe this feed.

  1. pavel
    October 12th, 2010 at 04:31 | #1

    I have a problem with the method waitForMe():
    The method waitForMe() from the type Task is deprecated
    And I can’t find enought information for this problem. The program compilator that I use is eclipse sdk 3.6.1 If somebody can tell me something about this method or the mistake that is coming

  2. October 12th, 2010 at 09:16 | #2

    HI Pavel,

    Please check out the waitForTask() which is the substitute for the deprecated one. For reason of the deprecation, check out the source code comments.


  3. pavel
    October 15th, 2010 at 06:48 | #3

    Thanks a lot, Steve!!!

  4. October 15th, 2010 at 20:24 | #4

    Glad you like it, Pavel!

  5. Geeta Gharpure
    March 14th, 2012 at 15:34 | #5

    >>”The vSphere Client sends a URL with HTTP session ID for the plug-in’s web application to >>connect back to the vCenter server just as if it were the vSphere Client itself.”

    Can you please let me know if I pass on this serviceURL and sessionId received by the plugin to another web application and use it to login to vCenter?
    Thanks in advanced.


  6. March 16th, 2012 at 02:51 | #6

    Yes. You can. For details, you can search the blog or check it out in my book.


  7. Robert White
    June 8th, 2015 at 13:06 | #7

    This was a very useful blog post, thanks!

    I have a question though. Let’s say I spin up 10 threads in my chosen programming language, and at essentially the exact same time I make a call to VimClient.CloneVM() in each one, all using the same HTTP session cookie (and therefore the same User Session).

    How does vCenter handle those requests? Will they be done in quick sequential action rather than parallel? That makes the most sense to me. If instead vCenter handles the 10 requests* in parallel, that would make it seem like 10 threads are created in vCenter to handle the 10 HTTP requests, which in turn means having 10 clients use the same User Session does indeed add load to the server.

    Thanks for the help!

    *I’m referring to the initial request to start the clone. I understand that the clone itself will be done in parallel after the HTTP call is returned to the client.

  1. August 1st, 2011 at 00:02 | #1