Home > vSphere API > Demystifying 3 “View”s from VMware

Demystifying 3 “View”s from VMware

March 23rd, 2010 Leave a comment Go to comments

After I blogged the top 5 myths of vSphere API, William Lam suggested me to write a bit more on the views in his comments. If you haven’t followed him (@lamw) at Twitter yet, you may want to. His vGhetto Perl repository is one of the best resources for people who use VI Perl.

For sure, VMware loves the term “view”. As far as I know, there are 3 different ”views.” Two of them are for APIs; the last one is for the desktop product family. We are not going to talk about the product View in this blog. You can find more information at VMware web site.

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.

Let’s instead focus on the two “Views” for developers: one is in VI Perl and .NET/PowerCLI; the other is part of the core vSphere API.

View in VI Perl/PowerCLI

Most system administrators like William already know the first View very well. It first appeared in the VI Perl and then ported to .Net and PowerCLI.

What it does is to have a cached copy of a managed object at the client side. You can also add criteria to get many view objects at a time. The following code create the views for the virtual machines:

my $vm_views = Vim::find_entity_views(view_type => ‘VirtualMachine’); 

Once you get the view, you can access its values. For example,

Print $vm->name;

Please note that the values in a view are not refreshed until you explicitly call the following code:


Besides the values, the view defines methods corresponding to the managed object type. So you do something like:


The views in PowerCLI and .Net are very similar, so I don’t repeat them here. 

View in vSphere API

This is the little known, and therefore mysterious sometimes, view compared with the one discussed above. It was then a new addition to VI SDK 2.5.

The original intension was for the VI Client to better communicate with VirtualCenter (vCenter) in a more efficient way. For one thing, the vCenter server doesn’t know what VI Client is currently displaying, therefore has no idea what changes should be sent to the client other than all of them. It works of course, but not efficient and mostly unnecessary because VI Client doesn’t need to show any changes that are invisible on screen. The larger your inventory, the less percentage of managed entities that are visible on the screen.

The view family managed objects are designed to solve this problem. With view, VI client can notify the vCenter what ‘s currently visible and just send me the changes with these visible entities. It can be a big saving on both communication and the workload for vCenter to monitor the changes.

There are totally 6 classes involved in the view family. The following is the UML diagram illustrating the inheritance hierarchy:


As you can see, the View is a super type that is inherited by ManagedObjectView, which is then further inherited by InventoryView, ContainerView, and ListView.

ContainerView is used to group the contents of a single container managed object. InventoryView represents all the inventory on the server side. ListView is used to group an arbitrary set of managed objects. From the name and methods, you can find the differences among these different view types.

The ViewManager is not part of the view hierarchy but used to manage them. You can get an instance of it from the ServiceInstance object, which is the starting object. With this object, you can create different types of views as you want.

The best way to explain the usage of an API is to use a sample code. Let’s take a look at the sample code that is included in my book: VMware VI and vSphere SDK:

package vim25.samples.mo;

import java.net.URL;

import com.vmware.vim25.ManagedObjectReference;
import com.vmware.vim25.ObjectSpec;
import com.vmware.vim25.ObjectUpdate;
import com.vmware.vim25.PropertyChange;
import com.vmware.vim25.PropertyFilterSpec;
import com.vmware.vim25.PropertyFilterUpdate;
import com.vmware.vim25.PropertySpec;
import com.vmware.vim25.SelectionSpec;
import com.vmware.vim25.TraversalSpec;
import com.vmware.vim25.UpdateSet;
import com.vmware.vim25.mo.ContainerView;
import com.vmware.vim25.mo.Folder;
import com.vmware.vim25.mo.ListView;
import com.vmware.vim25.mo.PropertyCollector;
import com.vmware.vim25.mo.PropertyFilter;
import com.vmware.vim25.mo.ServiceInstance;
import com.vmware.vim25.mo.View;
import com.vmware.vim25.mo.ViewManager;

public class ViewSample
  public static void main(String[] args) throws Exception
    if(args.length != 3)
      System.out.println("Usage: java ViewSample <url> "
          + "<username> <password>");

    ServiceInstance si = new ServiceInstance(new URL(args[0]),
      args[1], args[2], true);
    Folder rootFolder = si.getRootFolder();
    ViewManager vm = si.getViewManager();
    PropertyCollector pc = si.getPropertyCollector();
    //create a ContainerView with all VirtualMachine objects
    //covered recursively
    ContainerView cv = vm.createContainerView(rootFolder,
      new String[]{"VirtualMachine"}, true);
    PropertyFilterSpec pfs = new PropertyFilterSpec();
    //create a PropertySpec with no property set for retrieving
    pfs.setObjectSet(new ObjectSpec[]{createObjSpec(cv)});

    pfs.setPropSet(new PropertySpec[]{
        createPropSpec("VirtualMachine", new String[]{})});
    //create a Property with partialUpdate is true
    PropertyFilter pf = pc.createFilter(pfs, true);
    //wait for initial udpate with empty version string
    UpdateSet uSet = pc.waitForUpdates("");
    String ver = uSet.getVersion();
    //print out all the VirtualMachine objects

    //create a ListView from a ContainerView
    ListView lv = vm.createListViewFromView(cv);
        new ManagedObjectReference[]{}, //don't remove anything
        //remove the first VirtualMachine in the list
        new ManagedObjectReference[]{
    PropertyFilterSpec pfs1 = new PropertyFilterSpec();

    pfs1.setObjectSet(new ObjectSpec[]{createObjSpec(lv)});
    pfs1.setPropSet(new PropertySpec[]{
            new String[]{"runtime.powerState"})});
    PropertyFilter pf1 = pc.createFilter(pfs1, true);
      System.out.println("Waiting update from version: " + ver);
        uSet = pc.waitForUpdates(ver);
      }catch(Exception e)
        System.out.println("exception:" + e);
      ver = uSet.getVersion();
  private static ObjectSpec createObjSpec(View view)
    ObjectSpec oSpec = new ObjectSpec();
    oSpec.setSkip(true); //skip this ContainerView object
    TraversalSpec tSpec = new TraversalSpec();
    oSpec.setSelectSet(new SelectionSpec[] {tSpec});
    return oSpec;

  private static PropertySpec createPropSpec(String type,
      String[] props)
    PropertySpec pSpec = new PropertySpec();
    return pSpec;
  private static void printUpdateSet(UpdateSet uSet)
    PropertyFilterUpdate[] pfu = uSet.getFilterSet();
    for(int i=0; i<pfu.length; i++)
      ObjectUpdate[] ous = pfu[i].getObjectSet();
      for(int j=0; ous!=null && j<ous.length; j++)
        System.out.println(ous[j].getObj().getType() + ":"
          + ous[j].getObj().get_value());
        PropertyChange[] pcs = ous[j].getChangeSet();
        for(int k=0; pcs!=null && k<pcs.length; k++)
          System.out.println(pcs[k].getName() + "-->"
              + pcs[k].getVal());


