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!
Joe Houghes says
Quick note, you're missing the final '1' in the dot sourcing example to import the function. Just want to point it out so users don't have issues with running a copy/paste.
William Lam says
Thanks for the catch Joe! Just fixed
RM says
Has appinfo always been disabled by default? I don't recall having to turn it on when I checked out the first release of Tools 11. Maybe I'm going senile...
William Lam says
Richard,
Yes, please re-read my blog post as it states that clearly. Its very possible an OS owner was made aware and turned it on, as this has to do be done within the guest for this to actually work.
William Lam says
Richard,
I stand corrected, I was made aware internally that the AppInfo feature is actually enabled by default. Apologies, I had assumed it was off by default and hence I ran through enablement workflow but I think it was because the polling interval had not been reached. You're correct, no additional work needs to be done if you want to have this feature 🙂
RM says
Nice! I was thinking perhaps the 11.0.0 release had it turned on by default and the latest point release didn't.
In related news, Symantec A/V takes exception to having its executables read by vmtoolsd during the inventory process. I had an interesting e-mail exchange with our security group a day or two after Tools 11 was released. 🙂
Rob Z says
William,
Has this been tested on VMs running windows 10 in a Horizon VDI environment? How applicable do you think this would be in this environment to assist in providing the total usage of desktop applications?
William Lam says
Hi Rob,
I've personally not, but this will work on any system as it's using the OS APIs to retrieve this information. I suggest rolling it out on one of your VDI systems and see what it gives you to get an idea.
Chris P. Schiggen (@ace02000) says
great post, thank you 🙂
Chris P. Schiggen (@ace02000) says
Hi William,
is there any possibility to activate this feature automatically with the installation of the tools?
Tinselhernande says
If you have to explicitly enable this feature, what's the purpose of the KB article mentioning that there could be performance issue using AppInfo and instructing how to disable it? (https://kb.vmware.com/s/article/78434)