NAME
host_conf - Grid Engine execution host configuration file
format
DESCRIPTION
Host_conf reflects the format of the template file for the
execution host configuration. Via the -ae and -me options
of the qconf(1) command, you can add execution hosts and
modify the configuration of any execution host in the clus-
ter. Default execution host entries are added automatically
as soon as a sge_execd(8) registers to sge_qmaster(8) for
the very first time from a certain host. The qconf(1) -sel
switch can be used to display a list of execution host being
currently configured in your Grid Engine system. Via the -se
option you can print the execution host configuration of a
specified host.
The special hostname "global" can be used to define cluster
global characteristics.
FORMAT
The format of a host_conf file is defined as follows:
hostname
The name of the execution host.
load_scaling
A comma separated list of scaling values to be applied
to each or part of the load values being reported by
the sge_execd(8) on the host and being defined in the
cluster global "host" complex (see complex(5)). The
load scaling factors are intended to level hardware or
operating system specific differences between execution
hosts. If, for example, the load average value
(load_avg in the "host" complex; see also uptime(1)) of
a multiprocessor machine is to be compared with a sin-
gle processor machine the load as reported by the sin-
gle CPU host needs to be weighted up against the mul-
tiprocessor load (given the same CPU hardware) to be
comparable. The load scaling factors are integers being
multiplied with the reported load quantities to consti-
tute weighted load values. Thus, following the example
given above, the load value of the single processor
machine needs to be multiplied by the number of proces-
sors of the single processor machine to become compar-
able.
The syntax of a load factor specification is as fol-
lows: First the name of the load value (as defined in
the "host" complex) is given and, separated by an equal
sign, the load scaling value is provided. No blanks are
allowed in between the load_scaling value string.
The parameter load_scaling is not meaningful for the
definition of the "global" host.
complex_values
complex_values defines quotas for resource attributes
managed via this host. Each complex attribute is fol-
lowed by an "=" sign and the value specification com-
pliant with the complex attribute type (see com-
plex(5)). Quota specifications are separated by com-
mas.
The quotas are related to the resource consumption of
all jobs on a host in the case of consumable resources
(see complex(5) for details on consumable resources) or
they are interpreted on a per job slot basis in the
case of non-consumable resources. Consumable resource
attributes are commonly used to manage free memory,
free disk space or available floating software licenses
while non-consumable attributes usually define distinc-
tive characteristics like type of hardware installed.
For consumable resource attributes an available
resource amount is determined by subtracting the
current resource consumption of all running jobs on the
host from the quota in the complex_values list. Jobs
can only be dispatched to a host if no resource
requests exceed any corresponding resource availability
obtained by this scheme. The quota definition in the
complex_values list is automatically replaced by the
current load value reported for this attribute, if load
is monitored for this resource and if the reported load
value is more stringent than the quota. This effec-
tively avoids oversubscription of resources.
Note: Load values replacing the quota specifications
may have become more stringent because they have been
scaled (see load_scaling above) and/or load adjusted
(see sched_conf(5)). The -F option of qstat(1) and the
load display in the qmon(1) queue control dialog
(activated by clicking on a queue icon while the
"Shift" key is pressed) provide detailed information on
the actual availability of consumable resources and on
the origin of the values taken into account currently.
Note also: The resource consumption of running jobs
(used for the availability calculation) as well as the
resource requests of the jobs waiting to be dispatched
either may be derived from explicit user requests dur-
ing job submission (see the -l option to qsub(1)) or
from a "default" value configured for an attribute by
the administrator (see complex(5)). The -r option to
qstat(1) can be used for retrieving full detail on the
actual resource requests of all jobs in the system.
For non-consumable resources Grid Engine simply com-
pares the job's attribute requests with the correspond-
ing specification in complex_values taking the relation
operator of the complex attribute definition into
account (see complex(5)). If the result of the com-
parison is "true", the host is suitable for the job
with respect to the particular attribute. For parallel
jobs each job slot to be occupied by a parallel task is
meant to provide the same resource attribute value.
Note: Only numeric complex attributes can be defined as
consumable resources and hence non-numeric attributes
are always handled on a per job slot basis.
The default value for this parameter is NONE, i.e. no
administrator defined resource attribute quotas are
associated with the host.
load_values
This entry cannot be configured but is only displayed
in case of a qconf(1) -se command. All load values are
displayed as reported by the sge_execd(8) on the host.
The load values are enlisted in a comma separated list.
Each load value start with its name, followed by an
equal sign and the reported value.
processors
This entry cannot be configured but is only displayed
in case of a qconf(1) -se command. Its value is the
number of processors which has been detected by
sge_execd(8) on the corresponding host.
usage_scaling
The format is equivalent to load_scaling (see above),
the only valid attributes to be scaled however are cpu
for CPU time consumption, mem for Memory consumption
aggregated over the life-time of jobs and io for data
transferred via any I/O devices. The default NONE means
"no scaling", i.e. all scaling factors are 1.
user_lists
The user_lists parameter contains a comma separated
list of so called user access lists as described in
access_list(5). Each user contained in at least one of
the enlisted access lists has access to the host. If
the user_lists parameter is set to NONE (the default)
any user has access being not explicitly excluded via
the xuser_lists parameter described below. If a user
is contained both in an access list enlisted in
xuser_lists and user_lists the user is denied access to
the host.
xuser_lists
The xuser_lists parameter contains a comma separated
list of so called user access lists as described in
access_list(5). Each user contained in at least one of
the enlisted access lists is not allowed to access the
host. If the xuser_lists parameter is set to NONE (the
default) any user has access. If a user is contained
both in an access list enlisted in xuser_lists and
user_lists the user is denied access to the host.
projects
The projects parameter contains a comma separated list
of projects that have access to the host. Any projects
not in this list are denied access to the host. If set
to NONE (the default), any project has access that is
not specifically excluded via the xprojects parameter
described below. If a project is in both the projects
and xprojects parameters, the project is denied access
to the host.
xprojects
The xprojects parameter contains a comma separated list
of projects that are denied access to the host. If set
to NONE (the default), no projects are denied access
other than those denied access based on the projects
parameter described above. If a project is in both the
projects and xprojects parameters, the project is
denied access to the host.
report_variables
The report_variables parameter contains a comma
separated list of variables that shall be written to
the reporting file. The variables listed here will be
written to the reporting file when a load report
arrives from an execution host.
Default settings can be done in the global host. Host
specific settings for report_variables will overwrite
settings from the global host.
SEE ALSO
sge_intro(1), qconf(1), uptime(1), access_list(5), com-
plex(5), sge_execd(8), sge_qmater(8).
COPYRIGHT
See sge_intro(1) for a full statement of rights and permis-
sions.
Man(1) output converted with
man2html