Chapter 2 Known Problems and Workarounds

It is possible to have a process on a system match two Monitored Workloads. When this happens the resources used by that process are summed into both workloads and double counting results.

This double counting can be seen in the profile viewer in Capacity Advisor. The profile graph for a system will be different when viewed outside of a scenario than when viewed inside of the scenario. Data shown outside of a scenario is the actual system total, while system data shown inside of a scenario is the sum of the workloads. Double counting will cause the trace inside of a scenario to be higher.

To avoid this, be careful when defining monitored workloads.

Utilization data for Monitored Workloads is collected every 5 minutes. No data is collected for any process that does not exist both at the beginning and end of each 5 minute interval. It is possible for a process that runs for nearly 10 minutes to be missed.

Monitored workloads are currently more accurate when the processes in those workloads are fairly long running. No data will ever be collected for processes that run for less than 5 minutes. Capacity Advisor will randomly miss 0 to 10 minutes of processes that run longer than 5 minutes. On average each process will be under counted by 5 minutes (10% for a 50 minute process).

Be aware of the problem and take it into account when interpreting the results in Monitored Workloads.

Don't define a monitored workload where short lived processes are frequent. If no workloads are defined, Capacity Advisor will use data on the system workload. The system workload will count all short lived processes.

Occasionally erroneous data readings occur. Capacity Advisor filters out utilization data that is below 0, but it does not filter out data that is unlikely, or even impossibly high.

These stray readings have little effect on averages, or even 90th percentile values computed from the data, but they can cause peak readings to be off quite a bit.

Removing and reinstalling the VSE product will delete all workload information about the managed systems from the CMS. This does not delete the data from the managed systems.

As new workloads are created it is possible that the new workloads will reuse IDs of some of the old workloads. Data stored on the managed systems using the old workload ID may be collected and associated with a random new workload which happens to have the same ID.

This problem can be corrected by using the profile editor to mark any data older than the re-installation as invalid data. This problem is also addressed in the installation section of the Getting Started with HP Integrity Essentials Capacity Advisor^[1].

You can also remove and reinstall the “HP-UX Utilization Provider” product on the managed systems where the workloads were previously defined. This will remove the old data. The SD product name for the Utilization Provider is “utilProvider”.

Depending on the order the data is collected, capcollect(1m) can generate a warning the first time data is collected from an HP Virtual Machine.

Warning: unable to determine the 
    HPVM Host for Guest "guestname"
Valid CPU utilization data is 
    not available.

Re-collect the data; this should clear up the error.

The terminology “VM guest” was used internally for Virtual Machine or “VM”. Capacity Advisor uses the term “VM guests”.

Be aware that the terms “VM” and “VM Guest” are interchangeable.

Some times in HP-SIM are displayed in the time zone used by the browser, while other times are in the time zone of the CMS. Capacity Advisor times are in the time zone of the CMS.

Be aware of the source of times displayed in SIM, and whether they are in the time zone of the browser or of the CMS.

The default time is not always midnight as might be expected.

Double check the start and end times when creating a Capacity Advisor utilization report.

Using the Collect Capacity Advisor Data All menu pick, or running capcollect with no arguments will try to generate a list of all systems known to HP-SIM. An interprocess request will time out when there are a large number of systems in the list.

Use Collect Capacity Advisor Data on the collection All VSE Resources to collect Capacity Advisor data. This will keep you from having to redefine the scheduled task for data collection every time a new system is licensed for VSE.

The capcollect command does not adjust the time stamps of the profile data samples extracted from the managed system when storing it in the CMS database. The data is stored with time stamps from the system clock of the managed system.

Thus, if system clocks on all the managed systems and the CMS are not synchronized (via NTP, for example) then the utilization traces of the separate systems may be lined up incorrectly to the absolute time scale.

This means that utilization events that occurred simultaneously on two managed systems might look like they occurred at different times when collected onto the CMS and displayed.

Use a time synchronization utility such as the Network Time Protocol (NTP) to synchronize the system clocks of the managed systems and the CMS system to a common NTP server source.

The capcollect command reports that data was collected if any data was collected. If there was an error for part of the day's data you will get both a success message as well as an error message.

HP-SIM displays stdout and stderr on separate tabs and it is easy to miss an error message if you see a full set of success messages on the stdout tab.

Be sure to check the stderr tab to make sure there were no errors during the collections.

The “broken bar graph” representing a system with an allocation of memory that is smaller than the demand is sometimes displayed when it should not be. The code is assuming the memory value is an integer. Thus if a system has 3.98 GB of memory, the software believes it only has 3GB of memory and if the combined memory values exceed 3GB, the overflow condition is indicated by the “broken bar graph.”

Double check the numbers below the graph before deciding a system does not have enough memory to accommodate a new workload.

The message

The system "hostname" is not known 
  to HP-SIM.

is sometimes reported for systems or complexes that do honor a WBEM request. This message indicates that user-entered host names that are invalid or not in HP-SIM's system list.

Ignore this message when it is reported on a system you did not enter on the command line.

If you are using Internet Explorer and attempt to save a report, two File Download popups can appear and both may “hang,” and become non-responsive.

To recover, select a window focus that at least partially conceals the first popup.

Capacity Advisor does not check that the scenarios defined can be implemented by the systems being analysed. For example: running a 4-way VM guest on a 2-way VM host is not supported, but Capacity Advisor will let you try it out in a scenario.

