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 command, you
can add execution hosts and modify the configuration of any execution host in
the cluster. Default execution host entries are added automatically as soon as
a registers to for the very first time from a certain host. The
-sel
switch can be used to display a list of execution hosts 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.
Note Grid Engine allows backslashes (\) be used to escape newline characters.
The backslash and the newline are replaced with a space character before any
interpretation.
The format of a
host_conf file is defined as follows:
hostname¶
The execution host's name in the format for
host_name in
load_scaling¶
A comma-separated list of scaling values to be applied to each or part of the
load values being reported by the on the host. The load scaling factors are
intended to level hardware or operating system-specific differences between
execution hosts.
The syntax of a load factor specification is as follows: 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 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 followed by an "=" sign and the
value specification compliant with the complex attribute type (see Quota
specifications are separated by commas.
The quotas are related to the resource consumption of all jobs on a host in the
case of consumable resources (see 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 distinctive 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 effectively 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 The
-F option of and the load display in the 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 during job
submission (see the
-l option to or from a "default" value
configured for an attribute by the administrator (see The
-r option to
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 compares the job's attribute
requests with the corresponding specification in
complex_values taking
the relation operator of the complex attribute definition into account (see If
the result of the comparison 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
-se
command. All load values are displayed as reported by the on the host. The
load values are shown in a comma-separated list. Each load value starts with
its name, followed by an equal sign and the reported value.
processors¶
Note: Deprecated, may be removed in future release.
This entry cannot be configured but is only displayed in case of a
-se
command. Its value is the number of "processors" which has been
detected by on the corresponding host. This may include "hardware
threads" reported by the operating system.
usage_scaling¶
The
usage_scaling parameter scales the usage figures, but only for the
purposes of share tree calculations, i.e. a scaling factor of 0 means that use
of the relevant host(s) will be ignored for share tree purposes (e.g. if hosts
are dedicated for a specific use). The format is equivalent to
load_scaling (see above). However, the only valid attributes to be
scaled are
cpu for CPU time consumption,
mem for memory
consumption aggregated over the lifetime 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 Each user contained in at least one of the
listed access lists has access to the host. If the
user_lists parameter
is set to NONE (the default), any user has access if not explicitly excluded
via the
xuser_lists parameter described below. If a user is contained
both in an access list 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 Each user contained in at least one of the
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
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 if not
specifically excluded via the
xprojects parameter described below. If a
project is in both
projects and
xprojects, 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
projects and
xprojects, the project is denied access to the host.
report_variables¶
The
report_variables parameter contains a comma-separated list of
variables that should 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 override settings from the global host.
SEE ALSO¶
COPYRIGHT¶
See for a full statement of rights and permissions.