Home > vSphere API > Top 10 Best Practices Using VMware VI and vSphere SDK (part 2)

Top 10 Best Practices Using VMware VI and vSphere SDK (part 2)

January 29th, 2010 Leave a comment Go to comments

#6 Consider Views in Your GUI Application

Most developers don’t know much about the View and related managed objects. The reason for that is that they were mainly designed for VI/vSphere Client in the first place. But nothing stops you from using it to your advantages.

Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.

As you can imagine, you can use the View and its subtypes InventoryView, ListView, and ContainerView to monitor changes on the server side. It provides an efficient way to monitor for changes with only these visible in your GUI and nothing more. You can use ViewManager to create views according to your specific needs.

Note: There is a confusion with the views in the VI Perl. The View in the SDK itself is a managed object type that only exits on the server side; while the view in VI Perl is a mirrored copy of a managed object on the client side. They are two different things and used for different purposes. If you have used VI Perl before, pay extra attention here.

#7 Secure Your Applications

In general, you should use HTTPS over HTTP even if you work inside your enterprise network. HTTP traffic can be easily monitored by any network sniffers. Also, you should set up privileges, roles, and permissions to manage the access of the login user using your application. It’s partially administrator’s work, but you have to keep that in mind.

When it comes to a server application, the problem could become complicated. On one hand, you don’t want to create a session for each active user and leverage the built-in security management by vCenter or ESX/ESXi; on the other hand, you don’t want to grant everyone root or administrator privileges. You have to work out a mechanism to manage these in your application.

If your applications focus on very limited aspects of the system, you can actually create a new account just for the server application with only required privileges. For example, a performance analysis application that only need to read performance data. You can create a special account and grant only these privileges for reading performance data. If for whatever reason, the account info is leaked out, the impact is limited.

#8 Code With Performance In Mind

There are two things in scope. One is the performance of your own applications. You want snappy responses for sure. The other is the impact of your application on the server side.

Getting performance data can cause performance problem at the server side. You should limit the scope to the really necessary metrics on smallest set of managed objects with smallest time period you care about, and the coarsest grain you can accept. Format wise, you should use CSV format over normally array. Why? XML serialization and de-serialization are not efficient, and using CSV can avoid a little work there.

Another rule of thumb is you don’t fetch the same data from the server twice when performance becomes an issue. You should then consider creating a local cache. It can be error prone of course, so do it only when you have to. If you use VI Java API, you can leverage its caching framework which has been used in commercial products.

#9 Manage Your Sessions Carefully

Session management could be tricky in some circumstances. The rule of thumb is to keep as few concurrent sessions as possible. Some server applications can easily get into performance problem by creating a new session for each user as described in this blog.

Even if you don’t develop a server application that serves many users, you can still get this problem. For example, you may forget to logout a session in your code and run your application many times for testing. If you don’t explicitly close a session, it times out and disconnected by the server in 30 minutes. When you do many tests in short periods of times or you have created many sessions in a row programatically, you may accumulate too many. Remember, your application may not be the only client to the server — others may run vSphere Client or other applications against the same server. So log out your session when you don’t need it.

#10 Use APIs/Toolkits For Higher Productivity

The basic Web Service APIs are not developer friendly. By its nature, the Web Services is procedural, therefore you cannot leverage the benefits of Object Oriented programming even if you are using Java. Also, the original PropertyCollector is super powerful but pretty hard to use.

To get around these problems, you want to build your application on a higher level APIs instead of the basic Web Services. There are several choices:

  • Open source VI Java API (Disclosure: I am the creator of this API)
  • PowerCLI
  • VI Perl
  • VI C# API (an open source project by Andrew Kutz)

Note: a lot people know PowerCLI, but not the underlying .NET binding. I may talk about it later.

Now, I’ve gone through these best practices. How many of them do you follow in your applications? It’s time to check it out. Remember, every application is different and you got to decide what’s the best for your project.

More details can be found in my book published by Prentice Hall.

BTW, I just got a twitter from Luc Dekens (@LucD22) who just posted a follow up blog: PowerCLI and the SDK – part 3 – Steve Jin’s best practices. Thanks Luc!

  1. David Stratton
    January 30th, 2010 at 11:30 | #1

    Awesome post! I have been using VI3/vSphere for years and have been scripting for longer, I took note to #9 when I read you previous post on the subject, I manage a very large environment hundreds of hosts across 7 VC’s after reading your post I went and looked at our sessions, about half were from debugging my scripts and many users have multiple connections. Looking forward to clearing up some VC performance issues now that we been reminded having over 40 sessions open is not ideal. Thank You.

  2. bingfeng
    November 2nd, 2011 at 02:17 | #2

    Nice article! You have another option if you are using C++ tool chain. Open source vSphere API C++ interface provides equivalent object hierarchy and maps it to C++ syntax in a unify way. The project is hosted at github https://github.com/bfzhao/VIM-vSphere-SDK-Cpp-Wrapper.

  3. November 3rd, 2011 at 20:29 | #3

    Thanks Bingfeng, great contribution to the open source community! I will blog about it later.

    Steve

  4. Julia
    September 13th, 2012 at 00:42 | #4

    Hi Steven Jin:
    In the topic #9.I have had this mistake.But I do not know how to kill the historical sessions.
    In addition,what is the difference between the following two;
    si.getServerConnection().logout();
    si.getSessionManager().logout();
    Regardless of which to executed there will be error.
    Thanks for your help!

  5. Julia
    September 13th, 2012 at 02:23 | #5

    Hi Steven Jin:
    I saw the source code.Know that the si.getServerConnection().logout() can also do si.getSessionManager().logout().And I found the method terminateSession() to kill sessions.Thanks all the same.I continue to answer own questions.Hope I did not let you disgusted.

  6. September 13th, 2012 at 17:49 | #6

    Hi Julia,
    Thanks for the question. I am happy you had come up with an answer already and share it here with others. Thanks!
    Steve

  1. July 25th, 2010 at 10:05 | #1
  2. July 26th, 2011 at 00:03 | #2