After downloading the vSphere 5.5 SDK GA release last week, I started to look into the API reference immediately. Because I am pretty familiar with previous versions of vSphere APIs already, I just jumped directly into the “New and Changed Managed Object Elements in 5.5” page (there is a link on the home page of API Reference) as I had to work on the open source vijava API 5.5 which was released as beta last Friday.
As it’s asked about when the vijava API 5.5 is ready, the answer is NOW. A couple of minutes ago, I uploaded the beta release to the sourceforge.net site. Please feel free to download the beta release and give me your feedbacks and bug reports as soon as possible. I plan to GA the release in about one month.
During the last 3 weeks, I’ve been working on the courseware and online lab for the VMware vSphere API training. It’s now available for delivering as private classes, either online or onsite. All the contents in the training will be highly customizable per your project needs in terms of content and time. For example, if you are a networking company, we can put more focuses on the networking aspect of the vSphere APIs. As a former VMware employee who authored the VMware vSphere SDK book with Prentice Hall and created of the de facto open source VI Java API, I can also give you practical advice for your projects.
As some of you may have known, I just left VCE last Friday. It’s really a tough decision as I enjoyed very much working with my colleagues there during the last two years, and the company continues to grow rapidly. Building my own business is something I had always dreamed about. I am glad I finally took it into action.
Last week was pretty exciting with VMworld 2013 in San Francisco. I sat through the keynotes and talked to many friends at VMware and partner community who showed up in the SolutionExchange where I spent most of my time. On Thursday I got a bit time to attend a few breakout sessions.
In first day keynote, VMware CEO Pat Gelsinger laid out three imperatives for VMware: 1) Virtualization extended to ALL of IT; 2) Management gives way to automation; 3) Compatible hybrid cloud is ubiquitous. The keynote was centered around these three imperatives.
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.
In the virtualization world, virtual machine template (as know as virtual machine image) is a big feature. It allows users to quickly deploy a new virtual machine without the steps to install a new operating system and other software. Because of this feature, we start to have a new problem with too many (unused or useless) virtual machines. But this is a separate topic that deserves its own discussion.
After installing OpenStack and posting a few articles, I started to dig down a bit more on the KVM hypervisor used in OpenStack. For that, I wrote about the libvirt API and how to remotely manage KVM with it.
In this article, I will introduce how KVM is used in Openstack and what a virtual machine is made of.
How A Virtual Machine Instance Comes to Life?
Libvirt is an open source project for managing almost all hypervisors and containers. It’s implemented in C and can be exposed through different language bindings.
There are both server (a.k.a daemon or agent) and client. If you are familiar with VMware vSphere (I assume you are if you read my blog), the server is very much like the hostd running on the ESXi side. The client is like the VI Java API that can be used for remote management.
As discussed in my previous post, Libvirt is an open source project for managing hypervisors. With the increasing popularity of Openstack, it’s important to get familiar with KVM as an alternative virtualization platform to commercial products like vSphere and Hyper-V.
To use KVM, you don’t have to install Openstack – you can just install KVM as a standalone product as described in my previous post. In that, it’s pretty much like VMware Player or Workstation. In terms of maturity, KVM is pretty solid and way ahead of Openstack which is also improving quickly since last year with many commercial vendors jumping in.
While working with Openstack on both VMware virtual machines (with no virtualization instruction set exposed) and physical machines, I found virtual machine instances can be deployed seamlessly. On a machine that does not have virtualization instruction set exposed, KVM falls back to QEMU silently. That is why could I try out OpenStack on virtual machines before my hardware was ready. Because both KVM and QEMU support the same libvirt APIs, you would not notice any difference using command line like virsh, or Virtualization Manager. That is the beauty of standard APIs with different implementations, similar to the standard vSphere APIs that are implemented by both vCenter and ESXi.
As mentioned earlier, I got the KVM instances running on my compute cluster after installing the Openstack. I’ve been curious on KVM management APIs, so I took some time to give it a try. In the following, I’ll detail on how to set up environment and get your first HelloWorld type of Java code working.
After installing Openstack, I got KVM/QEMU installed as a by-product. To get myself familiar with the functionalities, I played with Virtulization Manager and the virsh command line. By comparing with the libvirt API, I found they are pretty similar. Therefore, I think it’s a good starting point before jumping to the APIs. Also, the virsh is implemented on top of the libvirt APIs.
In my last article on orchestration, I talked about the issues with the current workflow design. Although intuitive and easy to get started, it’s really inefficient and hard to handle for complicated workflows. A natural follow up question is, “is there any better way to design workflows?”
Like everything else, there is hardly an approach that is better than others in every aspect. The alternative approach, coding, may not be as intuitive as the visualized flow chart approach, but it’s highly productive. So the quick answer for the above question is yes if you can combine them together.
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.
The software-defined networking is the new buzzword for network centralization, which is also known as OpenFlow or network virtualization. The idea is to centralize the control to a server (or a cluster of servers) called controller.
With the acquisition of Nicira by VMware, the software-defined networking has caught many eyeballs from the community. From there, VMware extended it to a new vision called software-defined datacenter which includes three elements of computing: compute, network, and storage.
After server virtualization took off, virtualization became a buzzword which made it easy to get attention from market, and for startup companies, to get funding. Therefore you’ve seen many technologies claiming it’s * virtualization mostly for marketing purpose. Network virtualization is such a case. The even newer term for it is called software defined network, or simply SDN.
It’s Centralization, Really!