gwlmreport(1M)gwlmreport(1M)NAMEgwlmreport - produce advanced textual summary reports for workload
resource utilization
SYNOPSISgwlmreport command [options]
AVAILABILITY
This command is available only on gWLM Central Management Servers (sys‐
tems where you run gwlmcmsd). On HP-UX systems, it is in
/opt/gwlm/bin/. On Microsoft Windows systems, it is in C:\Pro‐
gram Files\HP\Virtual Server Environment\bin\ by default. However, a
different path may have been selected at installation.
To run the command, you must be logged in as root on HP-UX or into an
account that is a member of the Administrators group on Windows.
DESCRIPTION
Use gwlmreport to extract data for a given set of workloads over a
given date range, and either create summary reports or write that data
to comma-separated value (CSV) output. gwlmreport can get data from
one of two sources: By default, it pulls data from the gWLM database.
It can also use CSV input, which you point it to using the --inputpath
option.
NOTE: To ensure data from the current day is included in any reports
you create, run the following command on your CMS:
HP-UX # /opt/gwlm/bin/gwlm history --flush
Windows
C:\Program Files\HP\Virtual Server Environment\bin\gwlm
history --flush
(This is the default path for Windows. However, a differ‐
ent path may have been selected at installation.)
Valid values for command are:
extract Extract data from the gWLM database into CSV for‐
mat
resourceaudit Generate a resource audit report
(Provides an overview of resource usage)
topborrowers Generate a top borrowers report
(Helps identify workloads that may require addi‐
tional resources)
abnormalutil Generate an abnormal utilization report
(Shows CPU utilization over various time periods
so you have a "normal" utilization pattern
against which to compare abnormal utilization)
ovpafeed Extract data to use with OpenView Performance
Agent (OVPA) via data source integration (DSI)
config Generate a report showing configuration history
COMMANDS
This section describes the syntax of each command. Note that option
arguments are introduced by two dash characters (--), not a single dash
character (-).
The options are described in the next section. They are the same on
both HP-UX and Microsoft Windows.
extract [--workload=workload] [...]
[--help]
[--policy=policy]
[--startdate=YYYY/mm/dd]
[--enddate=YYYY/mm/dd]
[--duration=n{ days | weeks | months }]
[--inputpath=path]
[--outputpath=path]
[--dataversion=version]
[--columnhelp]
[--datestamps]
[--columns=colname1[,colname2,...]]
resourceaudit [--workload=workload] [...]
[--help]
[--policy=policy]
[--startdate=YYYY/mm/dd]
[--enddate=YYYY/mm/dd]
[--duration=n{ days | weeks | months }]
[--inputpath=path]
[--outputpath=path]
topborrowers [--workload=workload] [...]
[--help]
[--policy=policy]
[--startdate=YYYY/mm/dd]
[--enddate=YYYY/mm/dd]
[--duration=n{ days | weeks | months }]
[--inputpath=path]
[--outputpath=path]
abnormalutil [--workload=workload] [...]
[--help]
[--policy=policy]
[--startdate=YYYY/mm/dd]
[--enddate=YYYY/mm/dd]
[--duration=n{ days | weeks | months }]
[--inputpath=path]
[--outputpath=path]
[--targetdate=YYYY/mm/dd[:hh]]
ovpafeed [--workload=workload] [...]
[--help]
[--policy=policy]
[--startdate=YYYY/mm/dd]
[--enddate=YYYY/mm/dd]
[--duration=n{ days | weeks | months }]
[--inputpath=path]
[--outputpath=path]
[--dataversion=version]
[--setup]
config [--help]
[--dates]
[--targetdate=YYYY/mm/dd[:hh:mm:ss[.SSS]]]
[[--diff] --startdate=YYYY/mm/dd[:hh:mm:ss[.SSS]]
--enddate=YYYY/mm/dd[:hh:mm:ss[.SSS]]]
[--outputpath=path]
OPTIONS
The gwlmreport commands recognize the following options:
--workload=workload
Generate a report for workload. To create reports for:
+ Multiple (but not all) workloads:
Repeat --workload=workload with different values for workload
+ All workloads: Do not specify --workload
The absence of the option indicates gwlmreport should get data
for all workloads. (Be aware that collecting data for a single
workload can take up to two minutes. So, collecting data for all
the workloads can take a significant amount of time for large
configurations.)
You cannot omit --workload and use --inputpath.
--help
Print usage and exit.
--policy=policy
Filter data to show only those periods when policy was in effect.
If you do not specify --policy, there is no filtering.
--startdate=date
Base the report on data starting from date. Specify date in
YYYY/mm/dd format, such as 2004/06/09 for June 9th, 2004. (With
the config command, you can also specify the ":hh:mm:ss[.SSS]"
component. SSS represents milliseconds.)
If you do not specify --startdate, gWLM sets date to one calendar
month before today. (However, if you specify --enddate, you must
explicitly set --startdate.)
When you specify --startdate but not --enddate, you get data for
the one month period following date.
When running gwlmreport config --diff, you must specify both
--startdate and --enddate.
When running gwlmreport ovpafeed multiple times, be sure not to
use overlapping --startdate and --enddate arguments.
--enddate=date
Base the report on data ending date. Specify date in YYYY/mm/dd
format, such as 2004/06/09 for June 9th, 2004. (With the config
command, you can also specify the ":hh:mm:ss[.SSS]" component. SSS
represents milliseconds.)
You cannot specify --enddate with --duration.
The default end date is the current date. (However, if you specify
--startdate, the default end date is one month after the date
given with --startdate.)
When running gwlmreport config --diff, you must specify both
--startdate and --enddate.
When running gwlmreport ovpafeed multiple times, be sure not to
use overlapping --startdate and --enddate arguments.
--duration=n{ days | weeks | months }
Run the report with data from
date
to
date + n{ days | weeks | months }
where date is the value you specified in --startdate=date.
If you specify --duration, you must also specify --startdate. You
cannot specify --duration with --enddate.
The input format is n{ days | weeks | months }. Examples of valid
choices are: 5weeks, 2months.
If you do not specify --duration, gWLM uses a duration of one
month.
--inputpath=path
Specify the path for the CSV data being used to generate the
report.
You must specify --workload when you specify --inputpath.
There are three valid choices for path:
+ A single dash "-" to read all CSV data from stdin
+ An absolute path to a single file containing CSV data for all
workloads specified with the --workload option
+ A directory containing a group of CSV files, one per workload
For example, if the workloads specified are wl1 and wl2 and the
input path is /tmp, gwlmreport will attempt to read the CSV info
for workload wl1 from file /tmp/wl1.csv and the CSV info for
workload wl2 from file /tmp/wl2.csv.
--outputpath=path
Specify the path for the report output. The default path is to
send report output to stdout.
There are three valid choices for path:
+ A single dash "-" to write all report output to stdout
+ An absolute path to a single file to which all report data is to
be written
If a single file is specified and that file already exists, the
file is overwritten.
+ A directory
If a directory is specified, each report is placed in a file
named after its workload (unless you are using the topborrowers
command). The filenames change based on the report type. For
example, the following commands result in the indicated files:
gwlmreport resourceaudit \
--workload wkldA \
--workload wkldB \
--outputpath=/tmp/
Files: /tmp/wkldA.resaud, /tmp/wkldB.resaud
gwlmreport extract \
--workload wkldA \
--workload wkldB \
--outputpath=/tmp/
Files: /tmp/wkldA.csv, /tmp/wkldB.csv
gwlmreport abnormalutil \
--workload wkldA \
--workload wkldB \
--outputpath=/tmp/
Files: /tmp/wkldA.abutil, /tmp/wkldB.abutil
gwlmreport topborrowers \
--workload wkldA \
--workload wkldB \
--outputpath=/tmp/
File: /tmp/allworkloads.topbor
gwlmreport config --outputpath=/tmp/
File: /tmp/config.YYYY-mm-dd:hh:mm:ss
NOTE: Using --outputpath with ovpafeed directs data to the given
path instead of to the logfileset.
--dataversion=version
Specify the version of data to use for the intermediate
file. Valid choices are: 1.0, 2.0, 3.0, and 4.0. (This ver‐
sion is independent of the version of the gWLM product.)
If you do not specify --dataversion, gWLM sets version to
4.0.
You can convert from one data version to another by reading
a database or CVS source that is one version, say 2.0, and
specifying the --dataversion option with the other version
(for example, 4.0). New fields (when going from 3.0 to 4.0)
are filled as best as possible, while missing fields (going
from 4.0 to 3.0) are dropped.
When using ovpafeed, you can change the version as desired
because each version's data goes into a separate logfile‐
set, maintaining different sets of OpenView Performance
Agent metrics as provided by the given version.
--columnhelp
List the names for the all the columns of data in the
extract output. Use the names shown when you use the --col‐
umns option to limit the number of columns displayed.
The list of column names changes based on the --dataversion
value.
--datestamps
Convert timestamps to human-readable datestamps.
NOTE: If you use --datestamps and save the output to a file
(using --outputpath), that file cannot be used later as
input with the --inputpath option.
--columns=colname1[,colname2,...]]
Extract data only for the specified columns. (Separate col‐
umn names using only commas; do not use spaces.) To display
a list of column names, use the --columnhelp option. (The
columns available change based on the --dataversion value.)
NOTE: If you use --columns and save the output to a file
(using --outputpath), that file cannot be used later as
input with the --inputpath option.
--targetdate=YYYY/mm/dd[:hh:mm:ss[.SSS]]
Focus the report on the specified date.
The ":mm:ss[.SSS]" component is allowed only with the con‐
fig command. (SSS represents milliseconds.)
--setup
Sets up the DSI logfileset needed for feeding data to Open‐
View Performance Agent. Data is placed in logfilesets in
/var/opt/dsi/version/gwlm*.
NOTE: The ovpafeed command is available only on HP-UX sys‐
tems with the HPUX11i-OE-Ent.MeasureWare.PERFDSI fileset or
its equivalent installed. (One equivalent is the
B3701AA.MeasureWare.PERFDSI fileset, which is installed
when you install HP GlancePlus/UX Pak, version C.03.85.00
or later.) You must be root to use the command.
NOTE: Running gwlmreport ovpafeed --setup modifies your
/var/opt/perf/perflbd.rc file. Restart perflbd to see new
feed in the OpenView tools. For more information, search
for "mwa restart server" in the mwa(1) manpage.
You must run gwlmreport ovpafeed --setup before using any
other gwlmreport ovpafeed commands.
--dates
Display the dates when there were configurations saved.
--diff --startdate=date --enddate=date
Display any changes in configurations saved between
--startdate=date and --enddate=date.
EXAMPLES
Example 1
Produce a resource audit report for myworkloadA for the calendar month
prior to the current date (time at which gwlmreport is run). The work‐
load data is read from the gWLM database.
gwlmreport resourceaudit \
--workload=myworkloadA
Example 2
Produce a resource audit report for workloads myworkloadA, myworkloadB,
and myworkloadC for the three calendar months starting Sep 01, 2004.
The workload data is read from the gWLM database.
gwlmreport resourceaudit \
--workload=myworkloadA \
--workload=myworkloadB \
--workload=myworkloadC \
--startdate=2004/09/01 \
--duration=3months
Example 3
Produce a topborrowers report for workloads myworkloadA, myworkloadB
and myworkloadC for the calendar month starting Sep 01, 2004. The work‐
load data is read from the gWLM database.
gwlmreport topborrowers \
--workload=myworkloadA \
--workload=myworkloadB \
--workload=myworkloadC \
--startdate=2004/09/01 \
--duration=1month
Example 4
Walk through the CSV file /tmp/previously_extracted_data.csv and pro‐
duce a resource audit report for workload myworkloadA under the policy
myOwnBorrowPol for the three calendar months starting Sep 01, 2004.
Print it to stdout.
gwlmreport resourceaudit \
--workload=myworkloadA \
--policy=myOwnBorrowPol \
--startdate=2004/09/01 \
--duration=3months \
--inputpath=/tmp/previously_extracted_data.csv
Example 5
Extract the data for myworkloadA, for the three calendar months start‐
ing Sep 01, 2004. Print it to stdout. The workload data is read from
the gWLM database.
gwlmreport extract \
--workload=myworkloadA \
--startdate=2004/09/01 \
--duration=3months
Example 6
Extract the data for myworkloadA (formatting it as CSV data), for the
three calendar months starting Sep 01, 2004. The CSV data is stored in
a file called /tmp/mydata.csv. The workload data is read from the gWLM
database.
gwlmreport extract \
--workload=myworkloadA \
--startdate=2004/09/01 \
--duration=3months \
--outputpath=/tmp/mydata.csv
Example 7
Extract the data for myworkloadA and myworkloadB (formatting it as CSV
data), for the three calendar months starting Sep 01, 2004. Because the
--outputpath option points to a directory, the CSV data for myworkloadA
is stored in a file called /tmp/myworkloadA.csv, and the CSV data for
myworkloadB is stored in /tmp/myworkloadB.csv. The workload data is
read from the gWLM database.
gwlmreport extract \
--workload=myworkloadA \
--workload=myworkloadB \
--startdate=2004/09/01 \
--duration=3months \
--outputpath=/tmp/
Example 8
Read the data for myworkloadA and myworkloadB from /tmp/myworkloadA.csv
and /tmp/myworkloadB.csv for the three calendar months starting Sep 01,
2004, and use it to produce an audit report for each workload.
gwlmreport resourceaudit \
--workload=myworkloadA \
--workload=myworkloadB \
--startdate=2004/09/01 \
--duration=3months \
--inputpath=/tmp/
Example 9
Compare recent CPU utilization of a poorly performing workload against
its utilization when it was performing as desired. Say the poor perfor‐
mance is noticed on 2005/10/21 around 10am. To compare that utilization
to the utilization in periods related to that time, run a report as
follows:
gwlmreport abnormalutil \
--workload=myworkloadA \
--startdate=2005/10/01 \
--enddate=2005/10/30 \
--targetdate=2005/10/21:10
The resulting report would show all the historical samples for workload
utilization for several time periods:
+ The whole period (10/01 through 10/30)
+ All the Friday 10-10:59 am time periods (10/21 is a Friday)
+ The week (7 calendar days) prior to 10/21
+ The hour prior to 10:21:10
+ The sample immediately before 10:21:10
Comparing the data during the target period with these other periods,
you can see if the allocation and utilization are normal for a Friday
10am slot, and for a given week or month. If the allocation seems nor‐
mal but the utilization is high, perhaps there is extra demand or an
application problem. If the allocation seems too low compared to the
other time periods of interest, perhaps the workload is not getting
enough resources and a policy adjustment is needed.
You might then rerun the report with the same start and end dates, but
different targetdates, say 2005/10/21:11 and 2005/10/21:12, to compare
the original 10am report with an 11am and a noon-based report. These
variations quickly give a feel for the behavior of the application.
Example 10
Show the configuration changes made in September of 2006:
gwlmreport config --diff --startdate=2006/09/01 --enddate=2006/09/30
Example 11
Extract data for viewing with OpenView by running the following com‐
mands:
1. Set up the DSI logfileset:
gwlmreport ovpafeed --setup --dataversion=3.0
NOTE: This command fails if the DSI-related OV tools are not present
or you are not running on HP-UX.
This step adds a line to the /var/opt/perf/perflbd.rc file.
2. Restart the mwa servers
You must restart the mwa servers so that perflbd and other OV tools
can see the new data stream. The restart command is:
mwa restart server
3. Extract the data:
gwlmreport ovpafeed \
--workload=myworkloadA \
--startdate=2005/10/01 \
--enddate=2005/10/30 \
--dataversion=3.0
This step shows the data being used from the gWLM database. You can
use --inputpath to use CSV files as input instead.
Data is placed in a logfileset in /var/opt/dsi/version/gwlm* on the
CMS by default. These files grow with each run of gwlmreport
ovpafeed. Starting with gWLM A.02.00.00.07, the logfileset is set
up to hold enough historical samples to accommodate 90 days of data
for 20 workloads with 5-minute historical samples before the log‐
fileset 'rolls' and starts overwriting older data. This rolling lim‐
its the maximum disk space that will be consumed by
/var/opt/gwlm/dsi.
You can see the raw data that is being reported to OVPA by specify‐
ing a --outputpath to stdout or a file and then viewing the con‐
tents. However, when you use --outputpath, data is sent to the file
or stdout instead of being sent via DSI to OVPA.
4. Access the data using OpenView tools:
Available tools include:
+ /opt/perf/bin/extract
+ OpenView Performance Manager (OVPM) and other OpenView reporting
tools
For example, to see the data just added via the command line, run
the command:
/opt/perf/bin/extract -xp -C workloads DETAIL \
-l /var/opt/gwlm/dsi/version/gwlm \
-b 10/01/05 -e 10/30/05
Alternatively, you can view the data graphically using OVPM on the
CMS. When creating a new report in OVPM, the Metric Selection screen
will have an entry named GWLM_3_0:WORKLOADS. Select that entry to
see the possible gWLM metrics (including compCpuAlloc, compCpuUtil,
and polCpuRequest). Select the metrics of interest. Add a filter for
wlName == myworkloadA. Name and save the new report. Then display it
for the time period 2005/10/01 to 2005/10/30.
5. Repeat step 3 and step 4 for other workloads and/or time periods of
interest.
To automate use of gwlmreport ovpafeed, you can feed gWLM workload data
to OVPA regularly. For example, you could use a snippet similar to the
one below executed by cron to feed data to OVPA daily:
YESTERDAY=`TZ=GMT+24 date +%Y/%m/%d`
/opt/gwlm/bin/gwlmreport ovpafeed \
--startdate $YESTERDAY \
--enddate $YESTERDAY
Using yesterday for both the start and end dates gives all data from
yesterday.
Example 12
Set up an automatic report using a cron entry to run a resource audit
report on the first of each month for workload myworkloadB's resource
use during the previous month:
0 00 * 1 * /opt/gwlm/bin/gwlmreport resourceaudit \
--workload=myworkloadB | /usr/bin/mail the_admin@mycompany.com 2>&1
REPORT OUTPUT DESCRIPTIONSgwlmreport produces the following types of reports, depending on the
command you specify:
resourceaudit resource audit report
topborrowers top borrowers report
extract CSV report
abnormalutil abnormal utilization report
ovpafeed Data for use with OpenView Performance Agent via
data source integration (DSI)
config configuration history report
The sections below describe the contents of these reports. (Search for
"Report:" to find the start of each section.)
Report: resource audit
The resource audit report has the following sections:
+ Report information
+ Workload context information
+ Samples info
+ Utilization info
+ Footnotes
Report information
This section presents configuration data that is (usually) constant
over the report duration. If any of these items change during the
report duration, a footnote (see section below) is appended to the
report and the *most recent value* is displayed in the report.
ReportDate
The date and time when the report was generated.
Workload
The name of the workload.
TotalSamples
The total number of samples received from the data source
(either the gWLM database or the CSV input) that fall within the
report date range for the given workload. This is identical to
the Total value in the "Samples info" section. Samples during
times when the workload was in advisory mode are not counted.
TotalSamples may be less than PossibleSamples if gWLM was not on
for the whole period.
A footnote is produced if this value differs from PossibleSam‐
ples by more than 10%.
AvgSampleDuration
Length of sample in minutes.
ReportDateRange
Calendar dates covered by report.
PossibleSamples
Calculated maximum number of samples that are possible in
ReportDateRange. Basically ReportDateRange divided by AvgSam‐
pleDuration.
SeenDataRange
The date of the first sample from the gWLM database or the CSV
file used as input to the date of the last sample.
Workload context information
This section presents configuration data that is (usually) constant
over the report duration. If any of these items change during the
report duration, a footnote (see section below) is appended to the
report and the *most recent value* is displayed in the report.
SRDName
Name of workload's shared resource domain. If the name changed
over the report time, the most recent shared resource domain's
info is displayed and a footnote is produced.
SRDMode
Tells whether the workload's SRD was in managed mode or advisory
mode.
PolicyName
Name of workload's policy. If this has changed over the report
time, the most recent policy's info is displayed.
PolicyType
Fixed, OwnBorrow, Utilization, or Custom.
PolicySettings
For Fixed policies: target
For OwnBorrow policies: min/owned/max
For Utilization policies: min/max
For Custom policies: min/max
CompartmentName
Name of workload's compartment. If the name changed over the
report time, the most recent compartment's info is displayed and
a footnote is produced. Some compartments have no name, so this
field may be empty.
CompartmentType
hpvm, npar, vpar, fss, or pset.
CompartmentHost
Hostname of the workload's compartment.
Samples info
OwnedOnly
Percentage and count of samples where Owned is within 95% to
105% of Size.
Custom policies and Utilization policies treat their Min Size
values as their Owned values. Because gWLM always honors Min
Size values, these types of policies always honor their Owned
values, never going below them (that is, never lending CPU
resources). So, workloads with either of these policy types will
only own or borrow.
Workloads with Fixed policies will have all their samples at‐
tributed to OwnedOnly.
Borrowing
Percentage and count of samples borrowing (that is, samples
where Size > '105% of Owned')
Lending
Percentage and count of samples where the user lent resources
(that is, samples where Size < '95% of Owned').
Total (same as TotalSamples)
The total number of samples received from the data source
(either the gWLM database or the CSV input) that fall within the
report date range for the given workload.
For any sample, the workload must be in exactly one of three
states: OwnedOnly, Borrowing, or Lending. Total is the sum of
the number of samples for the workload in each of the three
states. Consequently, Total is equal to the TotalSamples metric
described above. (The Total count excludes times when the work‐
load was in advisory mode.)
The following metrics are not included in Total:
+ Able2Lend
+ Want2Borrow
+ CompClipped
+ PolClipped
+ PriClipped
Able2Lend and Want2Borrow can both describe a sample where the
workload is in the OwnedOnly state. The remaining metrics indi‐
cate forms of clipping, most likely describing a sample where
the workload is in the Borrowing state. To avoid double-count‐
ing, these metrics are not included in the Total metric.
Able2Lend
Percentage and count of samples where request was less than 95%
of Owned. This metric is not included the Total or TotalSamples
metrics.
Want2Borrow
Percentage and count of samples where request was more than 105%
of Owned. This metric is not included the Total or TotalSamples
metrics.
CompClipped
Compartment Clipped - percentage and count of samples where the
workload could not borrow or acquire as much as it wanted
because it is already allocated the compartment maximum. If this
condition persists, there may be different remedies based on
compartment type. For workloads based on virtual machines,
psets, or fss groups, the remedies are: buy a bigger server,
move the workload to a server with more room, or move some other
workload off the server. For workloads based on vpars, the same
remedies apply but you can also fix the problem by reducing the
number of bound CPUs (cores) on the virtual partitions. For
workloads based on npars, the remedies for workloads based on
psets or fss groups apply; additional Instant Capacity resources
can help as well.
PolClipped
Policy Clipped - occurs when the workload is allocated the maxi‐
mum CPU resource per its policy, but its utilization is above
the target, and thus cannot request any more. If this condition
persists, a potential remedy is to increase the policy maximum.
PriClipped
Priority Clipped - occurs when all the workloads' compartments
at higher priority levels or at the same priority level are
allocated their requested resources, not leaving enough
resources for the compartments remaining at the same or lower
priority levels. The remedy is to raise the priority, or, if
using OwnBorrow policies, edit the policy (or associate a new
policy) to give associated workloads a larger owned amount of
CPU resources.
Utilization section
AvgUtil
The average utilization of the workload during the reporting
duration.
MaxUtil
The maximum utilization of the workload during the reporting
duration. A date is displayed showing when the maximum occurred.
TradeBalance
Compute grade based on how often (and how much) the workload
lends or borrows. A running total is kept while samples are
read: For each sample that is lending, the total lent amount is
subtracted from the running total. For each sample that is bor‐
rowing, a total lent amount is added to the running total. The
end TradeBalance is the running total divided by the total sam‐
ple count, so a net negative amount means a net lender, while a
net positive amount means a net borrower. The magnitude is the
average amount lent or borrowed.
AvgUtilWhileLending
The average utilization during samples when this workload is
lending.
MaxUtilWhileLending
The maximum utilization encountered during a sample when this
workload is lending. If this is nonzero, a date is displayed
showing when this maximum occurred. Too large a value may indi‐
cate that this workload is being unfairly penalized.
AvgReq Average CPU allocation request for the workload by its policy.
AvgAlloc
Average CPU allocation gWLM gave to the workload.
AvgCons
Average CPU consumption in terms of cores.
CpuMinutesAlloc
CPU minutes allocated to the workload. For each sample in the
report period, the length of the sample in minutes is multipled
by the AvgAlloc (average allocation) value for that sample.
CpuMinutesAlloc is the sum of the results for all the samples.
CpuMinutesCons
CPU minutes consumed by the workload. For each sample in the
report period, the length of the sample in minutes is multipled
by the AvgCons (average consumption) value for that sample.
CpuMinutesCons is the sum of the results for all the samples.
Footnotes
Along with metrics in the detailed reports, a set of footnotes is
printed to show warnings or alerts for particular reports. These are to
alert you that there was some kind of exceptional event during the
report durations that could affect the data.
Note that the data samples during the exceptional conditions are still
included in the reports (as best the tools can manage).
For each type of condition shown below, one footnote is printed per
workload per report showing the type, the date it first occurred, and
the total number of times it occurred.
Advisory mode
This workload's SRD was in advisory mode, not managed mode, dur‐
ing one or more samples. This can mean that the allocations do
not track the requests because gWLM is advising only, not making
changes. The samples in advisory mode are not used to compute
state counts and other metrics.
Time gap
This workload's history does not extend through the entire
reporting period, or there are gaps in the sample stream of at
least one hour.
Compartment change
There was one or more significant compartment changes during the
report period. This could be changes to name, id, type, and so
on.
Policy change
There was one or more significant policy changes during the
report period. This could be changes to name, id, type, and so
on.
Overlapping samples
The timestamps for two or more samples show they overlap in
time, or are out of order. gwlmreport expects non-overlapping
samples in order by time-of-century.
Sample size changed
During the report period, the sample size changed by at least
10%. Because all samples are counted equally, this sort of
change will skew the results toward the data for the shorter
samples. (This size is set in minutes using the property
com.hp.gwlm.node.samples in the file /etc/opt/gwlm/conf/gwlm‐
cms.properties on HP-UX or in the file C:\Program Files\HP\Vir‐
tual Server Environment\conf\gwlmcms.properties on Windows. This
is the default path on Windows; however, a different path may
have been selected at installation.)
Report: top borrowers
The top borrowers report is a table view of workloads sorted by Trade‐
Balance. All the metrics and footnotes are identical to the Resource
Audit metrics, so see the section above for the metric definitions.
Report: extract (CSV)
The extract report extracts raw historical data from the gWLM database,
formats it as comma-separated values, and prints it to a specified file
or stdout.
To help consumers of the data, the first line of an extract report is a
Schema Version line, which gives the gWLM schema and extract-file for‐
mat versions. As there can be changes in one or both of these in any
gWLM release, all consumers should check the version numbers and con‐
firm they understand the data to follow.
The second line in the extract report is a comma-separated list of col‐
umn headers. These are the names of columns. The number and order of
the columns is fixed for a given extract version number. For informa‐
tion on the order of the columns, see the section "CSV Column Header
Lines" below.
The remaining lines in an extract report are lines of metrics in CSV
format.
Consumers of the CSV data should ignore any lines:
+ Starting with a # sign, as these are comments
+ Consisting only of whitespace
While neither of these types of lines is generated in the v3.0 extract
report, they may be added in future versions.
CSV File and Schema Version Lines
Here is the format of the CSV File and Schema Version line from the
gWLM A.04.10.xx version of gwlmreport:
schemaVersion=gWLM4.1 extractFormatVersion=4.0
The schemaVersion specifies the version of the gWLM schema used to pro‐
duce the data. The extractFormatVersion specifies the version of the
extract tool used to extract the data. For example, running the fol‐
lowing command
gwlmreport extract --dataversion=1.0
against a gWLM 4.0 database would result in a CSV file with a
"schemaVersion=gWLM4.0 extractFormatVersion=1.0" header. This header
shows that the data is from a 4.0 source (DB or CSV file) and is in 1.0
extract form. (Being in 1.0 extract form, the list and order of columns
would match what a 1.0-based extract would have returned.)
At least one version line must be read before column headers or metric
data lines are read so the tools know what names and how many metrics
to expect. If a column header line or metric data line is encountered
before a valid version line, gwlmreport exits with an error to stderr.
If you have concatenated several CSV files, you may have duplicate ver‐
sion lines. Only the first version line is used (later version lines
are ignored).
CSV Column Header Lines
The format of the CSV Column header line from gwlmreport with dataver‐
sion=4.0:
sampleStart, sampleEnd, srdName, srdId, srdMode, srdTicapMode,
compName, compId, compType, compHost, compCpuMin, compCpuMax,
compCpuSize, compCpuAlloc, compCpuUtil, wlName, wlId, polName,
polId, polType, polCpuMin, polCpuMax, polCpuRate, polCpuWeight,
polCpuTarget, polCpuRequest, polCpuReading, polCpuOwned, polTi‐
capEnabled, polActiveId, polActiveType
The 4.0 format includes all the 3.0 headers plus polActiveType.
The format of the CSV Column header line from gwlmreport with dataver‐
sion=3.0:
sampleStart, sampleEnd, srdName, srdId, srdMode, srdTicapMode,
compName, compId, compType, compHost, compCpuMin, compCpuMax,
compCpuSize, compCpuAlloc, compCpuUtil, wlName, wlId, polName,
polId, polType, polCpuMin, polCpuMax, polCpuRate, polCpuWeight,
polCpuTarget, polCpuRequest, polCpuReading, polCpuOwned, polTi‐
capEnabled, polActiveId
The 3.0 format includes all the 2.0 headers plus polTicapEnabled and
polActiveId.
The format of the CSV Column header line from gwlmreport with dataver‐
sion=2.0:
sampleStart, sampleEnd, srdName, srdId, srdMode, srdTicapMode,
compName, compId, compType, compHost, compCpuMin, compCpuMax,
compCpuSize, compCpuAlloc, compCpuUtil, wlName, wlId, polName,
polId, polType, polCpuMin, polCpuMax, polCpuRate, polCpuWeight,
polCpuTarget, polCpuRequest, polCpuReading, polCpuOwned
The 2.0 format includes all the 1.0 headers plus srdTicapMode and pol‐
CpuOwned.
Here is the format of the CSV Column header line from gwlmreport with
dataversion=1.0:
sampleStart, sampleEnd, srdName, srdId, srdMode, compName, com‐
pId, compType, compHost, compCpuMin, compCpuMax, compCpuSize,
compCpuAlloc, compCpuUtil, wlName, wlId, polName, polId,
polType, polCpuMin, polCpuMax, polCpuRate, polCpuWeight, pol‐
CpuTarget, polCpuRequest, polCpuReading
All the column headers are described below.
sampleStart
Indicates the start time (in milliseconds since Jan 1, 1970) for
the sample.
sampleEnd
Indicates the end time (in milliseconds since Jan 1, 1970) for
the sample.
srdName
Corresponds to SRDName, which is described above in the "Work‐
load context information" section.
srdId Is an ID for the SRD.
srdMode
Corresponds to SRDMode, which is described above in the "Work‐
load context information" section.
srdTicapMode
Indicates whether the SRD was configured to use Temporary
Instant Capacity (TiCAP). Possible entries in this column are:
none
Default setting--or the system does not support Temporary
Instant Capacity.
off
Temporary Instant Capacity is supported on the system but is
not being used to satisfy policy requests.
all
Temporary Instant Capacity is supported on the system and can
be used to satisfy policy requests.
compName
Corresponds to CompartmentName, which is described above in the
"Workload context information" section.
compId Is an ID for the compartment.
compType
Corresponds to CompartmentType, which is described above in the
"Workload context information" section.
compHost
Corresponds to CompartmentHost, which is described above in the
"Workload context information" section.
compCpuMin
Is the minimum amount of CPU resources that a compartment can
have. This value is the minimum resource allocation required by
the underlying compartment.
compCpuMax
Is the maximum amount of CPU resources that a compartment can
have. This value is the maximum resource allocation allowed by
the underlying compartment. However, gWLM may reduce this number
at times because an SRD has a large number of compartments and
each compartment must receive a minimum portion of the
resources.
compCpuSize
Is the amount of CPU resources a compartment actually has. Size
may differ from the allocation when gWLM is deployed in advisory
mode.
compCpuAlloc
Is the amount of CPU resources that gWLM sets aside for a com‐
partment after arbitrating resource requests from the policies
for all the compartments.
compCpuUtil
Is the percentage resulting from dividing a workload's CPU con‐
sumption by its CPU allocation.
wlName Corresponds to Workload, which is described above in the "Work‐
load context information" section.
wlId Is an ID for the workload.
polName
Corresponds to PolicyName, which is described above in the
"Workload context information" section.
polId Is an ID for the policy.
polType
Corresponds to PolicyType, which is described above in the
"Workload context information" section.
polCpuMin
Is the minimum amount of CPU resources that a policy will
request for any workload with which it is associated.
polCpuMax
Is the maximum amount of CPU resources that a policy will
request for any workload with which it is associated.
polCpuRate
Is the convergence rate for the policy.
The default rate is 1.0. Larger values produce larger changes in
the allocation, resulting in a faster convergence on the pol‐
icy's target. Similarly, smaller values slow down convergence
on the target.
polCpuWeight
Is the CPU weight for the policy. gWLM distributes CPU resources
in proportion to weights when there are not enough resources to
satisfy all requests at a given priority. gWLM also distributes
CPU resources in proportion to weights if there are resources
remaining once all requests at all priorities have been satis‐
fied.
polCpuTarget
Is the target value that drives a policy, influencing its
resource requests to gWLM.
For example, with utilization and OwnBorrow policies, the pol‐
CpuTarget is target CPU utilization. With a target CPU utiliza‐
tion, gWLM attempts to keep a workload's CPU utilization below
the target by adding CPU resources when the workload is using
too much of its current CPU allocation.
With a custom policy, polCpuTarget can be either a value to stay
below or to exceed. (You provide this value to gWLM using the
gwlmsend command). For example, response time would be a value
to stay below. Adding CPU resources should help the workload
stay below a certain response time. As an example of a value to
exceed, polCpuTarget could be x transactions per second. Adding
resources in this case helps the workload maintain or even
exceed the number of transactions.
polCpuRequest
Is the amount of CPU resources that a policy asks gWLM to give
to the policy's workloads.
polCpuReading
+ Utilization policies / OwnBorrow policies:
Is utilization.
+ Fixed policies:
Is the amount of CPU resources allocated to the compartment of
any associated workload.
+ Custom policies:
Is the value of the metric you update using the gwlmsend com‐
mand.
polCpuOwned
Is the number of CPUs (cores) owned by the policy.
polTicapEnabled
Indicates whether the policy was configured to use Temporary
Instant Capacity (TiCAP). If a policy is enabled to use TiCAP,
it can do so regardless of whether TiCAP use is enabled on the
SRD level, which is indicated in the srdTicapMode column.
Possible entries in this column are:
true
The policy is enabled to use TiCAP, if available, to satisfy
policy requests.
false
Default setting--the policy is not allowed to use TiCAP.
polActiveId
Is an ID for the effective policy. This value matches the polId
value unless a conditional policy is being used, in which case
the value identifies the policy in effect as a result of a con‐
dition being met.
polActiveType
Indicates the type (Fixed, OwnBorrow, Utilization, or Custom)
for the effective policy. This value matches the polType value
unless a conditional policy is being used, in which case the
value identifies the type of policy in effect as a result of a
condition being met.
Whitespace (tabs, spaces) within a line is ignored.
At least one column header line must be read before metric data lines
are read. If a metric data line is encountered before a valid column
header line, gwlmreport exits with an error to stderr.
If you have concatenated several CSV files, you may have duplicate
header lines. Only the first header line is used (later header lines
are ignored).
CSV Metric lines
After getting a version line and a column header line, the rest of the
file should be comma-delimited metrics. The number of metrics must
match the column headers and extract file version type. If they do not,
the data is discarded and gwlmreport exits with an error.
Here is an example line from gwlmreport with dataversion=3.0:
1194378195009, 1194378495019, MySystem.srd, 1, Managed, none,
default, 1, hpvm, MySystem.hp.com, 0.03, 3.0, 1.02, 1.02,
0.0029, MySystem.OTHER, 1, CPU_Utilization, 5, Utilization, 0.0,
2048.0, 1.0, 1.0, 75.0, 0.0115, 0.2888, 0.0, false, 5
Whitespace (tabs, spaces) within a line is ignored.
Report: abnormal utilization
The abnormal utilization report has the following sections:
+ Report information
+ Workload context information
+ Samples and Utilization by period
+ Period daterange and timeslot info
+ Footnotes
Reports are generated for each workload specified or for all possible
workloads if none are specified. The components of each section are
described below.
Report information
This section gives information about the report itself.
ReportDate
The date and time when the report was generated.
Workload
The name of the workload.
ReportDateRange
Calendar dates covered by report.
PossibleSamples
The total number of samples that is possible during the Report‐
DateRange. (This number is the sample length divided into the
ReportDateRange.)
SeenDataRange
The date of the first sample from the gWLM database or the CSV
file used as input to the date of the last sample.
TargetDate
Date the report is focused upon. This date was specified when
the report was requested. (If no date was specified, this value
matches the enddate value.)
Workload context information
Provides contextual information for the workload, such as its SRD, pol‐
icy, and compartment.
The workload context information generated with the abnormalutil report
matches the information produced with the resource audit report. For
descriptions of this information, refer to the "Workload context infor‐
mation" section in the "Report: resource audit" section.
Samples and utilization by period
This section shows CPU utilization over time, showing the "normal" uti‐
lization for a workload. If a workload misbehaves for a certain period,
you can compare its utilization during that period against the data
shown in this section to help determine what has changed. The section
provides the following metrics:
AvgUtil
Average CPU utilization.
AvgReq Average CPU allocation request for the workload by its policy.
AvgAlloc
Average CPU allocation gWLM gave to the workload.
AvgCons
Average CPU consumption in terms of cores.
ActSamp
The actual number of samples seen in a given time period (column
heading in the report) from the current data source.
PossSamp
The number of possible samples for a given time period (column
heading in the report).
AvgSampDur
Average duration of each sample.
PolMin The policy's minimum core value.
PolOwn The policy's owned core value.
PolMax The policy's maximum core value.
Period daterange and timeslot info
This section indicates dates and times for the samples. It gives a more
full explanation of the column headings from the table in the "Samples
and Utilization by period" section.
Previous Sample
Dates/times for the sample immediately before the TargetDate.
Previous Hour
The hour previous to the TargetDate.
DesiredDateRange
Shows the date/time for the previous hour.
ActualDateRange
Shows the date/time actually used. This value matches
DesiredDateRange if the workload existed for the entire
period. Otherwise, "null" indicates that samples were not
available at the beginning and/or end of the time period.
Samples
Indicates the number of samples collected from the given
time period.
Previous 24 Hours
The 24 hours previous to the TargetDate.
DesiredDateRange, ActualDateRange, and Samples are as described
for "Previous Hour" above.
Weekly Timeslot
The one hour matching the hour used with TargetDate, but from
the week before the TargetDate.
Samples indicates the number of samples collected from the given
time period.
All Samples
DesiredDateRange, ActualDateRange, and Samples are as described
for "Previous Hour" above.
So if --targetdate is 2005/07/14:12, then:
Previous Sample
is the sample immediately before 2005/07/14:12
Previous Hour
is the period 2005/07/14:11:00:00 to 2005/07/14:11:59:59
Previous 24 Hours
is 2005/07/13:12:00:00 to 2005/07/14:11:59:59
Weekly Timeslot
is any Monday from 12:00:00 to 12:59:59
All Samples
includes any samples that fell within ReportDateRange
Footnotes
Footnotes are printed to warn or alert you that there was some kind of
exceptional event during the report durations that could affect the
data.
The footnotes generated with the abnormalutil report match the foot‐
notes produced with the resource audit report. For descriptions of the
footnotes, refer to the Footnotes subsection of the "Report: resource
audit" section.
Report: ovpafeed
The gwlmreport ovpafeed command does not generate a text report;
rather, it produces data in a DSI logfileset in /var/opt/dsi/ver‐
sion/gwlm* for use by the OVPA subsystem.
The data is a subset of gWLM's historical data and the data presented
in gWLM's advanced reports. Making it available to OV tools is intended
as a service for customers that already use OVPA or OpenView Service
Reporter in their normal work. If you do not need to view gWLM data
with OVPA or OVSR, there is no need to run gwlmreport ovpafeed.
If you no longer need the data from the ovpafeed reports or you simply
want to erase all your DSI data and start over, you can delete the
/var/opt/gwlm/dsi/version/* directory. You must then run gwlmreport
ovpafeed --setup again before doing further ovpafeed reports.
For information on using the ovpafeed command, see Example 11 in the
EXAMPLES section above.
Report: config
The config report summarizes the current configuration. With --diff, it
summarizes configuration changes between the specified start and end
dates.
The report contents are self-explanatory.
ERRORS, WARNINGS, and FOOTNOTES
ERRORS
If gwlmreport is successful, it exits with a zero.
For any error, a message is printed to stderr and gwlmreport exits with
a nonzero value.
Errors include:
The --inputpath directory does not exist or is unreadable.
The --outputpath directory does not exist or is unwritable.
Cannot connect to gWLM database--gWLM is not running
If gWLM has difficulties retrieving historical data for a work‐
load, errors are logged to the gwlmcmsd log file and possibly to
the gwlmagent log file. For information on these log files, see
the gwlmcmsd(1M) manpage.
Unexpected line numbers in errors
When specifying --inputpath=path and multiple --workload=work‐
load arguments, gwlmreport combines the CSV files for all the
specified workloads into a single input stream. As a result,
any line numbers given in error messages are for the single
input stream--not the individual CSV files. For example, if you
have 3 files each of 1000 lines, an error might mention line
1711. This would actually be a problem around line 711 in the
CSV file for the second workload specified in your gwlmreport
command line.
WARNINGS
gwlmreport produces warnings to stderr of irregularities seen while
extracting the data and building any reports.
If no workloads match the target workload names, a warning is reported
that no samples were found for the given workloads. Similarly, if no
samples are found in the database or CSV input that match the specified
reporting time frame, policy name, or no Managed samples were found, a
warning is printed:
"No audit report possible for workload "mywkld" as it had zero
matching samples. There are several potential reasons for this:
there may be no workload by that name, no matching data for the
given dates, only samples that are Advisory or the wrong policy
name."
FOOTNOTES
For the resourceaudit, topborrowers, and abnormalutil reports, many
input data irregularities are detected and warnings produced via foot‐
notes in the report.
LIMITATIONS
You must be root on an HP-UX system or a member of the Administrators
group on a Windows system to run gwlmreport. Also, you must run gwlm‐
report on the gWLM central management server (the system where gwlmcmsd
is running.)
FEEDBACK
If you would like to comment on the current HP gWLM functionality or
make suggestions for future releases, please send email to:
gwlmfeedback@rsn.hp.com
gwlmreport(1M)