Revision 7db441e6
b/man/gnt-node.rst | ||
---|---|---|
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 |
{*nodename*} |
|
29 |
|
|
30 |
Adds the given node to the cluster. |
|
31 |
|
|
32 |
This command is used to join a new node to the cluster. You will |
|
33 |
have to provide the password for root of the node to be able to add |
|
34 |
the node in the cluster. The command needs to be run on the Ganeti |
|
35 |
master. |
|
36 |
|
|
37 |
Note that the command is potentially destructive, as it will |
|
38 |
forcibly join the specified host the cluster, not paying attention |
|
39 |
to its current status (it could be already in a cluster, etc.) |
|
40 |
|
|
41 |
The ``-s`` is used in dual-home clusters and specifies the new node's |
|
42 |
IP in the secondary network. See the discussion in **gnt-cluster**(8) |
|
43 |
for more information. |
|
44 |
|
|
45 |
In case you're readding a node after hardware failure, you can use |
|
46 |
the ``--readd`` parameter. In this case, you don't need to pass the |
|
47 |
secondary IP again, it will reused from the cluster. Also, the |
|
48 |
drained and offline flags of the node will be cleared before |
|
49 |
re-adding it. |
|
50 |
|
|
51 |
The ``-g`` is used to add the new node into a specific node group, |
|
52 |
specified by UUID or name. If only one node group exists you can |
|
53 |
skip this option, otherwise it's mandatory. |
|
54 |
|
|
55 |
The ``vm_capable`` and ``master_capable`` options are described in |
|
56 |
**ganeti**(7), and are used to set the properties of the new node. |
|
57 |
|
|
58 |
Example:: |
|
59 |
|
|
60 |
# gnt-node add node5.example.com |
|
61 |
# gnt-node add -s 192.0.2.5 node5.example.com |
|
62 |
# gnt-node add -g group2 -s 192.0.2.9 node9.group2.example.com |
|
63 |
|
|
64 |
|
|
65 |
ADD-TAGS |
|
66 |
~~~~~~~~ |
|
67 |
|
|
68 |
**add-tags** [--from *file*] {*nodename*} {*tag*...} |
|
69 |
|
|
70 |
Add tags to the given node. If any of the tags contains invalid |
|
71 |
characters, the entire operation will abort. |
|
72 |
|
|
73 |
If the ``--from`` option is given, the list of tags will be |
|
74 |
extended with the contents of that file (each line becomes a tag). |
|
75 |
In this case, there is not need to pass tags on the command line |
|
76 |
(if you do, both sources will be used). A file name of - will be |
|
77 |
interpreted as stdin. |
|
78 |
|
|
79 |
EVACUATE |
|
80 |
~~~~~~~~ |
|
81 |
|
|
82 |
**evacuate** [-f] [--early-release] [--iallocator *NAME* \| |
|
83 |
--new-secondary *destination\_node*] {*node*...} |
|
84 |
|
|
85 |
This command will move all secondary instances away from the given |
|
86 |
node(s). It works only for instances having a drbd disk template. |
|
87 |
|
|
88 |
The new location for the instances can be specified in two ways: |
|
89 |
|
|
90 |
- as a single node for all instances, via the ``--new-secondary`` |
|
91 |
option |
|
92 |
|
|
93 |
- or via the ``--iallocator`` option, giving a script name as |
|
94 |
parameter, so each instance will be in turn placed on the (per the |
|
95 |
script) optimal node |
|
96 |
|
|
97 |
|
|
98 |
The ``--early-release`` changes the code so that the old storage on |
|
99 |
node being evacuated is removed early (before the resync is |
|
100 |
completed) and the internal Ganeti locks are also released for both |
|
101 |
the current secondary and the new secondary, thus allowing more |
|
102 |
parallelism in the cluster operation. This should be used only when |
|
103 |
recovering from a disk failure on the current secondary (thus the |
|
104 |
old storage is already broken) or when the storage on the primary |
|
105 |
node is known to be fine (thus we won't need the old storage for |
|
106 |
potential recovery). |
|
107 |
|
|
108 |
Example:: |
|
109 |
|
|
110 |
# gnt-node evacuate -I dumb node3.example.com |
|
111 |
|
|
112 |
|
|
113 |
FAILOVER |
|
114 |
~~~~~~~~ |
|
115 |
|
|
116 |
**failover** [-f] [--ignore-consistency] {*node*} |
|
117 |
|
|
118 |
This command will fail over all instances having the given node as |
|
119 |
primary to their secondary nodes. This works only for instances having |
|
120 |
a drbd disk template. |
|
121 |
|
|
122 |
Normally the failover will check the consistency of the disks before |
|
123 |
failing over the instance. If you are trying to migrate instances off |
|
124 |
a dead node, this will fail. Use the ``--ignore-consistency`` option |
|
125 |
for this purpose. |
|
126 |
|
|
127 |
Example:: |
|
128 |
|
|
129 |
# gnt-node failover node1.example.com |
|
130 |
|
|
131 |
|
|
132 |
INFO |
|
133 |
~~~~ |
|
134 |
|
|
135 |
**info** [*node*...] |
|
136 |
|
|
137 |
Show detailed information about the nodes in the cluster. If you |
|
138 |
don't give any arguments, all nodes will be shows, otherwise the |
|
139 |
output will be restricted to the given names. |
|
140 |
|
|
141 |
LIST |
|
142 |
~~~~ |
|
143 |
|
|
144 |
| **list** [--sync] |
|
145 |
| [--no-headers] [--separator=*SEPARATOR*] |
|
146 |
| [--units=*UNITS*] [-o *[+]FIELD,...*] |
|
147 |
| [--roman] |
|
148 |
| [node...] |
|
149 |
|
|
150 |
Lists the nodes in the cluster. |
|
151 |
|
|
152 |
The ``--no-headers`` option will skip the initial header line. The |
|
153 |
``--separator`` option takes an argument which denotes what will be |
|
154 |
used between the output fields. Both these options are to help |
|
155 |
scripting. |
|
156 |
|
|
157 |
The units used to display the numeric values in the output varies, |
|
158 |
depending on the options given. By default, the values will be |
|
159 |
formatted in the most appropriate unit. If the ``--separator`` |
|
160 |
option is given, then the values are shown in mebibytes to allow |
|
161 |
parsing by scripts. In both cases, the ``--units`` option can be |
|
162 |
used to enforce a given output unit. |
|
163 |
|
|
164 |
By default, the query of nodes will be done in parallel with any |
|
165 |
running jobs. This might give inconsistent results for the free |
|
166 |
disk/memory. The ``--sync`` can be used to grab locks for all the |
|
167 |
nodes and ensure consistent view of the cluster (but this might |
|
168 |
stall the query for a long time). |
|
169 |
|
|
170 |
Passing the ``--roman`` option gnt-node list will try to output |
|
171 |
some of its fields in a latin-friendly way. This is not the default |
|
172 |
for backwards compatibility. |
|
173 |
|
|
174 |
The ``-o`` option takes a comma-separated list of output fields. |
|
175 |
The available fields and their meaning are: |
|
176 |
|
|
177 |
|
|
178 |
|
|
179 |
name |
|
180 |
the node name |
|
181 |
|
|
182 |
pinst_cnt |
|
183 |
the number of instances having this node as primary |
|
184 |
|
|
185 |
pinst_list |
|
186 |
the list of instances having this node as primary, comma separated |
|
187 |
|
|
188 |
sinst_cnt |
|
189 |
the number of instances having this node as a secondary node |
|
190 |
|
|
191 |
sinst_list |
|
192 |
the list of instances having this node as a secondary node, comma |
|
193 |
separated |
|
194 |
|
|
195 |
pip |
|
196 |
the primary ip of this node (used for cluster communication) |
|
197 |
|
|
198 |
sip |
|
199 |
the secondary ip of this node (used for data replication in dual-ip |
|
200 |
clusters, see gnt-cluster(8) |
|
201 |
|
|
202 |
dtotal |
|
203 |
total disk space in the volume group used for instance disk |
|
204 |
allocations |
|
205 |
|
|
206 |
dfree |
|
207 |
available disk space in the volume group |
|
208 |
|
|
209 |
mtotal |
|
210 |
total memory on the physical node |
|
211 |
|
|
212 |
mnode |
|
213 |
the memory used by the node itself |
|
214 |
|
|
215 |
mfree |
|
216 |
memory available for instance allocations |
|
217 |
|
|
218 |
bootid |
|
219 |
the node bootid value; this is a linux specific feature that |
|
220 |
assigns a new UUID to the node at each boot and can be use to |
|
221 |
detect node reboots (by tracking changes in this value) |
|
222 |
|
|
223 |
tags |
|
224 |
comma-separated list of the node's tags |
|
225 |
|
|
226 |
serial_no |
|
227 |
the so called 'serial number' of the node; this is a numeric field |
|
228 |
that is incremented each time the node is modified, and it can be |
|
229 |
used to detect modifications |
|
230 |
|
|
231 |
ctime |
|
232 |
the creation time of the node; note that this field contains spaces |
|
233 |
and as such it's harder to parse |
|
234 |
|
|
235 |
if this attribute is not present (e.g. when upgrading from older |
|
236 |
versions), then "N/A" will be shown instead |
|
237 |
|
|
238 |
mtime |
|
239 |
the last modification time of the node; note that this field |
|
240 |
contains spaces and as such it's harder to parse |
|
241 |
|
|
242 |
if this attribute is not present (e.g. when upgrading from older |
|
243 |
versions), then "N/A" will be shown instead |
|
244 |
|
|
245 |
uuid |
|
246 |
Show the UUID of the node (generated automatically by Ganeti) |
|
247 |
|
|
248 |
ctotal |
|
249 |
the toal number of logical processors |
|
250 |
|
|
251 |
cnodes |
|
252 |
the number of NUMA domains on the node, if the hypervisor can |
|
253 |
export this information |
|
254 |
|
|
255 |
csockets |
|
256 |
the number of physical CPU sockets, if the hypervisor can export |
|
257 |
this information |
|
258 |
|
|
259 |
master_candidate |
|
260 |
whether the node is a master candidate or not |
|
261 |
|
|
262 |
drained |
|
263 |
whether the node is drained or not; the cluster still communicates |
|
264 |
with drained nodes but excludes them from allocation operations |
|
265 |
|
|
266 |
offline |
|
267 |
whether the node is offline or not; if offline, the cluster does |
|
268 |
not communicate with offline nodes; useful for nodes that are not |
|
269 |
reachable in order to avoid delays |
|
270 |
|
|
271 |
role |
|
272 |
A condensed version of the node flags; this field will output a |
|
273 |
one-character field, with the following possible values: |
|
274 |
|
|
275 |
- *M* for the master node |
|
276 |
|
|
277 |
- *C* for a master candidate |
|
278 |
|
|
279 |
- *R* for a regular node |
|
280 |
|
|
281 |
- *D* for a drained node |
|
282 |
|
|
283 |
- *O* for an offline node |
|
284 |
|
|
285 |
master_capable |
|
286 |
whether the node can become a master candidate |
|
287 |
|
|
288 |
vm_capable |
|
289 |
whether the node can host instances |
|
290 |
|
|
291 |
group |
|
292 |
the name of the node's group, if known (the query is done without |
|
293 |
locking, so data consistency is not guaranteed) |
|
294 |
|
|
295 |
group.uuid |
|
296 |
the UUID of the node's group |
|
297 |
|
|
298 |
|
|
299 |
If the value of the option starts with the character ``+``, the new |
|
300 |
fields will be added to the default list. This allows to quickly |
|
301 |
see the default list plus a few other fields, instead of retyping |
|
302 |
the entire list of fields. |
|
303 |
|
|
304 |
Note that some of this fields are known from the configuration of |
|
305 |
the cluster (e.g. name, pinst, sinst, pip, sip and thus the master |
|
306 |
does not need to contact the node for this data (making the listing |
|
307 |
fast if only fields from this set are selected), whereas the other |
|
308 |
fields are "live" fields and we need to make a query to the cluster |
|
309 |
nodes. |
|
310 |
|
|
311 |
Depending on the virtualization type and implementation details, |
|
312 |
the mtotal, mnode and mfree may have slighly varying meanings. For |
|
313 |
example, some solutions share the node memory with the pool of |
|
314 |
memory used for instances (KVM), whereas others have separate |
|
315 |
memory for the node and for the instances (Xen). |
|
316 |
|
|
317 |
If no node names are given, then all nodes are queried. Otherwise, |
|
318 |
only the given nodes will be listed. |
|
319 |
|
|
320 |
LIST-TAGS |
|
321 |
~~~~~~~~~ |
|
322 |
|
|
323 |
**list-tags** {*nodename*} |
|
324 |
|
|
325 |
List the tags of the given node. |
|
326 |
|
|
327 |
MIGRATE |
|
328 |
~~~~~~~ |
|
329 |
|
|
330 |
**migrate** [-f] [--non-live] [--migration-mode=live\|non-live] |
|
331 |
{*node*} |
|
332 |
|
|
333 |
This command will migrate all instances having the given node as |
|
334 |
primary to their secondary nodes. This works only for instances |
|
335 |
having a drbd disk template. |
|
336 |
|
|
337 |
As for the **gnt-instance migrate** command, the options |
|
338 |
``--no-live`` and ``--migration-mode`` can be given to influence |
|
339 |
the migration type. |
|
340 |
|
|
341 |
Example:: |
|
342 |
|
|
343 |
# gnt-node migrate node1.example.com |
|
344 |
|
|
345 |
|
|
346 |
MODIFY |
|
347 |
~~~~~~ |
|
348 |
|
|
349 |
| **modify** [-f] [--submit] |
|
350 |
| [--master-candidate=``yes|no``] [--drained=``yes|no``] [--offline=``yes|no``] |
|
351 |
| [--master-capable=``yes|no``] [--vm-capable=``yes|no``] [--auto-promote] |
|
352 |
| [-s *secondary_ip*] |
|
353 |
| {*node*} |
|
354 |
|
|
355 |
This command changes the role of the node. Each options takes |
|
356 |
either a literal yes or no, and only one option should be given as |
|
357 |
yes. The meaning of the roles and flags are described in the |
|
358 |
manpage **ganeti**(7). |
|
359 |
|
|
360 |
In case a node is demoted from the master candidate role, the |
|
361 |
operation will be refused unless you pass the ``--auto-promote`` |
|
362 |
option. This option will cause the operation to lock all cluster nodes |
|
363 |
(thus it will not be able to run in parallel with most other jobs), |
|
364 |
but it allows automated maintenance of the cluster candidate pool. If |
|
365 |
locking all cluster node is too expensive, another option is to |
|
366 |
promote manually another node to master candidate before demoting the |
|
367 |
current one. |
|
368 |
|
|
369 |
Example (setting a node offline, which will demote it from master |
|
370 |
candidate role if is in that role):: |
|
371 |
|
|
372 |
# gnt-node modify --offline=yes node1.example.com |
|
373 |
|
|
374 |
The ``-s`` can be used to change the node's secondary ip. No drbd |
|
375 |
instances can be running on the node, while this operation is |
|
376 |
taking place. |
|
377 |
|
|
378 |
Example (setting the node back to online and master candidate):: |
|
379 |
|
|
380 |
# gnt-node modify --offline=no --master-candidate=yes node1.example.com |
|
381 |
|
|
382 |
|
|
383 |
REMOVE |
|
384 |
~~~~~~ |
|
385 |
|
|
386 |
**remove** {*nodename*} |
|
387 |
|
|
388 |
Removes a node from the cluster. Instances must be removed or |
|
389 |
migrated to another cluster before. |
|
390 |
|
|
391 |
Example:: |
|
392 |
|
|
393 |
# gnt-node remove node5.example.com |
|
394 |
|
|
395 |
|
|
396 |
REMOVE-TAGS |
|
397 |
~~~~~~~~~~~ |
|
398 |
|
|
399 |
**remove-tags** [--from *file*] {*nodename*} {*tag*...} |
|
400 |
|
|
401 |
Remove tags from the given node. If any of the tags are not |
|
402 |
existing on the node, the entire operation will abort. |
|
403 |
|
|
404 |
If the ``--from`` option is given, the list of tags to be removed will |
|
405 |
be extended with the contents of that file (each line becomes a tag). |
|
406 |
In this case, there is not need to pass tags on the command line (if |
|
407 |
you do, tags from both sources will be removed). A file name of - will |
|
408 |
be interpreted as stdin. |
|
409 |
|
|
410 |
VOLUMES |
|
411 |
~~~~~~~ |
|
412 |
|
|
413 |
| **volumes** [--no-headers] [--human-readable] |
|
414 |
| [--separator=*SEPARATOR*] [--output=*FIELDS*] |
|
415 |
| [*node*...] |
|
416 |
|
|
417 |
Lists all logical volumes and their physical disks from the node(s) |
|
418 |
provided. |
|
419 |
|
|
420 |
The ``--no-headers`` option will skip the initial header line. The |
|
421 |
``--separator`` option takes an argument which denotes what will be |
|
422 |
used between the output fields. Both these options are to help |
|
423 |
scripting. |
|
424 |
|
|
425 |
The units used to display the numeric values in the output varies, |
|
426 |
depending on the options given. By default, the values will be |
|
427 |
formatted in the most appropriate unit. If the ``--separator`` |
|
428 |
option is given, then the values are shown in mebibytes to allow |
|
429 |
parsing by scripts. In both cases, the ``--units`` option can be |
|
430 |
used to enforce a given output unit. |
|
431 |
|
|
432 |
The ``-o`` option takes a comma-separated list of output fields. |
|
433 |
The available fields and their meaning are: |
|
434 |
|
|
435 |
node |
|
436 |
the node name on which the volume exists |
|
437 |
|
|
438 |
phys |
|
439 |
the physical drive (on which the LVM physical volume lives) |
|
440 |
|
|
441 |
vg |
|
442 |
the volume group name |
|
443 |
|
|
444 |
name |
|
445 |
the logical volume name |
|
446 |
|
|
447 |
size |
|
448 |
the logical volume size |
|
449 |
|
|
450 |
instance |
|
451 |
The name of the instance to which this volume belongs, or (in case |
|
452 |
it's an orphan volume) the character "-" |
|
453 |
|
|
454 |
|
|
455 |
Example:: |
|
456 |
|
|
457 |
# gnt-node volumes node5.example.com |
|
458 |
Node PhysDev VG Name Size Instance |
|
459 |
node1.example.com /dev/hdc1 xenvg instance1.example.com-sda_11000.meta 128 instance1.example.com |
|
460 |
node1.example.com /dev/hdc1 xenvg instance1.example.com-sda_11001.data 256 instance1.example.com |
|
461 |
|
|
462 |
|
|
463 |
LIST-STORAGE |
|
464 |
~~~~~~~~~~~~ |
|
465 |
|
|
466 |
| **list-storage** [--no-headers] [--human-readable] |
|
467 |
| [--separator=*SEPARATOR*] [--storage-type=*STORAGE\_TYPE*] |
|
468 |
| [--output=*FIELDS*] |
|
469 |
| [*node*...] |
|
470 |
|
|
471 |
Lists the available storage units and their details for the given |
|
472 |
node(s). |
|
473 |
|
|
474 |
The ``--no-headers`` option will skip the initial header line. The |
|
475 |
``--separator`` option takes an argument which denotes what will be |
|
476 |
used between the output fields. Both these options are to help |
|
477 |
scripting. |
|
478 |
|
|
479 |
The units used to display the numeric values in the output varies, |
|
480 |
depending on the options given. By default, the values will be |
|
481 |
formatted in the most appropriate unit. If the ``--separator`` |
|
482 |
option is given, then the values are shown in mebibytes to allow |
|
483 |
parsing by scripts. In both cases, the ``--units`` option can be |
|
484 |
used to enforce a given output unit. |
|
485 |
|
|
486 |
The ``--storage-type`` option can be used to choose a storage unit |
|
487 |
type. Possible choices are lvm-pv, lvm-vg or file. |
|
488 |
|
|
489 |
The ``-o`` option takes a comma-separated list of output fields. |
|
490 |
The available fields and their meaning are: |
|
491 |
|
|
492 |
node |
|
493 |
the node name on which the volume exists |
|
494 |
|
|
495 |
type |
|
496 |
the type of the storage unit (currently just what is passed in via |
|
497 |
``--storage-type``) |
|
498 |
|
|
499 |
name |
|
500 |
the path/identifier of the storage unit |
|
501 |
|
|
502 |
size |
|
503 |
total size of the unit; for the file type see a note below |
|
504 |
|
|
505 |
used |
|
506 |
used space in the unit; for the file type see a note below |
|
507 |
|
|
508 |
free |
|
509 |
available disk space |
|
510 |
|
|
511 |
allocatable |
|
512 |
whether we the unit is available for allocation (only lvm-pv can |
|
513 |
change this setting, the other types always report true) |
|
514 |
|
|
515 |
|
|
516 |
Note that for the "file" type, the total disk space might not equal |
|
517 |
to the sum of used and free, due to the method Ganeti uses to |
|
518 |
compute each of them. The total and free values are computed as the |
|
519 |
total and free space values for the filesystem to which the |
|
520 |
directory belongs, but the used space is computed from the used |
|
521 |
space under that directory *only*, which might not be necessarily |
|
522 |
the root of the filesystem, and as such there could be files |
|
523 |
outside the file storage directory using disk space and causing a |
|
524 |
mismatch in the values. |
|
525 |
|
|
526 |
Example:: |
|
527 |
|
|
528 |
node1# gnt-node list-storage node2 |
|
529 |
Node Type Name Size Used Free Allocatable |
|
530 |
node2 lvm-pv /dev/sda7 673.8G 1.5G 672.3G Y |
|
531 |
node2 lvm-pv /dev/sdb1 698.6G 0M 698.6G Y |
|
532 |
|
|
533 |
|
|
534 |
MODIFY-STORAGE |
|
535 |
~~~~~~~~~~~~~~ |
|
536 |
|
|
537 |
**modify-storage** [``--allocatable=yes|no``] |
|
538 |
{*node*} {*storage-type*} {*volume-name*} |
|
539 |
|
|
540 |
Modifies storage volumes on a node. Only LVM physical volumes can |
|
541 |
be modified at the moment. They have a storage type of "lvm-pv". |
|
542 |
|
|
543 |
Example:: |
|
544 |
|
|
545 |
# gnt-node modify-storage --allocatable no node5.example.com lvm-pv /dev/sdb1 |
|
546 |
|
|
547 |
|
|
548 |
REPAIR-STORAGE |
|
549 |
~~~~~~~~~~~~~~ |
|
550 |
|
|
551 |
**repair-storage** [--ignore-consistency] {*node*} {*storage-type*} |
|
552 |
{*volume-name*} |
|
553 |
|
|
554 |
Repairs a storage volume on a node. Only LVM volume groups can be |
|
555 |
repaired at this time. They have the storage type "lvm-vg". |
|
556 |
|
|
557 |
On LVM volume groups, **repair-storage** runs "vgreduce |
|
558 |
--removemissing". |
|
559 |
|
|
560 |
|
|
561 |
|
|
562 |
**Caution:** Running this command can lead to data loss. Use it with |
|
563 |
care. |
|
564 |
|
|
565 |
The ``--ignore-consistency`` option will ignore any inconsistent |
|
566 |
disks (on the nodes paired with this one). Use of this option is |
|
567 |
most likely to lead to data-loss. |
|
568 |
|
|
569 |
Example:: |
|
570 |
|
|
571 |
# gnt-node repair-storage node5.example.com lvm-vg xenvg |
|
572 |
|
|
573 |
|
|
574 |
POWERCYCLE |
|
575 |
~~~~~~~~~~ |
|
576 |
|
|
577 |
**powercycle** [``--yes``] [``--force``] {*node*} |
|
578 |
|
|
579 |
This commands (tries to) forcefully reboot a node. It is a command |
|
580 |
that can be used if the node environemnt is broken, such that the |
|
581 |
admin can no longer login over ssh, but the Ganeti node daemon is |
|
582 |
still working. |
|
583 |
|
|
584 |
Note that this command is not guaranteed to work; it depends on the |
|
585 |
hypervisor how effective is the reboot attempt. For Linux, this |
|
586 |
command require that the kernel option CONFIG\_MAGIC\_SYSRQ is |
|
587 |
enabled. |
|
588 |
|
|
589 |
The ``--yes`` option can be used to skip confirmation, while the |
|
590 |
``--force`` option is needed if the target node is the master |
|
591 |
node. |
Also available in: Unified diff