DoubleCloud.org » vSphere API

Announcing Code Generator For vSphere Java API

Steve Jin — Wed, 01 Feb 2012 08:12:06 +0000

As I tweeted last week, there would be a big announcement when the open source VI Java API gets 20,000 downloads. It hit target yesterday. To celebrate it, I decide to release the code generator for the API, which William (@lamw) rated as “awesome.”

If you have used Onyx for generating PowerCLI code before, you can think it as Java version of Onyx. Even better, it generates complete Java code which is ready to run once you supply the URL, username, and password. It’s so easy that from now on, all the system administrators have no excuse for not trying open source vSphere Java API.

At its heart, the code generator is a reversed proxy which sits between a vSphere Client and vCenter or ESX(i) server, and intercepts the SOAP XML messages. With the XML messages, I designed the algorithm to automatically generate the Java code based on the open source Java API code.

Unlike Onyx, the Java code generator provides richer GUI which allows you to:

Record both the requests and responses.
Sort the recorded messages in any order.
Generate complete code of any selected requests.
Save recorded messages to a local file, and read it back later.
Support raw HTTP data, XML, Java simultaneously in different tabs.

Although the generator supports only Java today, I did designed it to be extensible architecture for other languages like Jython, JRuby, Perl, etc. When I have time, I will continue to work on these in the future.

Too much talk? Let’s take a peek at a few screenshots in this page which includes download link and getting started tutorial. Shorter than my 5 minute VI Java API tutorial, it should be less than one minute this time.

Hope you enjoy the tool and let me how you like it.

Announcing Code Generator For vSphere Java API originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Why vSphere PropertyCollector Is Hard By Design?

Steve Jin — Wed, 18 Jan 2012 05:01:21 +0000

If you’ve had a chance to use vSphere Web Service SDK, you must know the PropertyCollector is very hard to use. It takes a newcomer quite some time to learn how to use it, and even more time to learn to use it effectively. Luckily, you no longer have to if you use the open source vSphere Java API (a.k.a. vijava) because it has encapsulated the PropertyCollector behind these newly added getter methods of the managed object types.

Still, a question has lingered in my mind for a while: “Why was the PropertyCollector designed to be hard?” If you have a similar question, this article is for you. Note that this is just my own thoughts. Hope it offers a good explanation, and more importantly you can learn from it for your future designs.

Although vCenter and ESX/ESXi have implemented the same API interfaces, the vSphere API is mainly for vCenter and heavily influenced by vCenter. Functionality wise, vCenter supports almost all the APIs, while ESX/ESXi does part of them. It’s not strictly superset/subset relationship but pretty close.

As you know, the vCenter is built on top of relational databases, either Oracle or Microsoft SQL Server. With the vFabric Data Director and vPostgress, we can expect Postgress to be used. Why? According to Paul Maritz, you got to eat your own dog food.

So vCenter is a database centric application in server form. What does it really mean? At a high level, the managed object types are mapped to tables in the database; managed object instances to records; properties to fields. The ManagedObjectReference includes both type (table) and value (primary key). Secondly, different threads in vCenter share information via database.

With that in mind, the PropertyCollector is really an interface to the database retrieving different tables (managed object types) and their fields (properties). It’s very natural to design something like PropertyCollector, a single type that is responsible for getting all properties of all managed objects. Also with SOAP Web Services, it does not make much sense (check out the data transfer object design pattern) to provide numerous getters, each of which corresponds to a property.

While the single type making sense, the interface design can be improved however. The most common use case of PropertyCollector is to retrieve a property from a managed object. With the existing interfaces, you got to work with several data objects to specify what you want. It of course works but isn’t easy to use. Ideally it should have included a simple interface as follows:

Object getProperty(ManagedObjectReference obj, String propName)

This simple property retrieval is, however, not the most common usage of PropertyCollector in vSphere Client which has been the first and still the most important application built on top of vSphere API. This is yet another reason why the PropertyCollector is hard to use – its major application vSphere Client has different requirements that have been satisfied, therefore there hasn’t been enough incentives to improve the design.

Now, how to bridge the gap? I think the open source vSphere Java API has demonstrated a good approach. Should you be interested in how, you can check out the code. The architecture is designed so that other distributed system can leverage it as well. So you may still find it useful even if you are not using VMware vSphere.

