When an issue arises in your vSphere environment and you engage with VMware GSS, one of the first task you will mostly like be asked to perform is to generate a support log bundle and submit it. You can generate a support bundle using the vSphere Web/C# Client as seen in the screenshot below.
Last week I recieved a question from one of our development teams about generating support log bundles for both vCenter Server and ESXi hosts, but using the vSphere API instead of the UI. This functionality is available as part of the DiagnosticManager and the method you will want to call is GenerateLogBundles_Task() which allows you to specify which systems to collect support logs from. This by far is the easiest way if you just want to collect all logs and I will go into more detail in a bit on what I mean by this.
When invoking the GenerateLogBundles_Task(), support logs will be generated on each of the respective sub-systems which includes vCenter Server and the ESXi hosts. Once the log bundles have been created, the API will return a list of download URLs to the support log bundles. To demonstrate this functionality, I have created a sample vSphere SDK for Perl script called generateLogBundle.pl
The script assumes you want to collect ALL logs for both vCenter Server and ESXi hosts being managed by the given vCenter Server.
While working on the sample code, one thing I had noticed in the vSphere Web/C# Client is that you have the ability to select the specific logs to export.
I was looking through the vSphere API but I did not find a way to specify this level of granularity in the logs. I was of course curious and wondered if this was using some sort of private vSphere API (which I hoped was not the case). I decided to pull out one of my favorite tools when I get stuck with a question around the vSphere API which is Onyx. After manually generating the support log bundle and selecting a subset of the logs to export, I found out this process actually makes a call to a CGI script on the ESXi host called vm-support.cgi.
The list of available logs to export is generated by making a GET request to the following URL: https://[ESXI-HOSTNAME]/cgi-bin/vm-support.cgi?listmanifests=1
The output is an XML file that contains the manifest of the available logs to export in the log support bundle. To specify the specific logs to collect, you must provide the "id" property as seen in the screenshot above. In this example, I would like to collect the following: System:Base, VirtualMachines:GuestState, Storage:VSAN and VirtualMachines:diskinfo
To generate a support bundle from the ESXi host that contains the above, you will need to issue a GET request using the following URL: https://[ESXI-HOSTNAME]/cgi-bin/vm-support.cgi?manifests=System:Base VirtualMachines:GuestState Storage:VSAN VirtualMachines:diskinfo
This will instruct the ESXi host to generate the log bundle that contains the following manifest log files. To include others, you just need to append to the URL. You can easily test this out by pasting this URL into a web browser and providing your ESXi credentials and the logs will be available for download. Going back to my original observation, this is actually how vCenter Server provides the ability to export specific logs from each of the ESXi hosts when generating a support bundle.
If you would like to use the vSphere API to provide this same capability, you just need to leverage the AcquireGenericServiceTicket() API method which is available as part of the SessionManager and specify the URL for the support bundle. This will allow you to request a support log bundle from within vCenter Server without having to go directly to each of the ESXi hosts manually. You can see a very similar implementation of this API by taking a look at my How to efficiently transfer files to a datastore in vCenter using the vSphere API and specifically the efficent-upload-files-to-datastore.pl sample code.
Redmond Hallahan says
You can also get performance data via vm-support.cgi eg:
https://ESXi_host_FQDN/cgi-bin/vm-support.cgi?performance=true&interval=5&duration=300
I got this added to the kb last year: http://kb.vmware.com/kb/1967