gwlmplace(1M)gwlmplace(1M)NAMEgwlmplace - place a process in a gWLM workload
SYNOPSISgwlmplace [--help] [--recurse] --workload=workload --pid=PID [...]
AVAILABILITY
This command is available only on gWLM managed nodes (HP-UX systems
where you run gwlmagent) in /opt/gwlm/bin/ to users logged in as root.
DESCRIPTION
Use gwlmplace to place a process in a gWLM workload that is based on a
pset compartment or on an fss group compartment.
Use gwlmplace only when the process cannot be placed by a gWLM applica‐
tion record or user record. (You create these records in gWLM when cre‐
ating or editing workloads.)
Once gwlmplace has placed a process, application records, user records,
and process maps no longer affect that process.
For information on how process placement can be lost, see the LIMITA‐
TIONS section below.
OPTIONSgwlmplace recognizes the following options:
--help
Print usage and exit.
--recurse
Place the process with the specified PID and any of its descendant
processes. The default is to not recurse, just placing the single
specified process.
--workload=workload
Name the workload in which to place the process.
--pid=PID
Specify the PID for the process to place. You must specify a PID.
Specify multiple PIDs by preceding each PID with a --pid. All the
processes are moved to the same target workload that you specified
with the --workload option.
EXAMPLES
Example 1
Place process 1234 on myhost in workload myhost01. This overrides any
application records or user records in the deployed SRD configuration.
Note: This command must be run on the machine 'myhost'. Running from
another managed node produces an error.
gwlmplace --workload=myhost01 --pid=1234
Example 2
Place processes 1234, 3456, and 4567 on myhost in workload myhost01.
gwlmplace --workload=myhost01 --pid=1234 --pid=3456 --pid=4567
Example 3
Place the current shell's process in myhost03. This is useful in a
script to move the script itself to a workload. Because workload and
compartment membership is inherited by child processes, placing the
parent script process like this causes all subsequent child processes
to be run in that workload's compartment as well.
gwlmplace --workload=myhost03 --pid=$$
Example 4
Place process 234 and its descendant processes in workload myhost01.
(The descendants are all processes whose parent process ID in the
process hierarchy leads back to process 234. These processes could be
children, grandchildren, or later generations.)
gwlmplace--recurse --workload=myhost01 --pid=234
ERRORS
Exit codes
If gwlmplace exits with a:
Zero exit code
It was successful in its placements.
Nonzero exit code
It failed because the processes to be placed or the target work‐
load did not exist. gwlmplace reports an error in addition to
exiting with a nonzero code.
Failed placements when placing several processes
When requesting the placement of several processes (using multiple
--pid items or --recurse), the failure of just one placement results
in:
+ A nonzero exit code
+ An error indicating the PIDs of the processes that were not suc‐
cessfully placed
However, any placements that were possible were completed.
Attempted placements with workloads based on
virtual machines, vpars, or npars
If the workload compartment type is a virtual machine (hpvm), vpar, or
npar, gwlmplace cannot move the process to a different virtual machine,
vpar, or npar. As a result, an error message and code are returned
indicating that placement does not work on the given compartment type.
Logging
Regardless of success, a message is logged in the gWLM agent log file
for each PID for which a placement is attempted and a move to a new
workload is required:
Successful placements
Generate messages at the INFO level
Unsuccessful placements or missing workloads
Generate messages at the WARNING level
Attempted placements where the PID is already in the correct work‐
load
Produce no log message because no move is required
LIMITATIONS
Must run as root
You must be root to run gwlmplace.
Must run locally
You must run gwlmplace on the local managed node where the target pro‐
cesses are running.
Loss of process placement
All process placement with gwlmplace on a managed node is lost if:
+ The managed node is rebooted
+ The local gwlmagent daemon is restarted
+ You undeploy the current SRD
In these cases, processes are placed according to any application
records or user records that apply. If no records exist, nonroot pro‐
cesses are placed in the default pset or default fss group; root pro‐
cesses are left where they are. To restore the process placements that
existed before the reboot or restart, use gwlmplace again, using the
same arguments as before.
DEPENDENCIES
Requires the gWLM agent to be installed and running on the local man‐
aged node.
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
FILES
/var/opt/gwlm/gwlmagent.log.0 Log* of gwlmagent
* The name of the current log always ends in .log.0. Once this file
grows to a certain size, it is moved to a filename ending in .log.1 and
a new .log.0 file is started. If a .log.1 file already exists, it is
renamed .log.2. If a .log.2 file already exists, it is overwritten--or
moved to yet another file (up to a configurable number of files you can
set in /etc/opt/gwlm/conf/gwlmcms.properties.
SEE ALSOgwlm(1M), gwlm(5), gwlmagent(1M)gwlmplace(1M)