Why vSphere PropertyCollector Is Hard By Design? originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

What Roles Does A User Have in vSphere?

Steve Jin — Wed, 30 Nov 2011 06:00:30 +0000

If you have read my previous article on vSphere security model, you know how it works. Still, you may wonder what roles a particular user may have, as asked in a recent email from one of my former VMware colleagues.

In an operating system, a user is assigned to a group or multiple groups therefore granted a certain permissions. In vSphere, a role is simply a set of privileges and that is it. It’s natural to think of a role as a group sometimes, but it’s really not.

Generally speaking, there is no generic roles for a user to have, but always under a scope of what entity alone or plus its descendants in the inventory tree.

The following screenshot from MOB should explain more. As you can see, a Permission object always has entity while associating user with a role. The propagate field indicates whether the entity’s descendants are covered as well.

With that being clarified, you can check what roles a user has on a managed entity. To get that information, you can call the retrieveEntityPermissions() of the AuthorizationManager managed object type. Note that you need to pass in a managed entity or its ManagedObjectReference as parameter. Optionally, you can use the retrieveAllPermissions() method assuming you want to filter through all the returned Permission objects by yourself.

Now, this is not yet the end of the problem. What if as shown above, the principle is actually a group (indicated by the group field in Permission)? In that case, your ID may not show up in any of the Permission objects. How would you know you are part of one of the groups?

The answer is no if you only look at vSphere itself. You want to look it up from the AD of your domain. It is not that difficult by the way. On your computer running vSphere Client, just type in the following command in a DOS console:

> gpresult /X myGroup.xml

Then you will find your group information in the XML file. It’s too long to be list here, but you can easily try it out by yourself.

With these two piece of information, you can figure out what roles, if any, a user has over an entity in the inventory hierarchy.

What Roles Does A User Have in vSphere? originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Discontinuous Response Stream from vSphere

Steve Jin — Mon, 28 Nov 2011 06:47:20 +0000

Last month a question was raised in our open source vSphere Java API forum regarding an exception during HostSystem.getSummary() method call. As you can see from the stack trace, the actual exception was “org.dom4j.DocumentException.”

java.lang.RuntimeException: java.rmi.RemoteException: VI SDK invoke exception:org.dom4j.DocumentException: null Nested exception: null
        at com.vmware.vim25.mo.ManagedObject.retrieveObjectProperties(ManagedObject.java:158)
        at com.vmware.vim25.mo.ManagedObject.getCurrentProperty(ManagedObject.java:179)
        at com.vmware.vim25.mo.HostSystem.getSummary(HostSystem.java:96)
caused by: java.rmi.RemoteException: VI SDK invoke exception:org.dom4j.DocumentException: null Nested exception: null
        at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:182)
        at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:124)
        at com.vmware.vim25.ws.VimStub.retrieveProperties(VimStub.java:77)
        at com.vmware.vim25.mo.PropertyCollector.retrieveProperties(PropertyCollector.java:107)
        at com.vmware.vim25.mo.ManagedObject.retrieveObjectProperties(ManagedObject.java:155)
        ... 9 more

Thanks to the reporter PC Varma who actually debugged the issue, he found the root cause of the problem was discontinuous response stream that fails the dom4j XML parser. Even better, he offered a quick fix to the problem. Instead of feeding the response stream directly to the parser, just read it to a string buffer and then feed the string to the parser. The environment as reported is vCenter 4.1.0 build 258902. Should you get into similar issue and want a workaround, you can take a look the fix PC provided in the discussion thread.

Given that this is the only incident I’ve heard so far, the fix is not taken into the trunk. More importantly, the fix has performance implications. If you followed closely what I did in 2.0 beta, I first used the same approach but later on changed to the current implementation, which is feeding the response stream directly to the parser. The reason is rather simple: while waiting for coming bytes from the server, the parser can parse the received ones. In so doing, we basically get the parsing for free, or close to free.

Performance wise, the open source Java API is way ahead (10x times as reported) of other approaches for the moment. So we have enough room to revert back to the slower approach if really needed. If you get into similar issue, please don’t hesitate to report it. I need your feedbacks on this.

