root / man / gnt-node.rst @ 2afd577f
History | View | Annotate | Download (16.4 kB)
1 |
gnt-node(8) Ganeti | Version @GANETI_VERSION@ |
---|---|
2 |
============================================= |
3 |
|
4 |
Name |
5 |
---- |
6 |
|
7 |
gnt-node - Node administration |
8 |
|
9 |
Synopsis |
10 |
-------- |
11 |
|
12 |
**gnt-node** {command} [arguments...] |
13 |
|
14 |
DESCRIPTION |
15 |
----------- |
16 |
|
17 |
The **gnt-node** is used for managing the (physical) nodes in the |
18 |
Ganeti system. |
19 |
|
20 |
COMMANDS |
21 |
-------- |
22 |
|
23 |
ADD |
24 |
~~~ |
25 |
|
26 |
| **add** [--readd] [-s *secondary\_ip*] [-g *nodegroup*] |
27 |
| [--master-capable=``yes|no``] [--vm-capable=``yes|no``] |
28 |
| [--node-parameters *ndparams*] |
29 |
| {*nodename*} |
30 |
|
31 |
Adds the given node to the cluster. |
32 |
|
33 |
This command is used to join a new node to the cluster. You will |
34 |
have to provide the password for root of the node to be able to add |
35 |
the node in the cluster. The command needs to be run on the Ganeti |
36 |
master. |
37 |
|
38 |
Note that the command is potentially destructive, as it will |
39 |
forcibly join the specified host the cluster, not paying attention |
40 |
to its current status (it could be already in a cluster, etc.) |
41 |
|
42 |
The ``-s`` is used in dual-home clusters and specifies the new node's |
43 |
IP in the secondary network. See the discussion in **gnt-cluster**(8) |
44 |
for more information. |
45 |
|
46 |
In case you're readding a node after hardware failure, you can use |
47 |
the ``--readd`` parameter. In this case, you don't need to pass the |
48 |
secondary IP again, it will reused from the cluster. Also, the |
49 |
drained and offline flags of the node will be cleared before |
50 |
re-adding it. |
51 |
|
52 |
The ``--force-join`` option is to proceed with adding a node even if it already |
53 |
appears to belong to another cluster. This is used during cluster merging, for |
54 |
example. |
55 |
|
56 |
The ``-g`` is used to add the new node into a specific node group, |
57 |
specified by UUID or name. If only one node group exists you can |
58 |
skip this option, otherwise it's mandatory. |
59 |
|
60 |
The ``vm_capable``, ``master_capable`` and ``ndparams`` options are |
61 |
described in **ganeti**(7), and are used to set the properties of the |
62 |
new node. |
63 |
|
64 |
Example:: |
65 |
|
66 |
# gnt-node add node5.example.com |
67 |
# gnt-node add -s 192.0.2.5 node5.example.com |
68 |
# gnt-node add -g group2 -s 192.0.2.9 node9.group2.example.com |
69 |
|
70 |
|
71 |
ADD-TAGS |
72 |
~~~~~~~~ |
73 |
|
74 |
**add-tags** [--from *file*] {*nodename*} {*tag*...} |
75 |
|
76 |
Add tags to the given node. If any of the tags contains invalid |
77 |
characters, the entire operation will abort. |
78 |
|
79 |
If the ``--from`` option is given, the list of tags will be |
80 |
extended with the contents of that file (each line becomes a tag). |
81 |
In this case, there is not need to pass tags on the command line |
82 |
(if you do, both sources will be used). A file name of - will be |
83 |
interpreted as stdin. |
84 |
|
85 |
EVACUATE |
86 |
~~~~~~~~ |
87 |
|
88 |
**evacuate** [-f] [--early-release] [--iallocator *NAME* \| |
89 |
--new-secondary *destination\_node*] {*node*...} |
90 |
|
91 |
This command will move all secondary instances away from the given |
92 |
node(s). It works only for instances having a drbd disk template. |
93 |
|
94 |
The new location for the instances can be specified in two ways: |
95 |
|
96 |
- as a single node for all instances, via the ``--new-secondary`` |
97 |
option |
98 |
|
99 |
- or via the ``--iallocator`` option, giving a script name as |
100 |
parameter, so each instance will be in turn placed on the (per the |
101 |
script) optimal node |
102 |
|
103 |
|
104 |
The ``--early-release`` changes the code so that the old storage on |
105 |
node being evacuated is removed early (before the resync is |
106 |
completed) and the internal Ganeti locks are also released for both |
107 |
the current secondary and the new secondary, thus allowing more |
108 |
parallelism in the cluster operation. This should be used only when |
109 |
recovering from a disk failure on the current secondary (thus the |
110 |
old storage is already broken) or when the storage on the primary |
111 |
node is known to be fine (thus we won't need the old storage for |
112 |
potential recovery). |
113 |
|
114 |
Example:: |
115 |
|
116 |
# gnt-node evacuate -I dumb node3.example.com |
117 |
|
118 |
|
119 |
FAILOVER |
120 |
~~~~~~~~ |
121 |
|
122 |
**failover** [-f] [--ignore-consistency] {*node*} |
123 |
|
124 |
This command will fail over all instances having the given node as |
125 |
primary to their secondary nodes. This works only for instances having |
126 |
a drbd disk template. |
127 |
|
128 |
Normally the failover will check the consistency of the disks before |
129 |
failing over the instance. If you are trying to migrate instances off |
130 |
a dead node, this will fail. Use the ``--ignore-consistency`` option |
131 |
for this purpose. |
132 |
|
133 |
Example:: |
134 |
|
135 |
# gnt-node failover node1.example.com |
136 |
|
137 |
|
138 |
INFO |
139 |
~~~~ |
140 |
|
141 |
**info** [*node*...] |
142 |
|
143 |
Show detailed information about the nodes in the cluster. If you |
144 |
don't give any arguments, all nodes will be shows, otherwise the |
145 |
output will be restricted to the given names. |
146 |
|
147 |
LIST |
148 |
~~~~ |
149 |
|
150 |
| **list** |
151 |
| [--no-headers] [--separator=*SEPARATOR*] |
152 |
| [--units=*UNITS*] [-v] [-o *[+]FIELD,...*] |
153 |
| [--filter] |
154 |
| [node...] |
155 |
|
156 |
Lists the nodes in the cluster. |
157 |
|
158 |
The ``--no-headers`` option will skip the initial header line. The |
159 |
``--separator`` option takes an argument which denotes what will be |
160 |
used between the output fields. Both these options are to help |
161 |
scripting. |
162 |
|
163 |
The units used to display the numeric values in the output varies, |
164 |
depending on the options given. By default, the values will be |
165 |
formatted in the most appropriate unit. If the ``--separator`` |
166 |
option is given, then the values are shown in mebibytes to allow |
167 |
parsing by scripts. In both cases, the ``--units`` option can be |
168 |
used to enforce a given output unit. |
169 |
|
170 |
Queries of nodes will be done in parallel with any running jobs. This might |
171 |
give inconsistent results for the free disk/memory. |
172 |
|
173 |
The ``-v`` option activates verbose mode, which changes the display of |
174 |
special field states (see **ganeti(7)**). |
175 |
|
176 |
The ``-o`` option takes a comma-separated list of output fields. |
177 |
The available fields and their meaning are: |
178 |
|
179 |
@QUERY_FIELDS_NODE@ |
180 |
|
181 |
If the value of the option starts with the character ``+``, the new |
182 |
fields will be added to the default list. This allows to quickly |
183 |
see the default list plus a few other fields, instead of retyping |
184 |
the entire list of fields. |
185 |
|
186 |
Note that some of these fields are known from the configuration of the |
187 |
cluster (e.g. ``name``, ``pinst``, ``sinst``, ``pip``, ``sip``) and thus |
188 |
the master does not need to contact the node for this data (making the |
189 |
listing fast if only fields from this set are selected), whereas the |
190 |
other fields are "live" fields and require a query to the cluster nodes. |
191 |
|
192 |
Depending on the virtualization type and implementation details, the |
193 |
``mtotal``, ``mnode`` and ``mfree`` fields may have slighly varying |
194 |
meanings. For example, some solutions share the node memory with the |
195 |
pool of memory used for instances (KVM), whereas others have separate |
196 |
memory for the node and for the instances (Xen). |
197 |
|
198 |
If exactly one argument is given and it appears to be a query filter |
199 |
(see **ganeti(7)**), the query result is filtered accordingly. For |
200 |
ambiguous cases (e.g. a single field name as a filter) the ``--filter`` |
201 |
(``-F``) option forces the argument to be treated as a filter (e.g. |
202 |
``gnt-node list -F master_candidate``). |
203 |
|
204 |
If no node names are given, then all nodes are queried. Otherwise, |
205 |
only the given nodes will be listed. |
206 |
|
207 |
|
208 |
LIST-FIELDS |
209 |
~~~~~~~~~~~ |
210 |
|
211 |
**list-fields** [field...] |
212 |
|
213 |
Lists available fields for nodes. |
214 |
|
215 |
|
216 |
LIST-TAGS |
217 |
~~~~~~~~~ |
218 |
|
219 |
**list-tags** {*nodename*} |
220 |
|
221 |
List the tags of the given node. |
222 |
|
223 |
MIGRATE |
224 |
~~~~~~~ |
225 |
|
226 |
**migrate** [-f] [--non-live] [--migration-mode=live\|non-live] |
227 |
{*node*} |
228 |
|
229 |
This command will migrate all instances having the given node as |
230 |
primary to their secondary nodes. This works only for instances |
231 |
having a drbd disk template. |
232 |
|
233 |
As for the **gnt-instance migrate** command, the options |
234 |
``--no-live`` and ``--migration-mode`` can be given to influence |
235 |
the migration type. |
236 |
|
237 |
Example:: |
238 |
|
239 |
# gnt-node migrate node1.example.com |
240 |
|
241 |
|
242 |
MODIFY |
243 |
~~~~~~ |
244 |
|
245 |
| **modify** [-f] [--submit] |
246 |
| [--master-candidate=``yes|no``] [--drained=``yes|no``] [--offline=``yes|no``] |
247 |
| [--master-capable=``yes|no``] [--vm-capable=``yes|no``] [--auto-promote] |
248 |
| [-s *secondary_ip*] |
249 |
| [--node-parameters *ndparams*] |
250 |
| [--node-powered=``yes|no``] |
251 |
| {*node*} |
252 |
|
253 |
This command changes the role of the node. Each options takes |
254 |
either a literal yes or no, and only one option should be given as |
255 |
yes. The meaning of the roles and flags are described in the |
256 |
manpage **ganeti**(7). |
257 |
|
258 |
``--node-powered`` can be used to modify state-of-record if it doesn't reflect |
259 |
the reality anymore. |
260 |
|
261 |
In case a node is demoted from the master candidate role, the |
262 |
operation will be refused unless you pass the ``--auto-promote`` |
263 |
option. This option will cause the operation to lock all cluster nodes |
264 |
(thus it will not be able to run in parallel with most other jobs), |
265 |
but it allows automated maintenance of the cluster candidate pool. If |
266 |
locking all cluster node is too expensive, another option is to |
267 |
promote manually another node to master candidate before demoting the |
268 |
current one. |
269 |
|
270 |
Example (setting a node offline, which will demote it from master |
271 |
candidate role if is in that role):: |
272 |
|
273 |
# gnt-node modify --offline=yes node1.example.com |
274 |
|
275 |
The ``-s`` can be used to change the node's secondary ip. No drbd |
276 |
instances can be running on the node, while this operation is |
277 |
taking place. |
278 |
|
279 |
Example (setting the node back to online and master candidate):: |
280 |
|
281 |
# gnt-node modify --offline=no --master-candidate=yes node1.example.com |
282 |
|
283 |
|
284 |
REMOVE |
285 |
~~~~~~ |
286 |
|
287 |
**remove** {*nodename*} |
288 |
|
289 |
Removes a node from the cluster. Instances must be removed or |
290 |
migrated to another cluster before. |
291 |
|
292 |
Example:: |
293 |
|
294 |
# gnt-node remove node5.example.com |
295 |
|
296 |
|
297 |
REMOVE-TAGS |
298 |
~~~~~~~~~~~ |
299 |
|
300 |
**remove-tags** [--from *file*] {*nodename*} {*tag*...} |
301 |
|
302 |
Remove tags from the given node. If any of the tags are not |
303 |
existing on the node, the entire operation will abort. |
304 |
|
305 |
If the ``--from`` option is given, the list of tags to be removed will |
306 |
be extended with the contents of that file (each line becomes a tag). |
307 |
In this case, there is not need to pass tags on the command line (if |
308 |
you do, tags from both sources will be removed). A file name of - will |
309 |
be interpreted as stdin. |
310 |
|
311 |
VOLUMES |
312 |
~~~~~~~ |
313 |
|
314 |
| **volumes** [--no-headers] [--human-readable] |
315 |
| [--separator=*SEPARATOR*] [--output=*FIELDS*] |
316 |
| [*node*...] |
317 |
|
318 |
Lists all logical volumes and their physical disks from the node(s) |
319 |
provided. |
320 |
|
321 |
The ``--no-headers`` option will skip the initial header line. The |
322 |
``--separator`` option takes an argument which denotes what will be |
323 |
used between the output fields. Both these options are to help |
324 |
scripting. |
325 |
|
326 |
The units used to display the numeric values in the output varies, |
327 |
depending on the options given. By default, the values will be |
328 |
formatted in the most appropriate unit. If the ``--separator`` |
329 |
option is given, then the values are shown in mebibytes to allow |
330 |
parsing by scripts. In both cases, the ``--units`` option can be |
331 |
used to enforce a given output unit. |
332 |
|
333 |
The ``-o`` option takes a comma-separated list of output fields. |
334 |
The available fields and their meaning are: |
335 |
|
336 |
node |
337 |
the node name on which the volume exists |
338 |
|
339 |
phys |
340 |
the physical drive (on which the LVM physical volume lives) |
341 |
|
342 |
vg |
343 |
the volume group name |
344 |
|
345 |
name |
346 |
the logical volume name |
347 |
|
348 |
size |
349 |
the logical volume size |
350 |
|
351 |
instance |
352 |
The name of the instance to which this volume belongs, or (in case |
353 |
it's an orphan volume) the character "-" |
354 |
|
355 |
|
356 |
Example:: |
357 |
|
358 |
# gnt-node volumes node5.example.com |
359 |
Node PhysDev VG Name Size Instance |
360 |
node1.example.com /dev/hdc1 xenvg instance1.example.com-sda_11000.meta 128 instance1.example.com |
361 |
node1.example.com /dev/hdc1 xenvg instance1.example.com-sda_11001.data 256 instance1.example.com |
362 |
|
363 |
|
364 |
LIST-STORAGE |
365 |
~~~~~~~~~~~~ |
366 |
|
367 |
| **list-storage** [--no-headers] [--human-readable] |
368 |
| [--separator=*SEPARATOR*] [--storage-type=*STORAGE\_TYPE*] |
369 |
| [--output=*FIELDS*] |
370 |
| [*node*...] |
371 |
|
372 |
Lists the available storage units and their details for the given |
373 |
node(s). |
374 |
|
375 |
The ``--no-headers`` option will skip the initial header line. The |
376 |
``--separator`` option takes an argument which denotes what will be |
377 |
used between the output fields. Both these options are to help |
378 |
scripting. |
379 |
|
380 |
The units used to display the numeric values in the output varies, |
381 |
depending on the options given. By default, the values will be |
382 |
formatted in the most appropriate unit. If the ``--separator`` |
383 |
option is given, then the values are shown in mebibytes to allow |
384 |
parsing by scripts. In both cases, the ``--units`` option can be |
385 |
used to enforce a given output unit. |
386 |
|
387 |
The ``--storage-type`` option can be used to choose a storage unit |
388 |
type. Possible choices are lvm-pv, lvm-vg or file. |
389 |
|
390 |
The ``-o`` option takes a comma-separated list of output fields. |
391 |
The available fields and their meaning are: |
392 |
|
393 |
node |
394 |
the node name on which the volume exists |
395 |
|
396 |
type |
397 |
the type of the storage unit (currently just what is passed in via |
398 |
``--storage-type``) |
399 |
|
400 |
name |
401 |
the path/identifier of the storage unit |
402 |
|
403 |
size |
404 |
total size of the unit; for the file type see a note below |
405 |
|
406 |
used |
407 |
used space in the unit; for the file type see a note below |
408 |
|
409 |
free |
410 |
available disk space |
411 |
|
412 |
allocatable |
413 |
whether we the unit is available for allocation (only lvm-pv can |
414 |
change this setting, the other types always report true) |
415 |
|
416 |
|
417 |
Note that for the "file" type, the total disk space might not equal |
418 |
to the sum of used and free, due to the method Ganeti uses to |
419 |
compute each of them. The total and free values are computed as the |
420 |
total and free space values for the filesystem to which the |
421 |
directory belongs, but the used space is computed from the used |
422 |
space under that directory *only*, which might not be necessarily |
423 |
the root of the filesystem, and as such there could be files |
424 |
outside the file storage directory using disk space and causing a |
425 |
mismatch in the values. |
426 |
|
427 |
Example:: |
428 |
|
429 |
node1# gnt-node list-storage node2 |
430 |
Node Type Name Size Used Free Allocatable |
431 |
node2 lvm-pv /dev/sda7 673.8G 1.5G 672.3G Y |
432 |
node2 lvm-pv /dev/sdb1 698.6G 0M 698.6G Y |
433 |
|
434 |
|
435 |
MODIFY-STORAGE |
436 |
~~~~~~~~~~~~~~ |
437 |
|
438 |
**modify-storage** [``--allocatable=yes|no``] |
439 |
{*node*} {*storage-type*} {*volume-name*} |
440 |
|
441 |
Modifies storage volumes on a node. Only LVM physical volumes can |
442 |
be modified at the moment. They have a storage type of "lvm-pv". |
443 |
|
444 |
Example:: |
445 |
|
446 |
# gnt-node modify-storage --allocatable no node5.example.com lvm-pv /dev/sdb1 |
447 |
|
448 |
|
449 |
REPAIR-STORAGE |
450 |
~~~~~~~~~~~~~~ |
451 |
|
452 |
**repair-storage** [--ignore-consistency] {*node*} {*storage-type*} |
453 |
{*volume-name*} |
454 |
|
455 |
Repairs a storage volume on a node. Only LVM volume groups can be |
456 |
repaired at this time. They have the storage type "lvm-vg". |
457 |
|
458 |
On LVM volume groups, **repair-storage** runs "vgreduce |
459 |
--removemissing". |
460 |
|
461 |
|
462 |
|
463 |
**Caution:** Running this command can lead to data loss. Use it with |
464 |
care. |
465 |
|
466 |
The ``--ignore-consistency`` option will ignore any inconsistent |
467 |
disks (on the nodes paired with this one). Use of this option is |
468 |
most likely to lead to data-loss. |
469 |
|
470 |
Example:: |
471 |
|
472 |
# gnt-node repair-storage node5.example.com lvm-vg xenvg |
473 |
|
474 |
|
475 |
POWERCYCLE |
476 |
~~~~~~~~~~ |
477 |
|
478 |
**powercycle** [``--yes``] [``--force``] {*node*} |
479 |
|
480 |
This commands (tries to) forcefully reboot a node. It is a command |
481 |
that can be used if the node environemnt is broken, such that the |
482 |
admin can no longer login over ssh, but the Ganeti node daemon is |
483 |
still working. |
484 |
|
485 |
Note that this command is not guaranteed to work; it depends on the |
486 |
hypervisor how effective is the reboot attempt. For Linux, this |
487 |
command require that the kernel option CONFIG\_MAGIC\_SYSRQ is |
488 |
enabled. |
489 |
|
490 |
The ``--yes`` option can be used to skip confirmation, while the |
491 |
``--force`` option is needed if the target node is the master |
492 |
node. |
493 |
|
494 |
POWER |
495 |
~~~~~ |
496 |
|
497 |
**power** [``--force``] [``--ignore-status``] [``--all``] |
498 |
[``--power-delay``] on|off|cycle|status [*nodes*] |
499 |
|
500 |
This commands calls out to out-of-band management to change the power |
501 |
state of given node. With ``status`` you get the power status as |
502 |
reported by the out-of-band management script. |
503 |
|
504 |
Using ``--force`` you skip the confirmation to do the operation. |
505 |
Currently this only has effect on ``off`` and ``cycle``. On those two |
506 |
you can *not* operate on the master. However, the command will provide |
507 |
you with the command to invoke to operate on the master nerver-mind. |
508 |
This is considered harmful and Ganeti does not support the use of it. |
509 |
|
510 |
Providing ``--ignore-status`` will ignore the offline=N state of a node |
511 |
and continue with power off. |
512 |
|
513 |
``--power-delay`` specifies the time in seconds (factions allowed) |
514 |
waited between powering on the next node. This is by default 2 seconds |
515 |
but can increased if needed with this option. |
516 |
|
517 |
*nodes* are optional. If not provided it will call out for every node in |
518 |
the cluster. Except for the ``off`` and ``cycle`` command where you've |
519 |
to explicit use ``--all`` to select all. |
520 |
|
521 |
|
522 |
HEALTH |
523 |
~~~~~~ |
524 |
|
525 |
**health** [*nodes*] |
526 |
|
527 |
This commands calls out to out-pf-band management to ask for the health status |
528 |
of all or given nodes. The health contains the node name and then the items |
529 |
element with their status in a ``item=status`` manner. Where ``item`` is script |
530 |
specific and ``status`` can be one of ``OK``, ``WARNING``, ``CRITICAL`` or |
531 |
``UNKNOWN``. Items with status ``WARNING`` or ``CRITICAL`` are logged and |
532 |
annotated in the command line output. |