Consider the following recommendations before deploying AppManager for VMware vSphere:
When running AppManager for VMware vSphere on AppManager 8 or higher, use the Delta Discovery feature in Control Center to run discovery on a schedule to more quickly detect changes in your vCenter environment. NetIQ Corporation recommends that you do not run the Discovery_VirtualCenter script more than once an hour.
Use an AppManager agent computer that meets the following minimum requirements:
Dual Core/Dual vCPU 2.4 GHz (or higher)
2 GB RAM, in addition to the RAM needed for vCenter if the agent is installed on the vCenter server
If you are monitoring over 100 virtual machines or more than 50 hosts, install one of the following hotfixes to enable the module to collect a higher volume of data more reliably:
AppManager QDB hotfix 7010373 for AppManager 8.0 Service Pack 2
AppManager QDB hotfix 7010372 for AppManager 7.x
For more information about hotfixes, see the AppManager Suite Hotfixes page.
In addition to installing one of the above hotfixes, you should also update the PIOC (persistent IOC) file setting on the management server and update the mapqueue setting on the agent.
To update the PIOC file setting on the management server:
Navigate to the following location in the Registry Editor for the management server:
On 32-bit machine: HKEY_LOCAL_MACHINE\SOFTWARE\NetIQ\AppManager\4.0\NetIQms\Config.
On 64-bit machine: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\NetIQ\AppManager\4.0\NetIQms\ Config.
Set the PIOC Data Map File Size MB key to 150 MB and restart the management server.
To update the mapqueue setting on the agent:
Navigate to the following location in the Registry Editor for the agent:
On 32-bit machine: HKEY_LOCAL_MACHINE\SOFTWARE\NetIQ\AppManager\4.0\AgtShared.
On 64-bit machine: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\NetIQ\AppManager\4.0\AgtShared.
Set the DataCacheQueSize key to 500000 hexadecimal value and restart the NetIQmc service and the NetIQccm service.
This module might create a high number of events and data points for large virtual environments. If you monitor more than 100 virtual machines with multiple Knowledge Scripts, the number of data points and events might cause delays in other AppManager components. Specifically, the SQL server process on the QDB and the Operator Console process can consume high amounts of CPU until all information is inserted into the QDB and displayed in the Operator Console. Once the information is processed, CPU consumption will go down.
Follow these Knowledge Script suggestions:
Use Knowledge Script Groups (KSGs) to define collections of Knowledge Scripts you want to use to monitor the environment. For more information, see Section 4.40, Recommended Knowledge Script Groups.
Run the KSG before running individual Knowledge Scripts.
Do not discover virtual machine details.
Use monitoring policies to allow the monitoring jobs to be automatically updated when changes in the environment, such as a new virtual machine, are discovered.
NOTE:A monitoring policy is applied on the agent and runs an AppManager job for each Knowledge Script in the KSG. A monitoring policy may apply to many objects, and in the largest environments may not work for configuring AppManager. For assistance with configuring Knowledge Scripts and Knowledge Script Groups in a large environment, contact NetIQ Technical Support.
When running ad hoc jobs, define a subset of objects, such as virtual machines, that you want to monitor. For example, group virtual machines in a resource pool. Then run the KSG on the resource pool to monitor all virtual machines in the resource pool with a single job for each Knowledge Script in the KSG. LMA: Hiding this text. It’s the same information as the next bullet.
When running ad hoc jobs, organize the environment to allow a subset of objects, such as virtual machines in a resource pool, to be monitored with a single job. For example, run the ESX or ESXi host monitoring Knowledge Scripts on the cluster instead of running them individually on each ESX or ESXi host.
Ad hoc jobs do not automatically update when changes in the environment, such as a new virtual machine, are discovered. You must manually update a job to reflect changes to the environment.
Stagger the start time of jobs, especially jobs that monitor virtual machines, so they do not all start at the same time. Do this by specifying a daily schedule with a frequency of X minutes with a different start time for each job. For example, to monitor every 5 minutes, specify a daily schedule with a frequency of 5 minutes starting at 12:00:00 for the first job, 12:01:00 for the second job, and so on. Do not specify a schedule of regular intervals every 5 minutes.
Under vCenter Management Server Configuration, in the Select Statistics Collection Settings dialog box, set the Statistics Level to 2, which is required for latency metrics. Higher settings increase the number of metrics returned and will slow the performance of monitoring jobs.
Consider the following when collecting data and raising events:
Schedule jobs that monitor virtual machines to start during off-peak hours, such as in the evening or on the weekend.
Avoid frequent stops and restarts of virtual machine jobs, for example automatically restarting monitoring policies.
The Knowledge Scripts for virtual machines (VmCPUUsage, VmDiskIO, VmMemoryUsage, and VmNetworkIO) perform complex queries of vCenter the first time they run (the first iteration of the job). The information from these queries is stored and used by the job on all subsequent iterations. Therefore, the first iteration may take a long time to execute, depending on how many virtual machines you have. You may experience temporary delays for data and event collection.
The AppManager for VMware vSphere module can collect a large amount of data and can raise many events, depending on the number of virtual machines you are monitoring. Contact Technical Support for assistance in setting up your AppManager management server cache files.