On November 15, VMware offically announced the long-waited vSphere 6.5, which is a big release after 6.0 release early last year. Along with this vSphere release were a few other products like VMware vSAN 6.5, VMware vRealize Log Insight 4 and VMware vRealize Operations 6.4. According to the blog announcement, the vSphere 6.5 offers these high level features and benefits:
Although we are all familiar with the username and password based login to the VMware vSphere, it’s also possible to login into vSphere with just certificates. If you are a third party vendor, either IHV (independent hardware vendor) or ISV (independent software vendor), the certificate based login is actually a better and preferred alternative to the one using username and password.
Let me explain why it’s the case, and how it can be done painlessly.
Even before VMware announced the GA of vSphere 6.0, I’ve started to work on the vijavaNG making sure that vijavaNG will keep up with the latest release of vSphere. Although it may take a bit time for customers and partners to move onto this new release, we want early adopters to have the choice to use the best Java APIs for managing vSphere.
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.
Since I left VCE four months ago, I have been working intensively on a commercial version of the open source vijava API supporting all versions of vSphere APIs (5.5 is the latest). If you have used the open source API, you know the vijava is much faster than other alternatives. Since its debut, it has been used in many commercial products from companies like Cisco, EMC, HP, etc.
As reported in the community, there were quite excitement about the open source of the pyVmomi, the Python equivalent of vijava API. It was heatedly debated whether to open source the API even when I was working at VMware years ago. One camp of people thought it should be open sourced and even supported as Web Service SDKs; while the other group didn’t think it’s mature and would cause a lot of trouble in so doing. So it didn’t go anywhere in the past few years.
For those who run ESXi on a virtual machine, it’s a great news that VMware has released VMware Tools for nested ESXi as a fling in VMware Labs. Why? With the VMware Tools, you can get guest OS (really the ESXi here) information, like the IP address directly. It may sounds trivial as you can see the IP address from the virtual machine console of a virtualized ESXi. But for automation, it’s pretty hacky to get it programatically. Some people may wonder, “why not run commands via SSH?” It’s true that it’s easy to get the IP by running esxcli command, but you have to get IP first before running the command. With the VMware Tools, you can easily get the IP from vSphere Java API as would with any other normal virtual machines. Even more, you can also run commands like vim-cmd/esxcli in the virtual ESXi via APIs.
It’s not a secret that VMware has a private Python API or so called Python binding for vSphere API. If you haven’t heard about it before, no worry. Here is a link to Hostd General Architecture. Somehow it’s not publicly released as a product for customers or partners. Over the years, I only heard a big bank uses it for internal IT automation. But it’s super easy to get it if you want – it’s part of every ESXi installation. Just check it out at /lib/python26-visor.zip if you SSH to your ESXi box. Update: in ESXi 5.5, look at the /lib/python2.6/site-packages.
To understand the ESX Agent Manager API, we have to first explain the Agent, which is essentially Agent Virtual Machine. The agent virtual machine can be hardware drivers for your ESXi server, or simply software, i.e, virus scan, that should be deployed on each ESXi. They could have been designed and installed directly on ESXi via VIB, but it would increase the risk of destablizing ESXi due to access to lower level APIs of ESXi. To lower the risk, the driver VM idea came up – if the driver VM crashes the ESXi is still solid even though some service may be affected.
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.
While playing vSphere API last week, I got into an issue that I cannot disable the SSH server with Firewall APIs (see HostFirewallSystem). The following call would throw an exception:
There are many other different services like “sshClient” whose ports can be enabled and disabled via the API. As a nice surprise, they all work just fine.
During the past weekend, I upgraded the vijava API project to the new Allura platform provided by Sourceforge.net. That’s really a button click and then waited for incoming emails for status updates. It went smoothly and didn’t take long before it finished.
Note that the upgrade is limited to the project hosting, not the Web site (http://vijava.sf.net) which remains the same and continues to work as before.
It’s been two months since I announced beta of VI Java API 5.1 supporting vSphere 5.1 on September 23. I got many emails asking for the GA date from ISVs and IHVs as the API is now a corner stone in their products. With the long (could be longer, BTW) Thanksgiving holidays, I got some time to review the fixes and release the GA version. I intended to announce it yesterday but somehow extra spam comments pushed the database behind over 100MB limit thus I could not post any new article.
One of the key new features in vSphere 5.1 is the Single Sign On. Because it’s new and also complicated, I’ve heard it’s not easy to get it right the first time. Experts recommend that you should play with it in a test or staging environment before upgrading your production environment.
I know it’s well past the GA date of the product on September 10, but I still decide to write this what’s new for the completeness of vSphere SDK FAQs.
As I always emphasize, the SDK/APIs are “view” to the product (you can think it as “model” here). Therefore to understand a SDK/APIs, it’s important to check out the product first. No exception for the new features: what’s new in vSphere decides what’s new in vSphere SDK/APIs. For that, you want to check out the What’s New in VMware vSphere 5.1 at VMware website.
While trying latest Microsoft Visual Studio 2012 Express, I also played with the C# samples of the VMware vSphere SDK. Unfortunately, there isn’t direct support for VS 2012 but for VS 2010, 2008, and 2005. However, you can easily create project files for the VS 2012 by yourself assuming you are already familiar with the Visual Studio environment.
After VMware released the vSphere 5.1 on the night of September 10, I finally got a chance to look at the new vSphere API, including the API reference and more important to me the WSDL files.
I was relieved to find out that there weren’t many changes. No single managed object is added to the vSphere 5.1 API, meaning a lot less work than I thought for vijava API to support the latest vSphere 5.1.
Recently I got several questions and even a bug on supporting the next release of vSphere in the open source VI Java API. The questions are mostly from VMware partners who have early access of the private beta of next release of vSphere and want to ship their own products at the same time of vSphere GA. I figure more partners may have the same question, therefore decide to answer it all here with a possible work around.