Blog Posts

I presented the Java API for VI SDK at VMware Technology Exchange in San Jose yesterday and got very positive feedbacks.

Here are two UML diagrams I used in my presentation. I think they are very helpful to understand the API and the design thoughts behind it.

1. The overall object model

It can be inferred from our VI SDK API reference. Please note that we don't have a managed object type called ManagedObject in our reference. This is a type defined to capture all the common properties and behaviors of all managed objects. Given the limited size, I only show the names of the types, not properties and methods.

To better group these managed object types, I used colors. On the right most side of the diagram are the ServiceInstance class and various "manager" classes like AuthorizationManager. From the ServiceInstance, you can get any object of these types with single call, for example getAuthorizationManager().

In the middle of left side, you can find ManagedEntity class and its sub-classes like HostSystem, VirtualMachine. These classes represent all the items you could find in the inventory tree from VI client. They are the most important managed objects in the whole model, and all tagged with orange color except the HostSystem.

The HostSystem is very much like ServiceInstance in that it has many "System" or "Manager" types closely attached to it, for example, HostDatastoreSystem. You can get hold of these objects with a single method call from a HostSystem object. For this reason, both HostSystem and all the attached classes are tagged the same color.

2. A detailed partial UML diagram

This UML diagram is extracted from the overall model but adds much more details with properties and methods. If you can understand this diagram, you can then easily understand all the other managed object types.

The ManagedObject class holds three properties:

1. mor of type ManagedObjectReference -- pointing to the ManagedObjectReference object that is used to represent a managed object in VI SDK.

2. serverConnection of type ServerConnection -- pointing to the ServerConnection object I will cover later.

3. objectContent of type ObjectContent -- used for local caching for better performance.

Besides accessors, the class has getCurrentProperty() method defined to encapsulate the PropertyCollector. This method gets called in subclasses to get a property. For example, the getName() in ManagedEntity called it like (String) getCurrentProperty("name"); In most of cases, you don't need to use it at all, I already provide explicit getter methods in concrete subclasses. I may change its visibility to protected later. The other two methods, "getCachedProperty() and refreshPropertyCache()" are designed for caching.

The ServerConnection is used to represent a connection to the server under a specific login user. It holds information like url to the server, the userSession with username etc., and vimService which is the JUMBO interfaces with 300+ methods. For convenience, ServerConnection also has a reference to a ServiceInstance object.

Now let us take a look at the ServiceInstance type. It's a special managed object and the first managed object you will have in a typical application logic flow. You can create a new ServiceInstance object by providing url/username/password, or url/sessionID combination. The later is not used as much as the first constructor, but very helpful when you develop a VI client plugin in Java. I will talk more about it later blogs.

According to the API reference, the ServiceInstance has a ServiceContent object, which holds all the ManagedObjectReferences to various "manager" attached to it, and an AboutInfo object. You can get any of them in a single call. ServiceContent object is, therefore, no long needed, and I don't even provide a getter to it.

The right side of the diagram are the ExtensibleManagedObject and its subclass ManagedEnity. E.M.O doesn't have methods defined at all, but three properties. Therefore it only has three corresponding getters.

ManagedEntity is one of the most important class given that VirtualMachine, HostSystem etc. are all inherited from it. Besides accessors and several methods, I provides some methods to retrieve items in the inventory tree. For example, you can easily find all the Virtual in one single call. Property is used within these methods, but you don't see it.

The above two ML diagrams should have given you a big picture about the object model and how key types are related to each other. If you really need to know more details. Please click into my May 8 posting and read the source code there. For sure, it will give you much more details than I can cover in these two ML diagrams.

This week VMware announces the latest Software Development Kit and I had a chance to catch up with Hari Krishnan the VMware Infrastructure Product Manager for the VDDK.

Pablo: Please tell us about your professional background?
Hari: My professional background includes over 10 years of varied experience in product management, product marketing and technology development for software, security and networking products. Before joining VMware, I was a product manager at F5 Networks for SSL VPN product line. Prior to that I co-founded a start-up ISPsoft, Inc. where I managed IP service provisioning software product. Earlier in my career, I worked in Bell Labs (Lucent) where I developed technologies for IP network management. I got my MS degree in Computer Science from University of California at Los Angeles (UCLA) and Bachelor of Technology degree from Indian Institute of Technology (IIT), Chennai. On the personal side I enjoy the great outdoors and thought it would be nice to have an image of my favorite vacation spots; Yosemite National Park.

Pablo: You must be excited about releasing the VMware Virtual Disk Development Kit, can you tell us why our developers should be interested in it?
Hari: Yes. With VMware Virtual Disk Development Kit we are enabling a new eco-system of partners to develop solutions that integrate with VMware virtual disk. The VDDK is an open SDK that developers can use to build cutting edge applications for creating and accessing VMware virtual disk storage.

Pablo: What are some of the use cases for using the VMware Virtual Disk Development Kit?
Hari: Virtual Disk Development Kit provides easy access to VMware virtual disk storage.

This enables a wide range of use-cases for application vendors including:
o Creation of virtual machine disk files to store backup of physical images
o Read access to virtual disk to enable off-line centralized scanning of virtual machines for anti-virus
o Write access to virtual disk to enable off-line centralized patching of virtual machines Read access to virtual disk
to enable off-line software package analysis of virtual machines

Pablo: Can you tell us how the VDDK compare contrast to our other SDKs ?
Hari: Sure. It’s important to understand the focus of various VMware APIs and SDKs when developing a solution that supports VMware virtual infrastructure. VMware Developer Center is a good place to start.

In particular, if you are developing a backup solution it is important to understand how VDDK compares with VCB (VMware Consolidated Backup) and VI API. VI API is a Web Service / XML interface focused on management of virtual machines and ESX host configuration. Virtual Consolidated Backup enables LAN free backup of virtual machines from a centralized proxy server and eliminates backup traffic from your LAN to improve performance of production virtual machines. VDDK is focused on efficient access and transfer of data on virtual disk storage. VDDK can be used in conjunction with other APIs to offer a complete integrated solution for management of virtual infrastructure. For example, you can use VI API to discover virtual machines deployed on ESX. VDDK can be used to read or write information onto virtual disk associated with a virtual machine. Backup vendors can augment VCB with VDDK to tightly integrate with VMware virtual disk storage.

Pablo: What is the relationship between Open Virtualization Format (OVF) and the VDDK?
Hari: Open Virtualization Format (OVF) is an open, industry standard for packaging and distributing virtual machines. OVF can be used to encapsulate meta-data about a virtual machine such as virtual hardware requirements, licensing information, virtual disk information and product information for virtual appliance. OVF is extensible so virtual appliance vendors can also embed additional meta-data about their product in OVF. OVF supports multiple virtual disk formats including VMware’s VMDK format as well as Microsoft’s VHD format. OVF simplifies deployment of virtual machines by offering a standard way to package and distribute virtual appliances for multiple hypervisor platforms.

VDDK is an open API and SDK to create and access information on VMware virtual disk storage (VMDK). Future versions of VDDK will include support for creating and accessing virtual disks packaged in OVF format.

Pablo: What should our developers do?
Hari: I would encourage developers to check out the VMware developer center, download the VDDK, get involved in VMware developer community, ask questions as well as give us your feedback.
For Download http://vmware.com/go/virtualdisksdk . Bookmark link to VDDK Forum VDDK forums

For folks that might have recieved errors when replacing a VMDK with another VMDK file using FileOperation this Knowledge Base Article was just published, hope its helpful. KB ID 1003567