The Mythical Sessions in vSphere and VI

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:

Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.

  • 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

vmware_soap_session=”5229c547-1342-47d1-e830-223d99a47fba”

  • 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.

This entry was posted in vSphere API and tagged , , , , , , , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

7 Comments

  1. pavel
    Posted October 12, 2010 at 4:31 am | Permalink

    Hello.
    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. Posted October 12, 2010 at 9:16 am | Permalink

    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.

    -Steve

  3. pavel
    Posted October 15, 2010 at 6:48 am | Permalink

    Thanks a lot, Steve!!!

  4. Posted October 15, 2010 at 8:24 pm | Permalink

    Glad you like it, Pavel!

  5. Geeta Gharpure
    Posted March 14, 2012 at 3:34 pm | Permalink

    >>”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.”

    Steve,
    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.

    Regards,
    Geeta

  6. Posted March 16, 2012 at 2:51 am | Permalink

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

    Steve

  7. Robert White
    Posted June 8, 2015 at 1:06 pm | Permalink

    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!
    -Rob

    *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.

One Trackback

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  • NEED HELP?


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.