I recently spent some time on vCenter Orchestrator and really liked it with nice integration with vSphere Web Client, even though the Web Client has to improve quite some before it can overtake the standalone vSphere Client.Coming from the programming background, I find the workflow design is pretty easy to understand. Although targeted mostly for people with no programming background, workflow has in fact stronger typing than typical scripting. That may explain why having programming background helps a lot to quickly ramp up on workflow development.
After playing with the vCenter appliance simulator feature documented by William, I got into a show stopper that vCenter service (VPXD) could not be started. I don’t think it’s related to the simulator feature at all. My guess is that it’s caused by a sudden power off of the virtual machine but didn’t try to reproduce the problem that way – I care more to fix it than anything else.
A new feature called vCenter Linked Mode has been introduced in vSphere 4. It allows several vCenter servers to form a linked mode group. When you connect to any of the vCenter server via vSphere Client, you see all of them behind a single pane of glass.
I got questions from time to time, “what does it mean for vSphere API?” More specifically, if you connect to one vCenter in a linked mode group, will you “see” all of them? If not, how can vSphere Client achieve that?
Chargeback is an important feature for computing infrastructures. Even inside an enterprise where IT users are not charged with real money, it’s still nice to see the usage patterns and sometimes avoid wasting resources. As I mentioned in IBM RC2, applying chargeback reduced unnecessary usage overnight.
VMware vCenter Chargeback is a component for this purpose. It can run standalone with Web GUI, and surface to vSphere Client as a plug-in. Although its name includes vCenter, it can also work with vCloud Director (see Using vCenter Chargeback with VMware Cloud Director).
VMware vSphere provides comprehensive performance metrics for your needs on performance monitoring and diagnosis. These stats are available through not only vSphere Client but also vSphere APIs. To understand the overall performance management concepts, you want to read this article: Fundamentals of vSphere Performance Management.
Once having the basics, you may wonder what types of stats are exposed. The following table summaries all the 315 performance counters available in vSphere 4.1. As you might have guessed, the information is generated using open source Sphere Java API and then imported into WordPress using WP-Table Reloaded. You can easily sort and search the table.
If you manage a vSphere infrastructure, you may want to collect logs for troubleshooting, debugging, etc. You can get these logs from vSphere Client manually. You can also use vSphere API to collect them automatically.
The related managed object type in vSphere API is the DiagnosticManager. It helps to access logs from either a vCenter server or ESX server. It has no property but three methods:
1. queryDescriptions() provides a list of diagnostic files for a given system. It takes in an optional parameter host for specifying the HostSystem to extract information from. When you connect to the ESX server directly, the parameter isn’t needed. In vSphere Java API, you just pass in a null. When you connect to the vCenter server and the parameter isn’t specified, the method assumes you’re looking for vCenter logs. The return of this method is an array of DiagnosticManagerLogDescriptor data objects. The data object includes six properties: creator, fileName, format, info, key, and mimeType.
Last week I answered a question in VMware Web Services SDK forum about asterisks in vSphere API reference. Underneath these asterisks comes a note saying “May not be present.” What does it really mean?
The asterisks normally show up after properties or sub-properties defined with a managed object. As it says, it’s possible that there is NO value to the property.
How can it be like this?
There are two major causes. First, it reflects the different implementations of ESX, ESXi and vCenter. As a quick example, you can find many of the properties in the “content” (type: ServiceContent) come with asterisks.
On a vCenter server, you will find values to almost all the properties, but not quite so for ESX/ESXi. But we have one API reference document, so it’s natural to mark whatever possible no value as “may not present.”
Secondly, it may be as such depending on the state of a managed object. For instance, a virtual machine can be a bare machine without an OS installed. Therefore, the “guest” property of the virtual machine could have no value at all.
What does it mean to you?
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
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.
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.
In yesterday’s blog, I talked about a little known secret of vSphere MOB – the invisible embedded XML in the HTML pages. To take advantage of the secret, I created a client side REST API which was shipped in VI Java API 2.0.