We reviewed the three views from VMware. Two of them are for developers and system administrators; one for end users who use it as a desktop solution. We only focused on the first two in this blog.

The view in VI Perl and other toolkit is like a mirrored copy of a managed object from the server side. You can also call methods on these views. The views are not up to date unless you keep calling the refreshing method.

The view in vSphere API itself is a little known one given its specific use cases. With this blog, I hope you are clear what this View is and how different views are related to each other in the vSphere API. In general, you can leverage this set of APIs if you have a GUI application, or are interested in monitoring a subset of the managed entities in your inventory.

Given the limited use cases of the view in vSphere API, you are not required to use it or even know it. That is why it’s little known compared with the other two views. But if you happen to have the use case, it can be very powerful.

To be notified for future posts, feel free to subscribe to this feed, and follow me at Twitter

Categories: vSphere API Tags: , , , ,
  1. March 23rd, 2010 at 00:07 | #1


    Thanks for the post, definitely helped me understand “ViewManager” much better! Keep up the great blog posts!


  2. March 23rd, 2010 at 01:44 | #2

    Hi William,

    Thanks for making the suggestion that led to this post!


  3. January 11th, 2011 at 07:44 | #3

    I have a few confusions on how Views work on the server and how it is manipulated by the API calls. I will try to explain my understandings and questions in steps:

    First we create a ContainerView that contains the managed entities of certain types, in this case VirtualMachine. This creates the view on the server. Two questions here:
    1. If we have a vCenter in our setup, will it create the view on the vCenter machine or individual hosts?
    2. When the view is created, will it only contain all the managed entities of the filtered types, present at the moment of creation of this view? e.g. If I create a view and then afterwards add a new virtual machine to my ESX server, will the managed entity of this new virtual machine be included in my view?

    Then we create the PropertyFilterSpec over our created view and use it to create property collector and it is the property collector that is used to monitor the changes over this view.
    Here, the property collector is the main observer over the properties of our desired managed entities. Questions:

    3. Is the property collector also created over the server, like a view?
    4. If we are to retrieve our already created view from the ViewManager (ViewManager#getViewList()) and if we need to fetch the updated properties in our already created property collector, there is no way in the API. We will have to create the property collector again over our already created view.
    One option is to store the property collector in our cache, but it may not be possible if my program restarts and I want to retrieve the old property collector by using the same service connection (same session).
    Is this understanding correct? or do you think there is a better way to handle this?


  4. January 12th, 2011 at 12:55 | #4

    Hi Monis,

    Long and great questions! :-) Hope my answers help:

    1. It can either vCenter or host.
    2. It depends on your view type. The ListView for example doesn’t automatically include your newly created VM unless you programmatically add it.
    3. PropertyCollector is always there on the server, be it vCenter or ESX.
    4. There is only one PropertyCollector per server. You cannot create it. However, you can use view with the PropertyCollector to filter out what managed objects to get properties from.


  5. Eric
    December 3rd, 2012 at 09:42 | #5

    Wow, great post. It is just easier when you can see the code. Looking at the VMware docs, I was a LOOOoooooonnnnnngggggg way away from devising a solution like this. Thanks!

  6. Veena
    May 19th, 2016 at 16:09 | #6

    When creating container views using the vSphere API, what is the performance impact on the server? Or is it only the subsequent property collection that mainly impacts the server?

    I want to present a tree based UI for the user to navigate the vSphere inventory, quite similar to the “Hosts and Clusters” and “VM and Templates” views available within the vSphere Client. I do not necessarily need to monitor for any live updates.

    I could use a container view in a recursive manner for all managed entities, collect the parent property for each entity and then later build up the hierarchy myself from the response.

    Alternatively, I could use a container view in a non-recursive manner, i.e. create a container view and gets the objects at a level, and when the user wishes to browse deeper into any of the container objects, create another container view and get the next level of objects, and so on.

    Would there be a performance hit on the server end to create multiple container views in this manner?


  1. No trackbacks yet.