Several weeks ago, Christopher Wells sent me an email for permission for translating my blog into Japanese so that more people in Japan can benefit. Today he told me he had translated one of my posts into Japanese and posted it on his blog site. Here is the first paragraph in Japanese version:
オペレーティング･システム（OS）はソフトウェアの一部で、コンピュータのハードウェアを管理し、様々なアプリケーション用の一般サービスを提供しま す。クラウド・コンピューティングの台頭にともなって、OSがまだ関連するのか、また、将来のクラウドにおいてOSがどんな役割を果たすのか疑問に思う人 もいるでしょう。
Now a little quiz: which original article did Chris translate? I will leave it to you to guess out. Hint: here is the link to the full article. Read more...
In my last blog, I wrote about pattern idea from the famous books “Design Pattern” and “A Pattern Language” and how it can be applied to cloud architecture design. Below and in later posts in this series I shall follow the content outline used there to illustrate the cloud architecture patterns.
Provide a standard way to create new virtual machines based on user requirements.
There are enormous combinations of virtual machines with different operating systems, middleware, and applications. And then we have user data to the mix! We need a standard way to create new virtual machines.
General speaking, there are three basic ways to create new virtual machines: Read more...
Most developers may have noticed the asynchronous methods in vSphere API like PowerOnVM_Task method, but not so many know their synchronous peers like PowerOnVM before 4.1. VMware vSphere API Reference doesn’t mention them at all. But you can find them in WSDL(check out the WSDL snippets at the end of this article).
There is an exception however. In VI Perl, these synchronous methods are exposed. There, you can choose which one to use. In vSphere Java API 2.0, these methods are exposed only in the stub layer but not the object layer. You don’t want to use stub methods directly when you can use objects, therefore I don’t talk much about it even in my book. Somehow I came across a question in the forum asking about this. So I think it may be good to share a little history and insight here.
The differences of these twin methods are minimal. They have exactly same parameters but different returns. The methods whose names include _Task suffix have Task returned. When you have the Task return, the operation may not yet be done at the server side. But with the Task object, you can track the progress, and even get the result data objects. Read more...
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. Read more...
Design patterns have been very popular among software developers since the book by Gang of Four (Enrich Gamma, Richard Helm, Ralph Johnson, John Vlissides) in 1995. If you go to an interview for a software engineering position today, the chances are you most likely get one or more questions on design patterns.
Like many concepts in software that from other disciplines, the “pattern” idea was “borrowed” from “A Pattern Language,” a book by Christopher Alexander on architectural patterns published 20 years before we started to talk about software design pattern. His book turns out to be a great way to summarize and document reusable design elements for different engineering works.
As Christopher points out, “Each pattern describes a problem which occurs over and over again in our environment, and then described the core of the solution to that problem, in such a way you can use the solution a million times over, without ever doing it the same way twice.”
Today I “borrow” the same idea and apply the concept to cloud computing on architecture designs. The main focus is on virtual machine-based architecture patterns so that you can best leverage virtual machines for your cloud computing.
What is a Cloud Architecture Pattern?
An architectural pattern extracts the common and re-usable design concepts and components. If we put it in the big picture, it should be somewhere below the overall system architecture and above software design as the middle layer. Read more...
I recently had a short discussion with my colleague on implementing CLIs with vSphere Java API. One problem is that if you have multiple commands to run, each of them connects to the server and authenticate over and over. You’d better remember to logout the connection each time after you are done, or leave many un-used connections on the server that could significantly slow down your ESX or vCenter server (read this blog for details).
You can have two solutions to this problem. The first one is to have your own “interpreter” command. After you type the command, it shows you prompt for more sub-commands. It’s very much like the “ftp” command in that sense. You can have subcommands like “login” or “open” or “connect” for connecting to a server, and other commands. The “interpreter” command can then hold the ServiceInstance object until it’s closed in the end.
You can save about 0.3 to 0.5 second on creating new HTTPS connection and login for each command after the first one. It’s not a big deal given that vSphere Java API has hugely reduced that time from 3 to 4 seconds with Apache AXIS. So if you switch to vSphere Java API, you get instant 10 time performance gain. Still, if you have many commands to run, it could be a decent saving.
With this solution, you can also implement batch mode in which you can save all your commands into a file and then execute them all with one command. You can find many examples like PowerShell which support interactive mode and batch mode.
Another solution is just having normal commands. The problem becomes how to avoid the authentication for each command after the first. Luckily we have something for you in the API. Read more...
October 6, 2010, is a historical moment for VI Java API project – the total downloads exceeded 10,000. It’s two days earlier than I had expected. After yesterday’s blog on the NetApp and Brocade’s testimonials, the daily downloads suddenly doubled. When I found the stats approaching 10,000, I tweeted “vSphere Java API 9,999 downloads now. Who want to be No. 10,000?” I wish I could have been able to track who made the No. 10,000.
Strictly speaking, the total had exceeded 10,000 a while back. Besides typical downloads, you can also directly sync up with the subversion. As I checked the number there, it had passed 1,000 reads early this year.
Thanks to you all, the vSphere Java API community!
10,000 downloads is not a big deal for an application especially when it’s for end users. It’s a big deal for an API, and even bigger for an enterprise API which requires vSphere environment which not every developer has access to.
Besides the download number, I would like to brag these numbers: Read more...
I am very pleased to welcome NetApp and Brocade to the vSphere(VI) Java API poweredby page. Many thanks to Patric Chang and Katie Colbert from Brocade, and George Costea and Eric Forgette from NetApp for making this happen.
NetApp and Brocade have been using open source vSphere(VI) Java API for quite some time and each has several products shipped with this open source API. As you may recall from my previous blog on VMworld 2010, I did not talk about NetApp and Brocade because I hadn’t got written permission even though they had great shows out there. Please feel free to check them out at VMworld in Copenhagen next week.
I think the key takeaway from this is that vSphere Java API has been stable enough to be used by companies like NetApp and Brocade that demand highest quality of products. For one thing, you can prabably afford not connecting to networks for a little while, but for sure cannot afford messing up your data storage. NetApp and Brocade’s confidence in this API is the best testimonial on the quality and readiness of the API. There are many other even bigger companies are using the API as well. I will talk more about them later. Read more...
We just had the longest discussion in vSphere Java API forum regarding the “UUID of an NFS datastore.” The question is basically how to find the “UUID” via the vSphere API.
You can create datastores based on either VMFS or NFS. The VMFS can be backed up by local SCSI, or SAN (FC, iSCSI). It’s very easy to find UUID of a VMFS based datastore by calling getUuid() method from the corresponding data object VmfsDatstoreInfo.
For NFS based datastore, it’s a lot complicated. I am glad we digged to the bottom of the issue. Instead of going through the long discussion, I summarize the key takeways from the discussion.
Before jumping into details, let’s clarify one thing: NFS datastore does not have a UUID. (If you want to know more about UUID in vSphere, you should read this blog article.) You can check out the NasDatastoreInfo which does not have uuid property. It does, however, have an identifier like 73ca9790-6dbf88b0, which is not a UUID per se. We will call it simply an ID.
You may be wondering why you should care about the ID. It is pretty important in that it’s used in performance stats like the following: Read more...