This article will answer the following questions:
- I can only see Apps_Guestload in the views, instead of all my applications - why?
- What is "Apps_Guestload"?
- How do I set up application discovery?
- How do I configure WMI discovery on the virtual machines?
- Do I need to change the firewall settings on VMs to allow application discovery?
- How does application discovery work?
"Apps_Guestload" is the 'catchall' application which is 'all application performance that is not specifically discovered/categorized'. If you do not have application discovery set up or enabled, it is identical to the VM statistics (App_GuestLoad for VM xyz will be equivalent to the VM xyz vCPU, vMem and so on).
First, we should explain how application discovery works.
Right now, we support WMI discovery and monitoring for applications. We'll be adding support for other targets such as JMX in the near future.
The VMTurbo appliance will contact the VM's which you have discovered via WMI, and retrieve the application information, which is matched to some application names which are defined on the appliance. If the application name is not matched, "Apps_Guestload" will be used.
Most problems are due to login permissions, WMI access rights or firewall(s) on the VMs themselves.
1. License : The most important part!
If you don't have an application discovery licence, you will only ever see "App_Guestload" as we are not discovering any application information.
Contact firstname.lastname@example.org if you would like to upgrade to this feature, or trial it.
You can check if you have a licence by navigating to the Admin Tab, & clicking on the 'License Configuration' button in the "License Configuration" section.
2. User details: The user(s) who have a domain or local account valid on the target VMs needs to be set up.
Most often this will be a domain account (DOMAIN\username is the format to use). You can check and set this for the whole environment or on a per cluster or group basis, by navigating to the Policy/Discovery/Application Discovery/WMI Application and then selecting the group in middle panel:
Note that when you add these details, application discovery will restart. It can be up to 20 minutes (usually, less) for initial results to appear.
3. Application matching: The name(s) of the application executables you wish to categorize. If you are happy with the defaults here, you don't need to change anything at all.
VMTurbo ship some defaults for popular applications, such as IIS & MS-SQL. The definition for 'Sharepoint' shows you how you can match multiple application processes and group them together into one application. You can find these under Policy/Discovery/Application Discovery:
4. Permissions / Data Path: This is the ability of the VMTurbo appliance to communicate with each target VM.
This is the area you are most likely having trouble with. Once you have configured & checked this for a test VM or two, you may wish to push registry changes out using your regular administration toolset to all the VMs.
First, you need to make sure that the username you are using from Step 1 is able to access WMI on the VMs. Choose a test VM and check the following:
The user that you specify must be one of the server’s WBEM Scripting Locator owners.
Each VM requires specific permissions to allow management via WMI. These permissions are set in the host’s WBEM Scripting Locator registry key.
To set the permissions, you edit the registry key to add owners and grant them full control.
To add an owner to the VM’s registry key:
- Launch regedit on that machine as Administrator
- Find the following registry key:
- Right click the key and choose Permissions
- Click Advanced and display the Owner tab
- In the owners list, add the user you want to allow to connect to the machine
- Click Ok
- Highlight the user and grant Full Control
Note: For some versions of Windows there may also be a second registry key to update as shown above. Search for the following key in the registry:
If it exists, follow steps 1-7 above, for this key also.
You can re-check the application discovery here, and see if it is now successful. If not, you may have problems with firewall setup.
There are many different firewalls, so we can offer the following general advice:
- The WMI protocol communicates initially on port 135 (from VMTurbo to the VM)
- Next, a random non-privileged port is chosen, to continue the conversation on (for example, 9942)
- Most firewalls are aware of this and 'follow' the conversation so allowing communications
- Microsoft's own default firewall setup does NOT allow this 'port change'
The firewall would then need to be opened for the VMTurbo appliance to talk on the port you chose.
Alternatively, you may wish to instead configure the firewall to track WMI's 'port changing'.
Most commercial firewalls already support this, but for microsoft, the following command can be used to set enable this 'tracking':
netsh advfirewall firewall add rule name = VMTurbo dir = in protocol = tcp action = allow localport = rpc remoteip = <IP address of appliance> profile = DOMAIN
If you would like to configure the firewall via a graphical tool instead of using the command above, there are some instructions here on how to do that.
If you still encounter trouble, WMI diagnostics can be tried, first on the local VM (can the VM talk WMI to itself?) and then to a 'remote' machine from the test VM (can one VM talk to another via WMI?). Some guidance and tools for this can be found at the following link: