host_conf.5




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.


SEE ALSO

       sge_intro(1), sge_types(1), qconf(1), uptime(1), access_list(5),
       complex(5), sge_execd(8), sge_qmaster(8).


COPYRIGHT

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



SGE 8.1.3pre             $Date: 2011-06-22 15:24:22 $             HOST_CONF(5)

Man(1) output converted with man2html