Discontinuous Response Stream from vSphere originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

The Future of VI Java API and How You can Help

Steve Jin — Wed, 26 Oct 2011 06:07:29 +0000

Upon hearing about my leaving VMware, quite a few members in the community sent me emails or tweets asking about the future of the API. Most of them have built products or automation scripts using the API, therefore would like to see the continuous success of the open source project. I am sure there will be more inquiries coming without this post.

As it stands today, I do plan to maintain the project in the future, mainly upgrading the API to the latest and greatest future vSphere releases. If my time allows, I would also like to enhance the APIs in the following areas: [Note: all these should not be interpreted as a commitment; contact me otherwise.]

Continue the high level abstraction as I laid out in the VI Java API Crescendo release. A small part of the abstraction had been included in version 5 (Have you noticed it? BTW). But we still have a long way to go before we can match PowerCLI on the task oriented abstraction. Again, we will not re-implement PowerCLI in VI Java API, but would make it significantly easier to achieve similar tasks. After all, API is NOT command line or scripting; otherwise it’s wrong. I will blog about this more about the differences and how they should be related to each other.
Expand to other VMware APIs. It’s no doubt that vSphere APIs is, and I think continues to be in foreseeable future, the most important APIs from VMware. As VMware continues to innovate, many other important APIs will come up. It would nice if there is a unified API that works across different product lines. It’s more than simple addition of API calls, but an aggregated APIs among which you can navigate from one to another. The one on top of my head is the vCloud API. Please feel free to name others you want the first in your comment.
Early this year, I made a presentation proposal to talk about interoperability of VMware APIs. Better than a talk, this expansion, if done right, would give you real APIs to work with. As ambitious as it may seem, it’s indeed not an easy project, let alone the amount of work.
Support other open source hypervisors like XEN, KVM. This was actually my vision for the project I had two years ago. I believe a unified API to manage all hypervisors would be very helpful for the customers, and in particular for partners who want to write once and integrate with all.
As I found out after studying some of the management APIs, the biggest challenge is to come up with a common object model that makes sense for all the hypervisors. Given that each hypervisor has its different object model and even different naming, this effort may result in a least denominator of the existing object models. In my estimation, the least denominator would most likely equate to the vCloud API level abstraction.

To achieve these, I would like to get helps from the community, and companies as well:

Development/build/test environment, including hardware/software. It doesn’t need to be big, but good enough for the project. If it’s an environment accessible remotely, that would work too, probably even better.
Advisory board. I would like to invite experts who would agree to give meaningful help on regular basis (quarterly or bi-yearly, TBD) in many different areas, from project direction, user feedbacks, technology, etc.
Contribution, including coding, documenting, evangelism, etc.

Should you be interested in helping the project or referring others, please leave a comment or contact me: sjin2008 at users dot sf dot net.

The Future of VI Java API and How You can Help originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

VI Java API 5.0 GA Released

Steve Jin — Mon, 03 Oct 2011 03:47:47 +0000

It’s been one plus month since I pushed out the beta code which has since been downloaded more than 700 times. As promised, I am happy to announce the GA of VI Java API 5.0 today. This is the fourth major release after 1.0, 2.0, and 2.1 which are all shipped on time. Predictability is important for commercial products, even so for open source projects like this. I think we’ve demonstrated it in the past three and half years since the first release in May 2008.

As mentioned in beta announcement, I’ve decided to jump the number to 5.0 to better align with vSphere versioning which is now 5.0. I expect to sync up with future vSphere releases in both features and version numbers.

Now, let’s get to the technical side: what’s fixed from beta? Here are several of them:

Bug 3042167: xml characters not escaped.
Bug 3406597: Broken UTF-8 handling in WSClient class
Bug 3400964 API is missing the type ArrayOfDatastoreEventArgument
Bug 3405278 Client REST API breaks with vSphere 4.1 u1

I would like to thank my manager Rich Hogan for sponsoring some of my time to work on this release, VMware product management Mahesh Ramachandran and Tsun Tsun Ho for their support, and several internal and external teams who helped to give me many feedbacks and try the alpha and beta code.

Thanks also go to our community who has been very supportive and by trying the API, reporting bugs, and helping each other in the community forum. This is really encouraging experience for me.

