HOST_CONF(5) File Formats Manual HOST_CONF(5) NAME host_conf - Univa 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) com- mand, 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 host being currently configured in your Univa 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, Univa Grid Engine allows backslashes (\) be used to escape new- line (\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 hosts name as defined for host_name in sge_types(1). 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 complex configuration (see complex(5)). The load scaling factors are intended to level hardware or operating system spe- cific 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 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_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 com- plex(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, available floating software licenses, or access to specific co-processor devices, while non-consumable attributes usually define distinctive characteris- tics like type of hardware installed. For consumable resource attributes an available resource amount is determined by subtracting the current resource consumption of all run- ning 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. A special configuration is needed for resources with type RSMAP (see complex(5).) A RSMAP complex is initialized in the complex_values field not just only by the amount of instances available on the host, also a list of strings must be appended in parentheses (like idlist=2(id1 id2)). If the scheduler assigns a specific amount of those consumables to the jobs, it also maps that amount of ids to the job. The ids are chosen in the order they are configured in the list. The assigned ids can be seen in the qstat -j output. The job has set an environment variable SGE_HGR_=, in order to determine, which ids where selected. This is particular useful for devices, where a job needs an access key for (like for co-processors) in order to avoid access collisions by jobs. Within the environment variable iden- tifier () only shell compatible characters are printed ([a-z|A- Z|_|0-9]*), other characters are omitted. RSMAP id lists can also be enhanced with a topology mask on hosts, which are supported by the core binding feature. Then additionally to the id selection (which is always in order of the configured values), the job is bound to the cores, which are marked as available in the topology mask. The topology mask is only available for per HOST com- plexes (see complex(5)) and appended to each id by a colon. Example: complex_values GPU=2(GPU0:SccCC GPU1:SCCcc). When the job requests -l GPU=1 and the scheduler select GPU0, then the job gets bound to the third and fourth core of the host. If the GPU1 is selected, the job is automatically bound to the first and second core of the execution host. 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 Univa Grid Engine simply compares the job's attribute requests with the corresponding specification in com- plex_values taking the relation operator of the complex attribute defi- nition into account (see complex(5)). If the result of the comparison is "true", the host is suitable for the job with respect to the partic- ular 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 sepa- rated list. Each load value start 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. usage_scaling 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 scal- ing", 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 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. 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. report_variables The report_variables parameter contains a comma separated list of vari- ables that shall 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. license_constraints The license_constraints parameter contains a comma separated list of constraints that limits the usage of the given licenses. These con- straints are inherited from License Orchestrator and cannot be changed locally in UGE. A license constraint shows to which License Manager a license belongs to as also the used and total count. Optionally it can express that licenses are limited to special users and/or to hosts. For more information have a look at the License Orchestrator documenta- tion. license_oversubscription The license_oversubscription parameter contains a comma separated list of licenses whose reported load values are supposed to get increased. Each license attribute is followed by an "=" sign and the count which should get added to the reported load value. The load value only gets increase when the reported value is 0 and not all of this licenses are consumed by this cluster. SEE ALSO sge_intro(1), sge_types(1), qconf(1), uptime(1), access_list(5), com- plex(5), sge_execd(8), sge_qmaster(8). COPYRIGHT See sge_intro(1) for a full statement of rights and permissions. Univa Grid Engine File Formats UGE 8.5.4 HOST_CONF(5)