A common question that I have seen asked by customers is how to correlate a vApp back to it’s original vApp Template in vCloud Director. The primary driver for this information is usually for patching and/or application management but it can also serve other use cases such as application license auditing as well as billing and showback. In prior releases of vCloud Director, identifying this relationship meant monitoring the deployment task which contains the reference to the source vApp Template. This information is usually captured as part of the provisioning process through the use of a custom portal or deployment script. If this information is not captured prior to the task completing, the vApp Template reference would be lost. In vCloud Director 5.1, we have simplified this by allowing you now to retrieve the source vApp Template for any deployed vApp at any point in time.
This is accomplished by using a new vCloud Query Service API type called adminEventCBM as part of the vCloud 5.1 API. I have written about the vCloud Query Service API in the past which is extremely useful for quickly finding vCloud Director objects, you can find more details by referring to this article here.
Note: If you are not familiar with the vCloud API, take a look here and here for an introduction on using the vCloud API.
In the example below, I am demonstrating the API by using the Firefox RESTClient as it makes the output more legible. To lookup the source vApp Template for a given vApp, you will need perform a GET operation on the following URL below and substituting the name of your vApp for the entityName property:
The eventType that we are interested in is com/vmware/vcloud/event/vapp/create and the notation in the filter is just a shorthand for anything that ends with vapp/create and we should just get back one result.
Here is a screenshot of the expected output for our vApp called vCOScripting:
Note: Make sure you set Accept header to application/*+xml;version=5.1 since this API is only available in vCloud Director 5.1.
The information we are looking for is contained in the “details” property which may look a bit complex at first, but is actually structured data formatted in JSON. If we save the details section into a file:
We can make the output a bit more legiable by piping the output to the following python command for decoding: cat <your-file> | python -m json.tool
Here is a screenshot of the output:
The property that we are interested is called vapp.sourceVmContainer.ref which includes both the UUID and name of the original vApp Template that the vApp was cloned from. In our example, our vCOScripting vApp was deployed from a vApp Template called Debian-6.0.4-x32 located in our vCloud Director Catalog.
You can also find this information by using the vCloud UI, but you will need to sort through the Events log for the specific vApp and look for the “creation” event. Below is a screenshot displaying the same information as we saw from the vCloud API:
Another option to make this easily visible through the vCloud UI is to leverage the vCloud Custom Metadata and have a script that will automatically extract the source vApp Template and store that in a custom metadata entry which can then be seen by users when logging into the vCloud UI.
In addition to the new event type mentioned in the above article, there are other new event types as well as support for numeric comparison operations (<,>,<=,>=) which are all new enhancements to the vCloud Query Service found in the new vCloud 5.1 API.
Get notification of new blog postings and more by following lamw on Twitter: @lamw
Note: Make sure you set Accept header to application/*+xml;version=5.1 since this API is only available in vCloud Director 5.1.
The property that we are interested is called vapp.sourceVmContainer.ref which includes both the UUID and name of the original vApp Template that the vApp was cloned from. In our example, our vCOScripting vApp was deployed from a vApp Template called Debian-6.0.4-x32 located in our vCloud Director Catalog.
