root / man / gnt-node.sgml @ c70e1a9f
History | View | Annotate | Download (35.9 kB)
1 |
<!doctype refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [ |
---|---|
2 |
|
3 |
<!-- Fill in your name for FIRSTNAME and SURNAME. --> |
4 |
<!-- Please adjust the date whenever revising the manpage. --> |
5 |
<!ENTITY dhdate "<date>June 08, 2010</date>"> |
6 |
<!-- SECTION should be 1-8, maybe w/ subsection other parameters are |
7 |
allowed: see man(7), man(1). --> |
8 |
<!ENTITY dhsection "<manvolnum>8</manvolnum>"> |
9 |
<!ENTITY dhucpackage "<refentrytitle>gnt-node</refentrytitle>"> |
10 |
<!ENTITY dhpackage "gnt-node"> |
11 |
|
12 |
<!ENTITY debian "<productname>Debian</productname>"> |
13 |
<!ENTITY gnu "<acronym>GNU</acronym>"> |
14 |
<!ENTITY gpl "&gnu; <acronym>GPL</acronym>"> |
15 |
<!ENTITY footer SYSTEM "footer.sgml"> |
16 |
]> |
17 |
|
18 |
<refentry> |
19 |
<refentryinfo> |
20 |
<copyright> |
21 |
<year>2006</year> |
22 |
<year>2007</year> |
23 |
<year>2008</year> |
24 |
<year>2009</year> |
25 |
<holder>Google Inc.</holder> |
26 |
</copyright> |
27 |
&dhdate; |
28 |
</refentryinfo> |
29 |
<refmeta> |
30 |
&dhucpackage; |
31 |
|
32 |
&dhsection; |
33 |
<refmiscinfo>Ganeti 2.2</refmiscinfo> |
34 |
</refmeta> |
35 |
<refnamediv> |
36 |
<refname>&dhpackage;</refname> |
37 |
|
38 |
<refpurpose>Node administration</refpurpose> |
39 |
</refnamediv> |
40 |
<refsynopsisdiv> |
41 |
<cmdsynopsis> |
42 |
<command>&dhpackage; </command> |
43 |
|
44 |
<arg choice="req">command</arg> |
45 |
<arg>arguments...</arg> |
46 |
</cmdsynopsis> |
47 |
</refsynopsisdiv> |
48 |
<refsect1> |
49 |
<title>DESCRIPTION</title> |
50 |
|
51 |
<para> |
52 |
The <command>&dhpackage;</command> is used for managing the |
53 |
(physical) nodes in the Ganeti system. |
54 |
</para> |
55 |
|
56 |
</refsect1> |
57 |
<refsect1> |
58 |
<title>COMMANDS</title> |
59 |
|
60 |
<refsect2> |
61 |
<title>ADD</title> |
62 |
|
63 |
<cmdsynopsis> |
64 |
<command>add</command> |
65 |
<arg>--readd</arg> |
66 |
<arg>-s <replaceable>secondary_ip</replaceable></arg> |
67 |
<arg>-g <replaceable>nodegroup</replaceable></arg> |
68 |
<arg>--master-capable=<option>yes|no</option></arg> |
69 |
<arg>--vm-capable=<option>yes|no</option></arg> |
70 |
<arg choice="req"><replaceable>nodename</replaceable></arg> |
71 |
</cmdsynopsis> |
72 |
|
73 |
<para> |
74 |
Adds the given node to the cluster. |
75 |
</para> |
76 |
|
77 |
<para> |
78 |
This command is used to join a new node to the cluster. You |
79 |
will have to provide the password for root of the node to be |
80 |
able to add the node in the cluster. The command needs to be |
81 |
run on the Ganeti master. |
82 |
</para> |
83 |
|
84 |
<para> |
85 |
Note that the command is potentially destructive, as it will |
86 |
forcibly join the specified host the cluster, not paying |
87 |
attention to its current status (it could be already in a |
88 |
cluster, etc.) |
89 |
</para> |
90 |
|
91 |
<para> |
92 |
The <option>-s</option> is used in dual-home clusters and |
93 |
specifies the new node's IP in the secondary network. See the |
94 |
discussion in <citerefentry> |
95 |
<refentrytitle>gnt-cluster</refentrytitle> |
96 |
<manvolnum>8</manvolnum> </citerefentry> for more |
97 |
information. |
98 |
</para> |
99 |
|
100 |
<para> |
101 |
In case you're readding a node after hardware failure, you can |
102 |
use the <option>--readd</option> parameter. In this case, you |
103 |
don't need to pass the secondary IP again, it will reused from |
104 |
the cluster. Also, the <literal>drained</literal> and |
105 |
<literal>offline</literal> flags of the node will be cleared |
106 |
before re-adding it. |
107 |
</para> |
108 |
|
109 |
<para> |
110 |
The <option>-g</option> is used to add the new node into a specific |
111 |
node group, specified by uuid or name. If only one node group exists |
112 |
you can skip this option, otherwise it's mandatory. |
113 |
</para> |
114 |
|
115 |
<para> |
116 |
The <option>vm_capable</option> |
117 |
and <option>master_capable</option> options are described |
118 |
in <citerefentry><refentrytitle>ganeti</refentrytitle><manvolnum>7</manvolnum></citerefentry>, |
119 |
and are used to set the properties of the new node. |
120 |
</para> |
121 |
|
122 |
<para> |
123 |
Example: |
124 |
<screen> |
125 |
# gnt-node add node5.example.com |
126 |
# gnt-node add -s 192.0.2.5 node5.example.com |
127 |
# gnt-node add -g group2 -s 192.0.2.9 node9.group2.example.com |
128 |
</screen> |
129 |
</para> |
130 |
</refsect2> |
131 |
|
132 |
<refsect2> |
133 |
<title>ADD-TAGS</title> |
134 |
|
135 |
<cmdsynopsis> |
136 |
<command>add-tags</command> |
137 |
<arg choice="opt">--from <replaceable>file</replaceable></arg> |
138 |
<arg choice="req"><replaceable>nodename</replaceable></arg> |
139 |
<arg choice="req" |
140 |
rep="repeat"><replaceable>tag</replaceable></arg> |
141 |
</cmdsynopsis> |
142 |
|
143 |
<para> |
144 |
Add tags to the given node. If any of the tags contains |
145 |
invalid characters, the entire operation will abort. |
146 |
</para> |
147 |
|
148 |
<para> |
149 |
If the <option>--from</option> option is given, the list of |
150 |
tags will be extended with the contents of that file (each |
151 |
line becomes a tag). In this case, there is not need to pass |
152 |
tags on the command line (if you do, both sources will be |
153 |
used). A file name of - will be interpreted as stdin. |
154 |
</para> |
155 |
</refsect2> |
156 |
|
157 |
<refsect2> |
158 |
<title>EVACUATE</title> |
159 |
|
160 |
<cmdsynopsis> |
161 |
<command>evacuate</command> |
162 |
<arg>-f</arg> |
163 |
<arg>--early-release</arg> |
164 |
<group> |
165 |
<arg>--iallocator <replaceable>NAME</replaceable></arg> |
166 |
<arg>--new-secondary <replaceable>destination_node</replaceable></arg> |
167 |
</group> |
168 |
<arg choice="req" rep="repeat"><replaceable>node</replaceable></arg> |
169 |
</cmdsynopsis> |
170 |
|
171 |
<para> |
172 |
This command will move all secondary instances away from the |
173 |
given node(s). It works only for instances having a drbd disk |
174 |
template. |
175 |
</para> |
176 |
|
177 |
<para> |
178 |
The new location for the instances can be specified in two ways: |
179 |
<itemizedlist> |
180 |
<listitem> |
181 |
<simpara>as a single node for all instances, via the |
182 |
<option>--new-secondary</option> option</simpara> |
183 |
</listitem> |
184 |
<listitem> |
185 |
<simpara>or via the <option>--iallocator</option> option, |
186 |
giving a script name as parameter, so each instance will |
187 |
be in turn placed on the (per the script) optimal |
188 |
node</simpara> |
189 |
</listitem> |
190 |
</itemizedlist> |
191 |
</para> |
192 |
|
193 |
<para> |
194 |
The <option>--early-release</option> changes the code so that |
195 |
the old storage on node being evacuated is removed early |
196 |
(before the resync is completed) and the internal Ganeti locks |
197 |
are also released for both the current secondary and the new |
198 |
secondary, thus allowing more parallelism in the cluster |
199 |
operation. This should be used only when recovering from a |
200 |
disk failure on the current secondary (thus the old storage is |
201 |
already broken) or when the storage on the primary node is |
202 |
known to be fine (thus we won't need the old storage for |
203 |
potential recovery). |
204 |
</para> |
205 |
|
206 |
<para> |
207 |
Example: |
208 |
<screen> |
209 |
# gnt-node evacuate -I dumb node3.example.com |
210 |
</screen> |
211 |
</para> |
212 |
</refsect2> |
213 |
|
214 |
<refsect2> |
215 |
<title>FAILOVER</title> |
216 |
|
217 |
<cmdsynopsis> |
218 |
<command>failover</command> |
219 |
<arg>-f</arg> |
220 |
<arg>--ignore-consistency</arg> |
221 |
<arg choice="req"><replaceable>node</replaceable></arg> |
222 |
</cmdsynopsis> |
223 |
|
224 |
<para> |
225 |
This command will fail over all instances having the given |
226 |
node as primary to their secondary nodes. This works only for |
227 |
instances having a drbd disk template. |
228 |
</para> |
229 |
|
230 |
<para> |
231 |
Normally the failover will check the consistency of the disks |
232 |
before failing over the instance. If you are trying to migrate |
233 |
instances off a dead node, this will fail. Use the |
234 |
<option>--ignore-consistency</option> option for this purpose. |
235 |
</para> |
236 |
|
237 |
<para> |
238 |
Example: |
239 |
<screen> |
240 |
# gnt-node failover node1.example.com |
241 |
</screen> |
242 |
</para> |
243 |
</refsect2> |
244 |
|
245 |
<refsect2> |
246 |
<title>INFO</title> |
247 |
|
248 |
<cmdsynopsis> |
249 |
<command>info</command> |
250 |
<arg rep="repeat"><replaceable>node</replaceable></arg> |
251 |
</cmdsynopsis> |
252 |
|
253 |
<para> |
254 |
Show detailed information about the nodes in the cluster. If you |
255 |
don't give any arguments, all nodes will be shows, otherwise the |
256 |
output will be restricted to the given names. |
257 |
</para> |
258 |
</refsect2> |
259 |
|
260 |
<refsect2> |
261 |
<title>LIST</title> |
262 |
|
263 |
<cmdsynopsis> |
264 |
<command>list</command> |
265 |
<arg>--sync</arg> |
266 |
<sbr> |
267 |
<arg>--no-headers</arg> |
268 |
<arg>--separator=<replaceable>SEPARATOR</replaceable></arg> |
269 |
<sbr> |
270 |
<arg>--units=<replaceable>UNITS</replaceable></arg> |
271 |
<arg>-o <replaceable>[+]FIELD,...</replaceable></arg> |
272 |
<sbr> |
273 |
<arg>--roman</arg> |
274 |
<sbr> |
275 |
<arg rep="repeat">node</arg> |
276 |
</cmdsynopsis> |
277 |
|
278 |
<para> |
279 |
Lists the nodes in the cluster. |
280 |
</para> |
281 |
|
282 |
<para> |
283 |
The <option>--no-headers</option> option will skip the initial |
284 |
header line. The <option>--separator</option> option takes an |
285 |
argument which denotes what will be used between the output |
286 |
fields. Both these options are to help scripting. |
287 |
</para> |
288 |
|
289 |
<para> |
290 |
The units used to display the numeric values in the output |
291 |
varies, depending on the options given. By default, the values |
292 |
will be formatted in the most appropriate unit. If the |
293 |
<option>--separator</option> option is given, then the values |
294 |
are shown in mebibytes to allow parsing by scripts. In both |
295 |
cases, the <option>--units</option> option can be used to |
296 |
enforce a given output unit. |
297 |
</para> |
298 |
|
299 |
<para> |
300 |
By default, the query of nodes will be done in parallel with |
301 |
any running jobs. This might give inconsistent results for the |
302 |
free disk/memory. The <option>--sync</option> can be used to |
303 |
grab locks for all the nodes and ensure consistent view of the |
304 |
cluster (but this might stall the query for a long time). |
305 |
</para> |
306 |
|
307 |
<para> |
308 |
Passing the <option>--roman</option> option gnt-node list will try to |
309 |
output some of its fields in a latin-friendly way. This is not the |
310 |
default for backwards compatibility. |
311 |
</para> |
312 |
|
313 |
<para> |
314 |
The <option>-o</option> option takes a comma-separated list of |
315 |
output fields. The available fields and their meaning are: |
316 |
<variablelist> |
317 |
<varlistentry> |
318 |
<term>name</term> |
319 |
<listitem> |
320 |
<simpara>the node name</simpara> |
321 |
</listitem> |
322 |
</varlistentry> |
323 |
<varlistentry> |
324 |
<term>pinst_cnt</term> |
325 |
<listitem> |
326 |
<simpara>the number of instances having this node as |
327 |
primary</simpara> |
328 |
</listitem> |
329 |
</varlistentry> |
330 |
<varlistentry> |
331 |
<term>pinst_list</term> |
332 |
<listitem> |
333 |
<simpara>the list of instances having this node as |
334 |
primary, comma separated</simpara> |
335 |
</listitem> |
336 |
</varlistentry> |
337 |
<varlistentry> |
338 |
<term>sinst_cnt</term> |
339 |
<listitem> |
340 |
<simpara>the number of instances having this node as a |
341 |
secondary node</simpara> |
342 |
</listitem> |
343 |
</varlistentry> |
344 |
<varlistentry> |
345 |
<term>sinst_list</term> |
346 |
<listitem> |
347 |
<simpara>the list of instances having this node as a |
348 |
secondary node, comma separated</simpara> |
349 |
</listitem> |
350 |
</varlistentry> |
351 |
<varlistentry> |
352 |
<term>pip</term> |
353 |
<listitem> |
354 |
<simpara>the primary ip of this node (used for cluster |
355 |
communication)</simpara> |
356 |
</listitem> |
357 |
</varlistentry> |
358 |
<varlistentry> |
359 |
<term>sip</term> |
360 |
<listitem> |
361 |
<simpara> |
362 |
the secondary ip of this node (used for data |
363 |
replication in dual-ip clusters, see <citerefentry> |
364 |
<refentrytitle>gnt-cluster</refentrytitle> |
365 |
<manvolnum>8</manvolnum> |
366 |
</citerefentry> |
367 |
</simpara> |
368 |
</listitem> |
369 |
</varlistentry> |
370 |
<varlistentry> |
371 |
<term>dtotal</term> |
372 |
<listitem> |
373 |
<simpara>total disk space in the volume group used for |
374 |
instance disk allocations</simpara> |
375 |
</listitem> |
376 |
</varlistentry> |
377 |
<varlistentry> |
378 |
<term>dfree</term> |
379 |
<listitem> |
380 |
<simpara>available disk space in the volume group</simpara> |
381 |
</listitem> |
382 |
</varlistentry> |
383 |
<varlistentry> |
384 |
<term>mtotal</term> |
385 |
<listitem> |
386 |
<simpara>total memory on the physical node</simpara> |
387 |
</listitem> |
388 |
</varlistentry> |
389 |
<varlistentry> |
390 |
<term>mnode</term> |
391 |
<listitem> |
392 |
<simpara>the memory used by the node itself</simpara> |
393 |
</listitem> |
394 |
</varlistentry> |
395 |
<varlistentry> |
396 |
<term>mfree</term> |
397 |
<listitem> |
398 |
<simpara>memory available for instance |
399 |
allocations</simpara> |
400 |
</listitem> |
401 |
</varlistentry> |
402 |
<varlistentry> |
403 |
<term>bootid</term> |
404 |
<listitem> |
405 |
<simpara>the node bootid value; this is a linux specific |
406 |
feature that assigns a new UUID to the node at each boot |
407 |
and can be use to detect node reboots (by tracking |
408 |
changes in this value)</simpara> |
409 |
</listitem> |
410 |
</varlistentry> |
411 |
<varlistentry> |
412 |
<term>tags</term> |
413 |
<listitem> |
414 |
<simpara>comma-separated list of the node's |
415 |
tags</simpara> |
416 |
</listitem> |
417 |
</varlistentry> |
418 |
<varlistentry> |
419 |
<term>serial_no</term> |
420 |
<listitem> |
421 |
<simpara>the so called 'serial number' of the node; |
422 |
this is a numeric field that is incremented each time |
423 |
the node is modified, and it can be used to detect |
424 |
modifications</simpara> |
425 |
</listitem> |
426 |
</varlistentry> |
427 |
<varlistentry> |
428 |
<term>ctime</term> |
429 |
<listitem> |
430 |
<para> |
431 |
the creation time of the node; note that this field |
432 |
contains spaces and as such it's harder to parse |
433 |
</para> |
434 |
<para> |
435 |
if this attribute is not present (e.g. when upgrading |
436 |
from older versions), then "N/A" will be shown instead |
437 |
</para> |
438 |
</listitem> |
439 |
</varlistentry> |
440 |
<varlistentry> |
441 |
<term>mtime</term> |
442 |
<listitem> |
443 |
<para> |
444 |
the last modification time of the node; note that this |
445 |
field contains spaces and as such it's harder to parse |
446 |
</para> |
447 |
<para> |
448 |
if this attribute is not present (e.g. when upgrading |
449 |
from older versions), then "N/A" will be shown instead |
450 |
</para> |
451 |
</listitem> |
452 |
</varlistentry> |
453 |
<varlistentry> |
454 |
<term>uuid</term> |
455 |
<listitem> |
456 |
<simpara>Show the UUID of the node (generated |
457 |
automatically by Ganeti)</simpara> |
458 |
</listitem> |
459 |
</varlistentry> |
460 |
|
461 |
<varlistentry> |
462 |
<term>ctotal</term> |
463 |
<listitem> |
464 |
<simpara>the toal number of logical processors</simpara> |
465 |
</listitem> |
466 |
</varlistentry> |
467 |
<varlistentry> |
468 |
<term>cnodes</term> |
469 |
<listitem> |
470 |
<simpara>the number of NUMA domains on the node, if the |
471 |
hypervisor can export this information</simpara> |
472 |
</listitem> |
473 |
</varlistentry> |
474 |
<varlistentry> |
475 |
<term>csockets</term> |
476 |
<listitem> |
477 |
<simpara>the number of physical CPU sockets, if the |
478 |
hypervisor can export this information</simpara> |
479 |
</listitem> |
480 |
</varlistentry> |
481 |
<varlistentry> |
482 |
<term>master_candidate</term> |
483 |
<listitem> |
484 |
<simpara>whether the node is a master candidate or not</simpara> |
485 |
</listitem> |
486 |
</varlistentry> |
487 |
<varlistentry> |
488 |
<term>drained</term> |
489 |
<listitem> |
490 |
<simpara>whether the node is drained or not; the cluster |
491 |
still communicates with drained nodes but excludes them |
492 |
from allocation operations</simpara> |
493 |
</listitem> |
494 |
</varlistentry> |
495 |
<varlistentry> |
496 |
<term>offline</term> |
497 |
<listitem> |
498 |
<simpara>whether the node is offline or not; if offline, |
499 |
the cluster does not communicate with offline nodes; |
500 |
useful for nodes that are not reachable in order to |
501 |
avoid delays</simpara> |
502 |
</listitem> |
503 |
</varlistentry> |
504 |
<varlistentry> |
505 |
<term>role</term> |
506 |
<listitem> |
507 |
<para> |
508 |
A condensed version of the node flags; this field will |
509 |
output a one-character field, with the following |
510 |
possible values: |
511 |
<itemizedlist> |
512 |
<listitem> |
513 |
<simpara><emphasis>M</emphasis> for the master |
514 |
node</simpara> |
515 |
</listitem> |
516 |
<listitem> |
517 |
<simpara><emphasis>C</emphasis> for a master |
518 |
candidate</simpara> |
519 |
</listitem> |
520 |
<listitem> |
521 |
<simpara><emphasis>R</emphasis> for a regular |
522 |
node</simpara> |
523 |
</listitem> |
524 |
<listitem> |
525 |
<simpara><emphasis>D</emphasis> for a drained |
526 |
node</simpara> |
527 |
</listitem> |
528 |
<listitem> |
529 |
<simpara><emphasis>O</emphasis> for an offline |
530 |
node</simpara> |
531 |
</listitem> |
532 |
</itemizedlist> |
533 |
</para> |
534 |
</listitem> |
535 |
</varlistentry> |
536 |
<varlistentry> |
537 |
<term>master_capable</term> |
538 |
<listitem> |
539 |
<para>whether the node can become a master candidate</para> |
540 |
</listitem> |
541 |
</varlistentry> |
542 |
<varlistentry> |
543 |
<term>vm_capable</term> |
544 |
<listitem> |
545 |
<para>whether the node can host instances</para> |
546 |
</listitem> |
547 |
</varlistentry> |
548 |
<varlistentry> |
549 |
<term>group</term> |
550 |
<listitem> |
551 |
<para>the name of the node's group, if known (the query |
552 |
is done without locking, so data consistency is not |
553 |
guaranteed)</para> |
554 |
</listitem> |
555 |
</varlistentry> |
556 |
<varlistentry> |
557 |
<term>group.uuid</term> |
558 |
<listitem> |
559 |
<para>the UUID of the node's group</para> |
560 |
</listitem> |
561 |
</varlistentry> |
562 |
</variablelist> |
563 |
</para> |
564 |
|
565 |
<para> |
566 |
If the value of the option starts with the character |
567 |
<constant>+</constant>, the new fields will be added to the |
568 |
default list. This allows to quickly see the default list plus |
569 |
a few other fields, instead of retyping the entire list of |
570 |
fields. |
571 |
</para> |
572 |
|
573 |
<para> |
574 |
Note that some of this fields are known from the configuration |
575 |
of the cluster (e.g. <simplelist type="inline"> |
576 |
<member>name</member> <member>pinst</member> |
577 |
<member>sinst</member> <member>pip</member> |
578 |
<member>sip</member> </simplelist> and thus the master does |
579 |
not need to contact the node for this data (making the listing |
580 |
fast if only fields from this set are selected), whereas the |
581 |
other fields are "live" fields and we need to make a query to |
582 |
the cluster nodes. |
583 |
</para> |
584 |
|
585 |
<para> |
586 |
Depending on the virtualization type and implementation |
587 |
details, the mtotal, mnode and mfree may have slighly varying |
588 |
meanings. For example, some solutions share the node memory |
589 |
with the pool of memory used for instances |
590 |
(<acronym>KVM</acronym>), whereas others have separate memory |
591 |
for the node and for the instances (Xen). |
592 |
</para> |
593 |
|
594 |
<para> |
595 |
If no node names are given, then all nodes are |
596 |
queried. Otherwise, only the given nodes will be listed. |
597 |
</para> |
598 |
</refsect2> |
599 |
|
600 |
<refsect2> |
601 |
<title>LIST-TAGS</title> |
602 |
|
603 |
<cmdsynopsis> |
604 |
<command>list-tags</command> |
605 |
<arg choice="req"><replaceable>nodename</replaceable></arg> |
606 |
</cmdsynopsis> |
607 |
|
608 |
<para>List the tags of the given node.</para> |
609 |
</refsect2> |
610 |
|
611 |
<refsect2> |
612 |
<title>MIGRATE</title> |
613 |
<cmdsynopsis> |
614 |
<command>migrate</command> |
615 |
<arg>-f</arg> |
616 |
<arg>--non-live</arg> |
617 |
<arg>--migration-mode=live|non-live</arg> |
618 |
<arg choice="req"><replaceable>node</replaceable></arg> |
619 |
</cmdsynopsis> |
620 |
|
621 |
<para> |
622 |
This command will migrate all instances having the given |
623 |
node as primary to their secondary nodes. This works only for |
624 |
instances having a drbd disk template. |
625 |
</para> |
626 |
|
627 |
<para> |
628 |
As for the <command>gnt-instance migrate</command> command, |
629 |
the options <option>--no-live</option> |
630 |
and <option>--migration-mode</option> can be given to |
631 |
influence the migration type. |
632 |
</para> |
633 |
|
634 |
<para> |
635 |
Example: |
636 |
<screen> |
637 |
# gnt-node migrate node1.example.com |
638 |
</screen> |
639 |
</para> |
640 |
|
641 |
</refsect2> |
642 |
|
643 |
<refsect2> |
644 |
<title>MODIFY</title> |
645 |
<cmdsynopsis> |
646 |
<command>modify</command> |
647 |
<arg>-f</arg> |
648 |
<arg>--submit</arg> |
649 |
<arg>--master-candidate=<option>yes|no</option></arg> |
650 |
<arg>--drained=<option>yes|no</option></arg> |
651 |
<arg>--offline=<option>yes|no</option></arg> |
652 |
<arg>--master-capable=<option>yes|no</option></arg> |
653 |
<arg>--vm-capable=<option>yes|no</option></arg> |
654 |
<arg>-s <replaceable>secondary_ip</replaceable></arg> |
655 |
<arg>--auto-promote</arg> |
656 |
<arg choice="req"><replaceable>node</replaceable></arg> |
657 |
</cmdsynopsis> |
658 |
|
659 |
<para> |
660 |
This command changes the role of the node. Each options takes |
661 |
either a literal <literal>yes</literal> or |
662 |
<literal>no</literal>, and only one option should be given as |
663 |
<literal>yes</literal>. The meaning of the roles and flags are |
664 |
described in the manpage <citerefentry> |
665 |
<refentrytitle>ganeti</refentrytitle> <manvolnum>7</manvolnum> |
666 |
</citerefentry>. |
667 |
</para> |
668 |
|
669 |
<para> |
670 |
In case a node is demoted from the master candidate role, the |
671 |
operation will be refused unless you pass |
672 |
the <option>--auto-promote</option> option. This option will |
673 |
cause the operation to lock all cluster nodes (thus it will |
674 |
not be able to run in parallel with most other jobs), but it |
675 |
allows automated maintenance of the cluster candidate pool. If |
676 |
locking all cluster node is too expensive, another option is |
677 |
to promote manually another node to master candidate before |
678 |
demoting the current one. |
679 |
</para> |
680 |
|
681 |
<para> |
682 |
Example (setting a node offline, which will demote it from |
683 |
master candidate role if is in that role): |
684 |
<screen> |
685 |
# gnt-node modify --offline=yes node1.example.com |
686 |
</screen> |
687 |
</para> |
688 |
|
689 |
<para> |
690 |
The <option>-s</option> can be used to change the node's secondary ip. |
691 |
No drbd instances can be running on the node, while this operation is |
692 |
taking place. |
693 |
</para> |
694 |
|
695 |
<para>Example (setting the node back to online and master candidate): |
696 |
<screen> |
697 |
# gnt-node modify --offline=no --master-candidate=yes node1.example.com |
698 |
</screen> |
699 |
</para> |
700 |
|
701 |
</refsect2> |
702 |
|
703 |
<refsect2> |
704 |
<title>REMOVE</title> |
705 |
|
706 |
<cmdsynopsis> |
707 |
<command>remove</command> |
708 |
<arg choice="req"><replaceable>nodename</replaceable></arg> |
709 |
</cmdsynopsis> |
710 |
|
711 |
<para> |
712 |
Removes a node from the cluster. Instances must be removed or |
713 |
migrated to another cluster before. |
714 |
</para> |
715 |
|
716 |
<para> |
717 |
Example: |
718 |
<screen> |
719 |
# gnt-node remove node5.example.com |
720 |
</screen> |
721 |
</para> |
722 |
</refsect2> |
723 |
|
724 |
<refsect2> |
725 |
<title>REMOVE-TAGS</title> |
726 |
<cmdsynopsis> |
727 |
<command>remove-tags</command> |
728 |
<arg choice="opt">--from <replaceable>file</replaceable></arg> |
729 |
<arg choice="req"><replaceable>nodename</replaceable></arg> |
730 |
<arg choice="req" |
731 |
rep="repeat"><replaceable>tag</replaceable></arg> |
732 |
</cmdsynopsis> |
733 |
|
734 |
<para> |
735 |
Remove tags from the given node. If any of the tags are not |
736 |
existing on the node, the entire operation will abort. |
737 |
</para> |
738 |
|
739 |
<para> |
740 |
If the <option>--from</option> option is given, the list of |
741 |
tags will be extended with the contents of that file (each |
742 |
line becomes a tag). In this case, there is not need to pass |
743 |
tags on the command line (if you do, both sources will be |
744 |
used). A file name of - will be interpreted as stdin. |
745 |
</para> |
746 |
</refsect2> |
747 |
|
748 |
<refsect2> |
749 |
<title>VOLUMES</title> |
750 |
|
751 |
<cmdsynopsis> |
752 |
<command>volumes</command> |
753 |
<arg>--no-headers</arg> |
754 |
<arg>--human-readable</arg> |
755 |
<arg>--separator=<replaceable>SEPARATOR</replaceable></arg> |
756 |
<arg>--output=<replaceable>FIELDS</replaceable></arg> |
757 |
<sbr> |
758 |
<arg rep="repeat"><replaceable>node</replaceable></arg> |
759 |
</cmdsynopsis> |
760 |
|
761 |
<para> |
762 |
Lists all logical volumes and their physical disks from the node(s) |
763 |
provided. |
764 |
</para> |
765 |
|
766 |
<para> |
767 |
The <option>--no-headers</option> option will skip the initial |
768 |
header line. The <option>--separator</option> option takes an |
769 |
argument which denotes what will be used between the output |
770 |
fields. Both these options are to help scripting. |
771 |
</para> |
772 |
|
773 |
<para> |
774 |
The units used to display the numeric values in the output |
775 |
varies, depending on the options given. By default, the values |
776 |
will be formatted in the most appropriate unit. If the |
777 |
<option>--separator</option> option is given, then the values |
778 |
are shown in mebibytes to allow parsing by scripts. In both |
779 |
cases, the <option>--units</option> option can be used to |
780 |
enforce a given output unit. |
781 |
</para> |
782 |
|
783 |
<para> |
784 |
The <option>-o</option> option takes a comma-separated list of |
785 |
output fields. The available fields and their meaning are: |
786 |
<variablelist> |
787 |
<varlistentry> |
788 |
<term>node</term> |
789 |
<listitem> |
790 |
<simpara>the node name on which the volume exists</simpara> |
791 |
</listitem> |
792 |
</varlistentry> |
793 |
<varlistentry> |
794 |
<term>phys</term> |
795 |
<listitem> |
796 |
<simpara>the physical drive (on which the LVM physical |
797 |
volume lives)</simpara> |
798 |
</listitem> |
799 |
</varlistentry> |
800 |
<varlistentry> |
801 |
<term>vg</term> |
802 |
<listitem> |
803 |
<simpara>the volume group name</simpara> |
804 |
</listitem> |
805 |
</varlistentry> |
806 |
<varlistentry> |
807 |
<term>name</term> |
808 |
<listitem> |
809 |
<simpara>the logical volume name</simpara> |
810 |
</listitem> |
811 |
</varlistentry> |
812 |
<varlistentry> |
813 |
<term>size</term> |
814 |
<listitem> |
815 |
<simpara>the logical volume size</simpara> |
816 |
</listitem> |
817 |
</varlistentry> |
818 |
<varlistentry> |
819 |
<term>instance</term> |
820 |
<listitem> |
821 |
<simpara>The name of the instance to which this volume |
822 |
belongs, or (in case it's an orphan volume) the |
823 |
character <quote>-</quote></simpara> |
824 |
</listitem> |
825 |
</varlistentry> |
826 |
</variablelist> |
827 |
</para> |
828 |
|
829 |
<para> |
830 |
Example: |
831 |
<screen> |
832 |
# gnt-node volumes node5.example.com |
833 |
Node PhysDev VG Name Size Instance |
834 |
node1.example.com /dev/hdc1 xenvg instance1.example.com-sda_11000.meta 128 instance1.example.com |
835 |
node1.example.com /dev/hdc1 xenvg instance1.example.com-sda_11001.data 256 instance1.example.com |
836 |
</screen> |
837 |
</para> |
838 |
</refsect2> |
839 |
|
840 |
<refsect2> |
841 |
<title>LIST-STORAGE</title> |
842 |
|
843 |
<cmdsynopsis> |
844 |
<command>list-storage</command> |
845 |
<arg>--no-headers</arg> |
846 |
<arg>--human-readable</arg> |
847 |
<arg>--separator=<replaceable>SEPARATOR</replaceable></arg> |
848 |
<arg>--storage-type=<replaceable>STORAGE_TYPE</replaceable></arg> |
849 |
<arg>--output=<replaceable>FIELDS</replaceable></arg> |
850 |
<sbr> |
851 |
<arg rep="repeat"><replaceable>node</replaceable></arg> |
852 |
</cmdsynopsis> |
853 |
|
854 |
<para> |
855 |
Lists the available storage units and their details for the |
856 |
given node(s). |
857 |
</para> |
858 |
|
859 |
<para> |
860 |
The <option>--no-headers</option> option will skip the initial header |
861 |
line. The <option>--separator</option> option takes an argument which |
862 |
denotes what will be used between the output fields. Both these options |
863 |
are to help scripting. |
864 |
</para> |
865 |
|
866 |
<para> |
867 |
The units used to display the numeric values in the output varies, |
868 |
depending on the options given. By default, the values will be |
869 |
formatted in the most appropriate unit. If the |
870 |
<option>--separator</option> option is given, then the values are shown |
871 |
in mebibytes to allow parsing by scripts. In both cases, the |
872 |
<option>--units</option> option can be used to enforce a given output |
873 |
unit. |
874 |
</para> |
875 |
|
876 |
<para> |
877 |
The <option>--storage-type</option> option can be used to choose a |
878 |
storage unit type. Possible choices are <literal>lvm-pv</literal>, |
879 |
<literal>lvm-vg</literal> or <literal>file</literal>. |
880 |
</para> |
881 |
|
882 |
<para> |
883 |
The <option>-o</option> option takes a comma-separated list of |
884 |
output fields. The available fields and their meaning are: |
885 |
<variablelist> |
886 |
<varlistentry> |
887 |
<term>node</term> |
888 |
<listitem> |
889 |
<simpara>the node name on which the volume exists</simpara> |
890 |
</listitem> |
891 |
</varlistentry> |
892 |
<varlistentry> |
893 |
<term>type</term> |
894 |
<listitem> |
895 |
<simpara>the type of the storage unit (currently just |
896 |
what is passed in via |
897 |
<option>--storage-type</option>)</simpara> |
898 |
</listitem> |
899 |
</varlistentry> |
900 |
<varlistentry> |
901 |
<term>name</term> |
902 |
<listitem> |
903 |
<simpara>the path/identifier of the storage unit</simpara> |
904 |
</listitem> |
905 |
</varlistentry> |
906 |
<varlistentry> |
907 |
<term>size</term> |
908 |
<listitem> |
909 |
<simpara> |
910 |
total size of the unit; for the file type see a note below |
911 |
</simpara> |
912 |
</listitem> |
913 |
</varlistentry> |
914 |
<varlistentry> |
915 |
<term>used</term> |
916 |
<listitem> |
917 |
<simpara> |
918 |
used space in the unit; for the file type see a note below |
919 |
</simpara> |
920 |
</listitem> |
921 |
</varlistentry> |
922 |
<varlistentry> |
923 |
<term>free</term> |
924 |
<listitem> |
925 |
<simpara> |
926 |
available disk space |
927 |
</simpara> |
928 |
</listitem> |
929 |
</varlistentry> |
930 |
<varlistentry> |
931 |
<term>allocatable</term> |
932 |
<listitem> |
933 |
<simpara> |
934 |
whether we the unit is available for allocation |
935 |
(only <literal>lvm-pv</literal> can change this |
936 |
setting, the other types always report true) |
937 |
</simpara> |
938 |
</listitem> |
939 |
</varlistentry> |
940 |
</variablelist> |
941 |
</para> |
942 |
|
943 |
<para> |
944 |
Note that for the <quote>file</quote> type, the total disk |
945 |
space might not equal to the sum of used and free, due to the |
946 |
method Ganeti uses to compute each of them. The total and free |
947 |
values are computed as the total and free space values for the |
948 |
filesystem to which the directory belongs, but the used space |
949 |
is computed from the used space under that directory |
950 |
<emphasis>only</emphasis>, which might not be necessarily the |
951 |
root of the filesystem, and as such there could be files |
952 |
outside the file storage directory using disk space and |
953 |
causing a mismatch in the values. |
954 |
</para> |
955 |
|
956 |
<para> |
957 |
Example: |
958 |
<screen> |
959 |
node1# gnt-node list-storage node2 |
960 |
Node Type Name Size Used Free Allocatable |
961 |
node2 lvm-pv /dev/sda7 673.8G 1.5G 672.3G Y |
962 |
node2 lvm-pv /dev/sdb1 698.6G 0M 698.6G Y |
963 |
</screen> |
964 |
</para> |
965 |
</refsect2> |
966 |
|
967 |
<refsect2> |
968 |
<title>MODIFY-STORAGE</title> |
969 |
|
970 |
<cmdsynopsis> |
971 |
<command>modify-storage</command> |
972 |
<arg><option>--allocatable=yes|no</option></arg> |
973 |
<sbr> |
974 |
<arg choice="req"><replaceable>node</replaceable></arg> |
975 |
<arg choice="req"><replaceable>storage-type</replaceable></arg> |
976 |
<arg choice="req"><replaceable>volume-name</replaceable></arg> |
977 |
</cmdsynopsis> |
978 |
|
979 |
<para> |
980 |
Modifies storage volumes on a node. Only LVM physical volumes |
981 |
can be modified at the moment. They have a storage type |
982 |
of <quote>lvm-pv</quote>. |
983 |
</para> |
984 |
|
985 |
<para> |
986 |
Example: |
987 |
<screen> |
988 |
# gnt-node modify-storage --allocatable no node5.example.com lvm-pv /dev/sdb1 |
989 |
</screen> |
990 |
</para> |
991 |
</refsect2> |
992 |
|
993 |
<refsect2> |
994 |
<title>REPAIR-STORAGE</title> |
995 |
|
996 |
<cmdsynopsis> |
997 |
<command>repair-storage</command> |
998 |
<arg>--ignore-consistency</arg> |
999 |
<arg choice="req"><replaceable>node</replaceable></arg> |
1000 |
<arg choice="req"><replaceable>storage-type</replaceable></arg> |
1001 |
<arg choice="req"><replaceable>volume-name</replaceable></arg> |
1002 |
</cmdsynopsis> |
1003 |
|
1004 |
<para> |
1005 |
Repairs a storage volume on a node. Only LVM volume groups can |
1006 |
be repaired at this time. They have the storage type |
1007 |
<quote>lvm-vg</quote>. |
1008 |
</para> |
1009 |
|
1010 |
<para> |
1011 |
On LVM volume groups, <command>repair-storage</command> runs |
1012 |
<quote>vgreduce --removemissing</quote>. |
1013 |
</para> |
1014 |
|
1015 |
<caution> |
1016 |
<para> |
1017 |
Running this command can lead to data loss. Use it with care. |
1018 |
</para> |
1019 |
</caution> |
1020 |
|
1021 |
<para> |
1022 |
The <option>--ignore-consistency</option> option will ignore |
1023 |
any inconsistent disks (on the nodes paired with this |
1024 |
one). Use of this option is most likely to lead to data-loss. |
1025 |
</para> |
1026 |
|
1027 |
<para> |
1028 |
Example: |
1029 |
<screen> |
1030 |
# gnt-node repair-storage node5.example.com lvm-vg xenvg |
1031 |
</screen> |
1032 |
</para> |
1033 |
</refsect2> |
1034 |
|
1035 |
<refsect2> |
1036 |
<title>POWERCYCLE</title> |
1037 |
|
1038 |
<cmdsynopsis> |
1039 |
<command>powercycle</command> |
1040 |
<arg><option>--yes</option></arg> |
1041 |
<arg><option>--force</option></arg> |
1042 |
<arg choice="req"><replaceable>node</replaceable></arg> |
1043 |
</cmdsynopsis> |
1044 |
|
1045 |
<para> |
1046 |
This commands (tries to) forcefully reboot a node. It is a |
1047 |
command that can be used if the node environemnt is broken, |
1048 |
such that the admin can no longer login over ssh, but the |
1049 |
Ganeti node daemon is still working. |
1050 |
</para> |
1051 |
|
1052 |
<para> |
1053 |
Note that this command is not guaranteed to work; it depends |
1054 |
on the hypervisor how effective is the reboot attempt. For |
1055 |
Linux, this command require that the kernel option |
1056 |
<literal>CONFIG_MAGIC_SYSRQ</literal> is enabled. |
1057 |
</para> |
1058 |
|
1059 |
<para> |
1060 |
The <option>--yes</option> option can be used to skip |
1061 |
confirmation, while the <option>--force</option> option is |
1062 |
needed if the target node is the master node. |
1063 |
</para> |
1064 |
|
1065 |
</refsect1> |
1066 |
|
1067 |
&footer; |
1068 |
|
1069 |
</refentry> |
1070 |
|
1071 |
<!-- Keep this comment at the end of the file |
1072 |
Local variables: |
1073 |
mode: sgml |
1074 |
sgml-omittag:t |
1075 |
sgml-shorttag:t |
1076 |
sgml-minimize-attributes:nil |
1077 |
sgml-always-quote-attributes:t |
1078 |
sgml-indent-step:2 |
1079 |
sgml-indent-data:t |
1080 |
sgml-parent-document:nil |
1081 |
sgml-default-dtd-file:nil |
1082 |
sgml-exposed-tags:nil |
1083 |
sgml-local-catalogs:nil |
1084 |
sgml-local-ecat-files:nil |
1085 |
End: |
1086 |
--> |