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.
OVF stands for Open Virtualization Format, a platform independent, extensible packaging and distribution format for virtual machines. It’s now a DMTF standard.
VMDK stands for Virtual Machine Disk, a format that encodes a single virtual disk for a virtual machine. It’s proprietary by VMware but whose format is publicly documented by the company. You can use VDDK to manipulate the VMDKs.
Several folks asked me about how to use vSphere(VI) Java API to connect to a VM running on vSphere. The quick answer is vSphere Java API is not designed for this. You will need VMware Remote Console, browser plug-in, remote desktop/VNC, SSH client etc. However, it can help you to get the information required by the console or plug-in. Tal Altman from CISCO suggested that it be a topic for doublecloud.org. Here it is.
There are 3 ways to connect to the VM from your client side outside the vSphere and Web Access which have built-in support for console access.
The first two connect to the ESX host, and work even there is no guest OS installed on the VM. The last one assumes you have guest OS installed, and have IP network and server components in place already.
Note that these 3 ways work for the VMs in the public cloud as well if the related ports are open in your firewall. It is, however, not the case for most enterprises, therefore I particularly say it’s for VMs in private cloud. If you don’t have firewall issue, feel free to give it a try with public cloud as well.
Let’s go over one by one in details and see how vSphere Java API helps.
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.
English
Recent Comments