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 sge_execd(8) registers to sge_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 currently configured in
16 your Grid Engine system. Via the -se option you can print the execution
17 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 reported by the sge_execd(8) on the host and defined
35 in the cluster global "host" complex (see complex(5)). The load scal‐
36 ing factors are intended to balance hardware or operating system spe‐
37 cific 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 sge_execd(8) on the host. The load values are listed 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 This entry cannot be configured but is only displayed in case of a
111 qconf(1) -se command. Its value is the number of processors which has
112 been detected by sge_execd(8) on the corresponding host.
113
114 usage_scaling
115 The format is equivalent to load_scaling (see above), the only valid
116 attributes to be scaled however are cpu for CPU time consumption, mem
117 for Memory consumption aggregated over the life-time of jobs and io for
118 data transferred via any I/O devices. The default NONE means "no scal‐
119 ing", i.e. all scaling factors are 1.
120
121 user_lists
122 The user_lists parameter contains a comma separated list of user access
123 lists as described in access_list(5). Each user contained in at least
124 one of the listed access lists has access to the host. If the
125 user_lists parameter is set to NONE (the default) any user has access
126 not explicitly excluded via the xuser_lists parameter described below.
127 If a user is contained both in an access list listed in xuser_lists and
128 user_lists the user is denied access to the host.
129
130 xuser_lists
131 The xuser_lists parameter contains a comma separated list of user
132 access lists as described in access_list(5). Each user contained in at
133 least one of the listed access lists is not allowed to access the host.
134 If the xuser_lists parameter is set to NONE (the default) any user has
135 access. If a user is contained both in an access list listed in
136 xuser_lists and user_lists the user is denied access to the host.
137
138 projects
139 The projects parameter contains a comma separated list of projects that
140 have access to the host. Any projects not in this list are denied
141 access to the host. If set to NONE (the default), any project has
142 access that is not specifically excluded via the xprojects parameter
143 described below. If a project is in both the projects and xprojects
144 parameters, the project is denied access to the host.
145
146 xprojects
147 The xprojects parameter contains a comma separated list of projects
148 that are denied access to the host. If set to NONE (the default), no
149 projects are denied access other than those denied access based on the
150 projects parameter described above. If a project is in both the
151 projects and xprojects parameters, the project is denied access to the
152 host.
153
154 report_variables
155 The report_variables parameter contains a comma separated list of vari‐
156 ables that shall be written to the reporting file. The variables
157 listed here will be written to the reporting file when a load report
158 arrives from an execution host.
159
160 Default settings can be done in the global host. Host specific settings
161 for report_variables will override settings from the global host.
162
164 sge_intro(1), sge_types(1), qconf(1), uptime(1), access_list(5), com‐
165 plex(5), sge_execd(8), sge_qmaster(8).
166
168 See sge_intro(1) for a full statement of rights and permissions.
169
170
171
172GE 6.1 $Date: 2007/07/19 08:17:17 $ HOST_CONF(5)