After leaving VMware and VCE, I founded DoubleCloud Inc. While working with many of my clients, we found it’s really a pain point for people to use vSphere Web Client which is quite slow and based on obsolete Flash technology. The old vSphere Client is a lot better in performance and usability, but VMware stopped upgrading it with new features.
When I was doing a demo today, I got an error saying “An internal error has occurred – Error #1099. Reloading the client is recommended, so as to clear any problems left by this error. Click Yes to reload the vSphere Web Client?” After reloading the Web Client, I got the same error. So something has to be fixed on the server side.
There is a big change in the vCenter 6.0 with the introduction of Platform Service Controller. To run vCenter 6.0, there must be a PSC server somewhere: either existing one, or new one installed together with vCenter. For most dev/test environments, you would choose the latter option which is also referenced as embedded mode. Because of this separation of vCenter and PSC, the installation process of vCenter appliance 6.0 is quite different from the previous versions.
If you want to find out the information in the vCenter database, the VMware support bundle comes handy. For example, if you want to analyze the event history, task history, you can dig out these information from the support bundle. By default, the vCenter support bundle is collected as part of the VMware support bundle on standalone client, but not on the vSphere Web Client. So make sure to mark the check box if you want the vCenter info.
As @lamw documented in his blog, you can access the database in the vCenter software appliance (vCSA). In the first appliance of version 5.0, VMware included IBM DB2 Embedded and then switched to vPostgres right after. That’s because vPostgres is VMware’s own product based on the open source Postgres.
By default, the access to the vPostgress database is limited to local applications. In other words, if you want to access the database remotely, it will not work. After researching a little, I figured out how to configure the databse for remote access.
In my last article, I discussed on the format requirement for Java APIs and how I found out the root cause and its solution. Even more mysterious is the format requirement of VMware vCenter as I discovered in another VMware related project, in which I needed to register an extension with vCenter and set up its certificate.
Just played with vCenter Orchestrator REST APIs and found it’s pretty straight-forward to use. With the REST APIs, you can manage various resources such as workflow, workflow run, workflow presentation, workflow user interaction presentation, catalog, action, package, inventory, action, category, configuration, content, notification, service descriptor, user. It seems possible to build your vCO client like GUI with this set of APIs.
API Documentation Included
While playing with VMware Single Sign On (SSO) SDK, I got into an exception indicating that the request had expired.
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Request has expired at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) at $Proxy40.issue(Unknown Source) at com.vmware.sso.client.samples.AcquireHoKTokenByUserCredentialSample.getToken(AcquireHoKTokenByUserCredentialSample.java:233) at com.vmware.sso.client.samples.AcquireHoKTokenByUserCredentialSample.main(AcquireHoKTokenByUserCredentialSample.java:285)
Initially I thought it might be caused by timestamps in the arguments sent to SSO server. But further investigation showed that the time on my vCenter appliance server had run 3 hours faster than normal, so whatever request I had submitted from my desktop (whose time is up to the date) was “thought” to be submitted 3 hours ago. No wonder the request was rejected as expired. I think there is an allowance of a few minutes and 3 hours was just too big to ignore.
Logging is an important tool for system monitoring and troubleshooting. vCenter has comprehensive logs for itself and related solutions. We’ll introduce how to change the settings for these logs in vCenter appliance. One obvious use case is to increase the log levels for troubleshooting.
As usual, the vCenter configuration file resides in a subfolder in the /etc folder.
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.