1HOST_CONF(5) Grid Engine File Formats HOST_CONF(5)
2
3
4
6 host_conf - Grid Engine execution host configuration file format
7
9 Host_conf reflects the format of the template file for the execution
10 host configuration. Via the -ae and -me options of the qconf(1) com‐
11 mand, you can add execution hosts and modify the configuration of any
12 execution host in the cluster. Default execution host entries are added
13 automatically as soon as a ge_execd(8) registers to ge_qmaster(8) for
14 the very first time from a certain host. The qconf(1) -sel switch can
15 be used to display a list of execution host being currently configured
16 in your Grid Engine system. Via the -se option you can print the execu‐
17 tion host configuration of a specified host.
18
19 The special hostname "global" can be used to define cluster global
20 characteristics.
21
22 Note, Grid Engine allows backslashes (\) be used to escape newline
23 (\newline) characters. The backslash and the newline are replaced with
24 a space (" ") character before any interpretation.
25
27 The format of a host_conf file is defined as follows:
28
29 hostname
30 The execution hosts name as defined for host_name in sge_types(1).
31
32 load_scaling
33 A comma separated list of scaling values to be applied to each or part
34 of the load values being reported by the ge_execd(8) on the host and
35 being defined in the cluster global "host" complex (see complex(5)).
36 The load scaling factors are intended to level hardware or operating
37 system specific differences between execution hosts.
38
39 The syntax of a load factor specification is as follows: First the name
40 of the load value (as defined in the "host" complex) is given and, sep‐
41 arated by an equal sign, the load scaling value is provided. No blanks
42 are allowed in between the load_scaling value string.
43
44 The parameter load_scaling is not meaningful for the definition of the
45 "global" host.
46
47 complex_values
48 complex_values defines quotas for resource attributes managed via this
49 host. Each complex attribute is followed by an "=" sign and the value
50 specification compliant with the complex attribute type (see com‐
51 plex(5)). Quota specifications are separated by commas.
52
53 The quotas are related to the resource consumption of all jobs on a
54 host in the case of consumable resources (see complex(5) for details on
55 consumable resources) or they are interpreted on a per job slot basis
56 in the case of non-consumable resources. Consumable resource attributes
57 are commonly used to manage free memory, free disk space or available
58 floating software licenses while non-consumable attributes usually
59 define distinctive characteristics like type of hardware installed.
60
61 For consumable resource attributes an available resource amount is
62 determined by subtracting the current resource consumption of all run‐
63 ning jobs on the host from the quota in the complex_values list. Jobs
64 can only be dispatched to a host if no resource requests exceed any
65 corresponding resource availability obtained by this scheme. The quota
66 definition in the complex_values list is automatically replaced by the
67 current load value reported for this attribute, if load is monitored
68 for this resource and if the reported load value is more stringent than
69 the quota. This effectively avoids oversubscription of resources.
70
71 Note: Load values replacing the quota specifications may have become
72 more stringent because they have been scaled (see load_scaling above)
73 and/or load adjusted (see sched_conf(5)). The -F option of qstat(1)
74 and the load display in the qmon(1) queue control dialog (activated by
75 clicking on a queue icon while the "Shift" key is pressed) provide
76 detailed information on the actual availability of consumable resources
77 and on the origin of the values taken into account currently.
78
79 Note also: The resource consumption of running jobs (used for the
80 availability calculation) as well as the resource requests of the jobs
81 waiting to be dispatched either may be derived from explicit user
82 requests during job submission (see the -l option to qsub(1)) or from a
83 "default" value configured for an attribute by the administrator (see
84 complex(5)). The -r option to qstat(1) can be used for retrieving full
85 detail on the actual resource requests of all jobs in the system.
86
87 For non-consumable resources Grid Engine simply compares the job's
88 attribute requests with the corresponding specification in complex_val‐
89 ues taking the relation operator of the complex attribute definition
90 into account (see complex(5)). If the result of the comparison is
91 "true", the host is suitable for the job with respect to the particular
92 attribute. For parallel jobs each job slot to be occupied by a parallel
93 task is meant to provide the same resource attribute value.
94
95 Note: Only numeric complex attributes can be defined as consumable
96 resources and hence non-numeric attributes are always handled on a per
97 job slot basis.
98
99 The default value for this parameter is NONE, i.e. no administrator
100 defined resource attribute quotas are associated with the host.
101
102 load_values
103 This entry cannot be configured but is only displayed in case of a
104 qconf(1) -se command. All load values are displayed as reported by the
105 ge_execd(8) on the host. The load values are enlisted in a comma sepa‐
106 rated list. Each load value start with its name, followed by an equal
107 sign and the reported value.
108
109 processors
110 Note: Deprecated, may be removed in future release.
111 This entry cannot be configured but is only displayed in case of a
112 qconf(1) -se command. Its value is the number of processors which has
113 been detected by ge_execd(8) on the corresponding host.
114
115 usage_scaling
116 The format is equivalent to load_scaling (see above), the only valid
117 attributes to be scaled however are cpu for CPU time consumption, mem
118 for Memory consumption aggregated over the life-time of jobs and io for
119 data transferred via any I/O devices. The default NONE means "no scal‐
120 ing", i.e. all scaling factors are 1.
121
122 user_lists
123 The user_lists parameter contains a comma separated list of so called
124 user access lists as described in access_list(5). Each user contained
125 in at least one of the enlisted access lists has access to the host. If
126 the user_lists parameter is set to NONE (the default) any user has
127 access being not explicitly excluded via the xuser_lists parameter
128 described below. If a user is contained both in an access list
129 enlisted in xuser_lists and user_lists the user is denied access to the
130 host.
131
132 xuser_lists
133 The xuser_lists parameter contains a comma separated list of so called
134 user access lists as described in access_list(5). Each user contained
135 in at least one of the enlisted access lists is not allowed to access
136 the host. If the xuser_lists parameter is set to NONE (the default) any
137 user has access. If a user is contained both in an access list
138 enlisted in xuser_lists and user_lists the user is denied access to the
139 host.
140
141 projects
142 The projects parameter contains a comma separated list of projects that
143 have access to the host. Any projects not in this list are denied
144 access to the host. If set to NONE (the default), any project has
145 access that is not specifically excluded via the xprojects parameter
146 described below. If a project is in both the projects and xprojects
147 parameters, the project is denied access to the host.
148
149 xprojects
150 The xprojects parameter contains a comma separated list of projects
151 that are denied access to the host. If set to NONE (the default), no
152 projects are denied access other than those denied access based on the
153 projects parameter described above. If a project is in both the
154 projects and xprojects parameters, the project is denied access to the
155 host.
156
157 report_variables
158 The report_variables parameter contains a comma separated list of vari‐
159 ables that shall be written to the reporting file. The variables
160 listed here will be written to the reporting file when a load report
161 arrives from an execution host.
162
163 Default settings can be done in the global host. Host specific settings
164 for report_variables will override settings from the global host.
165
167 ge_intro(1), ge_types(1), qconf(1), uptime(1), access_list(5), com‐
168 plex(5), ge_execd(8), ge_qmaster(8).
169
171 See ge_intro(1) for a full statement of rights and permissions.
172
173
174
175GE 6.2u5 $Date: 2008/07/08 09:10:05 $ HOST_CONF(5)