Configuration of VmgOSMemoryTest

Memory shortage on a VM can affect the memory allocation to crucial processes that are being executed on the VM, which in turn can adversely impact the performance of the applications running on the VM. One of the primary reasons for Memory shortage is that of precious memory space being unnecessarily hogged by Modified and Standby memory lists that hold temporary/unused data. The Modified and Standby memory lists cache temporary data when the applications/services run in the VM. These temporary data will no longer be used by the applications/services thus hogging memory space unnecessarily. Therefore, administrators should clear the cached data on a regular basis. If the cached data is not cleared regularly, sometimes, you may not be able to allocate memory to the business-critical processes, which will seriously impact service/application delivery and impair user experience. Therefore, it is imperative that you should closely observe if the memory shortage occurs due to data growth of the Modified and Standby memory lists and proactively initiate remedial actions before it causes severe memory contention on the VM. This can be achieved with the help of the VmgOSMemoryTest.

This test auto discovers the VMs on the virtual server and periodically monitors the memory usage of each VM, checks whether adequate physical memory is available to the VM, and if not, promptly alerts users to the same. In the process, the test also reveals the VMs on which the memory space is abnormally hogged by Modified or Standby memory list. This way, VMs that experience potential memory contention are brought to your attention. Besides warning you of memory contention that Modified/Standby memory lists can cause, the test also empowers you to avoid probable memory shortage by initiating automated actions. These automated actions can be closely tracked using detailed diagnostics.

The default parameters associated with this test are:

• The TEST PERIOD list box helps the user to decide how often this test needs to be executed.

• In the HOST text box, the host name of the server for which the test is to be configured has to be specified.

• Specify the PORT at which the HOST listens. By default, this is NULL.

• Specify the name of the pSeries server in the REAL SERVERNAME text box. If the target pSeries server has been auto-discovered using HMC, the server name will be set automatically in the REAL SERVERNAME text box. However, while configuring this test for a pSeries server that has been manually added, you have to explicitly provide the server name in the REAL SERVERNAME text box.

  Note:
  To obtain the real server name, a user can login to the target pSeries server as a valid pSeries user, go to the shell prompt of the server, and execute the following command: lssyscfg - r sys -F name

• By selecting an option from the IS MANAGED BY list, indicate whether the target pSeries server is managed using an HMC server or an IVM (Integrated Virtual Manager) server. If the target server has been auto-discovered via an HMC server, the HMC option will be automatically chosen from this list.

• This test connects to an HMC/IVM server to perform LPAR discovery and to collect host-level and “outside view” metrics from the pSeries server. To enable this communication, first, provide the IP address/host name of the HMC/IVM server in the MANAGEMENT SERVER text box. If the eG manager had automatically discovered the target pSeries server by connecting to an HMC server in the environment, then, the IP address/host name and user credentials pertaining to that HMC server will be automatically displayed in the MANAGEMENT SERVER, MANAGEMENT USER, and MANAGEMENT PASSWORD text boxes.

  However, if the pSeries server being monitored was manually added to the eG Enterprise system (and not auto-discovered via the HMC server), then, you will have to explicitly indicate whether the target pSeries server is managed by an HMC server or an IVM server by selecting an option from the IS MANAGED BY list. If the HMC option is chosen, then, you will have to provide the IP address of the HMC server that manages the target pSeries server in the MANAGEMENT SERVER text box. In such a case, in the MANAGEMENT USER and MANAGEMENT PASSWORD text boxes, you will have to provide the credentials of an HMC user who is assigned the hmcviewer role.

  On the other hand, if the IVM option is chosen from the IS MANAGED BY list, it implies that the IP address/host name and user credentials pertaining to that IVM server has to be explicitly provided in the MANAGEMENT SERVER, MANAGEMENT USER, and MANAGEMENT PASSWORD text boxes.

  Confirm the password by retyping it in the CONFIRM PASSWORD textbox.

• Set the DOMAIN parameter to none.

• The eG agent remotely communicates with each discovered LPAR on the pSeries server to obtain their “inside view”. For this, the eG agent will have to be configured with the credentials of a valid user with access rights to each LPAR. If a single user is authorized to access all the LPARs on the pSeries server, provide the name and password of the user in the ADMIN USER and ADMIN PASSWORD text boxes. On the other hand, if the test needs to communicate with different LPARs using different user accounts, then, multiple user names and passwords will have to be provided. To help administrators provide these multiple user details quickly and easily, the eG administrative interface embeds a special configuration page. To access this page, simply click on the Click here hyperlink that appears just above the parameters of this test in the test configuration page. In the page that appears next, specify the following:
  • First, provide the name of the Domain to which the LPARs belong. By default, none will be displayed here.
  • The eG agent must be configured with user privileges that will allow the agent to communicate with the LPARs and extract statistics. To enable communication with one of the LPARs, specify the name of a user with access rights to that LPAR in the Admin User field.
  • The password of the specified Admin User should be mentioned in the Admin Pwd text box.
  • Confirm the password by retyping it in the Confirm Pwd text box.
  • To provide the access credentials for another LPAR, click on the circled ‘+’ button in the page. This will allow you to add one more user specification.
  • To clear all the user specifications, simply click the Clear button.
  • To remove the details of a particular user alone, just click the circled ‘-’ button corresponding to the user specification.
  • To save the specification, just click on the Update button. This will lead you back to the test configuration page, where you will find the multiple user names and passwords listed against the respective fields.
  • Once this is done, then, while attempting to connect to an LPAR, the eG agent will begin by using the first Admin User name of the specification. If the agent is unable to login using the first Admin User name, then it will try to login again, but this time using the second Admin User name of the specification. This routine will continue till a login attempt succeeds. Once a login attempt succeeds, then the agent will ignore the subsequent user specifications for that LPAR.

