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...
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...
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? Read more...
Last week I discussed how to get event type with vSphere API, followed by a comment asking why there is no DatacenterRemovedEvent? Very good question and almost got me there.
vSphere API has a comprehensive object model for event. In version 4.1, we have 474 different types of events representing different things happened in vSphere. When a managed entity is removed, there are normally events associated, for example, VmDeployedEvent, HostRemovedEvent, ClusterDestroyedEvent, ResourcePoolDestroyedEvent, DatastoreDestroyedEvent, DatastoreRemovedOnHostEvent, etc. It’s natural to expect DatacenterRemovedEvent. But you don’t find one.
It’s not only Datacenter which does have DatacenterCreatedEvent and DatacenterRenamedEvent. For Folder type, you find nothing other than VmBeingClonedNoFolderEvent which is not related to lifecycle of Folder at all.
Why are these events missing? Read more...
vSphere has a powerful extension mechanism that allows you to add new features as integral part of the platform. Many vendors have already leveraged this by providing plug-ins so that users can manage their components seamlessly within same vSphere Client.
You can actually do more than that with the extension. The following sample shows how to create your own task and event with vSphere API. The code should be self explanatory therefore I don’t elaborate much here. Note that you must run the sample with a vCenter server as extensibility is implemented only in vCenter.
When running the code, you can see a new task created and progresses with 10% every second in the “Recent Tasks” pane of vSphere Client. When the task is done, you will also see a new event posted in the “Tasks & Events” tab of the host you associate the task with.
What can you do with this capability? Here are two typical use cases: Read more...
Since vSphere 2.5, there is a feature allowing you to capture screen shot of a running virtual machine. It’s not well publicized but you can find a short description with screenshotSupported (boolean) in the HostCapability data object. Thanks to Nikita for bringing this up in the comment of the vSphere Java API 2.1 GA post.
Indicates whether the screenshot retrival over https is supported for this host’s virtual machines. If true, a screenshot can be retrieved at the HTTPS relative path /screen?id=<managed object ID of virtual machine or snapshot>. If any of the optional parameters ‘top’, ‘left’, ‘bottom’, and ‘right’ is specified, the returned image will be cropped from the rectangle with upper left corner (left, top) and bottom right corner (right – 1, bottom – 1). These values default to the top, left, bottom and right edges of the image. The client must use an authenticated session with privilege VirtualMachine.Interact.ConsoleInteract on the requested virtual machine or, in the case of a snapshot, the virtual machine associated with that snapshot.
The managed object ID of virtual machine is the value of ManagedObjectReference, which can be easily found using MOB.
Once you have it, you can issue a URL as follows in any browser and get the screen shot in PNG format. Read more...
VMware vSphere API is defined by WSDL. As discussed in my previous blog REST or SOAP, Web Services is by nature procedural, and it does not support OO (object oriented). This contributes to the learning curve of vSphere Web Service API which is modeled with OO.
What if you want to find out what properties are supported by a particular managed object type in vSphere API? There was a specific question recently in blog comment: how to get valid/supported property paths like summary.hardware.numNics with HostSystem type.
Currently there is no systematically way to get this metadata which is not defined in WSDL. You have to manually read through vSphere API Reference.
Since vSphere Java API 1.0 (a.k.a. VI Java API by then), I have manually added a getter method for every property in the Java API. So the metadata is built in vSphere Java API from the beginning. Whenever there is a manual process, it could be error-prone. As much carefully as I liked, I made mistakes with properties ignored in vSphere Java API occasionally. These mistakes have been immediately patched up upon bug reports or self reviewing.
To get exactly what you want programmatically, you have to do something extra with Java reflection API. Let’s pick HostSystem as an example here. Read more...
Last week was a super busy week for all the people involved in VMworld 2010 in San Francisco. Because I spent two hours driving to Moscone Center and back home, I didn’t write any blog after getting back totally exhausted. Now it’s time to get back to it.
I believe there are many blogs/news on VMworld in general. Let me get down to a much narrow part: VMware Sponsored open source vSphere Java API at VMworld 2010.
Thanks to the community, my presentation on vSphere API Best Practice went very well. It’s based on the top 10 best practices blog (part 1, part 2) I wrote early this year, with real world experiences shared with partner engagements. Two copies of my book were given away at the end of the presentation. Thanks to Pablo Roesch for getting the books!
After the presentation, I was invited to check out new products built on top of vSphere Java API. I cannot disclose all of them here because some are not yet on the poweredby page. Here are several companies I can publicly talk about: Read more...
As I mentioned in a previous blog, vSphere(VI) Java API can be used in any JVM languages/frameworks. We have samples in Jython, Groovy, Grail. This weekend I got a sample in JRuby shared by our community member Martin Jackson in the API forum. Thanks Martin!
I think it would be fun to share it with you. If you can write Ruby code, you can take advantage of VI Java API for managing and automating vSphere as well. If you have samples leveraging the API to share, I am happy to hear about it.
Now, let us take a look at Martin’s sample code ported from a VI Java API sample. Read more...
WIth 2.1 GAed yesterday, I am happy to announce the 3.0 project kicks off officially. For more fun, I picked up a code name for 3.0 release: Crescendo. For folks know music, crescendo means music gets louder and louder. That is where I want to bring the project to. It’s been a huge success for this VMware sponsored open source project. We’ve had 9,000+ downloads, plus 1000+ SVN code sync, after its first debut in 2008.
So where are we going next?
Before answering the question, let’s take a look at the themes of previous releases. The theme of 1.0 was ease of use with full object model and getter methods hiding property collector. The theme of 2.0 was Just Enough High Performance Web Service Engine resulted in not only performance boost, but also clean license with pure BSD, and much smaller footprint and zero memory leak.
Now it’s time to re-visit ease of use again, but from a different perspective. As I discussed early, the learning curve of vSphere API comes from two folds: lack of object model, and complexity of data objects. The 1.0 release solved the problem nicely. Now it’s time to tackle the second one. Read more...
Right after vSphere 4.1 released, VI Java API 2.1 beta supporting vSphere 4.1 was released on July 15. After 40 days, I am pleased to announce GA of the 2.1 release. Many thanks to all vijava community memembers who helped to try 2.1 beta and give feedbacks.
The 2.1 beta is pretty good in terms of quality. I got several emails reporting greeen. I did get several bugs, some of which are carry-overs that should have been fixed in previous releases. Check the end of this blog for a list of bug fixes.
During the beta period, I started a poweredby page which now features 10 companies/products which use vijava API. If you would like your organizations/products included, please let me know.
Enough being said, are you ready to give 2.1 a try? Please feel to download it here. Even you are new to this API, 5 minutes is good enough to have your first HelloVSphere running with this tutorial. Read more...
My colleagues and I had a discussion regarding the vApp template. After virtual machine template for virtual machine, you would expect vApp template for vApp and manage it in a similar way from the vSphere Client. But you cannot.
Most of us know that from vSphere Client, you have context menu item allowing you to convert a virtual machine to a template easily with a click. However you cannot find a similar menu item with a vApp. You can choose to convert a virtual machine inside a vApp, but then the converted template will jump out of the vApp container.
Can we have vApp template? The answer is we can, but in a different way. Read more...
According to a recent post by Duncan, there is an issue with password in ESX(i) 4.1. Only the first 8 characters of a password are taken and validated. A VMware KB article offered solutions to this issue. Read more...
There is a recent question asking how to get the type of event from vSphere API in my previous blog. On one hand, you can clearly see the types of events on a vSphere Client, for instance “info”, “warning”, “error”, and “user.” On the other hand, you cannot find any information about the type from a given event itself using vSphere API.
Strictly speaking an event just indicates something has happened. That is it. You can categorize it differently depending on your goal. The Event type itself in vSphere API models an event as what it is, not about how you look at it. This is a right design philosophy, but turns out to be a little tricky for you to figure out the type of an event.
How does vSphere Client do the trick? Read more...
As a feature, lockdown mode has been added to vSphere 4.0 . Enabling it disables all remote root access to an ESXi machine. Any local changes to the host must be using:
- DCUI (Direct Console User Interface).
- vSphere Client or vCLI connecting to vCenter.
- vSphere Client or vCLI connecting to ESXi with a local user account on the host.
My colleague Duncan Epping has summarized a table showing whether you can change ESXi with different access methods in two modes.
As a general practice for better security, it’s recommended to enable lockdown mode. However the lockdown mode could be breached by adding root user to local groups, Read more...
There is a recent question in vSphere(VI) Java API forum about this. On its face, it’s very easy because most people know how to get hold of the version as follows:
String version = si.getAboutInfo().getVersion();
The si in the above code is the variable of ServiceInstance object. If you have never used the API yet, please try this Getting Started Tutorial which shows how to get your first program running from scratch in 5 minutes.
If you are connecting to a vCenter server and try to get the version of a HostSystem the vCenter manages, it’s not so obvious. But it’s definitely doable. Here is the solution assuming you already get hold of the HostSystem object as host variable here:
String version = host.getConfig().getProduct().getVersion();
Here you know why. First, the aboutInfo is now called product although they are of the same type. Second, it’s hidden within the config property.
Before taking the code away, I would like to share with you an important tip for better performance. Read more...
UUID stands for universally unique identifier (UUID). It’s a 128-bit value. vSphere uses it as IDs for many different types of entities like HostSystem, VirtualMachine, Datastore, etc.
The UUID surfaces to the vSphere API as well. You can find many methods use UUID as parameter or return result. The most commonly used one is the SearchIndex.findByUuid() which find you a virtual machine or a host based on its UUID, either instance or BIOS UUID. The format used for UUID is as follows:
Since 4.0, DistributedVirtualSwitchManager managed object is added and it has a method called queryDvsByUuid(). As reported by VI Java API community, the standard format doesn’t work. The accepted format is like this: Read more...