Migrating from WLM to gWLM

8
Migration example: FSS-based workloads with usage goals
WLM and gWLM both provide usage goals. However, in gWLM, the usage goal is known as a
utilization policy.
The WLM configuration
The example below splits an 8-core server into two FSS-based workload groups, each sized by CPU
utilization. Each group gets a minimum of one core and maximum of seven cores. Application records
place a few applications in the workload groups.
prm {
groups = app_dev_grp : 2,
db_dev_grp : 3;
# place a custom binary and perl script into app_dev_grp,
# shell script and oracle instance into g3
apps = app_dev_grp : /opt/perl/bin/perl "myperlscript.pl",
app_dev_grp : /opt/myapp/bin/myapp,
db_dev_grp : /bin/sh "myscript.sh",
db_dev_grp :
/oracle/u01/app/oracle/product/10.2.0/db_dev_1/bin/oracle "ora*MYINST*";
}
slo slo2 {
pri = 1;
goal = usage _CPU;
mincpu = 100;
maxcpu = 700;
entity = PRM group app_dev_grp;
}
slo slo3 {
pri = 1;
goal = usage _CPU;
mincpu = 100;
maxcpu = 700;
entity = PRM group db_dev_grp;
}
tune {
absolute_cpu_units=1; # 100 units is 100% of 1 CPU, not the whole server
}
Creating an equivalent gWLM configuration
To create an equivalent gWLM configuration, follow the steps below in HP Systems Insight Manager.
(For information on installing, configuring, and accessing VSE Management Software, such as
gWLM, in HP Systems Insight Manager, see the VSE Management Software Installation and Update
Guide, available from http://docs.hp.com/en/vse.html.)
In a WLM configuration, you can optionally specify the default user workload group OTHERS. In the
gWLM configuration though, the workload must be specified. It takes a name of the form
hostname.OTHER. The steps below reflect this requirement. Although gWLM provides a number of
policies you can use, the procedure below creates a new policy to match the behavior of the SLOs in
the WLM configuration. While the WLM configuration explicitly uses absolute CPU units, gWLM uses
such units by default.