• By default, the HMC/IVM server (as the case may be) is not SSL-enabled. Accordingly, the SSL flag is set to No by default. This indicates that the eG agent will communicate with the corresponding MANAGEMENT SERVER via HTTP by default.

• Administrators of some high security LPAR environments might not have permissions to internally monitor one/more LPARs. The eG agent can be configured to not obtain the ‘inside view’ of such ‘inaccessible’ LPARs using the IGNORE VMS INSIDE VIEW parameter. Against this parameter, you can provide a comma-separated list of LPAR names, or LPAR name patterns, for which the inside view need not be obtained. For instance, your IGNORE VMS INSIDE VIEW specification can be: *lp,aixlp*,lin*. Here, the * (asterisk) is used to denote leading and trailing spaces (as the case may be). By default, this parameter is set to none indicating that the eG agent obtains the inside view of all LPARs on a pSeries server by default.

  Note:

  While performing LPAR discovery, the eG agent will not discover the operating system of the LPARs configured in the IGNORE VMS INSIDE VIEW text box.

• Administrators of some virtualized environments may not want to monitor some of their less-critical LPARs - for instance, LPAR templates - both from ‘outside’ and from ‘inside’. The eG agent in this case can be configured to completely exclude such VMs from its monitoring purview. To achieve this, provide a comma-separated list of LPARs to be excluded from monitoring in the EXCLUDE VMS text box. Instead of LPARs, LPAR name patterns can also be provided here in a comma-separated list. For example, your EXCLUDE VMS specification can be: *lp,aixlp*,lin*. Here, the * (asterisk) is used to denote leading and trailing spaces (as the case may be). By default, this parameter is set to none indicating that the eG agent obtains the inside and outside views of all VMs on a virtual host by default. By providing a comma-separted list of LPARs/LPAR name patterns in the EXCLUDE VMS text box, you can make sure the eG agent stops collecting ‘inside’ and ‘outside’ view metrics for a configured set of LPARs.

• By default, the detailed diagnosis of the Used physical memory measure of this test reports the number of instances of each process running on the VM, and the aggregated memory usage (in MB and %) of every process across all its instances. For example, if users to a VM are together having 15 instances of Chrome open on the machine at around the same time, then the detailed diagnosis of the Used physical memory measure will compute and display the collective memory usage of all 15 instances against the Application Name, Chrome. From this, you can quickly identify the exact process that is ‘collectively’ (i.e., across its instances) over-utilizing the memory. Sometimes, administrators might want to isolate not just the process, but also similar process arguments that are guilty of abnormal memory consumption. This granular insight will take administrators closer to the root-cause of the memory bottleneck on a desktop. For instance, in the Chrome example above, say 8 of the 15 instances are used to access the same YouTube video, and 7 instances are accessing a shopping site. In such a case, if memory usage is aggregated at the URL-level and not the process-level, then administrators can quickly identify which precise URL is draining memory - the YouTube video? or the shopping site? For this, detailed diagnostics should be grouped by process arguments (eg., URLs) and not just by process/application names. To enable grouping by arguments, set the GROUP PROCESSES WITH ARGUMENTS flag to Yes. By default, this flag is set to No.

• HIGH SECURITY flag is applicable only when the target Linux host is monitored in agentless manner. In highly secure environments, eG Enterprise could not perform agentless monitoring on a Linux host using SSH. To enable monitoring of the Linux hosts in such environments, set the High Security flag to Yes. It indicates that eG Enterprise will connect to the target Linux host in a more secure way and collect performance metrics. By default, this flag is set to No.

• The DD FREQUENCY refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 2:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD FREQUENCY.

• To make diagnosis more efficient and accurate, the eG Enterprise suite embeds an optional DETAILED DIAGNOSIS capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the ON option. To disable the capability, click on the OFF option.

  The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability.
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

• If multiple components of the same component type are awaiting configuration, then an APPLY TO OTHER COMPONENTS check box will appear in this page. Clicking on this check box will allow you to apply the configuration to all/selected components of that type.

• Once the above value is provided, click on the Update button to register the changes made.

When changing the configuration for specific servers, a “*” beside the text box corresponding to the parameter signifies that these values have to be manually configured by the user. The parameter values that require to be configured will typically be prefixed with a “$” or contain a series of “*”. A value of "none" in the parameter value indicates that the corresponding parameter value can be changed if required.