Ready to give 5.0 a try? Check it out here.

VI Java API 5.0 GA Released originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

One More Secret About Session Management in vSphere

Steve Jin — Tue, 27 Sep 2011 05:44:45 +0000

Session management is a very important part of vSphere management, especially when scalability is involved. I’ve blogged about this in my previous posts (1, 2). If you haven’t read them yet, it’s high time to do so.

In this article, I am going to share with you a new finding while helping a development team. By default, an idle session is terminated by vSphere server after 30 minutes. The team found that it’s not totally true. They use several types of sessions for different purposes. Two of the sessions remain live even after the 30 minute default while others are gone.

The initial question we asked ourselves was, “what are the differences of the two from others?” Because all the sessions are using the same username, it’s not easy to tell which is which, therefore hard to track the logic behind the two ever-lasting sessions. A little more discussion with the team uncovered that there are two sessions that are different from all others in that they call waitForUpdate() method for pushing changes from server to client.

In the push mode, the server thread gets into corresponding function/method call. It cannot return unless there are new changes per PropertyFilter objects that specify monitoring points. It’s a reasonable argument that the server should know of inactivity of 30 minutes and terminate the session. But in reality, I guess the server side thread may not be able to count time because it’s still within the method call.

Note that the problem wouldn’t be there if a logout is called, which I highly recommend in top 10 best practices using vSphere API. Basically you don’t want to leave doubts to the server side which works most but not all of the times.

Well, sometimes you don’t have full control and the unexpected does happen, for example, your client application shuts down unexpectedly. In that case, if you can avoid push mode, you should be fine; otherwise, you got to manually terminate remaining sessions.

One More Secret About Session Management in vSphere originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Escaping Characters for SOAP XML: Late But Here

Steve Jin — Mon, 26 Sep 2011 05:01:23 +0000

It’s a known bug in VI Java API that it did not escape strings to be included within a XML tag. The potential risk, although very very rare, is that it can blow the de-serialization of a request on the server side. I did get one or two reports on failing on login, which turned out to be caused by special characters like < or > in passwords. As a quick fix, an escaping logic has been added to escape the special characters in passwords.

This is of course just a workaround, not really meant to be future proof. I think the chance of getting into similar trouble is so small that it may not worth the effort to make it right until a recent bug report on the OVF importing. The method call ResourcePool.importVApp() returns with InvalidRequest exception as follows:

com.vmware.vim25.InvalidRequest: null
...
at com.vmware.vim25.ws.XmlGen.fromXml(XmlGen.java:201) ~[vijava3.jar:na]
at com.vmware.vim25.ws.XmlGen.parseSoapFault(XmlGen.java:80) ~[vijava3.jar:na]
at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:133) ~[vijava3.jar:na]
at com.vmware.vim25.ws.VimStub.importVApp(VimStub.java:1418) ~[vijava3.jar:na]
at com.vmware.vim25.mo.ResourcePool.importVApp(ResourcePool.java:102) ~[vijava3.jar:na]

After being debugged it turned out to be related to a field of string type holding XML content, therefore breaks the server side.

We can patch it up with the same approach as with password, but decided to get it right this time as the possibility of running into this issue is higher in vSphere 5.

The fix should be fairly simple- that is to escape in the serialization engine. Whenever there is a string value, escape it with the following code.