Use Capacity Advisor to model real-life systems and situations. Common sense should prevail when creating scenarios and modifying system or workload attributes.

To obtain accurate utilization data for a VM requires information from the Utilization Provider on both the VM and its VM Host. The CPU utilization values for a VM gathered from the Utilization Provider running within the VM does not accurately reflect the true CPU utilization, but does provide the Memory, Network and Disk utilization values. To obtain accurate CPU utilization values for a VM, the values from the corresponding FSS partition on the VM Host are used. This requires matching the VM with its FSS partition on the VM Host. If a VM is shut down and rebooted, it may run in a different FSS partition after rebooting than it did before. When capcollect runs, it notes the current assignment of VMs to FSS partitions and uses that assignment to associate CPU utilization data from a FSS partition with the correct VM. To prevent misleading CPU utilization values being recorded for a VM, if a VM has been rebooted during a particular 24-hour period from midnight (in the GMT time zone) to the following midnight, all CPU utilization values in that period preceding the reboot are not stored.

To minimize the gaps in Utilization data for VMs, collect capacity advisor data on a VM just before it is rebooted. The next periodic collection from the VM will fill in the data after the reboot and preserve the data collected before the reboot.

When collecting from a VM Host and its VMs for the first time, use caution in interpreting the CPU utilization values for any of the VMs that have been rebooted in the last 30 days. The CPU utilization values shown for the VM for the days preceding the last reboot may not apply to the current VM.

Capacity Advisor will collect data on the system as a whole as well as on any workloads. The whole system data is used in a scenario when there are no workloads, but workload data is what is preferred. It is possible to have months of whole system data, but have none for the workloads that were defined earlier today. Capacity Advisor will try to use the workload data even though it is empty.

Import data from another profile via capprofile (in /opt/vse/bin). See capprofile(1m) for additional information about this command.

Example 2-1 Stitching Data Obtained Prior to Adding Workloads

Given a system named “myhost” with system data that goes back to January 1st, 2005. At 2pm on June 30th, 2005 you add two workload definitions named “existingWL” and “addedWL”. When you do this, the six month's of system data before June 30th are no longer available for use in a scenario.

You can make use of this data by copying it into one of your new workloads. Stitch the system data from the first half of the year onto your existingWL workload by using the capprofile(1m) command:

capprofile -x -b20050101 \ -e200506301400 \ myhost.myco.com > /tmp/sysdata capprofile -i existingWL < \ /tmp/sysdata

If:

the system will no longer be visible within any Capacity Advisor scenarios because it has a workload with uncollected data and Capacity Advisor is not able to aggregate profiles correctly. This may cause Edit Scenario errors if any changes apply to this system.

Re-collect Capacity Advisor data on the system.

The Move Workload page usually computes its metrics over a different time interval than the Edit Scenario page does. This causes some of the metric calculations to differ between the two pages. Peak metrics can be off significantly.

Double check your accumulated workloads in the Edit Scenario page. Avoid using the peak metric as your guide as this metric is the most sensitive to changes in the simulation interval.

The Profile Viewer screen can display data for different intervals ending on a given end date. The Edit Scenario screen can use a simulation interval that starts or ends on a given interval. When launching the Profile Viewer from the Edit Scenario page it is reasonable to have the Profile Viewer display the data for the simulation interval. If the simulation interval is specified using a beginning date launching the Profile Viewer will display the wrong interval.

Define simulation intervals using an ending date, or re-adjust the date each time the Profile Viewer is visited. The data is adjusted forward a number of days equal to the size of the simulation interval minus one. For example, if the Edit Scenario page is looking at Month data beginning March 1st, then change the Profile Viewer date from March 1st to March 31st.

Sometimes the network data imported from OVPA does not match the data collected by Capacity Advisor. The differences seem related to the use of auto port aggregation.

Interpret data collected from OVPA differently from data collected by Capacity Advisor. OVPA data is sum of BYNETIF_IN_BYTE_RATE and BYNETIF_OUT_BYTE_RATE for all LAN ports on the system. Capacity Advisor collects the total bytes in and out of each LAN port on the system, but uses the pstat(2) function for the data.

Capacity Advisor imports OVPA data assuming the units for memory is in kilobytes. The most recent version of OVPA extract outputs memory in megabytes. This change was discovered too late to make a change in Capacity Advisor to correctly import this data.

There are several options to workaround this issue:

A feature of capovpaextract is that when importing data from a system, you do not generally need to give the fully qualified host name on the command line. You can usually give just the hostname, even though workload data is internally stored using the fully qualified domain name. capovpaextract cannot import data if two workloads match the hostname. This happens when workloads are defined on the system as the default name for the OTHER workload will match the system name. It also happens when one system has a name that is a prefix of another, such as “host1” and “host10”.

The error message in this case is not as helpful as it might be. You will see the following message:

One of the tool's parameters was 
invalid.  An argument value contained 
a prohibited character. Do not specify 
the new line character or any of the 
following characters in an argument:
  `;&|(#><

When importing data where one host's name is a prefix for another, use the fully qualified domain name.

When the system name is also matching the OTHER workload, you can workaround this by renaming the OTHER workload.

Another workaround is to run one of the underlying commands directly. This form is subject to change and should not be used in a script that is expected to run in a future release of the product.

/opt/mx/bin/mxexec \
  -t "Import OVPA System Data" \
  -h -A "host1.myco.com" -n \
  host1.myco.com