Comments (0)

The following tables list all the managed object types in VI 3.5, vSphere 4 and 4.1. A short description is provided for each type explaining its major responsibilities.

Note that the managed object types are added in an incremental way. The types in older versions are still supported in newer versions. The complete types in a verion include ones in the correpsonding table plus all the ones in all older version tables.

Hope this post gives you a high level overview of functionalities of the vSphere APIs. Check out other blogs such as best practices (1-5, 6-10) on how to use them in general. And don’t forget my book which introduces them extensively with many read to use samples.

Table 1 Managed Object Types in VI 3.5 Read more »

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

Comments (4)

Examining logs is an important way for debugging and troubleshooting a system. There are about ten log files in the ESX server for the hostd agent, which listens API calls, with the same naming pattern as hostd-?.log under the /var/log/vmware directory. The hostd-index file has the number of currently used log files.

The log entry has a similar format to that of VC server logs. Following is a quick sample:

[2008-06-21 07:24:40.769 ‘SOAP’ 64834480 trivia] Received soap request from []: checkForUpdates

The log level can be configured in the /etc/vmware/vpxa.cfg file. Just look for a section like the following. The possible levels are the same as those of VC logs: none, error, warning,info, verbose, or trivia, in an order from less to more detailed messages. Read more »

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

Comments (3)

Every time I google for VI(vSphere) Java API, I get something new. Here is yet another one I just found. It’s a blog article Easy VMware Development with VI Java API and Groovy by Aaron Sweemer. By reading his blog site, I came to know Aaron is actually my colleague at VMware working as a Sr. System Engineer in Cincinnati Ohio. He is the principal blogger at Virtual Insanity.

In his blog, Aaron showed a HelloVM.groovy program after my HelloVM.java from the VMware VI Java API project. Upon reading his code, you can have a good sense what the Groovy version looks like. He also gave a nice and short introduction about Groovy, along with links to online tutorials. So don’t worry if you are new to Groovy. In the end, he listed 7 steps on using VI Java API in Groovy for fun! In one of follow up comments, Guillaume Laforge contributed a slightly “goovy-fied” version. Great jobs Aaron and Guillaume! If you want to leverage VI Java API in Groovy, the article is a must read.

The VI Java API can be used in any JVM languages. If you are interested in writing a tutorial for other languages, please let me know (sjin2008 at users.sourceforge.net) and I will be happy to include your tutorial in the VI Java API website.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

Comments (0)

As I discussed extensively in my book, the PropertyCollector is very powerful yet not easy to use. There was a question posted at vSphere Java API forum related to the property collector which I think worths sharing here. Although it’s found using vSphere Java API, but it really goes beyond the API to the vSphere API itself.

The problem was not able to retrieve the info.vmfs property of a Datastore managed object using vSphere Java API, but OK with others like info.freeSpace, info.maxFileSize, info.name, etc. If MOB is used, the info.vmfs can be retrieved without any problem.

vSphere Java API wraps up the PropertyCollector using getter methods for all the direct properties in very managed object. Mostly you don’t need to touch the PropertyCollector at all.

In some cases, you do want to get hold of the sub properties directly to save CPU cycle and bandwidth. That is why I decided to open up the getPropertyByPath() method with which you can provide the property path and get the value in one call.

Now, what is the cause of the problem?

It’s related the typing of the property. The info property is typed as DatastoreInfo. It does NOT have a sub property called vmfs. But DatastoreInfo is an abstract type which is extended to VmfsDatastoreInfo which does have vmfs sub property. There are other possibilities, for example, DatastoreInfo to NasDatastoreInfo which does NOT have vmfs sub property at all. So before being certain about the real type, we cannot request for info.vmfs.

How to solve this issue?

It’s pretty easy. You want to get the info with getInfo() method, and check the instance type before casting it to VmfsDatastoreInfo. Once it’s casted, you can use the vmfs as easy as one getVmfs() call.

For future tricks and tips, feel free to subscribe to this feed, and follow me at Twitter.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

Comments (0)

With today’s global market, a software vendor has to consider the internationalization (I18N) issue to better serve users in different areas and maximize the return on the product investment. This article introduces the I18N basics of vSphere. Much of the content is based on my book VMware VI and vSphere SDK by Prentice Hall.

There are two basic meanings. First, you have to design your software so that it is localizable. In other words, you have to use the right APIs that can handle double byte characters. Sometimes people call this globalization (G11N).

Second, you should provide localized versions of your software so that users can read and use their native languages. Sometimes people call this localization.

In most cases, you externalize all the text strings that are visible to end users from the code to the resource files and translate them into different languages. Then localizing the software is as easy as combining the code and localized resource files. This is the way VirtualCenter server is localized. Depending on the programming language and platform, the resource files can be organized differently and might have another format. For example, Java uses properties files, yet C++ on Windows uses resource dlls.

That said, I18N is a broad topic that does much more than what is briefly covered here. Further discussion is beyond the scope of this book, but you can find more detailed information online.

As discussed, the VI SDK is essentially a set of Web Services interfaces. The WS-I18N summarizes four internationalization patterns that can be applied with Web Services when deployed. Read more »

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.