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.