private static String escapeForXML(String str)
{
  StringBuilder sb = new StringBuilder(str.length());

  for(int i=0; i')
    {
      sb.append(">");
    }
    else if(c=='"')
    {
      sb.append(""");
    }
    else if(c=='\'')
    {
      sb.append("'");
    }
    else
    {
      sb.append(c);
    }
  }
  return sb.toString();
}

One of the reasons that I was slow to get it right was concern on performance. After testing it, it’s not bad at all. At least I cannot tell much difference in performance. After all, the string typed parameters are mostly pretty small in size. Also, using StringBuilder instead of StringBuffer might also have helped.

The fix will be in 5.0 GA build. From there, we will have a piece of mind that it won’t be a potential problem any more. Also changed is the importing vApp sample included in VI Java API.

Escaping Characters for SOAP XML: Late But Here originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Missing ArrayOfDatastoreEventArgument

Steve Jin — Mon, 19 Sep 2011 06:06:19 +0000

After the vSphere Java API 5.0 beta was released, I got a very interesting bug that I think is worthwhile to share with the community. Note that I used the word “interesting.” It turned out to have no solution logically, but quite easy to work around and patch up. The workaround addresses only particular issue but does not prevent similar bugs from happening in the future.

Confused? Let’s take a quick look at the bug report:

This was observed with the 2.1 version. This is a type that was observed in the EventEx for storage redundancy lost/restored. I have verified that on adding the type, the error is resolved. Attaching the file I added

java.lang.ClassNotFoundException: com.vmware.vijavavim25.ArrayOfDatastoreEventArgument
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at com.vmware.vijavavim25.ws.XmlGen.getVimClass(XmlGen.java:179)
at com.vmware.vijavavim25.ws.XmlGen.fromXml(XmlGen.java:233)
at com.vmware.vijavavim25.ws.XmlGen.fromXml(XmlGen.java:288)
at com.vmware.vijavavim25.ws.XmlGen.fromXML(XmlGen.java:133)
at com.vmware.vijavavim25.ws.WSClient.invoke(WSClient.java:153)
at com.vmware.vijavavim25.ws.VimStub.queryEvents(VimStub.java:2351)
at com.vmware.vijavavim25.mo.EventManager.queryEvents(EventManager.java:86)
at EventTest.main(EventTest.java:33) Exception in thread “main” java.rmi.RemoteException: Exception in WSClient.invoke:; nested exception is:
java.lang.NullPointerException
at com.vmware.vijavavim25.ws.WSClient.invoke(WSClient.java:157)
at com.vmware.vijavavim25.ws.VimStub.queryEvents(VimStub.java:2351)
at com.vmware.vijavavim25.mo.EventManager.queryEvents(EventManager.java:86)
at EventTest.main(EventTest.java:33) Caused by: java.lang.NullPointerException
at com.vmware.vijavavim25.ws.XmlGen.fromXml(XmlGen.java:255)
at com.vmware.vijavavim25.ws.XmlGen.fromXml(XmlGen.java:288)
at com.vmware.vijavavim25.ws.XmlGen.fromXML(XmlGen.java:133)
at com.vmware.vijavavim25.ws.WSClient.invoke(WSClient.java:153)

A little clarification here: although observed in 2.1 but it’s really with vSphere 5.

The call stack clearly states that the type ArrayOfDatastoreEventArgument is missing. Naturally I first verified whether it’s actually defined in the com.vmware.vim25 package. After failing to find it, I checked the WSDL files of vSphere 5.0. To my surprise, it’s not there neither. You may be thinking: why not the WSDL files of vSphere 4.1 which corresponds to the version 2.1. A good question. To be compatible, vSphere API does not remove types therefore the vSphere 5.0 API should have all of 4.1. Therefore not finding it in 5.0 is sufficient to say it’s not in 4.1.

Now it becomes a puzzle why there is a type that not defined. Further thinking about the case which it happens, I dig down to the EventEx data object. As the API reference states, “EventEx is a dynamically typed Event class who type is indicated by its eventTypeId property.” It means this EventEx type is a super type for these whose type is to be decided later.

All the properties of the EventEx look good except the arguments which is KeyAnyValue[]. Within KeyAnyValue object, two properties defined: key as xsd:string; and value as xsd:anyType. The key should have caused no trouble because string type is defined and used a lot in the API. Now the second one could be problematic because it basically says it can be any type, including types that are not yet defined.

The question then becomes how you can know before hand what future concrete types the value will be. Logically it’s impossible! That is why I said early there is no solution to this.

To be clear, there are other places where xsd:anyType is used. But in these places, they are mostly strings or other types that have been defined in the WSDL files. Therefore it does not cause trouble. In this particular bug, ArrayOfDatastoreEventArgument type is not defined anywhere but leaked from the server side.

Because the exception is clear and specific, working it around is very easy – just add that type as other existing ArrayOfXXX types in the WSDL. As you expect, it worked. So if you are using VI Java API 5.0 GA, you should be covered.

But I know it’s not future proof. Similar problem can come up without control of client side. Possible solutions to this issue include specifying specific types in place of xsd:anyType, which is a bit late given that it’s already out; or limiting the possible types to only existing ones in WSDL; or proactively add more possible types into WSDL.

Missing ArrayOfDatastoreEventArgument originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

VIX Implementation in vSphere Java API

Steve Jin — Tue, 13 Sep 2011 04:44:59 +0000

Among all the new features vSphere API exposes, I think VIX integration is very important. All of sudden, the vSphere API gets a boost on manageability of guest OS, and you can do many more with single set of APIs.

Yes, VIX has been there for a while. To use it, you have to download the SDK separately and tie your application to either Windows or Linux, and interfaces for C, Perl or COM. It’s not as portable as vSphere API which is built on top of Web Services. Of course, vSphere Web Service API has its own problem but has been mostly addressed in open source vSphere Java API.

While designing Java API for the VIX in VI Java API 5.0 beta, I made some changes to make it more object-oriented, and as a result easier to use. So if you use vSphere Java API for access VIX, you want to read carefully.

The standard VIX APIs defined in vSphere API have signatures like the following:

public GuestListFileInfo listFilesInGuest(ManagedObjectReference _this, ManagedObjectReference vm,
        GuestAuthentication auth, String filePath, int index, int maxResults, String matchPattern)
         throws java.rmi.RemoteException, GuestOperationsFault, InvalidState, TaskInProgress,
                FileFault, RuntimeFault

Note that the first parameter is the MOR to the GuestFileManager managed object type; the second is to the virtual machine on which the guest OS runs.

In the typical vSphere Java API, the first parameter is captured in corresponding type and therefore not visible in the new signature exposed in vSphere Java API. In the above case, we would have something like the following: (omit the exceptions, same for following signatures.)

public GuestListFileInfo listFilesInGuest(VirtualMachine vm, GuestAuthentication auth,
           String filePath,  int index, int maxResults, String matchPattern)

Still, if you want to do something with a guest OS on a virtual machine, you have to provide the VirtualMachine object every time. It’s OK but could be better. BTW, if you are familiar with the FlyWeight design pattern, that is the style. In this context, the situation to use the pattern does not hold mostly. So we prefer typical OO style.

So I decided to shorten the interface as follows:

public GuestListFileInfo listFilesInGuest(GuestAuthentication auth, String filePath, int index, int maxResults, String matchPattern)

Now how does the API knows which virtual machine? This information is captured in the GuestFileManager managed object type as follows:

public class GuestFileManager extends ManagedObject
{
private VirtualMachine vm = null;
public GuestFileManager(ServerConnection sc, ManagedObjectReference mor, VirtualMachine vm)
{
super(sc, mor);
this.vm = vm;
}

Note that I also include the constructor so you know how it’s created.

Because the GuestFileManager is retrieved from the GuestOperationManager. The original signature there has to be changed as well. In the GuestFileManager case, one additional parameter is added to the original getter method without any signature:

public GuestFileManager getFileManager(VirtualMachine vm)
{
ManagedObjectReference mor = (ManagedObjectReference) getCurrentProperty("fileManager");
return new GuestFileManager(getServerConnection(), mor, vm);
}

So to get a GuestFileManager, you must provide a VirtualMachine object as parameter. Same is true for other three types: GuestAuthManager, GuestOperationsManager, and GuestProcessManager. The result is, as you will find out, cleaner code, especially when you have multiple operations with the same GuestFileManager for example.

I hope you now have better idea what to expect while leveraging vSphere Java API for guest management.

VIX Implementation in vSphere Java API originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

DoubleCloud.org » vSphere API

Announcing Code Generator For vSphere Java API

Related Posts

Why vSphere PropertyCollector Is Hard By Design?

Related Posts

What Roles Does A User Have in vSphere?

Related Posts

Discontinuous Response Stream from vSphere

Related Posts

The Future of VI Java API and How You can Help

Related Posts

VI Java API 5.0 GA Released

Related Posts

One More Secret About Session Management in vSphere

Related Posts

Escaping Characters for SOAP XML: Late But Here

Related Posts

Missing ArrayOfDatastoreEventArgument

Related Posts

VIX Implementation in vSphere Java API

Related Posts