1CRM(8) Pacemaker documentation CRM(8)
2
6 crm - Pacemaker command line interface for configuration and management
7
9 crm [-D output_type] [-f file] [-hFRDw] [--version] [args]
10
12 Pacemaker configuration is stored in a CIB file (Cluster Information
13 Base). The CIB is a set of instructions coded in XML. Editing the CIB
14 is a challenge, not only due to its complexity and a wide variety of
15 options, but also because XML is more computer than user friendly. The
16 crm shell alleviates this issue significantly by introducing small and
17 simple configuration language. The CIB is translated into this language
18 on the fly.
19 crm is also a management tool. For management tasks it relies almost
21 exclusively on other command line tools, such as crm_resource(8) or
22 crm_attribute(8). Use of these programs is, however, plagued by the
23 notorious weakness common to all UNIX tools: a multitude of options,
24 necessary for operation and yet very hard to remember. crm tries to
25 present a consistent interface to the user and to hide the arcane
26 detail.
27 It may be used either as an interactive shell or for single commands
29 directly on the shell’s command line. It is also possible to feed it a
30 set of commands from standard input or a file, thus turning it into a
31 scripting tool. Templates with ready made configurations may help
32 newbies learn about the cluster configuration or facilitate testing
33 procedures.
34 The crm shell is line oriented: every command must start and finish on
36 the same line. It is possible to use a continuation character (\) to
37 write one command in two or more lines. The continuation character is
38 commonly used when displaying configurations.
39
41 -f, --file=FILE
42 Load commands from the given file. If the file is - then use
43 terminal stdin.
44 -D, --display=OUTPUT_TYPE
46 Choose one of the output options: plain, color, or uppercase. The
47 default is color if the terminal emulation supports colors.
48 Otherwise, plain is used.
49 -F, --force
51 Make crm proceed with doing changes even though it would normally
52 ask user to confirm some of them. Mostly useful in scripts.
53 -w, --wait
55 Make crm wait for the transition to finish. Applicable only for
56 commands such as "resource start."
57 -h, --help
59 Print help page.
60 --version
62 Print Pacemaker version and build information (Mercurial Hg
63 changeset hash).
64 -R, --regression-tests
66 Run in the regression test mode. Used mainly by the regression
67 testing suite.
68 -d, --debug
70 Print some debug information. Used by developers. [Not yet refined
71 enough to print useful information for other users.]
72
74 Arguably the most important aspect of such a program is the user
75 interface. We begin with an informal introduction so that the reader
76 may get acquainted with it and get a general feeling of the tool. It is
77 probably best just to give some examples:
78 1. Command line (one-shot) use:
80 # crm resource stop www_app
82 2. Interactive use:
84 # crm
86 crm(live)# resource
87 crm(live)resource# unmanage tetris_1
88 crm(live)resource# end
89 crm(live)# node standby node4
90 3. Cluster configuration:
92 # crm<<EOF
94 configure
95 erase
96 #
97 # resources
98 #
99 primitive disk0 iscsi \
100 params portal=192.168.2.108:3260 target=iqn.2008-07.com.suse:disk0
101 primitive fs0 Filesystem \
102 params device=/dev/disk/by-label/disk0 directory=/disk0 fstype=ext3
103 primitive internal_ip IPaddr params ip=192.168.1.101
104 primitive apache apache \
105 params configfile=/disk0/etc/apache2/site0.conf
106 primitive apcfence stonith:apcsmart \
107 params ttydev=/dev/ttyS0 hostlist="node1 node2" \
108 op start timeout=60s
109 primitive pingd pingd \
110 params name=pingd dampen=5s multiplier=100 host_list="r1 r2"
111 #
112 # monitor apache and the UPS
113 #
114 monitor apache 60s:30s
115 monitor apcfence 120m:60s
116 #
117 # cluster layout
118 #
119 group internal_www \
120 disk0 fs0 internal_ip apache
121 clone fence apcfence \
122 meta globally-unique=false clone-max=2 clone-node-max=1
123 clone conn pingd \
124 meta globally-unique=false clone-max=2 clone-node-max=1
125 location node_pref internal_www \
126 rule 50: #uname eq node1 \
127 rule pingd: defined pingd
128 #
129 # cluster properties
130 #
131 property stonith-enabled=true
132 commit
133 EOF
134 If you’ve ever done a CRM style configuration, you should be able to
136 understand the above examples without much difficulties. The shell
137 should provide a means to manage the cluster efficiently or put
138 together a configuration in a concise manner.
139 The (live) string in the prompt signifies that the current CIB in use
141 is the cluster live configuration. It is also possible to work with the
142 so-called shadow CIBs, i.e. configurations which are stored in files
143 and aren’t active, but may be applied at any time to the cluster.
144 Since the CIB is hierarchical such is the interface too. There are
146 several levels and entering each of them enables the user to use a
147 certain set of commands.
148 Shadow CIB usage
150 Shadow CIB is a normal cluster configuration stored in a file. They may
151 be manipulated in the same way like the live CIB, but these changes
152 have no effect on the cluster resources. The administrator may choose
153 to apply any of them to the cluster, thus replacing the running
154 configuration with the one which is in the shadow CIB. The crm prompt
155 always contains the name of the configuration which is currently in use
156 or string live if we are using the current cluster configuration.
157 At the configure level no changes take place before the commit command.
159 Sometimes though, the administrator may start working with the running
160 configuration, but change mind and instead of committing the changes to
161 the cluster save them to a shadow CIB. This short configure session
162 excerpt shows how:
163 crm(live)configure# cib new test-2
165 INFO: test-2 shadow CIB created
166 crm(test-2)configure# commit
167 Templates
169 Templates are ready made configurations created by cluster experts.
170 They are designed in such a way so that users may generate valid
171 cluster configurations with minimum effort. If you are new to
172 Pacemaker, templates may be the best way to start.
173 We will show here how to create a simple yet functional Apache
175 configuration:
176 # crm configure
178 crm(live)configure# template
179 crm(live)configure template# list templates
180 apache filesystem virtual-ip
181 crm(live)configure template# new web <TAB><TAB>
182 apache filesystem virtual-ip
183 crm(live)configure template# new web apache
184 INFO: pulling in template apache
185 INFO: pulling in template virtual-ip
186 crm(live)configure template# list
187 web2-d web2 vip2 web3 vip web
188 We enter the template level from configure. Use the list command to
190 show templates available on the system. The new command creates a
191 configuration from the apache template. You can use tab completion to
192 pick templates. Note that the apache template depends on a virtual IP
193 address which is automatically pulled along. The list command shows the
194 just created web configuration, among other configurations (I hope that
195 you, unlike me, will use more sensible and descriptive names).
196 The show command, which displays the resulting configuration, may be
198 used to get an idea about the minimum required changes which have to be
199 done. All ERROR messages show the line numbers in which the respective
200 parameters are to be defined:
201 crm(live)configure template# show
203 ERROR: 23: required parameter ip not set
204 ERROR: 61: required parameter id not set
205 ERROR: 65: required parameter configfile not set
206 crm(live)configure template# edit
207 The edit command invokes the preferred text editor with the web
209 configuration. At the top of the file, the user is advised how to make
210 changes. A good template should require from the user to specify only
211 parameters. For example, the web configuration we created above has the
212 following required and optional parameters (all parameter lines start
213 with %%):
214 $ grep -n ^%% ~/.crmconf/web
216 23:%% ip
217 31:%% netmask
218 35:%% lvs_support
219 61:%% id
220 65:%% configfile
221 71:%% options
222 76:%% envfiles
223 These lines are the only ones that should be modified. Simply append
225 the parameter value at the end of the line. For instance, after editing
226 this template, the result could look like this (we used tabs instead of
227 spaces to make the values stand out):
228 $ grep -n ^%% ~/.crmconf/web
230 23:%% ip 192.168.1.101
231 31:%% netmask
232 35:%% lvs_support
233 61:%% id websvc
234 65:%% configfile /etc/apache2/httpd.conf
235 71:%% options
236 76:%% envfiles
237 As you can see, the parameter line format is very simple:
239 %% <name> <value>
241 After editing the file, use show again to display the configuration:
243 crm(live)configure template# show
245 primitive virtual-ip ocf:heartbeat:IPaddr \
246 params ip="192.168.1.101"
247 primitive apache ocf:heartbeat:apache \
248 params configfile="/etc/apache2/httpd.conf"
249 monitor apache 120s:60s
250 group websvc \
251 apache virtual-ip
252 The target resource of the apache template is a group which we named
254 websvc in this sample session.
255 This configuration looks exactly as you could type it at the configure
257 level. The point of templates is to save you some typing. It is
258 important, however, to understand the configuration produced.
259 Finally, the configuration may be applied to the current crm
261 configuration (note how the configuration changed slightly, though it
262 is still equivalent, after being digested at the configure level):
263 crm(live)configure template# apply
265 crm(live)configure template# cd ..
266 crm(live)configure# show
267 node xen-b
268 node xen-c
269 primitive apache ocf:heartbeat:apache \
270 params configfile="/etc/apache2/httpd.conf" \
271 op monitor interval="120s" timeout="60s"
272 primitive virtual-ip ocf:heartbeat:IPaddr \
273 params ip="192.168.1.101"
274 group websvc apache virtual-ip
275 Note that this still does not commit the configuration to the CIB which
277 is used in the shell, either the running one (live) or some shadow CIB.
278 For that you still need to execute the commit command.
279 To complete our example, we should also define the preferred node to
281 run the service:
282 crm(live)configure# location websvc-pref websvc 100: xen-b
284 If you are not happy with some resource names which are provided by
286 default, you can rename them now:
287 crm(live)configure# rename virtual-ip intranet-ip
289 crm(live)configure# show
290 node xen-b
291 node xen-c
292 primitive apache ocf:heartbeat:apache \
293 params configfile="/etc/apache2/httpd.conf" \
294 op monitor interval="120s" timeout="60s"
295 primitive intranet-ip ocf:heartbeat:IPaddr \
296 params ip="192.168.1.101"
297 group websvc apache intranet-ip
298 location websvc-pref websvc 100: xen-b
299 To summarize, working with templates typically consists of the
301 following steps:
302 · new: create a new configuration from templates
304 · edit: define parameters, at least the required ones
306 · show: see if the configuration is valid
308 · apply: apply the configuration to the configure level
310 Tab completion
312 The crm makes extensive use of the tab completion of readline. The
313 completion is both static (i.e. for crm commands) and dynamic. The
314 latter takes into account the current status of the cluster or
315 information from installed resource agents. Sometimes, completion may
316 also be used to get short help on resource parameters. Here a few
317 examples:
318 crm(live)# resource
320 crm(live)resource# <TAB><TAB>
321 bye failcount move restart unmigrate
322 cd help param show unmove
323 cleanup list promote start up
324 demote manage quit status utilization
325 end meta refresh stop
326 exit migrate reprobe unmanage
327 crm(live)resource# end
328 crm(live)# configure
329 crm(live)configure# primitive fence-1 <TAB><TAB>
330 heartbeat: lsb: ocf: stonith:
331 crm(live)configure# primitive fence-1 stonith:<TAB><TAB>
332 apcmaster external/ippower9258 fence_legacy
333 apcmastersnmp external/kdumpcheck ibmhmc
334 apcsmart external/libvirt ipmilan
335 baytech external/nut meatware
336 bladehpi external/rackpdu null
337 cyclades external/riloe nw_rpc100s
338 drac3 external/sbd rcd_serial
339 external/drac5 external/ssh rps10
340 external/dracmc-telnet external/ssh-bad ssh
341 external/hmchttp external/ssh-slow suicide
342 external/ibmrsa external/vmware wti_mpc
343 external/ibmrsa-telnet external/xen0 wti_nps
344 external/ipmi external/xen0-ha
345 crm(live)configure# primitive fence-1 stonith:ipmilan params <TAB><TAB>
346 auth= hostname= ipaddr= login= password= port= priv=
347 crm(live)configure# primitive fence-1 stonith:ipmilan params auth=<TAB><TAB>
348 auth* (string)
349 The authorization type of the IPMI session ("none", "straight", "md2", or "md5")
350 crm(live)configure# primitive fence-1 stonith:ipmilan params auth=
351 Configuration semantic checks
353 Resource definitions may be checked against the meta-data provided with
354 the resource agents. These checks are currently carried out:
355 · are required parameters set
357 · existence of defined parameters
359 · timeout values for operations
361 The parameter checks are obvious and need no further explanation.
363 Failures in these checks are treated as configuration errors.
364 The timeouts for operations should be at least as long as those
366 recommended in the meta-data. Too short timeout values are a common
367 mistake in cluster configurations and, even worse, they often slip
368 through if cluster testing was not thorough. Though operation timeouts
369 issues are treated as warnings, make sure that the timeouts are usable
370 in your environment. Note also that the values given are just advisory
371 minimum---your resources may require longer timeouts.
372 User may tune the frequency of checks and the treatment of errors by
374 the check-frequency and check-mode preferences.
375 Note that if the check-frequency is set to always and the check-mode to
377 strict, errors are not tolerated and such configuration cannot be
378 saved.
379 Access Control Lists (ACL)
381 It is desirable to allow users fine grained access to the cluster and
382 not just `all or nothing:'' all being the two ultimate power ids `root
383 and hacluster.
384 Access control lists consist of an ordered set of access rules. Each
386 rule allows read or write access or denies access completely. Rules are
387 typically combined to produce a specific role. Then, users may be
388 assigned a role.
389 For instance, this is a role which defines a set of rules allowing
391 management of a single resource:
392 role bigdb_admin \
394 write meta:bigdb:target-role \
395 write meta:bigdb:is-managed \
396 write location:bigdb \
397 read ref:bigdb
398 The first two rules allow modifying the target-role and is-managed meta
400 attributes which effectively enables users in this role to stop/start
401 and manage/unmanage the resource. The constraints write access rule
402 allows moving the resource around. Finally, the user is granted read
403 access to the resource definition.
404 For proper operation of all Pacemaker programs, it is advisable to add
406 the following role to all users:
407 role read_all \
409 read cib
410 For finer grained read access try with the rules listed in the
412 following role:
413 role basic_read \
415 read node attribute:uname \
416 read node attribute:type \
417 read property \
418 read status
419 It is however possible that some Pacemaker programs (e.g. ptest) may
421 not function correctly if the whole CIB is not readable.
422 Some of the ACL rules in the examples above are expanded by the shell
424 to XPath specifications. For instance, meta:bigdb:target-role is a
425 shortcut for
426 //primitive[@id='bigdb']/meta_attributes/nvpair[@name='target-role'].
427 You can see the expansion by showing XML:
428 crm(live) configure# show xml bigdb_admin
430 ...
431 <acls>
432 <acl_role id="bigdb_admin">
433 <write id="bigdb_admin-write"
434 xpath="//primitive[@id='bigdb']/meta_attributes/nvpair[@name='target-role']"/>
435 Many different XPath expressions can have equal meaning. For instance,
437 the following two are equal, but only the first one is going to be
438 recognized as shortcut:
439 //primitive[@id='bigdb']/meta_attributes/nvpair[@name='target-role']
441 //resources/primitive[@id='bigdb']/meta_attributes/nvpair[@name='target-role']
442 XPath is a powerful language, but you should try to keep your ACL
444 xpaths simple and the builtin shortcuts should be used whenever
445 possible.
446
448 We define a small and simple language. Most commands consist of just a
449 list of simple tokens. The only complex constructs are found at the
450 configure level.
451 The syntax is described in a somewhat informal manner: <> denotes a
453 string, [] means that the construct is optional, the ellipsis (...)
454 signifies that the previous construct may be repeated, | means pick one
455 of many, and the rest are literals (strings, :, =).
456 status
458 Show cluster status. The status is displayed by crm_mon. Supply
459 additional arguments for more information or different format. See
460 crm_mon(8) for more details.
461 Usage:
463 status [<option> ...]
465 option :: bynode | inactive | ops | timing | failcounts
467 cib (shadow CIBs)
469 This level is for management of shadow CIBs. It is available both at
470 the top level and the configure level.
471 All the commands are implemented using cib_shadow(8) and the CIB_shadow
473 environment variable. The user prompt always includes the name of the
474 currently active shadow or the live CIB.
475 new
477 Create a new shadow CIB. The live cluster configuration and status
478 is copied to the shadow CIB. Specify withstatus if you want to edit
479 the status section of the shadow CIB (see the cibstatus section).
480 Add force to force overwriting the existing shadow CIB.
481 To start with an empty configuration that is not copied from the
483 live CIB, specify the empty keyword. (This also allows a shadow CIB
484 to be created in case no cluster is running.)
485 Usage:
487 new <cib> [withstatus] [force] [empty]
489 delete
491 Delete an existing shadow CIB.
492 Usage:
494 delete <cib>
496 reset
498 Copy the current cluster configuration into the shadow CIB.
499 Usage:
501 reset <cib>
503 commit
505 Apply a shadow CIB to the cluster.
506 Usage:
508 commit <cib>
510 use
512 Choose a CIB source. If you want to edit the status from the shadow
513 CIB specify withstatus (see cibstatus). Leave out the CIB name to
514 switch to the running CIB.
515 Usage:
517 use [<cib>] [withstatus]
519 diff
521 Print differences between the current cluster configuration and the
522 active shadow CIB.
523 Usage:
525 diff
527 list
529 List existing shadow CIBs.
530 Usage:
532 list
534 import
536 At times it may be useful to create a shadow file from the existing
537 CIB. The CIB may be specified as file or as a PE input file number.
538 The shell will look up files in the local directory first and then
539 in the PE directory (typically /var/lib/pengine). Once the CIB file
540 is found, it is copied to a shadow and this shadow is immediately
541 available for use at both configure and cibstatus levels.
542 If the shadow name is omitted then the target shadow is named after
544 the input CIB file.
545 Note that there are often more than one PE input file, so you may
547 need to specify the full name.
548 Usage:
550 import {<file>|<number>} [<shadow>]
552 Examples:
554 import pe-warn-2222
556 import 2289 issue2
557 cibstatus
559 Enter edit and manage the CIB status section level. See the CIB
560 status management section.
561 ra
563 This level contains commands which show various information about the
564 installed resource agents. It is available both at the top level and at
565 the configure level.
566 classes
568 Print all resource agents' classes and, where appropriate, a list
569 of available providers.
570 Usage:
572 classes
574 list
576 List available resource agents for the given class. If the class is
577 ocf, supply a provider to get agents which are available only from
578 that provider.
579 Usage:
581 list <class> [<provider>]
583 Example:
585 list ocf pacemaker
587 meta (info)
589 Show the meta-data of a resource agent type. This is where users
590 can find information on how to use a resource agent.
591 Usage:
593 meta [<class>:[<provider>:]]<type>
595 meta <type> <class> [<provider>] (obsolete)
596 Example:
598 meta apache
600 meta ocf:pacemaker:Dummy
601 meta stonith:ipmilan
602 providers
604 List providers for a resource agent type. The class parameter
605 defaults to ocf.
606 Usage:
608 providers <type> [<class>]
610 Example:
612 providers apache
614 resource
616 At this level resources may be managed.
617 All (or almost all) commands are implemented with the CRM tools such as
619 crm_resource(8).
620 status (show, list)
622 Print resource status. If the resource parameter is left out status
623 of all resources is printed.
624 Usage:
626 status [<rsc>]
628 start
630 Start a resource by setting the target-role attribute. If there are
631 multiple meta attributes sets, the attribute is set in all of them.
632 If the resource is a group or a clone, all target-role attributes
633 are removed from the children resources.
634 Usage:
636 start <rsc>
638 stop
640 Stop a resource using the target-role attribute. If there are
641 multiple meta attributes sets, the attribute is set in all of them.
642 If the resource is a group or a clone, all target-role attributes
643 are removed from the children resources.
644 Usage:
646 stop <rsc>
648 restart
650 Restart a resource. This is essentially a shortcut for resource
651 stop followed by a start. The shell is first going to wait for the
652 stop to finish, that is for all resources to really stop, and only
653 then to order the start action. Due to this command entailing a
654 whole set of operations, informational messages are printed to let
655 the user see some progress.
656 Usage:
658 restart <rsc>
660 Example:
662 # crm resource restart g_webserver
664 INFO: ordering g_webserver to stop
665 waiting for stop to finish .... done
666 INFO: ordering g_webserver to start
667 #
668 promote
670 Promote a master-slave resource using the target-role attribute.
671 Usage:
673 promote <rsc>
675 demote
677 Demote a master-slave resource using the target-role attribute.
678 Usage:
680 demote <rsc>
682 manage
684 Manage a resource using the is-managed attribute. If there are
685 multiple meta attributes sets, the attribute is set in all of them.
686 If the resource is a group or a clone, all is-managed attributes
687 are removed from the children resources.
688 Usage:
690 manage <rsc>
692 unmanage
694 Unmanage a resource using the is-managed attribute. If there are
695 multiple meta attributes sets, the attribute is set in all of them.
696 If the resource is a group or a clone, all is-managed attributes
697 are removed from the children resources.
698 Usage:
700 unmanage <rsc>
702 migrate (move)
704 Migrate a resource to a different node. If node is left out, the
705 resource is migrated by creating a constraint which prevents it
706 from running on the current node. Additionally, you may specify a
707 lifetime for the constraint---once it expires, the location
708 constraint will no longer be active.
709 Usage:
711 migrate <rsc> [<node>] [<lifetime>] [force]
713 unmigrate (unmove)
715 Remove the constraint generated by the previous migrate command.
716 Usage:
718 unmigrate <rsc>
720 param
722 Show/edit/delete a parameter of a resource.
723 Usage:
725 param <rsc> set <param> <value>
727 param <rsc> delete <param>
728 param <rsc> show <param>
729 Example:
731 param ip_0 show ip
733 meta
735 Show/edit/delete a meta attribute of a resource. Currently, all
736 meta attributes of a resource may be managed with other commands
737 such as resource stop.
738 Usage:
740 meta <rsc> set <attr> <value>
742 meta <rsc> delete <attr>
743 meta <rsc> show <attr>
744 Example:
746 meta ip_0 set target-role stopped
748 utilization
750 Show/edit/delete a utilization attribute of a resource. These
751 attributes describe hardware requirements. By setting the
752 placement-strategy cluster property appropriately, it is possible
753 then to distribute resources based on resource requirements and
754 node size. See also node utilization attributes.
755 Usage:
757 utilization <rsc> set <attr> <value>
759 utilization <rsc> delete <attr>
760 utilization <rsc> show <attr>
761 Example:
763 utilization xen1 set memory 4096
765 failcount
767 Show/edit/delete the failcount of a resource.
768 Usage:
770 failcount <rsc> set <node> <value>
772 failcount <rsc> delete <node>
773 failcount <rsc> show <node>
774 Example:
776 failcount fs_0 delete node2
778 cleanup
780 Cleanup resource status. Typically done after the resource has
781 temporarily failed. If a node is omitted, cleanup on all nodes. If
782 there are many nodes, the command may take a while.
783 Usage:
785 cleanup <rsc> [<node>]
787 refresh
789 Refresh CIB from the LRM status.
790 Usage:
792 refresh [<node>]
794 reprobe
796 Probe for resources not started by the CRM.
797 Usage:
799 reprobe [<node>]
801 node
803 Node management and status commands.
804 status
806 Show nodes' status. If the node parameter is omitted then all nodes
807 are shown.
808 Usage:
810 status [<node>]
812 show
814 Show a node definition. If the node parameter is omitted then all
815 nodes are shown.
816 Usage:
818 show [<node>]
820 standby
822 Set a node to standby status. The node parameter defaults to the
823 node where the command is run. Additionally, you may specify a
824 lifetime for the standby---if set to reboot, the node will be back
825 online once it reboots. forever will keep the node in standby after
826 reboot.
827 Usage:
829 standby [<node>] [<lifetime>]
831 lifetime :: reboot | forever
833 online
835 Set a node to online status. The node parameter defaults to the
836 node where the command is run.
837 Usage:
839 online [<node>]
841 fence
843 Make CRM fence a node. This functionality depends on stonith
844 resources capable of fencing the specified node. No such stonith
845 resources, no fencing will happen.
846 Usage:
848 fence <node>
850 clearnodestate
852 Resets and clears the state of the specified node. This node is
853 afterwards assumed clean and offline. This command can be used to
854 manually confirm that a node has been fenced (e.g., powered off).
855 Be careful! This can cause data corruption if you confirm that a
857 node is down that is, in fact, not cleanly down - the cluster will
858 proceed as if the fence had succeeded, possibly starting resources
859 multiple times.
860 Usage:
862 clearstate <node>
864 delete
866 Delete a node. This command will remove the node from the CIB and,
867 in case the heartbeat stack is running, run hb_delnode too.
868 Usage:
870 delete <node>
872 attribute
874 Edit node attributes. This kind of attribute should refer to
875 relatively static properties, such as memory size.
876 Usage:
878 attribute <node> set <attr> <value>
880 attribute <node> delete <attr>
881 attribute <node> show <attr>
882 Example:
884 attribute node_1 set memory_size 4096
886 utilization
888 Edit node utilization attributes. These attributes describe
889 hardware characteristics as integer numbers such as memory size or
890 the number of CPUs. By setting the placement-strategy cluster
891 property appropriately, it is possible then to distribute resources
892 based on resource requirements and node size. See also resource
893 utilization attributes.
894 Usage:
896 utilization <node> set <attr> <value>
898 utilization <node> delete <attr>
899 utilization <node> show <attr>
900 Examples:
902 utilization node_1 set memory 16384
904 utilization node_1 show cpu
905 status-attr
907 Edit node attributes which are in the CIB status section, i.e.
908 attributes which hold properties of a more volatile nature. One
909 typical example is attribute generated by the pingd utility.
910 Usage:
912 status-attr <node> set <attr> <value>
914 status-attr <node> delete <attr>
915 status-attr <node> show <attr>
916 Example:
918 status-attr node_1 show pingd
920 options
922 The user may set various options for the crm shell itself.
923 skill-level
925 Based on the skill-level setting, the user is allowed to use only a
926 subset of commands. There are three levels: operator,
927 administrator, and expert. The operator level allows only commands
928 at the resource and node levels, but not editing or deleting
929 resources. The administrator may do that and may also configure the
930 cluster at the configure level and manage the shadow CIBs. The
931 expert may do all.
932 Usage:
934 skill-level <level>
936 level :: operator | administrator | expert
938 user
940 Sufficient privileges are necessary in order to manage a cluster:
941 programs such as crm_verify or crm_resource and, ultimately,
942 cibadmin have to be run either as root or as the CRM owner user
943 (typically hacluster). You don’t have to worry about that if you
944 run crm as root. A more secure way is to run the program with your
945 usual privileges, set this option to the appropriate user (such as
946 hacluster), and setup the sudoers file.
947 Usage:
949 user system-user
951 Example:
953 user hacluster
955 editor
957 The edit command invokes an editor. Use this to specify your
958 preferred editor program. If not set, it will default to either the
959 value of the EDITOR environment variable or to one of the standard
960 UNIX editors (vi,emacs,nano).
961 Usage:
963 editor program
965 Example:
967 editor vim
969 pager
971 The view command displays text through a pager. Use this to specify
972 your preferred pager program. If not set, it will default to either
973 the value of the PAGER environment variable or to one of the
974 standard UNIX system pagers (less,more,pg).
975 sort-elements
977 crm by default sorts CIB elements. If you want them appear in the
978 order they were created, set this option to no.
979 Usage:
981 sort-elements {yes|no}
983 Example:
985 sort-elements no
987 wait
989 In normal operation, crm runs a command and gets back immediately
990 to process other commands or get input from the user. With this
991 option set to yes it will wait for the started transition to
992 finish. In interactive mode dots are printed to indicate progress.
993 Usage:
995 wait {yes|no}
997 Example:
999 wait yes
1001 output
1003 crm can adorn configurations in two ways: in color (similar to for
1004 instance the ls --color command) and by showing keywords in upper
1005 case. Possible values are plain, color, and uppercase. It is
1006 possible to combine the latter two in order to get an upper case
1007 xmass tree. Just set this option to color,uppercase.
1008 colorscheme
1010 With output set to color, a comma separated list of colors from
1011 this option are used to emphasize:
1012 · keywords
1014 · object ids
1016 · attribute names
1018 · attribute values
1020 · scores
1022 · resource references
1024 crm can show colors only if there is curses support for python
1026 installed (usually provided by the python-curses package). The
1027 colors are whatever is available in your terminal. Use normal if
1028 you want to keep the default foreground color.
1029 This user preference defaults to
1031 yellow,normal,cyan,red,green,magenta which is good for terminals
1032 with dark background. You may want to change the color scheme and
1033 save it in the preferences file for other color setups.
1034 Example:
1036 colorscheme yellow,normal,blue,red,green,magenta
1038 check-frequency
1040 Semantic check of the CIB or elements modified or created may be
1041 done on every configuration change (always), when verifying
1042 (on-verify) or never. It is by default set to always. Experts may
1043 want to change the setting to on-verify.
1044 The checks require that resource agents are present. If they are
1046 not installed at the configuration time set this preference to
1047 never.
1048 See Configuration semantic checks for more details.
1050 check-mode
1052 Semantic check of the CIB or elements modified or created may be
1053 done in the strict mode or in the relaxed mode. In the former
1054 certain problems are treated as configuration errors. In the
1055 relaxed mode all are treated as warnings. The default is strict.
1056 See Configuration semantic checks for more details.
1058 show
1060 Display all current settings.
1061 save
1063 Save current settings to the rc file ($HOME/.crm.rc). On further
1064 crm runs, the rc file is automatically read and parsed.
1065 configure
1067 This level enables all CIB object definition commands.
1068 The configuration may be logically divided into four parts: nodes,
1070 resources, constraints, and (cluster) properties and attributes. Each
1071 of these commands support one or more basic CIB objects.
1072 Nodes and attributes describing nodes are managed using the node
1074 command.
1075 Commands for resources are:
1077 · primitive
1079 · monitor
1081 · group
1083 · clone
1085 · ms/master (master-slave)
1087 There are three types of constraints:
1089 · location
1091 · colocation
1093 · order
1095 Finally, there are the cluster properties, resource meta attributes
1097 defaults, and operations defaults. All are just a set of attributes.
1098 These attributes are managed by the following commands:
1099 · property
1101 · rsc_defaults
1103 · op_defaults
1105 In addition to the cluster configuration, the Access Control Lists
1107 (ACL) can be setup to allow access to parts of the CIB for users other
1108 than root and hacluster. The following commands manage ACL:
1109 · user
1111 · role
1113 The changes are applied to the current CIB only on ending the
1115 configuration session or using the commit command.
1116 Comments start with # in the first line. The comments are tied to the
1118 element which follows. If the element moves, its comments will follow.
1119 node
1121 The node command describes a cluster node. Nodes in the CIB are
1122 commonly created automatically by the CRM. Hence, you should not
1123 need to deal with nodes unless you also want to define node
1124 attributes. Note that it is also possible to manage node attributes
1125 at the node level.
1126 Usage:
1128 node <uname>[:<type>]
1130 [attributes <param>=<value> [<param>=<value>...]]
1131 [utilization <param>=<value> [<param>=<value>...]]
1132 type :: normal | member | ping
1134 Example:
1136 node node1
1138 node big_node attributes memory=64
1139 primitive
1141 The primitive command describes a resource. It may be referenced
1142 only once in group, clone, or master-slave objects. If it’s not
1143 referenced, then it is placed as a single resource in the CIB.
1144 Operations may be specified in three ways. "Anonymous" as a simple
1146 list of "op" specifications. Use that if you don’t want to
1147 reference the set of operations elsewhere. That’s by far the most
1148 common way to define operations. If reusing operation sets is
1149 desired, use the "operations" keyword along with the id to give the
1150 operations set a name and the id-ref to reference another set of
1151 operations.
1152 Operation’s attributes which are not recognized are saved as
1154 instance attributes of that operation. A typical example is
1155 OCF_CHECK_LEVEL.
1156 For multistate resources, roles are specified as role=<role>.
1158 Usage:
1160 primitive <rsc> [<class>:[<provider>:]]<type>
1162 [params attr_list]
1163 [meta attr_list]
1164 [utilization attr_list]
1165 [operations id_spec]
1166 [op op_type [<attribute>=<value>...] ...]
1167 attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
1169 id_spec :: $id=<id> | $id-ref=<id>
1170 op_type :: start | stop | monitor
1171 Example:
1173 primitive apcfence stonith:apcsmart \
1175 params ttydev=/dev/ttyS0 hostlist="node1 node2" \
1176 op start timeout=60s \
1177 op monitor interval=30m timeout=60s
1178 primitive www8 apache \
1180 params configfile=/etc/apache/www8.conf \
1181 operations $id-ref=apache_ops
1182 primitive db0 mysql \
1184 params config=/etc/mysql/db0.conf \
1185 op monitor interval=60s \
1186 op monitor interval=300s OCF_CHECK_LEVEL=10
1187 primitive r0 ocf:linbit:drbd \
1189 params drbd_resource=r0 \
1190 op monitor role=Master interval=60s \
1191 op monitor role=Slave interval=300s
1192 monitor
1194 Monitor is by far the most common operation. It is possible to add
1195 it without editing the whole resource. Also, long primitive
1196 definitions may be a bit uncluttered. In order to make this command
1197 as concise as possible, less common operation attributes are not
1198 available. If you need them, then use the op part of the primitive
1199 command.
1200 Usage:
1202 monitor <rsc>[:<role>] <interval>[:<timeout>]
1204 Example:
1206 monitor apcfence 60m:60s
1208 Note that after executing the command, the monitor operation may be
1210 shown as part of the primitive definition.
1211 group
1213 The group command creates a group of resources.
1214 Usage:
1216 group <name> <rsc> [<rsc>...]
1218 [meta attr_list]
1219 [params attr_list]
1220 attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
1222 Example:
1224 group internal_www disk0 fs0 internal_ip apache \
1226 meta target_role=stopped
1227 clone
1229 The clone command creates a resource clone. It may contain a single
1230 primitive resource or one group of resources.
1231 Usage:
1233 clone <name> <rsc>
1235 [meta attr_list]
1236 [params attr_list]
1237 attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
1239 Example:
1241 clone cl_fence apc_1 \
1243 meta clone-node-max=1 globally-unique=false
1244 ms (master)
1246 The ms command creates a master/slave resource type. It may contain
1247 a single primitive resource or one group of resources.
1248 Usage:
1250 ms <name> <rsc>
1252 [meta attr_list]
1253 [params attr_list]
1254 attr_list :: [$id=<id>] <attr>=<val> [<attr>=<val>...] | $id-ref=<id>
1256 Example:
1258 ms disk1 drbd1 \
1260 meta notify=true globally-unique=false
1261 Note on id-ref usage
1262 Instance or meta attributes (‘params` and meta) may contain a
1264 reference to another set of attributes. In that case, no other
1265 attributes are allowed. Since attribute sets’ ids, though they do
1266 exist, are not shown in the crm, it is also possible to reference
1267 an object instead of an attribute set. crm will automatically
1268 replace such a reference with the right id:
1269 crm(live)configure# primitive a2 www-2 meta $id-ref=a1
1271 crm(live)configure# show a2
1272 primitive a2 ocf:heartbeat:apache \
1273 meta $id-ref="a1-meta_attributes"
1274 [...]
1275 It is advisable to give meaningful names to attribute sets which
1277 are going to be referenced.
1278 location
1280 location defines the preference of nodes for the given resource.
1281 The location constraints consist of one or more rules which specify
1282 a score to be awarded if the rule matches.
1283 Usage:
1285 location <id> <rsc> {node_pref|rules}
1287 node_pref :: <score>: <node>
1289 rules ::
1291 rule [id_spec] [$role=<role>] <score>: <expression>
1292 [rule [id_spec] [$role=<role>] <score>: <expression> ...]
1293 id_spec :: $id=<id> | $id-ref=<id>
1295 score :: <number> | <attribute> | [-]inf
1296 expression :: <simple_exp> [bool_op <simple_exp> ...]
1297 bool_op :: or | and
1298 simple_exp :: <attribute> [type:]<binary_op> <value>
1299 | <unary_op> <attribute>
1300 | date <date_expr>
1301 type :: string | version | number
1302 binary_op :: lt | gt | lte | gte | eq | ne
1303 unary_op :: defined | not_defined
1304 date_expr :: lt <end>
1306 | gt <start>
1307 | in_range start=<start> end=<end>
1308 | in_range start=<start> <duration>
1309 | date_spec <date_spec>
1310 duration|date_spec ::
1311 hours=<value>
1312 | monthdays=<value>
1313 | weekdays=<value>
1314 | yearsdays=<value>
1315 | months=<value>
1316 | weeks=<value>
1317 | years=<value>
1318 | weekyears=<value>
1319 | moon=<value>
1320 Examples:
1322 location conn_1 internal_www 100: node1
1324 location conn_1 internal_www \
1326 rule 50: #uname eq node1 \
1327 rule pingd: defined pingd
1328 location conn_2 dummy_float \
1330 rule -inf: not_defined pingd or pingd number:lte 0
1331 colocation (collocation)
1333 This constraint expresses the placement relation between two or
1334 more resources. If there are more than two resources, then the
1335 constraint is called a resource set. Collocation resource sets have
1336 an extra attribute to allow for sets of resources which don’t
1337 depend on each other in terms of state. The shell syntax for such
1338 sets is to put resources in parentheses.
1339 Usage:
1341 colocation <id> <score>: <rsc>[:<role>] <rsc>[:<role>] ...
1343 Example:
1345 colocation dummy_and_apache -inf: apache dummy
1347 colocation c1 inf: A ( B C )
1348 order
1350 This constraint expresses the order of actions on two resources or
1351 more resources. If there are more than two resources, then the
1352 constraint is called a resource set. Ordered resource sets have an
1353 extra attribute to allow for sets of resources whose actions may
1354 run in parallel. The shell syntax for such sets is to put resources
1355 in parentheses.
1356 Usage:
1358 order <id> score-type: <rsc>[:<action>] <rsc>[:<action>] ...
1360 [symmetrical=<bool>]
1361 score-type :: advisory | mandatory | <score>
1363 Example:
1365 order c_apache_1 mandatory: apache:start ip_1
1367 order o1 inf: A ( B C )
1368 property
1370 Set the cluster (crm_config) options.
1371 Usage:
1373 property [$id=<set_id>] <option>=<value> [<option>=<value> ...]
1375 Example:
1377 property stonith-enabled=true
1379 rsc_defaults
1381 Set defaults for the resource meta attributes.
1382 Usage:
1384 rsc_defaults [$id=<set_id>] <option>=<value> [<option>=<value> ...]
1386 Example:
1388 rsc_defaults failure-timeout=3m
1390 role
1392 An ACL role is a set of rules which describe access rights to CIB.
1393 Rules consist of an access right read, write, or deny and a
1394 specification denoting part of the configuration to which the
1395 access right applies. The specification can be an XPath or a
1396 combination of tag and id references. If an attribute is appended,
1397 then the specification applies only to that attribute of the
1398 matching element.
1399 There is a number of shortcuts for XPath specifications. The meta,
1401 params, and utilization shortcuts reference resource meta
1402 attributes, parameters, and utilization respectively. The location
1403 may be used to specify location constraints most of the time to
1404 allow resource move and unmove commands. The property references
1405 cluster properties. The node allows reading node attributes.
1406 nodeattr and nodeutil reference node attributes and node capacity
1407 (utilization). The status shortcut references the whole status
1408 section of the CIB. Read access to status is necessary for various
1409 monitoring tools such as crm_mon(8) (aka crm status).
1410 Usage:
1412 role <role-id> rule [rule ...]
1414 rule :: acl-right cib-spec [attribute:<attribute>]
1416 acl-right :: read | write | deny
1418 cib-spec :: xpath-spec | tag-ref-spec
1420 xpath-spec :: xpath:<xpath> | shortcut
1421 tag-ref-spec :: tag:<tag> | ref:<id> | tag:<tag> ref:<id>
1422 shortcut :: meta:<rsc>[:<attr>]
1424 params:<rsc>[:<attr>]
1425 utilization:<rsc>
1426 location:<rsc>
1427 property[:<attr>]
1428 node[:<node>]
1429 nodeattr[:<attr>]
1430 nodeutil[:<node>]
1431 status
1432 Example:
1434 role app1_admin \
1436 write meta:app1:target-role \
1437 write meta:app1:is-managed \
1438 write location:app1 \
1439 read ref:app1
1440 user
1442 Users which normally cannot view or manage cluster configuration
1443 can be allowed access to parts of the CIB. The access is defined by
1444 a set of read, write, and deny rules as in role definitions or by
1445 referencing roles. The latter is considered best practice.
1446 Usage:
1448 user <uid> {roles|rules}
1450 roles :: role:<role-ref> [role:<role-ref> ...]
1452 rules :: rule [rule ...]
1453 Example:
1455 user joe \
1457 role:app1_admin \
1458 role:read_all
1459 op_defaults
1461 Set defaults for the operations meta attributes.
1462 Usage:
1464 op_defaults [$id=<set_id>] <option>=<value> [<option>=<value> ...]
1466 Example:
1468 op_defaults record-pending=true
1470 show
1472 The show command displays objects. It may display all objects or a
1473 set of objects. The user may also choose to see only objects which
1474 were changed. Optionally, the XML code may be displayed instead of
1475 the CLI representation.
1476 Usage:
1478 show [xml] [<id> ...]
1480 show [xml] changed
1481 edit
1483 This command invokes the editor with the object description. As
1484 with the show command, the user may choose to edit all objects or a
1485 set of objects.
1486 If the user insists, he or she may edit the XML edition of the
1488 object. If you do that, don’t modify any id attributes.
1489 Usage:
1491 edit [xml] [<id> ...]
1493 edit [xml] changed
1494 filter
1496 This command filters the given CIB elements through an external
1497 program. The program should accept input on stdin and send output
1498 to stdout (the standard UNIX filter conventions). As with the show
1499 command, the user may choose to filter all or just a subset of
1500 elements.
1501 It is possible to filter the XML representation of objects, but
1503 probably not as useful as the configuration language. The
1504 presentation is somewhat different from what would be displayed by
1505 the show command---each element is shown on a single, i.e. there
1506 are no backslashes and no other embelishments.
1507 Don’t forget to put quotes around the filter if it contains spaces.
1509 Further, if you use this in a single-shot mode (from the sh command
1510 line), protect all quotes with a backslash. Otherwise, they won’t
1511 reach the crm shell parser.
1512 Usage:
1514 filter <prog> [xml] [<id> ...]
1516 filter <prog> [xml] changed
1517 Examples:
1519 filter "sed '/^primitive/s/target-role=[^ ]*//'"
1521 delete
1523 Delete one or more objects. If an object to be deleted belongs to a
1524 container object, such as a group, and it is the only resource in
1525 that container, then the container is deleted as well. Any related
1526 constraints are removed as well.
1527 Usage:
1529 delete <id> [<id>...]
1531 default-timeouts
1533 This command takes the timeouts from the actions section of the
1534 resource agent meta-data and sets them for the operations of the
1535 primitive.
1536 Usage:
1538 default-timeouts <id> [<id>...]
1540 Note on default-timeouts
1541 You may be happy using this, but your applications may not. And it
1543 will tell you so at the worst possible moment. You have been
1544 warned.
1545 rename
1547 Rename an object. It is recommended to use this command to rename a
1548 resource, because it will take care of updating all related
1549 constraints and a parent resource. Changing ids with the edit
1550 command won’t have the same effect.
1551 If you want to rename a resource, it must be in the stopped state.
1553 Usage:
1555 rename <old_id> <new_id>
1557 refresh
1559 Refresh the internal structures from the CIB. All changes made
1560 during this session are lost.
1561 Usage:
1563 refresh
1565 erase
1567 The erase clears all configuration. Apart from nodes. To remove
1568 nodes, you have to specify an additional keyword nodes.
1569 Note that removing nodes from the live cluster may have some
1571 strange/interesting/unwelcome effects.
1572 Usage:
1574 erase [nodes]
1576 ptest
1578 Show PE (Policy Engine) motions using ptest(8).
1579 A CIB is constructed using the current user edited configuration
1581 and the status from the running CIB. The resulting CIB is run
1582 through ptest to show changes which would happen if the
1583 configuration is committed.
1584 The status section may be loaded from another source and modified
1586 using the cibstatus level commands. In that case, the ptest command
1587 will issue a message informing the user that the Policy Engine
1588 graph is not calculated based on the current status section and
1589 therefore won’t show what would happen to the running but some
1590 imaginary cluster.
1591 If you have graphviz installed and X11 session, dotty(1) is run to
1593 display the changes graphically.
1594 Add a string of v characters to increase verbosity. ptest can also
1596 show allocation scores. utilization turns on information about the
1597 remaining capacity of nodes. With the actions option, ptest will
1598 print all resource actions.
1599 Usage:
1601 ptest [nograph] [v...] [scores] [actions] [utilization]
1603 Examples:
1605 ptest scores
1607 ptest vvvvv
1608 cib (shadow CIBs)
1610 This level is for management of shadow CIBs. It is available at the
1611 configure level to enable saving intermediate changes to a shadow CIB
1612 instead of to the live cluster. This short excerpt shows how:
1613 crm(live)configure# cib new test-2
1615 INFO: test-2 shadow CIB created
1616 crm(test-2)configure# commit
1617 Note how the current CIB in the prompt changed from live to test-2
1619 after issuing the cib new command. See also the CIB shadow management
1620 for more information.
1621 cibstatus
1623 Enter edit and manage the CIB status section level. See the CIB
1624 status management section.
1625 template
1627 The specified template is loaded into the editor. It’s up to the
1628 user to make a good CRM configuration out of it. See also the
1629 template section.
1630 Usage:
1632 template [xml] url
1634 Example:
1636 template two-apaches.txt
1638 commit
1640 Commit the current configuration to the CIB in use. As noted
1641 elsewhere, commands in a configure session don’t have immediate
1642 effect on the CIB. All changes are applied at one point in time,
1643 either using commit or when the user leaves the configure level. In
1644 case the CIB in use changed in the meantime, presumably by somebody
1645 else, the crm shell will refuse to apply the changes. If you know
1646 that it’s fine to still apply them add force.
1647 Usage:
1649 commit [force]
1651 verify
1653 Verify the contents of the CIB which would be committed.
1654 Usage:
1656 verify
1658 upgrade
1660 If you get the CIB not supported error, which typically means that
1661 the current CIB version is coming from the older release, you may
1662 try to upgrade it to the latest revision. The command to perform
1663 the upgrade is:
1664 # cibadmin --upgrade --force
1666 If we don’t recognize the current CIB as the old one, but you’re
1668 sure that it is, you may force the command.
1669 Usage:
1671 upgrade [force]
1673 save
1675 Save the configuration of the current level to a file. Optionally,
1676 as XML.
1677 Usage:
1679 save [xml] <file>
1681 Example:
1683 save myfirstcib.txt
1685 load
1687 Load a part of configuration (or all of it) from a local file or a
1688 network URL. The replace method replaces the current configuration
1689 with the one from the source. The update tries to import the
1690 contents into the current configuration. The file may be a CLI file
1691 or an XML file.
1692 Usage:
1694 load [xml] <method> URL
1696 method :: replace | update
1698 Example:
1700 load xml update myfirstcib.xml
1702 load xml replace http://storage.big.com/cibs/bigcib.xml
1703 xml
1705 Even though we promissed no xml, it may happen, but hopefully very
1706 very seldom, that an element from the CIB cannot be rendered in the
1707 configuration language. In that case, the element will be shown as
1708 raw xml, prefixed by this command. That element can then be edited
1709 like any other. If the shell finds out that after the change it can
1710 digest it, then it is going to be converted into the normal
1711 configuration language. Otherwise, there is no need to use xml for
1712 configuration.
1713 Usage:
1715 xml <xml>
1717 template
1719 User may be assisted in the cluster configuration by templates prepared
1720 in advance. Templates consist of a typical ready configuration which
1721 may be edited to suit particular user needs.
1722 This command enters a template level where additional commands for
1724 configuration/template management are available.
1725 new
1727 Create a new configuration from one or more templates. Note that
1728 configurations and templates are kept in different places, so it is
1729 possible to have a configuration name equal a template name.
1730 If you already know which parameters are required, you can set them
1732 directly on the command line.
1733 The parameter name id is set by default to the name of the
1735 configuration.
1736 Usage:
1738 new <config> <template> [<template> ...] [params name=value ...]"
1740 Examples:
1742 new vip virtual-ip
1744 new bigfs ocfs2 params device=/dev/sdx8 directory=/bigfs
1745 load
1747 Load an existing configuration. Further edit, show, and apply
1748 commands will refer to this configuration.
1749 Usage:
1751 load <config>
1753 edit
1755 Edit current or given configuration using your favourite editor.
1756 Usage:
1758 edit [<config>]
1760 delete
1762 Remove a configuration. The loaded (active) configuration may be
1763 removed by force.
1764 Usage:
1766 delete <config> [force]
1768 list
1770 List existing configurations or templates.
1771 Usage:
1773 list [templates]
1775 apply
1777 Copy the current or given configuration to the current CIB. By
1778 default, the CIB is replaced, unless the method is set to "update".
1779 Usage:
1781 apply [<method>] [<config>]
1783 method :: replace | update
1785 show
1787 Process the current or given configuration and display the result.
1788 Usage:
1790 show [<config>]
1792 cibstatus
1794 The status section of the CIB keeps the current status of nodes and
1795 resources. It is modified only on events, i.e. when some resource
1796 operation is run or node status changes. For obvious reasons, the CRM
1797 has no user interface with which it is possible to affect the status
1798 section. From the user’s point of view, the status section is
1799 essentially a read-only part of the CIB. The current status is never
1800 even written to disk, though it is available in the PE (Policy Engine)
1801 input files which represent the history of cluster motions. The current
1802 status may be read using the cibadmin -Q command.
1803 It may sometimes be of interest to see how status changes would affect
1805 the Policy Engine. The set of ‘cibstatus` level commands allow the user
1806 to load status sections from various sources and then insert or modify
1807 resource operations or change nodes’ state.
1808 The effect of those changes may then be observed by running the ptest
1810 command at the configure level or simulate and run commands at this
1811 level. The ptest runs with the user edited CIB whereas the latter two
1812 commands run with the CIB which was loaded along with the status
1813 section.
1814 The simulate and run commands as well as all status modification
1816 commands are implemented using crm_simulate(8).
1817 load
1819 Load a status section from a file, a shadow CIB, or the running
1820 cluster. By default, the current (live) status section is modified.
1821 Note that if the live status section is modified it is not going to
1822 be updated if the cluster status changes, because that would
1823 overwrite the user changes. To make crm drop changes and resume use
1824 of the running cluster status, run load live.
1825 All CIB shadow configurations contain the status section which is a
1827 snapshot of the status section taken at the time the shadow was
1828 created. Obviously, this status section doesn’t have much to do
1829 with the running cluster status, unless the shadow CIB has just
1830 been created. Therefore, the ptest command by default uses the
1831 running cluster status section.
1832 Usage:
1834 load {<file>|shadow:<cib>|live}
1836 Example:
1838 load bug-12299.xml
1840 load shadow:test1
1841 save
1843 The current internal status section with whatever modifications
1844 were performed can be saved to a file or shadow CIB.
1845 If the file exists and contains a complete CIB, only the status
1847 section is going to be replaced and the rest of the CIB will remain
1848 intact. Otherwise, the current user edited configuration is saved
1849 along with the status section.
1850 Note that all modifications are saved in the source file as soon as
1852 they are run.
1853 Usage:
1855 save [<file>|shadow:<cib>]
1857 Example:
1859 save bug-12299.xml
1861 origin
1863 Show the origin of the status section currently in use. This
1864 essentially shows the latest load argument.
1865 Usage:
1867 origin
1869 show
1871 Show the current status section in the XML format. Brace yourself
1872 for some unreadable output. Add changed option to get a human
1873 readable output of all changes.
1874 Usage:
1876 show [changed]
1878 node
1880 Change the node status. It is possible to throw a node out of the
1881 cluster, make it a member, or set its state to unclean.
1882 online
1884 Set the node_state crmd attribute to online and the expected
1885 and join attributes to member. The effect is that the node
1886 becomes a cluster member.
1887 offline
1889 Set the node_state crmd attribute to offline and the expected
1890 attribute to empty. This makes the node cleanly removed from
1891 the cluster.
1892 unclean
1894 Set the node_state crmd attribute to offline and the expected
1895 attribute to member. In this case the node has unexpectedly
1896 disappeared.
1897 Usage:
1899 node <node> {online|offline|unclean}
1901 Example:
1903 node xen-b unclean
1905 op
1907 Edit the outcome of a resource operation. This way you can tell CRM
1908 that it ran an operation and that the resource agent returned
1909 certain exit code. It is also possible to change the operation’s
1910 status. In case the operation status is set to something other than
1911 done, the exit code is effectively ignored.
1912 Usage:
1914 op <operation> <resource> <exit_code> [<op_status>] [<node>]
1916 operation :: probe | monitor[:<n>] | start | stop |
1918 promote | demote | notify | migrate_to | migrate_from
1919 exit_code :: <rc> | success | generic | args |
1920 unimplemented | perm | installed | configured | not_running |
1921 master | failed_master
1922 op_status :: pending | done | cancelled | timeout | notsupported | error
1923 n :: the monitor interval in seconds; if omitted, the first
1925 recurring operation is referenced
1926 rc :: numeric exit code in range 0..9
1927 Example:
1929 op start d1 xen-b generic
1931 op start d1 xen-b 1
1932 op monitor d1 xen-b not_running
1933 op stop d1 xen-b 0 timeout
1934 quorum
1936 Set the quorum value.
1937 Usage:
1939 quorum <bool>
1941 Example:
1943 quorum false
1945 run
1947 Run the policy engine with the edited status section.
1948 Add a string of v characters to increase verbosity. Specify scores
1950 to see allocation scores also. utilization turns on information
1951 about the remaining capacity of nodes.
1952 If you have graphviz installed and X11 session, dotty(1) is run to
1954 display the changes graphically.
1955 Usage:
1957 run [nograph] [v...] [scores] [utilization]
1959 Example:
1961 run
1963 simulate
1965 Run the policy engine with the edited status section and simulate
1966 the transition.
1967 Add a string of v characters to increase verbosity. Specify scores
1969 to see allocation scores also. utilization turns on information
1970 about the remaining capacity of nodes.
1971 If you have graphviz installed and X11 session, dotty(1) is run to
1973 display the changes graphically.
1974 Usage:
1976 simulate [nograph] [v...] [scores] [utilization]
1978 Example:
1980 simulate
1982 end (cd, up)
1984 The end command ends the current level and the user moves to the parent
1985 level. This command is available everywhere.
1986 Usage:
1988 end
1990 help
1992 The help command prints help for the current level or for the specified
1993 topic (command). This command is available everywhere.
1994 Usage:
1996 help [<topic>]
1998 quit (exit, bye)
2000 Leave the program.
2001
2003 Even though all sensible configurations (and most of those that are
2004 not) are going to be supported by the crm shell, I suspect that it may
2005 still happen that certain XML constructs may confuse the tool. When
2006 that happens, please file a bug report.
2007 The crm shell will not try to update the objects it does not
2009 understand. Of course, it is always possible to edit such objects in
2010 the XML format.
2011
2013 Written by Dejan Muhamedagic, <dejan@suse.de>
2014
2016 crm_resource(8), crm_attribute(8), crm_mon(8), cib_shadow(8), ptest(8),
2017 dotty(1), crm_simulate(8), cibadmin(8)
2018
2020 Copyright (C) 2008-2011 Dejan Muhamedagic. Free use of this software is
2021 granted under the terms of the GNU General Public License (GPL).
2022crm 1.1 09/07/2011 CRM(8)