Home > vSphere API > VIX Implementation in vSphere Java API

VIX Implementation in vSphere Java API

September 12th, 2011 Leave a comment Go to comments

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.

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


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.

Categories: vSphere API Tags: ,