    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_list
              The comma separated list of administrator defined  com-
              plexes  (see  complex(5)  for details) to be associated
              with the host. Only complex attributes contained in the
              enlisted  complexes  and  those  from  the "global" and
              "host" complex, which are implicitly attached  to  each
              host,  can be used in the complex_values list below. In
              case of the "global" host, the "host"  complex  is  not
              attached  and  only  "global"  complex  attributes  are
              allowed per default in the complex_values list  of  the
              "global" host.

              The default value for this parameter is NONE,  i.e.  no
              administrator defined complexes are associated with the
              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.  Only  attributes  as defined in complex_list (see
              above) may be used.

              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
              This entry is only present in a Grid Engine  Enterprise
              Edition system. It is not available in Grid Engine.

              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.

         resource_capability_factor
              This entry is only present in a Grid Engine  Enterprise
              Edition system. It is not available in Grid Engine.

              The resource capability factor is used by  Grid  Engine
              Enterprise  Edition  when  assigning  jobs to execution
              hosts. The resource capability factor tells Grid Engine
              Enterprise Edition how the resources (CPU, memory, I/O,
              etc.) of one execution host compare to the resources of
              other  execution hosts. This helps to ensure that a job
              requiring a large percentage of resources (i.e. lots of
              tickets)  gets placed on an execution host containing a
              large percentage of the available resources.  The  load
              situation  on the execution hosts is taken into account
              in addition, to guarantee that  the  selected  host  is
              both powerful enough and lightly loaded.

              For example, you might consider setting  your  resource
              capability factors for each execution host based on the
              number of CPUs, the speed of the CPUs and the installed
              main memory:

                 #_of_CPUs * (MHz/200) + GB_of_memory

              This would give an execution host with 32 200 MHz  CPUs
              and 10 gigabytes of memory a resource capability factor
              of 42, while an execution host with 24 200 MHz CPUs and
              40  gigabytes of memory would get a resource capability
              factor of 64, i.e. memory has a significant  impact  in
              this example.

              Other factors that you might want to consider  in  set-
              ting the resource capability factor are:

                 job mix              - CPU or memory bound jobs
                 CPU benchmarks       - comparison by CPU vendor
                 megaflops (MFLOPS)   - for number crunching
                 I/O capabilities     - disk/network speed
                 available disk space - at the execution host

              The resource capability factor is stored as a  floating
              point  double  value.  The  range of values used is not
              important. Grid Engine Enterprise Edition only looks at
              the relation between values of different hosts.

         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.   This  parameter is only available in a
              Grid Engine Enterprise Edition system.

         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.   This  parameter  is  only
              available in a Grid Engine Enterprise Edition system.

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