Ubuntu Manpage: host_conf - Grid Engine execution host configuration file format

Provided by: gridengine-common_8.1.9+dfsg-11_all

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 cluster. 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 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.

FORMAT

The format of a host_conf file is defined as follows:

hostname
The execution host's name in the format for host_name in sge_types(5).

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. 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 complex(5)). 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 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 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
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 during 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 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 complex(5)). 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 qconf(1) -se command.
All load values are displayed as reported by the sge_execd(8) 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 qconf(1) -se command.
Its value is the number of "processors" which has been detected by sge_execd(8) 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 access_list(5). 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 access_list(5). 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.

COPYRIGHT

       See sge_intro(1) for a full statement of rights and permissions.

NAME

DESCRIPTION

FORMAT

SEE ALSO

COPYRIGHT