The holidays are just around the corner and hopefully everyone is taking some time off to spend with their families, I know I certainly will! As I start to wind down 2019, I like to use this time catch up on things in my backlog that I was not able to get to in the year. This can range from blog posts that I still need to read, to session recordings that I have attempted to watch but have only made it half way to random notes on topics to potentially investigate in.

When VMware Tools 11 was released back in September, I had noticed an interesting feature that was delivered as part of that release:

Added appInfo to publish information about running applications inside the guest.

I thought this might be something worth looking at when I found some time. One of the nice benefits of having VMware Tools de-coupled from a specific vSphere release is that VMware can now ship additional GuestOS capabilities to customers without requiring them to upgrade the entire vSphere infrastructure, which brings us to the new appInfo feature.

AppInfo is a new plugin within VMware Tools that enables the collection of the "raw" running application processes within a GuestOS. Once enabled, this information is then published into new VM guestinfo property called guestinfo.appinfo which can then be consumed by standard vSphere Automation Tools. This has been one of the most common VM Automation questions I have received over the years from customers and we can now provide additional insights to our administrators on the underlying applications and its version running within a Virtual Machine.

By default, this new AppInfo capability is enabled by default after installing VMware Tools 11 and is supported with both Windows and Linux GuestOS. If you wish to disable this feature, you can find the instructions here. Below is a Windows Server 2016 which I have Active Directory among other applications running which has the appInfo collection enabled.



Once enabled, the default collection period runs every 30 minutes which can be changed following the instructions mentioned earlier. To make this easier to consume, I wrote a quick PowerCLI function called Get-VMApplicationInfo.ps1 which expects a VM object and then retrieves the appInfo details. As part of the output, the results also includes the last discovered time along with an update counter which can be used to track the number of times the collection has ran since enabling.

UPDATE (08/03/20) - Just learned that the latest like VMware Tools 11.1 now includes supports for appInfo capability for Linux GuestOSes. Previously, this was only supported when using a Windows GuestOS but now customers can have this same visibility into their Linux systems. Here is an example running my PowerShell function against the latest TKG Guest Cluster Control Plane VM which you can see both standard Linux processes along with container processes for Kubernetes.

One thing I did notice is that we simply return all instances of a given process and that may or may not be ideal depending on your use case. I have updated my function to include a boolean switch called -UniqueOnly which will automatically filter out the duplicates as shown in the screenshot below.

. ./VMApplicationInfo.ps1

Get-VMApplicationInfo -VM (Get-VM "DC-01")



In addition to the raw application process running, we can also retrieve the version of the application (if available) and this can certainly be useful to benchmark across your systems in case you are looking for rogue applications that have not been updated. I can think of so many interesting use cases for this data and I know many of you will find interesting ways of leveraging this data.

Programmatic access to this data is certainly useful but I already know some of you will want to save this data into other formats. I decided to also implement an optional -Output flag which accepts either CSV or JSON value and will automatically export that to a file with the name of the VM and the update counter.



One important thing to note is that although this "raw" data can be useful, it may still be too low level for some customers to make any sense of. This is where tools like vRealize Operations and their integrated application discovery and dependency mapping capability is far better suited for this job which enables additional customization and tagging of custom applications that you may have running. Best of all, the vROps team also provides a REST API which enables customers to interact with this higher level application data which can be used to dynamically update a CMDB to understanding the applications running across their fleet of VMs.

Hopefully you enjoyed this quick post on how you can easily enable application discovery directly within vSphere! This will likely be my last blog post of 2019 and I want to thank all my readers for your support and engagement. Have a wonderful rest of the year and see everyone in 2020!