PCS(8)

📦

version 0.12.3 · 7 versions

0.12.3 · fedora 43, fedora 44 (latest)
0.10.11 · ubuntu jammy
0.11.7 · ubuntu noble
0.12.2 · fedora 44, ubuntu stonking
0.11.5 · debian bookworm
0.12.1 · fedora 43, ubuntu questing, ubuntu resolute
0.12.0.2 · debian trixie

💖 PCS(8) 💖

okay bestie, welcome to the PCS(8) manual page. this is the pacemaker/corosync configuration system, and she's a whole icon. let's get into it.

✨ NAME ✨

pcs — pacemaker/corosync configuration system

🌸 SYNOPSIS 🌸

pcs [-f file] [-h] [commands]...

🦋 DESCRIPTION 🦋

Control and configure pacemaker and corosync. like, that's her job. she controls and configures pacemaker and corosync. periodt.

💅 OPTIONS 💅

-h, --help — display usage and exit. she's giving helpful and then leaving.
-f file — perform actions on file instead of active CIB. Commands supporting the option use the initial state of the specified file as their input and then overwrite the file with the state reflecting the requested operation(s). A few commands only use the specified file in read-only mode since their effect is not a CIB modification. so like, it's file mode, not live CIB mode.
--debug — print all network traffic and external commands run. no cap, full transparency, it's giving surveillance but for debugging.
--version — print pcs version information. List pcs capabilities if --full is specified. so --version alone is just the version, but --version --full spills the capabilities tea.
--request-timeout=<timeout> — timeout for each outgoing request to another node in seconds. Default is 60s.

🫶 Commands: 🫶

cluster — configure cluster options and nodes.
resource — manage cluster resources.
stonith — manage fence devices.
constraint — manage resource constraints.
property — manage pacemaker properties.
acl — manage pacemaker access control lists.
qdevice — manage quorum device provider on the local host.
quorum — manage cluster quorum settings.
booth — manage booth (cluster ticket manager).
status — view cluster status.
config — view and manage cluster configuration.
pcsd — manage pcs daemon.
host — manage hosts known to pcs/pcsd.
node — manage cluster nodes.
alert — manage pacemaker alerts.
client — manage pcsd client configuration.
dr — manage disaster recovery configuration.
tag — manage pacemaker tags.
cib — manage CIB (Cluster Information Base).

🎀 resource 🎀

`[status [<resource id | tag id>] [node=<node>] [--hide-inactive]]`

Show status of all currently configured resources. If --hide-inactive is specified, only show active resources. If a resource or tag id is specified, only show status of the specified resource or resources in the specified tag. If node is specified, only show status of resources configured for the specified node.

`config [--show-secrets] [--output-format text|cmd|json] [<resource id>]...`

Show options of all currently configured resources or if resource ids are specified show the options for the specified resource ids. If --show-secrets is specified, display the values of secret attributes in the configuration text output. By default, only attribute names are displayed and values are omitted. There are 3 formats of output available: 'cmd', 'json' and 'text', default is 'text'. Format 'text' is a human friendly output. Format 'cmd' prints pcs commands which can be used to recreate the same configuration. Format 'json' is a machine oriented output of the configuration.

`list [filter] [--nodesc]`

Show list of all available resource agents (if filter is provided then only resource agents matching the filter will be shown). If --nodesc is used then descriptions of resource agents are not printed.

`describe [<standard>:[<provider>:]]<type> [--full]`

Show options for the specified resource. If --full is specified, all options including advanced and deprecated ones are shown.

`create`

create <resource id> [<standard>:[<provider>:]]<type> [<resource options>] [op <operation action> <operation options> [<operation action> <operation options>]...] [meta <meta options>] [clone [<clone id>] [<clone meta options>] | promotable [<clone id>] [<promotable meta options>] | --group <group id> [--before <resource id> | --after <resource id>] | bundle <bundle id>] [--disabled] [--agent-validation] [--no-default-ops] [--wait[=n]]
create --future <resource id> [<standard>:[<provider>:]]<type> [<resource options>] [op <operation action> <operation options> [<operation action> <operation options>]...] [meta <meta options>] [clone [<clone id>] [meta <clone meta options>] | promotable [<clone id>] [meta <promotable meta options>] | group <group id> [before <resource id> | after <resource id>] | bundle <bundle id>] [--disabled] [--agent-validation] [--no-default-ops] [--wait[=n]]

Create specified resource.

If clone is used, a clone resource is created. If promotable is used, a promotable clone resource is created.

If --group is specified, the resource is added to the group named. You can use --before or --after to specify the position of the added resource relatively to some resource already existing in the group.

If bundle is specified, resource will be created inside of the specified bundle.

If --disabled is specified, the resource is not started automatically.

If --agent-validation is specified, resource agent validate-all action will be used to validate resource options and will prevent creating a misconfigured resource. If --agent-validation is not specified, the validation will be done anyway, but it will only produce warnings not preventing the resource from being created.

If --no-default-ops is specified, only monitor operations are created for the resource and all other operations use default settings.

If --wait is specified, pcs will wait up to 'n' seconds for the resource to start and then return 0 if the resource is started, or 1 if the resource has not yet started. If 'n' is not specified it defaults to 60 minutes.

Specifying --future switches to the new command format that changes the way clone and promotable meta options are expected to be specified.

Example: Create a new resource called 'VirtualIP' with IP address 192.168.0.99, netmask of 32, monitored everything 30 seconds, on eth2:

pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=32 nic=eth2 op monitor interval=30s

`delete <resource id|group id|bundle id|clone id>... [--no-stop] [--future]`

Deletes the specified resources, groups, bundles or clones (and all resources within the groups/bundles/clones).

If --no-stop is specified, the resources will not be stopped before their deletion. This may result in orphaned resources being left behind in case the deleted resources are not already stopped.

Using --force currently also means the resources will not be stopped before their deletion. If you need to use --force and still want to stop the resources, you need to combine it with the --future flag.

`remove <resource id|group id|bundle id|clone id>... [--no-stop] [--future]`

Deletes the specified resources, groups, bundles or clones (and all resources within the groups/bundles/clones).

If --no-stop is specified, the resources will not be stopped before their deletion. This may result in orphaned resources being left behind in case the deleted resources are not already stopped.

`enable <resource id | tag id>... [--wait[=n]]`

Allow the cluster to start the resources. Depending on the rest of the configuration (constraints, options, failures, etc), the resources may remain stopped. If --wait is specified, pcs will wait up to 'n' seconds for the resources to start and then return 0 if the resources are started, or 1 if the resources have not yet started. If 'n' is not specified it defaults to 60 minutes.

`disable <resource id | tag id>... [--safe [--brief] [--no-strict]] [--simulate [--brief]] [--wait[=n]]`

Attempt to stop the resources if they are running and forbid the cluster from starting them again. Depending on the rest of the configuration (constraints, options, failures, etc), the resources may remain started.

If --safe is specified, no changes to the cluster configuration will be made if other than specified resources would be affected in any way. If --brief is also specified, only errors are printed.

If --no-strict is specified, no changes to the cluster configuration will be made if other than specified resources would get stopped or demoted. Moving resources between nodes is allowed.

If --simulate is specified, no changes to the cluster configuration will be made and the effect of the changes will be printed instead. If --brief is also specified, only a list of affected resources not specified in the command will be printed.

If --wait is specified, pcs will wait up to 'n' seconds for the resources to stop and then return 0 if the resources are stopped or 1 if the resources have not stopped. If 'n' is not specified it defaults to 60 minutes.

safe-disable 💅

safe-disable <resource id | tag id>... [--brief] [--no-strict]
[--simulate [--brief]] [--wait[=n]] [--force]

Okay so bestie, this one tries to stop the resources if they're running and forbid the cluster from ever starting them again. Periodt. But heads up — depending on the rest of your config (constraints, options, failures, all of that), the resources might lowkey just... stay started. And if anything other than the resources you specified would be affected in any way, no changes to the cluster configuration get made. None. Zero. Nada. 🫶

--brief — only errors get printed. That's it, that's the whole vibe.
--no-strict — no changes to the cluster configuration will be made if anything other than the specified resources would get stopped or demoted. Moving resources between nodes is allowed tho. 🦋
--simulate — no changes to the cluster configuration will be made, and instead you just get the effect of the changes printed out. Iconic preview mode. And if --brief is also specified, only a list of affected resources not specified in the command will be printed.
--wait — pcs will wait up to n seconds for the resources to stop, then return 0 if the resources are stopped or 1 if they have not stopped. If n isn't specified it defaults to 60 minutes.
--force — checks for safe disable get skipped entirely. Main character energy, no safety net. 💀

restart ✨

restart <resource id> [node] [--wait=n]

Restart the resource specified. If you name a node and the resource is a clone or a bundle, it will be restarted only on that node. And if --wait is specified, we wait up to n seconds for the resource to be restarted and return 0 if the restart was successful or 1 if it was not. Simple as. 🎀

description 🌸

description <resource id>

This command is an alias of cib element description. Get the description of a CIB element. Yep, that's the whole thing.

description <resource id> <description text>

Also an alias of cib element description — this version sets a description on a CIB element. Wanna remove a description? Set it to an empty string. Bye bestie. 👋

debug-start 🔥

debug-start <resource id> [--full]

This command forces the specified resource to start on this node, ignoring the cluster's recommendations, and prints the output from starting the resource. Using --full gives you more detailed output. Mainly used for debugging resources that fail to start. Not me debugging at 2am... 🙈

debug-stop 🔥

debug-stop <resource id> [--full]

Same deal, but for stopping: forces the specified resource to stop on this node, ignores the cluster recommendations, prints the output from stopping the resource. --full = more detailed output. Mainly for debugging resources that fail to stop.

debug-promote 🔥

debug-promote <resource id> [--full]

Forces the specified resource to be promoted on this node, ignoring the cluster recommendations, and prints the output from promoting the resource. --full gives more detailed output. Mainly used for debugging resources that fail to promote.

debug-demote 🔥

debug-demote <resource id> [--full]

Forces the specified resource to be demoted on this node, ignoring the cluster recommendations, and prints the output from demoting the resource. --full for the detailed version. Mainly used for debugging resources that fail to demote.

debug-monitor 🔥

debug-monitor <resource id> [--full]

Forces the specified resource to be monitored on this node, ignoring the cluster recommendations, and prints the output from monitoring the resource. --full = more detailed output. Mainly used for debugging resources that fail to be monitored.

move 🦋

move <resource id> [destination node] [--promoted] [--strict]
[--wait[=n]]

Move the resource off the node it's currently running on. How? By creating a -INFINITY location constraint to ban the node. If a destination node is specified, the resource gets moved to that node by creating an INFINITY location constraint to prefer the destination node. The constraint needed for moving the resource gets automatically removed once the resource is running on its new location. Slay.

The command will fail in case it's not possible to verify that the resource will not be moved back after deleting the constraint. And if that happens after the location constraint has already been created, the constraint will be left in the configuration. Awkward. 😭

--strict — the command will also fail if other resources would be affected.
--promoted — the scope of the command is limited to the Promoted role, and a promotable clone id must be used (instead of the resource id).
--wait — pcs will wait up to n seconds for the resource to move and then return 0 on success or 1 on error. If n isn't specified it defaults to 60 minutes.

NOTE: This command has been changed in pcs-0.11. It is equivalent to the command resource move <resource id> --autodelete from pcs-0.10.9. Legacy functionality of the resource move command is still available as resource move-with-constraint <resource id>.

If you want the resource to preferably avoid running on some nodes but still be able to failover to them, use pcs constraint location avoids. 💖

move-with-constraint 🎀

move-with-constraint <resource id> [destination node]
[lifetime=<lifetime>] [--promoted] [--wait[=n]]

Move the resource off the node it's currently running on by creating a -INFINITY location constraint to ban the node. If a destination node is specified, the resource gets moved to that node by creating an INFINITY location constraint to prefer the destination node.

If lifetime is specified, the constraint will expire after that time. Otherwise it defaults to infinity, and the constraint can be cleared manually with pcs resource clear or pcs constraint delete. Lifetime is expected to be specified as an ISO 8601 duration (see https://en.wikipedia.org/wiki/ISO_8601#Durations).

--promoted — the scope of the command is limited to the Promoted role, and a promotable clone id must be used (instead of the resource id).
--wait — pcs will wait up to n seconds for the resource to move and then return 0 on success or 1 on error. If n isn't specified it defaults to 60 minutes.

And again, if you want the resource to preferably avoid running on some nodes but be able to failover to them, use pcs constraint location avoids. ✨

ban 💅

ban <resource id> [node] [--promoted] [lifetime=<lifetime>] [--wait[=n]]

Prevent the resource id specified from running on the node — or on the current node it's running on, if no node is specified — by creating a -INFINITY location constraint. Not on my watch. 🚫

--promoted — the scope of the command is limited to the Promoted role, and a promotable clone id must be used (instead of the resource id).
lifetime=<lifetime> — if specified, the constraint expires after that time. Otherwise it defaults to infinity, and the constraint can be cleared manually with pcs resource clear or pcs constraint delete. Lifetime is expected to be specified as an ISO 8601 duration (see https://en.wikipedia.org/wiki/ISO_8601#Durations).
--wait — pcs will wait up to n seconds for the resource to move and then return 0 on success or 1 on error. If n isn't specified it defaults to 60 minutes.

Yep, and if you want the resource to preferably avoid running on some nodes but still be able to failover to them, use pcs constraint location avoids. 🌈

clear 🧚

clear <resource id> [node] [--promoted] [--expired] [--wait[=n]]

Remove constraints created by move and/or ban on the specified resource (and node, if specified). Spring cleaning but for constraints. 🌸

--promoted — the scope of the command is limited to the Promoted role, and a promotable clone id must be used (instead of the resource id).
--expired — only constraints with expired lifetimes will be removed.
--wait — pcs will wait up to n seconds for the operation to finish (including starting and/or moving resources if appropriate) and then return 0 on success or 1 on error. If n isn't specified it defaults to 60 minutes.

standards ⭐

List available resource agent standards supported by this installation (OCF, LSB, etc.). The whole roster, right there.

providers ⭐

List available OCF resource agent providers. Look at them go. 👑

agents ⭐

agents [standard[:provider]]

List available agents, optionally filtered by standard and provider. Filtering? We love a curated feed. ✨

update 💜

update <resource id> [resource options] [op [<operation action>
<operation options>]...] [meta <meta options>] [--agent-validation]
[--wait[=n]]

Add, remove or change options of the specified resource, clone or multi-state resource. Unspecified options get kept unchanged. And if you want to remove an option, set it to an empty value, i.e. option_name=. Poof, gone. 💨

If an operation (op) is specified, it will update the first found operation with the same action on the specified resource. If no operation with that action exists, then a new operation gets created.

WARNING: all existing options on the updated operation will be reset if not specified.

If you want to create multiple monitor operations you should use the op add & op remove commands instead.

If meta attributes are specified, they will not be validated by this command. For meta attribute validation use the pcs resource meta command instead.

--agent-validation — the resource agent validate-all action will be used to validate resource options and will prevent creating a misconfigured resource. If --agent-validation is not specified, the validation will be done anyway, but it will only produce warnings, not preventing the resource from being updated.
--wait — pcs will wait up to n seconds for the changes to take effect and then return 0 if the changes have been processed or 1 otherwise. If n isn't specified it defaults to 60 minutes.

op add 🍓

op add <resource id> <operation action> [operation properties]

Add an operation for the specified resource. Short, sweet, iconic. 💖

op delete <resource id> <operation action> [<operation properties>...] — yeets that one operation you specified 💅 but bestie, listen: you have to give the exact operation properties or it won't cleanly remove the existing operation. Like, precision is the whole vibe here, no cap.
op delete <operation id> — nukes the operation with that exact id. simple. iconic. done. ✨
op remove <resource id> <operation action> [<operation properties>...] — same thing as op delete, just wearing a different outfit 💖. Removes the operation you named — and yeah, again, you need the exact operation properties for the removal to actually work properly.
op remove <operation id> — removes the operation by its id. twin of the delete version, we love a matching set 🫶.
op defaults [config] [--all | --no-expire-check] [--full] [--output-format text|cmd|json] — shows you all the currently configured default values for operations 📋. The tea:
- --all → also lists the expired sets of values too, not just the live ones.
- --full → also lists the ids, so you get the whole picture.
- --no-expire-check → skips checking whether sets of values are expired at all. no judgement, just data.
- --output-format text|cmd|json → three flavours available: 'cmd', 'json', and 'text'. default is 'text'. 'text' is the human-friendly one 🌸. 'cmd' prints out pcs commands you can use to recreate the exact same configuration 🔥. 'json' is the machine-oriented output of the configuration — for the robots 🤖.
op defaults set create [<set options>] [meta [<name>=<value>]...] [rule [<expression>]] — creates a brand new set of default values for resource / stonith device operations ✨. You can also hand it a rule that describes which resources / stonith devices and / or operations the set applies to. main character energy.

The set options are: id, score.

An expression looks like one of these, bestie:

op <operation name> [interval=<interval>]
resource [<standard>]:[<provider>]:[<type>]
defined|not_defined <node attribute>
<node attribute> lt|gt|lte|gte|eq|ne [string|integer|number|version] <value>
date gt|lt <date>
date in_range [<date>] to <date>
date in_range <date> to duration <duration options>
date-spec <date-spec options>
<expression> and|or <expression>
(<expression>)

In a resource expression you can specify all of 'standard', 'provider' and 'type', or any of them, whatever you need. For example: 'resource ocf::' matches all resources of the 'ocf' standard 👑, while 'resource ::Dummy' matches all resources of 'Dummy' type no matter what their standard and provider are. And if you need to name a full agent that has no provider, use a double colon — like 'resource stonith::fence_virt'. iykyk 💅

Dates are expected to be in ISO 8601 format. that's the rules.

Duration options are: years, months, weeks, days, hours, minutes, seconds. The value for each of these is an integer.

Date-spec options are: years, weekyears, months, weeks, yeardays, monthdays, weekdays, hours, minutes, seconds. The value for these is an integer, or a range written as integer-integer.

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values. so if they got their own thing going on, defaults just don't hit them. periodt.

op defaults set delete [<set id>]... — deletes the option sets you point at. bye bestie 👋.
op defaults set remove [<set id>]... — literally the same energy as op defaults set delete. deletes those option sets.
op defaults set update <set id> [meta [<name>=<value>]...] — adds, removes, or changes values in the set of default values you named for resource / stonith device operations 🎀. Anything you don't mention stays exactly as it was, untouched, living its best life. Wanna remove an option? set it to an empty value, i.e. 'option_name='.

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values. yes we're saying it again because it matters 💀.

op defaults update <name>=<value>... — adds, removes, or changes default values for operations 💜. This one's the simplified version, chef's kiss for when you're only managing a single set of default values. Unspecified options are kept unchanged. To remove an option, set it to an empty value, i.e. 'option_name='.

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values. (third time, because it's still true 🫶)

meta <resource id> <meta options> [--wait[=n]] — slaps the options you give onto the resource you named 🌈. Meta options go in name=value format, and you can remove an option by setting it with no value at all. If --wait is there, pcs waits up to 'n' seconds for the changes to land, then returns 0 if they got processed or 1 if they didn't. If you don't give 'n', it defaults to 60 minutes ⏳. Example, fresh from the source:

pcs resource meta TestResource failure-timeout=50 resource-stickiness=

group list — shows you every currently configured resource group and all the resources chilling inside them 🧚.
group add <group id> <resource id> [resource id] ... [resource id] [--before <resource id> | --after <resource id>] [--wait[=n]] — adds the resource you named to the group, and if that group doesn't exist yet it just creates it, no biggie ✨. If the resource was already hanging out in another group, it gets moved over to the new one. And if the old group ends up empty after the move, it gets deleted — and for cloned groups, the clone gets deleted too 💀. Heads up though: that delete can fail if the group is referenced somewhere in the configuration, like by constraints. If that happens, run 'pcs resource ungroup' before moving all the resources out of the group.

You can use --before or --after to set where the added resources land relative to some resource that's already in the group. And here's a fun trick: by adding resources to a group they're already in while giving --after or --before, you can actually move the resources around inside the group 🎀.

If --wait is specified, pcs waits up to 'n' seconds for the operation to finish (including moving resources if that applies) and then returns 0 on success or 1 on error. No 'n'? defaults to 60 minutes ⏳.

group delete <group id> [resource id]... [--wait[=n]] — removes the group (and bestie, note: this does not remove any resources from the cluster) — or, if you gave resource ids, it removes just those resources from the group. If --wait is specified, pcs waits up to 'n' seconds for the operation to finish (including moving resources if appropriate) and then returns 0 on success or 1 on error. If 'n' isn't given, it defaults to 60 minutes ⏳.
group remove <group id> [resource id]... [--wait[=n]] — same exact vibe as group delete: removes the group (again, note: this does not remove any resources from the cluster), or if resources are specified, removes those resources from the group. With --wait, pcs waits up to 'n' seconds for the operation to finish (including moving resources if appropriate) and returns 0 on success or 1 on error. No 'n' → 60 minutes ⏳.
ungroup <group id> [resource id]... [--wait[=n]] — you guessed it, it's the same as the delete/remove twins 💅. Removes the group (note: this does not remove any resources from the cluster), or if resources are specified, removes the specified resources from the group. --wait means pcs waits up to 'n' seconds for the operation to finish (including moving resources if appropriate) and returns 0 on success or 1 on error. 'n' defaults to 60 minutes ⏳.
clone <resource id | group id> [<clone id>] [meta <clone meta options>] [--wait[=n]] — sets up the resource or group you named as a clone 🔥. If --wait is specified, pcs waits up to 'n' seconds for the operation to finish (including starting clone instances if appropriate) and then returns 0 on success or 1 on error. No 'n'? 60 minutes ⏳.
promotable <resource id | group id> [<clone id>] [meta <clone meta options>] [--wait[=n]] — sets up the resource or group you named as a promotable clone 👑. This is an alias for 'pcs resource clone <resource id> promotable=true'.
unclone <clone id | resource id | group id> [--wait[=n]] — removes the clone you named, or the clone that contains the group or resource you named (don't worry, the resource or group itself will not be removed) 🙈. If --wait is specified, pcs waits up to 'n' seconds for the operation to finish (including stopping clone instances if appropriate) and then returns 0 on success or 1 on error. If 'n' isn't given it defaults to 60 minutes ⏳.
bundle create <bundle id> container <container type> [<container options>] [network <network options>] [port-map <port options>]... [storage-map <storage options>]... [meta <meta options>] [--disabled] [--wait[=n]] — creates a brand new bundle that's encapsulating no resources at all 🎀. You can use that bundle just as it is, or drop a resource into it whenever you feel like it. If --disabled is specified, the bundle does not start automatically. If --wait is specified, pcs waits up to 'n' seconds for the bundle to start and then returns 0 on success or 1 on error. No 'n'? 60 minutes ⏳.
bundle reset <bundle id> [container <container options>] [network <network options>] [port-map <port options>]... [storage-map <storage options>]... [meta <meta options>] [--disabled] [--wait[=n]] — configures the bundle you named with the options you give 💜. Unlike bundle update, this one resets the bundle according to those options — nothing from before is kept, it's a clean slate, no baggage. The resources inside the bundle stay exactly as they are though 🫶. If --disabled is specified, the bundle is not started automatically. If --wait is specified, pcs waits up to 'n' seconds for the bundle to start and then returns 0 on success or 1 on error. 'n' defaults to 60 minutes ⏳.
bundle update <bundle id> [container <container options>] [network <network options>] [port-map (add <port options>) | (delete | remove <id>...)]... [storage-map (add <storage options>) | (delete | remove <id>...)]... [meta <meta options>] [--wait[=n]] — adds, removes, or changes options on the bundle you named ✨. Anything you don't mention is kept unchanged, no surprises. Wanna remove an option? set it to an empty value, i.e. 'option_name='.

If you want to update a resource that's encapsulated inside the bundle, use the 'pcs resource update' command instead and pass the resource id — that's the move 🎯.

If --wait is specified, pcs waits up to 'n' seconds for the operation to finish (including moving resources if appropriate) and then returns 0 on success or 1 on error. If 'n' is not specified it defaults to 60 minutes ⏳.

manage <resource id | tag id>... [--monitor] — okay so this sets the resources you list to managed mode (which is the default, bestie 💅). If you add --monitor, it enables all monitor operations for those resources. Slay.
unmanage <resource id | tag id>... [--monitor] — this flips them to unmanaged mode. When a resource is unmanaged, the cluster is literally not allowed to start nor stop it. If you specify --monitor, it disables all monitor operations for the resources. No cap.
defaults [config] [--all | --no-expire-check] [--full] [--output-format text|cmd|json] — lists the currently configured default values for resources / stonith devices. If --all is given, it also lists expired sets of values. If --full is specified, it also lists ids. If --no-expire-check is specified, it does not evaluate whether sets of values are expired. There are 3 output formats available: 'cmd', 'json', and 'text' — default is 'text'. Format 'text' is human friendly. Format 'cmd' prints pcs commands which can be used to recreate the same configuration. Format 'json' is a machine oriented output of the configuration. ✨
defaults set create [<set options>] [meta [<name>=<value>]...] [rule [<expression>]] — creates a new set of default values for resources / stonith devices. You may specify a rule describing resources / stonith devices to which the set applies. 🫶
- Set options are: id, score
- Expression looks like one of the following:

resource [<standard>]:[<provider>]:[<type>]
date gt|lt <date>
date in_range [<date>] to <date>
date in_range <date> to duration <duration options>
date-spec <date-spec options>
<expression> and|or <expression>
(<expression>)

You may specify all or any of 'standard', 'provider' and 'type' in a resource expression. For example: 'resource ocf::' matches all resources of 'ocf' standard, while 'resource ::Dummy' matches all resources of 'Dummy' type regardless of their standard and provider. To specify a full name of an agent which does not have a provider, use a double colon, for example 'resource stonith::fence_virt'.
Dates are expected to conform to ISO 8601 format.
Duration options are: years, months, weeks, days, hours, minutes, seconds. Value for these options is an integer.
Date-spec options are: years, weekyears, months, weeks, yeardays, monthdays, weekdays, hours, minutes, seconds. Value for these options is an integer or a range written as integer-integer.

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values. 💀

defaults set delete [<set id>]... — deletes specified options sets. Bye bye 👋
defaults set remove [<set id>]... — also deletes specified options sets. Same energy, different name. 🦋
defaults set update <set id> [meta [<name>=<value>]...] — add, remove or change values in a specified set of default values for resources / stonith devices. Unspecified options will be kept unchanged. If you wish to remove an option, set it to empty value, i.e. 'option_name='. 🎀

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values. 💀

defaults update <name>=<value>... — add, remove or change default values for resources / stonith devices. This is a simplified command useful for cases when you only manage one set of default values. Unspecified options will be kept unchanged. If you wish to remove an option, set it to empty value, i.e. 'option_name='. ✨

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values. 💀

cleanup [<resource id | stonith id>] [node=<node>] [operation=<operation> [interval=<interval>]] [--strict] — makes the cluster forget failed operations from the history of the resource / stonith device and re-detect its current state. This can be useful to purge knowledge of past failures that have since been resolved. 🔥
- If the named resource is part of a group, or one numbered instance of a clone or bundled resource, the clean-up applies to the whole collective resource unless --strict is given.
- If a resource id / stonith id is not specified then all resources / stonith devices will be cleaned up.
- If a node is not specified then resources / stonith devices on all nodes will be cleaned up.
refresh [<resource id | stonith id>] [node=<node>] [--strict] — makes the cluster forget the complete operation history (including failures) of the resource / stonith device and re-detect its current state. If you are interested in forgetting failed operations only, use the 'pcs resource cleanup' command. 🧚
- If the named resource is part of a group, or one numbered instance of a clone or bundled resource, the refresh applies to the whole collective resource unless --strict is given.
- If a resource id / stonith id is not specified then all resources / stonith devices will be refreshed.
- If a node is not specified then resources / stonith devices on all nodes will be refreshed.
failcount [show [<resource id | stonith id>] [node=<node>] [operation=<operation> [interval=<interval>]]] [--full] — shows current failcount for resources and stonith devices, optionally filtered by a resource / stonith device, node, operation and its interval. If --full is specified, it does not sum failcounts per resource / stonith device and node. Use 'pcs resource cleanup' or 'pcs resource refresh' to reset failcounts. 📉
relocate dry-run [resource1] [resource2] ... — the same as 'relocate run' but has no effect on the cluster. It's giving "just practicing" energy. 🙈
relocate run [resource1] [resource2] ... — relocates specified resources to their preferred nodes. If no resources are specified, it relocates all resources. This command calculates the preferred node for each resource while ignoring resource stickiness. Then it creates location constraints which will cause the resources to move to their preferred nodes. Once the resources have been moved the constraints are deleted automatically. Note that the preferred node is calculated based on current cluster status, constraints, location of resources and other settings and thus it might change over time. 🔄
relocate show — displays current status of resources and their optimal node ignoring resource stickiness. 👑
relocate clear — removes all constraints created by the 'relocate run' command. 🧹
utilization [<resource id> [<name>=<value> ...]] — add specified utilization options to specified resource. If resource is not specified, shows utilization of all resources. If utilization options are not specified, shows utilization of specified resource. Utilization option should be in format name=value, value has to be integer. Options may be removed by setting an option without a value. Example: pcs resource utilization TestResource cpu= ram=20 For the utilization configuration to be in effect, cluster property 'placement-strategy' must be configured accordingly. 🌸
relations <resource id> [--full] — displays relations of a resource specified by its id with other resources in a tree structure. Supported types of resource relations are: ordering constraints, ordering set constraints, relations defined by resource hierarchy (clones, groups, bundles). If --full is used, more verbose output will be printed. 🌳

🎀 cluster 🎀

setup — creates a cluster from the listed nodes and synchronizes cluster configuration files to them. If --corosync_conf is specified, it does not connect to other nodes and saves corosync.conf to the specified path; see 'Local only mode' below for details. 👑

setup <cluster name> (<node name> [addr=<node address>]...)...
[transport knet|udp|udpu [<transport options>] [link <link options>]...
[compression <compression options>] [crypto <crypto options>]] [totem
<totem options>] [quorum <quorum options>] [--no-cluster-uuid]
([--enable] [--start [--wait[=<n>]]] [--no-keys-sync]) |
[--corosync_conf <path>]

Nodes are specified by their names and optionally their addresses. If no addresses are specified for a node, pcs will configure corosync to communicate with that node using an address provided in 'pcs host auth' command. Otherwise, pcs will configure corosync to communicate with the node using the specified addresses.
Transport knet:
- This is the default transport. It allows configuring traffic encryption and compression as well as using multiple addresses (links) for nodes.
- Transport options are: ip_version, knet_pmtud_interval, link_mode
- Link options are: link_priority, linknumber, mcastport, ping_interval, ping_precision, ping_timeout, pong_count, transport (udp or sctp)
- Each 'link' followed by options sets options for one link in the order the links are defined by nodes' addresses. You can set link options for a subset of links using a linknumber. See examples below.
- Compression options are: level, model, threshold
- Crypto options are: cipher, hash, model
- By default, encryption is enabled with cipher=aes256 and hash=sha256. To disable encryption, set cipher=none and hash=none.
Transports udp and udpu:
- These transports are limited to one address per node. They do not support traffic encryption nor compression.
- Transport options are: ip_version, netmtu
- Link options are: bindnetaddr, broadcast, mcastaddr, mcastport, ttl
Totem and quorum can be configured regardless of used transport.
- Totem options are: block_unlisted_ips, consensus, downcheck, fail_recv_const, heartbeat_failures_allowed, hold, join, max_messages, max_network_delay, merge, miss_count_const, send_join, seqno_unchanged_const, token, token_coefficient, token_retransmit, token_retransmits_before_loss_const, window_size
- Quorum options are: auto_tie_breaker, last_man_standing, last_man_standing_window, wait_for_all

Transports and all their lil option babies, plus link, compression, crypto and totem options, are all documented in the corosync.conf(5) man page — bestie, go read it. Heads up: knet link options are prefixed knet_ over there, compression options are prefixed knet_compression_, and crypto options are prefixed crypto_. Quorum options live in their own whole thing, documented in votequorum(5). 💅

--no-cluster-uuid — this one says no ty to generating a unique ID for the cluster. No ID for you. 🚫
--enable — sets the cluster up so it starts on node boot. Wake up babe, we're booting. 🌅
--start — starts the cluster right after creating it, no waiting around.
--wait — waits up to n seconds for the cluster to start. Patient queen. ⏳
--no-keys-sync — skips creating and distributing the pcsd SSL certificate and key, plus the corosync and pacemaker authkey files. Use this if you're bringing your own certificates and keys, iykyk. 🔑

Local only mode ✨

By default, pcs connects to every single node you listed, to verify they can actually be used in the new cluster, and to yeet the cluster configuration files over to them. That's the default vibe.

But if that's not what you want? Specify the --corosync_conf option followed by a file path. Then pcs will save corosync.conf to the file you named and won't connect to cluster nodes at all. Solo mode. Main character energy. 💅

These are the tasks that pcs skips in that case:

make sure the nodes are not running or configured to run a cluster already
make sure cluster packages are installed on all nodes and their versions are compatible
make sure there are no cluster configuration files on any node (run pcs cluster destroy and remove pcs_settings.conf file on all nodes)
synchronize corosync and pacemaker authkeys, /etc/corosync/authkey and /etc/pacemaker/authkey respectively, and the corosync.conf file
authenticate the cluster nodes against each other (pcs cluster auth or pcs host auth command)
synchronize pcsd certificates (so that pcs web UI can be used in an HA mode)

Examples 🎀

Create a cluster with default settings:

pcs cluster setup newcluster node1 node2

Create a cluster using two links:

pcs cluster setup newcluster node1 addr=10.0.1.11 addr=10.0.2.11 node2 addr=10.0.1.12 addr=10.0.2.12

Set link options for all links. Link options are matched to the links in order. The first link (link 0) has sctp transport, the second link (link 1) has mcastport 55405:

pcs cluster setup newcluster node1 addr=10.0.1.11 addr=10.0.2.11 node2 addr=10.0.1.12 addr=10.0.2.12 transport knet link transport=sctp link mcastport=55405

Set link options for the second and fourth links only. Link options are matched to the links based on the linknumber option (the first link is link 0, remember that bestie):

pcs cluster setup newcluster node1 addr=10.0.1.11 addr=10.0.2.11 addr=10.0.3.11 addr=10.0.4.11 node2 addr=10.0.1.12 addr=10.0.2.12 addr=10.0.3.12 addr=10.0.4.12 transport knet link linknumber=3 mcastport=55405 link linknumber=1 transport=sctp

Create a cluster using udp transport with a non-default port:

pcs cluster setup newcluster node1 node2 transport udp link mcastport=55405

config [show] [--output-format text|cmd|json] [--corosync_conf <path>] 🌈

Shows you the cluster configuration, periodt. There are 3 formats of output available: cmd, json and text, and the default is text.

text — human friendly output, so like, readable by actual humans 🫶
cmd — prints pcs commands which can be used to recreate the same configuration. Iconic for copy-pasting.
json — a machine oriented output of the configuration. Robots only. 🤖

If --corosync_conf is specified, the configuration file specified by <path> is used instead of the current cluster configuration.

config update [transport <transport options>] [compression <compression options>] [crypto <crypto options>] [totem <totem options>] [--corosync_conf <path>] 💜

Updates the cluster configuration. Anything you don't specify gets kept unchanged — no surprise deletions, we don't do that here. If you actually want to remove an option, set it to an empty value, i.e. option_name=.

If --corosync_conf is specified, update cluster configuration in a file specified by <path>.

All options are documented in the corosync.conf(5) man page (yes, again, go read it). There are different transport options for different transport types. Compression and crypto options are only available for knet transport. Totem options can be set regardless of the transport type, lucky them.

Transport options for knet transport are: ip_version, knet_pmtud_interval, link_mode
Transport options for udp and updu transports are: ip_version, netmtu
Compression options are: level, model, threshold
Crypto options are: cipher, hash, model
Totem options are: block_unlisted_ips, consensus, downcheck, fail_recv_const, heartbeat_failures_allowed, hold, join, max_messages, max_network_delay, merge, miss_count_const, send_join, seqno_unchanged_const, token, token_coefficient, token_retransmit, token_retransmits_before_loss_const, window_size

config uuid generate [--corosync_conf <path>] [--force] 🦋

Generates a brand new cluster UUID and distributes it to all cluster nodes. Fun fact: the cluster UUID is not used by the cluster stack in any way — it's literally just there so you can easily distinguish between multiple clusters in a multi-cluster environment, since the cluster name doesn't have to be unique. It's giving name tag at a party. 🎀

If --corosync_conf is specified, update cluster configuration in file specified by <path>.

If --force is specified, existing UUID will be overwritten. Yes, the old one. Gone. 💀

authkey corosync [<path>] 🔑

Generates a new corosync authkey and distributes it to all cluster nodes. If <path> is specified, do not generate a key and use the key from the file instead.

start [--all | <node>... ] [--wait[=<n>]] [--request-timeout=<seconds>] 🌅

Starts a cluster on the specified node(s). If no nodes are specified then start a cluster on the local node. If --all is specified then start a cluster on all the nodes.

If the cluster has many nodes then the start request may time out 😭. In that case you should consider setting --request-timeout to a suitable value.

If --wait is specified, pcs waits up to n seconds for the cluster to get ready to provide services after the cluster has successfully started. So like, it's actually ready-ready, not just "started" ready.

stop [--all | <node>... ] [--request-timeout=<seconds>] 🛑

Stops a cluster on the specified node(s). If no nodes are specified then stop a cluster on the local node. If --all is specified then stop a cluster on all nodes.

If the cluster is running resources which take a long time to stop then the stop request may time out before the cluster actually stops 🙈. In that case you should consider setting --request-timeout to a suitable value.

kill 💀

Force corosync and pacemaker daemons to stop on the local node (performs kill -9). It's giving violence, but make it cluster admin.

Note that the init system (e.g. systemd) can detect that the cluster is not running and start it again. If you want to stop the cluster on a node, run pcs cluster stop on that node instead. Bestie, please, just use stop.

enable [--all | <node>... ] ✨

Configure the cluster to run on node boot on the specified node(s). If node is not specified then the cluster is enabled on the local node. If --all is specified then the cluster is enabled on all nodes.

disable [--all | <node>... ] 🙈

Configure the cluster to not run on node boot on the specified node(s). If node is not specified then the cluster is disabled on the local node. If --all is specified then the cluster is disabled on all nodes.

auth [-u <username>] [-p <password>] 🔐

Authenticate pcs/pcsd to pcsd on nodes configured in the local cluster.

status 👑

View current cluster status (an alias of pcs status cluster). Just a lil shortcut, no cap.

rename 🎀

Rename the configured cluster. The cluster has to be stopped to complete this operation. Like, actually stopped. Do not skip this.

Manual steps are needed in case the cluster uses GFS2 filesystem or DLM:

for GFS2:

The lock table name on each GFS2 filesystem must be updated to reflect the new name of the cluster so that the filesystems can be mounted.

for DLM:

The DLM cluster name in the shared volume groups metadata must be updated so that the volume groups can start.

sync 🔄

Sync cluster configuration (files which are supported by all subcommands of this command) to all cluster nodes. Keep everybody on the same page, fr fr.

sync corosync 🔄

Sync corosync configuration to all nodes found from the current corosync.conf file.

cib [filename] [scope=<scope> | --config] 📜

Get the raw xml from the CIB (Cluster Information Base). If a filename is provided, we save the CIB to that file, otherwise the CIB is printed. Specify scope to get a specific section of the CIB.

Valid values of the scope are: acls, alerts, configuration, constraints, crm_config, fencing-topology, nodes, op_defaults, resources, rsc_defaults, tags.

--config is the same as scope=configuration.

Do not specify a scope if you want to edit the saved CIB using pcs (pcs -f <command>). Seriously.

cib-push <filename> [--wait[=<n>]] [diff-against=<filename_original> | scope=<scope> | --config] 🔥

Push the raw xml from <filename> to the CIB (Cluster Information Base). You can obtain the CIB by running the pcs cluster cib command, which is the recommended first step when you want to perform desired modifications (pcs -f <command>) for the one-off push.

If diff-against is specified, pcs diffs contents of filename against contents of filename_original and pushes the result to the CIB.

Specify scope to push a specific section of the CIB. Valid values of the scope are: acls, alerts, configuration, constraints, crm_config, fencing-topology, nodes, op_defaults, resources, rsc_defaults, tags.

--config is the same as scope=configuration. Use of --config is recommended.

Do not specify a scope if you need to push the whole CIB or be warned in the case of an outdated CIB.

If --wait is specified wait up to n seconds for changes to be applied.

WARNING: the selected scope of the CIB will be overwritten by the current content of the specified file. Like, overwritten overwritten. Be so careful bestie. 😭

Example:

pcs cluster cib > original.xml
cp original.xml new.xml
pcs -f new.xml constraint location apache prefers node2
pcs cluster cib-push new.xml diff-against=original.xml

cib-upgrade — glows up your CIB so it matches the newest version of the document schema ✨

edit [scope=<scope> | --config] — opens the cib in whatever editor $EDITOR points at 💅 and pushes out all your changes the moment you save. Pass scope if you only wanna touch one specific chunk of the CIB. The valid scope values are literally: acls, alerts, configuration, constraints, crm_config, fencing-topology, nodes, op_defaults, resources, rsc_defaults, tags. --config is the same thing as scope=configuration, and honestly using --config is the recommended move. And bestie, do not specify a scope if you need to edit the whole entire CIB, or if you want to be warned when the CIB is outdated 🫶

node add <node name> [addr=<node address>]... [watchdog=<watchdog path>] [device=<SBD device path>]... [--start [--wait[=<n>]]] [--enable] [--no-watchdog-validation] — adds the node to the cluster and syncs all the relevant config files over to it 💖 This one can only be run on a node that's already in the cluster, no cap.

The new node gets identified by its name, plus optionally its addresses. If you don't hand over any addresses for the node, pcs will set up corosync to talk to it using an address that was provided in the pcs host auth command. Otherwise? pcs configures corosync to talk to it using the addresses you specified, periodt.

Use watchdog to name a path to a watchdog on the new node, for when SBD is enabled in the cluster. And if SBD is set up with shared storage, use device to point at the path to the shared device(s) on the new node.

If --start is specified it'll also start the cluster on the new node, and if --wait is specified it waits up to n seconds for the new node to start. If --enable is specified, the cluster gets configured to start on the new node at boot. And if --no-watchdog-validation is specified, the watchdog validation just gets skipped. 🙈

WARNING: By default, pcs tests whether the watchdog you specified is actually supported. This can cause a restart of the system when a watchdog with no-way-out-feature enabled is present 😭 Use --no-watchdog-validation to skip watchdog validation.

node delete <node name> [<node name>]... — shuts down the node(s) you named and yeets them out of the cluster 💀
node remove <node name> [<node name>]... — same energy, same job: shuts down the specified nodes and removes them from the cluster.

node add-remote <node name> [<node address>] [options] [op <operation action> <operation options> [<operation action> <operation options>]...] [meta <meta options>] [--wait[=<n>]] — adds the node to the cluster as a remote node 🦋 Syncs all the relevant config files over to the new node, starts it, and configures it to start the cluster on boot. The available options are port and reconnect_interval. Operations and meta belong to an underlying connection resource (ocf:pacemaker:remote). If no node address is specified for the node, pcs will configure pacemaker to communicate with the node using an address provided in the pcs host auth command. Otherwise, pcs configures pacemaker to communicate with the node using the addresses you specified. And if --wait is specified, it waits up to n seconds for the node to start ⭐

node delete-remote <node identifier> [--no-stop] [--future] — shuts down the specified remote node and removes it from the cluster 🌸 The node-identifier can be the name of the node or the address of the node, your call.

If --no-stop is specified, the resource representing the remote node will not be stopped before its deletion 👀 This may leave orphaned resources behind in case the deleted resources aren't already stopped. Messy.

Using --force currently also means the resources won't be stopped before their deletion. So if you need --force and you still want the resources stopped, you have to combine it with the --future flag. iykyk.

node remove-remote <node identifier> [--no-stop] [--future] — shuts down the specified remote node and removes it from the cluster 💜 The node-identifier can be the name of the node or the address of the node.

If --no-stop is specified, the resource representing the remote node will not be stopped before its deletion. This may result in orphaned resources being left behind in case the deleted resources are not already stopped 😭

node add-guest <node name> <resource id> [options] [--wait[=<n>]] — makes the resource you specified into a guest node resource 🎀 Syncs all relevant config files to the new node, starts the node, and configures it to start the cluster on boot. Options are remote-addr, remote-port and remote-connect-timeout. If remote-addr isn't specified for the node, pcs will configure pacemaker to communicate with the node using an address provided in the pcs host auth command. Otherwise, pcs configures pacemaker to communicate with the node using the addresses you specified. If --wait is specified, it waits up to n seconds for the node to start 🌈
node delete-guest <node identifier> — shuts down the specified guest node and removes it from the cluster 🧚 The node-identifier can be the name of the node, or the address of the node, or the id of the resource that's being used as the guest node.
node remove-guest <node identifier> — shuts down the specified guest node and removes it from the cluster 🧚 The node-identifier can be the name of the node, or the address of the node, or the id of the resource that is used as the guest node.

node clear <node name> — wipes the specified node out of various cluster caches 🧹 Run this when a node you already removed is still being treated by the cluster like it's a member. Rude of it, honestly.

node rename-cib <old name> <new name> — renames a cluster node inside the CIB 👑 This swaps out all references to the old name with the new name. Any references that can't be updated automatically get reported back to you for manual review.

This command is one step of the node rename procedure. The recommended procedure is:

put all nodes in standby mode,
stop the cluster,
authenticate nodes using their new names,
rename nodes in corosync.conf using pcs cluster node rename-corosync command,
at this step, you can change nodes' addresses, if you wish to do so,
start the cluster,
rename nodes in the CIB using this command,
take all nodes from standby mode,
optionally, you can deauthenticate old node names.

node rename-corosync <old name> <new name> [--skip-offline] — renames a cluster node in corosync.conf and distributes the updated configuration out to every node ✨

This command is one step of the node rename procedure. The recommended procedure is:

put all nodes in standby mode,
stop the cluster,
authenticate nodes using their new names,
rename nodes in corosync.conf using this command,
at this step, you can change nodes' addresses, if you wish to do so,
start the cluster,
rename nodes in the CIB using pcs cluster node rename-cib command,
take all nodes from standby mode,
optionally, you can deauthenticate old node names.

link add <node_name>=<node_address>... [options <link options>] — adds a corosync link 🔗 You gotta specify one address for every single cluster node. And if no linknumber is specified, pcs just uses the lowest available linknumber. Efficiency queen.

Link options (documented in the corosync.conf(5) man page) are: link_priority, linknumber, mcastport, ping_interval, ping_precision, ping_timeout, pong_count, transport (udp or sctp).

link delete <linknumber> [<linknumber>]... — removes the specified corosync links 💅
link remove <linknumber> [<linknumber>]... — removes the specified corosync links.
link update <linknumber> [<node_name>=<node_address>...] [options <link options>] — adds, removes or changes node addresses / link options of an existing corosync link 🦋 Use this when you can't add / remove links, which is the preferred way. Any options you don't specify stay unchanged. And if you want to remove an option, set it to an empty value, i.e. option_name=.

Link options (documented in the corosync.conf(5) man page) are:

for knet transport: link_priority, mcastport, ping_interval, ping_precision, ping_timeout, pong_count, transport (udp or sctp)
for udp and udpu transports: bindnetaddr, broadcast, mcastaddr, mcastport, ttl

uidgid — lists the current configured uids and gids of users that are allowed to connect to corosync 🔥
uidgid add [uid=<uid>] [gid=<gid>] — adds the specified uid and/or gid to the list of users/groups allowed to connect to corosync 💖
uidgid delete [uid=<uid>] [gid=<gid>] — removes the specified uid and/or gid from the list of users/groups allowed to connect to corosync 🧹
uidgid remove [uid=<uid>] [gid=<gid>] — removes the specified uid and/or gid from the list of users/groups allowed to connect to corosync.

corosync [node] — grabs the corosync.conf from the node you specified, or from the current node if you didn't specify one 🫶
reload corosync — reloads the corosync configuration on the current node 🔄

destroy [--all] [--yes] — permanently destroys the cluster on the current node, killing every cluster process and removing all the cluster configuration files 💀 Using --all will attempt to destroy the cluster on all nodes in the local cluster.

WARNING: This command permanently removes any cluster configuration that has been created 😭 It is recommended to run pcs cluster stop before destroying the cluster. And to prevent any accidental running of this command, --yes or an interactive user response is required in order to proceed.

verify [--full] [-f <filename>] — checks the pacemaker configuration (CIB) for syntax and common conceptual errors 👑 If no filename is specified, the check runs against the currently running cluster. And if --full is used, you get way more verbose output. Slay.

💾 report

report [--from "YYYY-M-D H:M:S" [--to "YYYY-M-D H:M:S"]] <dest> [--overwrite]

okay so this one makes you a lil tarball 📦 with literally everything you need when you're out here reporting cluster problems to the universe. if you don't hand it --from and --to, it just grabs the past 24 hours by default, slay. and heads up bestie — it will not overwrite any existing files, so if you want it to just steamroll whatever's already sitting there, you gotta say --overwrite out loud. 💅

⚔️ stonith

📊 status

status [<resource id | tag id>] [node=<node>] [--hide-inactive]

shows you the status of all currently configured stonith devices 💖. and like:

if --hide-inactive is specified — only the active stonith devices show up, the rest get the ✨ invisible treatment
if a resource or tag id is specified — you only see the status of that specific resource, or the resources chillin' in that specific tag 🎀
if node is specified — only the status of resources configured for that node, no extras

🔐 config

config [--show-secrets] [--output-format text|cmd|json] [<stonith id>]...

shows the options of all currently configured stonith devices 🦋 — or, if you name some stonith device ids, it shows the options for just those ones.

if --show-secrets is specified — it'll actually display the values of secret attributes in the configuration text output 🔥. by default only attribute names show up and the values are straight up omitted, so if you want the tea you gotta ask for it.
there are 3 formats of output available: 'cmd', 'json' and 'text', and the default is 'text'.
- format 'text' is a human friendly output 🌸
- format 'cmd' prints pcs commands which can be used to recreate the same configuration 💅
- format 'json' is a machine oriented output of the configuration 🤖

Note: The 'json' output format does not include fencing levels. Use pcs stonith level config --output-format=json to get fencing levels. iykyk 🫶

📋 list

list [filter] [--nodesc]

shows you the list of all available stonith agents ✨ — and if a filter is provided, then only the stonith agents matching that filter will show up. and if --nodesc is used, then the descriptions of the stonith agents are not printed, so it's the lowkey version 🍓

🔎 describe

describe <stonith agent> [--full]

shows the options for the specified stonith agent 💜. if --full is specified, then all options — including the advanced and the deprecated ones — are shown. no secrets kept, periodt 👑

🛠️ create

create <stonith id> <stonith device type> [stonith device options] [op <operation action> <operation options> [<operation action> <operation options>]...] [meta <meta options>] [--disabled] [--agent-validation] [--wait[=n]]

creates a stonith device with the specified type and options 🌈.

if --disabled is specified the stonith device is not used.
if --agent-validation is specified, the stonith agent validate-all action will be used to validate the stonith device options and will prevent creating a misconfigured stonith device 🛑. if --agent-validation is not specified, the validation will be done anyway, but it will only produce warnings — not preventing the stonith device from being created. so like, soft launch validation 😭
if --wait is specified, pcs will wait up to n seconds for the stonith device to start and then return 0 if the stonith device is started, or 1 if the stonith device has not yet started. if n is not specified it defaults to 60 minutes ⏳.

Example: Create a device for nodes node1 and node2

pcs stonith create MyFence fence_virt pcmk_host_list=node1,node2

Example: Use port p1 for node n1 and ports p2 and p3 for node n2

pcs stonith create MyFence fence_virt 'pcmk_host_map=n1:p1;n2:p2,p3'

🔄 update

update <stonith id> [stonith options] [op [<operation action> <operation options>]...] [meta <meta options>] [--agent-validation] [--wait[=n]]

add, remove or change options of the specified stonith device 💫. unspecified options will be kept unchanged. and if you wanna remove an option, just set it to an empty value, i.e. 'option_name='.

if an operation (op) is specified it will update the first found operation with the same action on the specified stonith device. if no operation with that action exists, then a new operation will be created. > (WARNING: all existing options on the updated operation will be reset if not specified.) so like, be careful bestie 💀 if you want to create multiple monitor operations you should use the 'op add' & 'op remove' commands instead.

if meta attributes are specified they will not be validated by this command 🙈. for meta attributes validation use the 'pcs stonith meta' command instead.

if --agent-validation is specified, the stonith agent validate-all action will be used to validate stonith device options and will prevent creating a misconfigured stonith device 🛑. if --agent-validation is not specified, the validation will be done anyway, but it will only produce warnings not preventing the stonith device from being updated.
if --wait is specified, pcs will wait up to n seconds for the changes to take effect and then return 0 if the changes have been processed or 1 otherwise. if n is not specified it defaults to 60 minutes ⏳.

🧲 update-scsi-devices

update-scsi-devices <stonith id> (set <device-path> [<device-path>...]) | (add <device-path> [<device-path>...] delete|remove <device-path> [<device-path>...] )

updates scsi fencing devices without affecting other resources 🦋. you must specify either a list of set devices, or at least one device for add or delete/remove devices. the stonith resource must be running on one cluster node. each device will be unfenced on each cluster node running cluster. supported fence agents: fence_scsi, fence_mpath 🎀

🗑️ delete

delete <stonith id>...

removes stonith resources from the configuration 💅

🗑️ remove

remove <stonith id>...

removes stonith resources from the configuration 💅 (yes bestie, same energy as delete — it's a whole twin situation)

📝 description

description <stonith id>

this command is an alias of 'cib element description' command 💖

gets the description of a CIB element ✨

description <stonith id> <description text>

this command is an alias of 'cib element description' command 💖

sets a description to a CIB element. if you wish to remove a description, set it to an empty string 🌸

➕ op add

op add <stonith id> <operation action> [operation properties]

adds an operation for the specified stonith device 👑

➖ op delete

op delete <stonith id> <operation action> [<operation properties>...]

removes the specified operation (note: you must specify the exact operation properties to properly remove an existing operation 🔥)

op delete <operation id>

removes the specified operation id 🫶

➖ op remove

op remove <stonith id> <operation action> [<operation properties>...]

removes the specified operation (note: you must specify the exact operation properties to properly remove an existing operation 🔥)

op remove <operation id>

removes the specified operation id 🫶

⚙️ op defaults

op defaults [config] [--all | --no-expire-check] [--full] [--output-format text|cmd|json]

this command is an alias of 'resource op defaults [config]' command 💖

lists currently configured default values for operations 🌈.

if --all is specified, also list expired sets of values 🍓
if --full is specified, also list ids 💜
if --no-expire-check is specified, do not evaluate whether sets of values are expired 🙈
there are 3 formats of output available: 'cmd', 'json' and 'text', and the default is 'text'.
- format 'text' is a human friendly output 🌸
- format 'cmd' prints pcs commands which can be used to recreate the same configuration 💅
- format 'json' is a machine oriented output of the configuration 🤖

🌱 op defaults set create

op defaults set create [<set options>] [meta [<name>=<value>]...] [rule [<expression>]]

this command is an alias of 'resource op defaults set create' command 💖

creates a new set of default values for resource / stonith device operations ✨. you may specify a rule describing resources / stonith devices and / or operations to which the set applies 🎀

set options are: id, score

expression looks like one of the following:

op <operation name> [interval=<interval>]
resource [<standard>]:[<provider>]:[<type>]
defined|not_defined <node attribute>
<node attribute> lt|gt|lte|gte|eq|ne [string|integer|number|version] <value>
date gt|lt <date>
date in_range [<date>] to <date>
date in_range <date> to duration <duration options>
date-spec <date-spec options>
<expression> and|or <expression>
(<expression>)

you may specify all or any of 'standard', 'provider' and 'type' in a resource expression 💫. for example: 'resource ocf::' matches all resources of 'ocf' standard, while 'resource ::Dummy' matches all resources of 'Dummy' type regardless of their standard and provider. to specify a full name of an agent which does not have a provider, use a double colon, for example 'resource stonith::fence_virt' 👑

dates are expected to conform to ISO 8601 format 📅

duration options are: years, months, weeks, days, hours, minutes, seconds. value for these options is an integer 🔢

date-spec options are: years, weekyears, months, weeks, yeardays, monthdays, weekdays, hours, minutes, seconds. value for these options is an integer or a range written as integer-integer 🎀

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values. so like, if they said their own thing, the default is not the main character anymore 😭

🗑️ op defaults set delete

op defaults set delete [<set id>]...

this command is an alias of 'resource op defaults set delete' command 💖

deletes the specified options sets 💅

🗑️ op defaults set remove

op defaults set remove [<set id>]...

this command is an alias of 'resource op defaults set delete' command 💖

deletes the specified options sets 💅

🩹 op defaults set update

op defaults set update <set id> [meta [<name>=<value>]...]

this command is an alias of 'resource op defaults set update' command 💖

adds, removes or changes values in the specified set of default values for resource / stonith device operations ✨. unspecified options will be kept unchanged. if you wish to remove an option, set it to empty value, i.e. 'option_name='.

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values. fr fr 😤

🩹 op defaults update

op defaults update <name>=<value>...

this command is an alias of 'resource op defaults update' command 💖

adds, removes or changes default values for operations 🌈. this is a simplified command useful for cases when you only manage one set of default values 🎀. unspecified options will be kept unchanged. if you wish to remove an option, set it to empty value, i.e. 'option_name='.

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values. Like, the whole point of a default is that it's a fallback, bestie — if your resource already said what it wants, that's the vibe. Periodt. 💅

meta <stonith id> <meta options> [--wait[=n]] — okay so this adds the options you list to the stonith device you named. 🎀 Meta options gotta be in name=value format, and if you want to remove an option you just set it without any value at all (iconic, honestly). If you throw --wait on there, pcs will sit patiently for up to n seconds waiting for the changes to actually take effect, then hand you back 0 if they got processed or 1 if they didn't. If you don't say what n is, it defaults to 60 minutes (yes, an hour, she's patient like that 🧚).

Example:

pcs stonith meta test_stonith failure-timeout=50 resource-stickiness=

defaults [config] [--all | --no-expire-check] [--full] [--output-format text|cmd|json] — this one is literally just an alias of the resource defaults [config] command, no cap.

It lists the default values you've currently got configured for resources / stonith devices. 🌸 If --all is specified, it also lists expired sets of values. If --full is specified, it also lists ids. If --no-expire-check is specified, it does not evaluate whether sets of values are expired (skips the vibe check entirely). There are 3 formats of output available: cmd, json and text, and the default is text. Format text is a human friendly output. Format cmd prints pcs commands which can be used to recreate the same configuration. Format json is a machine oriented output of the configuration. ✨

defaults set create [<set options>] [meta [<name>=<value>]...] [rule [<expression>]] — alias of the resource defaults set create command.

This makes a new set of default values for resources / stonith devices. You may specify a rule describing resources / stonith devices to which the set applies. 💖

Set options are: id, score

Expression looks like one of the following:

resource [<standard>]:[<provider>]:[<type>]
date gt|lt <date>
date in_range [<date>] to <date>
date in_range <date> to duration <duration options>
date-spec <date-spec options>
<expression> and|or <expression>
(<expression>)

You may specify all or any of standard, provider and type in a resource expression. For example: resource ocf:: matches all resources of ocf standard, while resource ::Dummy matches all resources of Dummy type regardless of their standard and provider. To specify a full name of an agent which does not have a provider, use a double colon, for example resource stonith::fence_virt. 🦋

Dates are expected to conform to ISO 8601 format.

Duration options are: years, months, weeks, days, hours, minutes, seconds. Value for these options is an integer.

Date-spec options are: years, weekyears, months, weeks, yeardays, monthdays, weekdays, hours, minutes, seconds. Value for these options is an integer or a range written as integer-integer.

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values.

defaults set delete [<set id>]... — alias of the resource defaults set delete command.

Delete specified options sets. Gone. Poof. 💀

defaults set remove [<set id>]... — alias of the resource defaults set delete command.

Delete specified options sets. (Same energy, different spelling, she contains multitudes.) 🙈

defaults set update <set id> [meta [<name>=<value>]...] — alias of the resource defaults set update command.

Add, remove or change values in a specified set of default values for resources / stonith devices. Unspecified options will be kept unchanged. If you wish to remove an option, set it to empty value, i.e. option_name=. 👑

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values.

defaults update <name>=<value>... — alias of the resource defaults update command.

Add, remove or change default values for resources / stonith devices. This is a simplified command useful for cases when you only manage one set of default values. Unspecified options will be kept unchanged. If you wish to remove an option, set it to empty value, i.e. option_name=. ✨

NOTE: Defaults do not apply to resources / stonith devices which override them with their own defined values.

cleanup [<resource id | stonith id>] [node=<node>] [operation=<operation> [interval=<interval>]] [--strict] — alias of the resource cleanup command.

Make the cluster forget failed operations from history of the resource / stonith device and re-detect its current state. This can be useful to purge knowledge of past failures that have since been resolved. 🌈 (It's giving "let it go" energy, fr fr.)

If the named resource is part of a group, or one numbered instance of a clone or bundled resource, the clean-up applies to the whole collective resource unless --strict is given.

If a resource id / stonith id is not specified then all resources / stonith devices will be cleaned up.

If a node is not specified then resources / stonith devices on all nodes will be cleaned up.

refresh [<resource id | stonith id>] [node=<node>] [--strict] — alias of the resource refresh command.

Make the cluster forget the complete operation history (including failures) of the resource / stonith device and re-detect its current state. If you are interested in forgetting failed operations only, use the pcs resource cleanup command. 🎀

If the named resource is part of a group, or one numbered instance of a clone or bundled resource, the refresh applies to the whole collective resource unless --strict is given.

If a resource id / stonith id is not specified then all resources / stonith devices will be refreshed.

If a node is not specified then resources / stonith devices on all nodes will be refreshed.

failcount [show [<resource id | stonith id>] [node=<node>] [operation=<operation> [interval=<interval>]]] [--full] — alias of the resource failcount show command.

Show current failcount for resources and stonith devices, optionally filtered by a resource / stonith device, node, operation and its interval. If --full is specified, do not sum failcounts per resource / stonith device and node. Use pcs resource cleanup or pcs resource refresh to reset failcounts. 🔥

enable <stonith id>... [--wait[=n]] — Allow the cluster to use the stonith devices. If --wait is specified, pcs will wait up to n seconds for the stonith devices to start and then return 0 if the stonith devices are started, or 1 if the stonith devices have not yet started. If n is not specified it defaults to 60 minutes. ⭐
disable <stonith id>... [--wait[=n]] — Attempt to stop the stonith devices if they are running and disallow the cluster to use them. If --wait is specified, pcs will wait up to n seconds for the stonith devices to stop and then return 0 if the stonith devices are stopped or 1 if the stonith devices have not stopped. If n is not specified it defaults to 60 minutes. 🫶
level [config] [--output-format text|cmd|json] — Lists all of the fencing levels currently configured. There are 3 formats of output available: cmd, json and text, default is text. Format text is a human friendly output. Format cmd prints pcs commands which can be used to recreate the same configuration. Format json is a machine oriented output of the configuration. 💜
level add <level> <target> <stonith id> [<stonith id>...] [id=<level id>] — Add the fencing level for the specified target with the list of stonith devices to attempt for that target at that level. Fence levels are attempted in numerical order (starting with 1). If a level succeeds (meaning all devices are successfully fenced in that level) then no other levels are tried, and the target is considered fenced. 🎯 Target may be a node name <node_name> or %<node_name> or node%<node_name>, a node name regular expression regexp%<node_pattern> or a node attribute value attrib%<name>=<value>. Id for the fencing level will be generated if not specified by the id option.
level delete <level> [target <target>] [stonith <stonith id>...] — Removes the fence level for the level, target and/or devices specified. If no target or devices are specified then the fence level is removed. Target may be a node name <node_name> or %<node_name> or node%<node_name>, a node name regular expression regexp%<node_pattern> or a node attribute value attrib%<name>=<value>. 🌸
level remove <level> [target <target>] [stonith <stonith id>...] — Removes the fence level for the level, target and/or devices specified. If no target or devices are specified then the fence level is removed. Target may be a node name <node_name> or %<node_name> or node%<node_name>, a node name regular expression regexp%<node_pattern> or a node attribute value attrib%<name>=<value>. 🌸 (Yeah it's the same as delete, she's just flexible like that.)
level clear [target <target> | stonith <stonith id>...] — Clears the fence levels on the target (or stonith id) specified, or clears all fence levels if a target/stonith id is not specified. Target may be a node name <node_name> or %<node_name> or node%<node_name>, a node name regular expression regexp%<node_pattern> or a node attribute value attrib%<name>=<value>. Example:

pcs stonith level clear stonith dev_a dev_b

level verify — Verifies all fence devices and nodes specified in fence levels exist. ✅ (Vibe check for your fence config, iykyk.)
fence <node> [--off] — Fence the node specified (if --off is specified, use the off API call to stonith which will turn the node off instead of rebooting it). 💥
confirm <node> [--yes] — Confirm to the cluster that the specified node is powered off. This allows the cluster to recover from a situation where no stonith device is able to fence the node.

This command should ONLY be used after manually ensuring that the node is powered off and has no access to shared resources. Like, for real for real, bestie — do NOT skip the manual check. 😭

WARNING: If this node is not actually powered off or it does have access to shared resources, data corruption/cluster failure can occur. To prevent accidental running of this command, --yes or interactive user response is required in order to proceed.

NOTE: It is not checked if the specified node exists in the cluster in order to be able to work with nodes not visible from the local cluster partition.

`history [show [<node>]]`

Fencing-history reveal time 👑 — this shows you the fencing history for the node you named, or for every single node if you didn't name one. No node? No problem, you get them all. 💅

`history cleanup [<node>]]`

Cleans up the fence history for the node you specified — or for all the nodes, if you didn't specify one. Fresh-start energy, literally. ✨

`history update`

Updates the fence history from all nodes. Like a lil sync-up for your history data. 🔄

`sbd enable [watchdog=<path>[@<node>]]... [device=<path>[@<node>]]... [<SBD_OPTION>=<value>]... [--no-watchdog-validation]`

Okay bestie, this turns SBD on in the cluster. 🎀

The default path for the watchdog device is /dev/watchdog.
The allowed SBD options are: SBD_WATCHDOG_TIMEOUT (default: 5), SBD_DELAY_START (default: no), SBD_STARTMODE (default: always) and SBD_TIMEOUT_ACTION. These SBD options are documented in the sbd(8) man page.
You can specify up to 3 devices per node.
If --no-watchdog-validation is specified, validation of watchdogs will be skipped.

WARNING: Cluster has to be restarted in order to apply these changes. 😭

WARNING: By default, it is tested whether the specified watchdog is supported. This may cause a restart of the system when a watchdog with no-way-out-feature enabled is present. Use --no-watchdog-validation to skip watchdog validation. 💀

So the example from the original — enabling SBD in the cluster where the watchdogs are /dev/watchdog2 on node1, /dev/watchdog1 on node2, /dev/watchdog0 on all the other nodes, the device is /dev/sdb on node1 and /dev/sda on all the other nodes, and the watchdog timeout gets set to 10 seconds — looks like this:

pcs stonith sbd enable watchdog=/dev/watchdog2@node1 watchdog=/dev/watchdog1@node2 watchdog=/dev/watchdog0 device=/dev/sdb@node1 device=/dev/sda SBD_WATCHDOG_TIMEOUT=10

`sbd disable`

Turns SBD off in the cluster. 🙈

WARNING: Cluster has to be restarted in order to apply these changes. 😭

`sbd device setup device=<path> [device=<path>]... [watchdog-timeout=<integer>] [allocate-timeout=<integer>] [loop-timeout=<integer>] [msgwait-timeout=<integer>] [--yes]`

Initializes the SBD structures on the device(s) you list, with the timeouts you specify. 🛠️

WARNING: All content on the specified device(s) will be overwritten. To prevent accidental running of this command, --yes or interactive user response is required in order to proceed. 💀

`sbd device message <device-path> <node> <message-type>`

Manually sets a message of the specified type on the device, for the node. The possible message types — and yes, they're documented in the sbd(8) man page — are: test, reset, off, crashdump, exit, clear. 📨

`sbd status [--full]`

Shows the status of the SBD services in the cluster plus the local device(s) that are configured. If you add --full, you also get a dump of the SBD headers on the device(s). 🔍

`sbd config`

Shows the SBD configuration in the cluster. ✨

`sbd watchdog list`

Shows all available watchdog devices on the local node. 🐶

WARNING: Listing available watchdogs may cause a restart of the system when a watchdog with no-way-out-feature enabled is present. 😭

`sbd watchdog test [<watchdog-path>] [--yes]`

Heads up, this operation is expected to force-reboot the local system without following any shutdown procedures, using a watchdog. If no watchdog is specified, an available watchdog will be used if only one watchdog device is available on the local system. To prevent accidental running of this command, --yes or interactive user response is required in order to proceed. 💀🔥

✨ acl ✨

`[config]`

Lists all the current access control lists. 📋

`enable`

Enables access control lists. 🔓

`disable`

Disables access control lists. 🔒

`role create <role id> [description=<description>] [((read | write | deny) (xpath <query> | id <id>))...]`

Creates a role with the id and (optional) description you specify. Each role can also have an unlimited number of permissions (read/write/deny) applied to either an xpath query or the id of a specific element in the cib. 👑

Permissions are applied to the selected XML element's entire XML subtree — that's all the elements enclosed within it. Write permission grants the ability to create, modify, or remove the element and its subtree, and also the ability to create any "scaffolding" elements (enclosing elements that do not have attributes other than an ID). Permissions for more specific matches (more deeply nested elements) take precedence over more general ones. If multiple permissions are configured for the same match (for example, in different roles applied to the same user), any deny permission takes precedence, then write, then lastly read.

An xpath may include an attribute expression to select only elements that match the expression, but the permission still applies to the entire element (and its subtree), not to the attribute alone. For example, using the xpath "//*[@name]" to give write permission would allow changes to the entirety of all elements that have a "name" attribute and everything enclosed by those elements. There is no way currently to give permissions for just one attribute of an element. That is to say, you can not define an ACL that allows someone to read just the dc-uuid attribute of the cib tag — that would select the cib element and give read access to the entire CIB. 💅

`role delete <role id>`

Deletes the role you specified and removes it from any users/groups it was assigned to. 🗑️

`role remove <role id>`

Deletes the role you specified and removes it from any users/groups it was assigned to. (Yes bestie, it's the same thing as delete — twin energy. 👯)

`role assign <role id> [to] user|group <username/group>`

Assigns a role to a user or group that was already created with 'pcs acl user|group create'. 🎀

`role unassign <role id> [from] user|group <username/group>`

Removes a role from the specified user or group. ✂️

`user create <username> [<role id>]...`

Creates an ACL for the user you specified and assigns roles to that user. 🌸

`user delete <username>`

Removes the user you specified — and any roles assigned to them get unassigned for that user. 🗑️

`user remove <username>`

Removes the user you specified — and any roles assigned to them get unassigned for that user. (Again, same as delete. 👯)

`group create <group> [<role id>]...`

Creates an ACL for the group you specified and assigns roles to that group. 🌸

`group delete <group>`

Removes the group you specified — and any roles assigned to it get unassigned for that group. 🗑️

`group remove <group>`

Removes the group you specified — and any roles assigned to it get unassigned for that group. 👯

`permission add <role id> ((read | write | deny) (xpath <query> | id <id>))...`

Adds the listed permissions to the role you specified. Permissions are applied to either an xpath query or the id of a specific element in the CIB. ✨

`permission delete <permission id>`

Removes the permission id you specified — and permission id's are listed in parenthesis after permissions in the 'pcs acl' output. 🗑️

`permission remove <permission id>`

Removes the permission id you specified — and permission id's are listed in parenthesis after permissions in the 'pcs acl' output. 👯

✨ property ✨

`[config [<property>... | --all | --defaults | (--output-format text|cmd|json)]] | [--all | --defaults | (--output-format text|cmd|json)]`

Lists the property settings (default: it lists the configured properties). If --defaults is specified it'll show all the property defaults; if --all is specified, the current configured properties will be shown together with the unset properties and their defaults. See 'pcs property describe' for a description of the properties. 🌈

There are 3 formats of output available: 'cmd', 'json' and 'text' — the default is 'text'. Format 'text' is a human friendly output. Format 'cmd' prints pcs commands which can be used to recreate the same configuration. Format 'json' is a machine oriented output of the configuration. 💖

`defaults [<property>...] | [--full]`

Lists all the property defaults, or only the defaults for the properties you specified. If --full is specified, all the property defaults — including advanced ones — are shown. ⭐

`describe [<property>...] [--output-format text|json] [--full]`

Shows cluster properties. There are 2 formats of output available: 'json' and 'text' — the default is 'text'. Format 'text' is a human friendly output. Format 'json' is a machine oriented output of the configuration. If --full is specified, all the property descriptions — including advanced ones — are shown. 🔍

set <property>=[<value>] ... [--force] — bestie, this is how you set specific pacemaker properties 💅 Leave the value blank and the property gets straight-up removed from the configuration. Now listen: if pcs doesn't recognise a property, it will not be created — unless you flex --force. Wanna know what properties even exist? Run pcs property describe and thank me later 🫶
unset <property> ... — yep, it removes the property from the configuration. And again, pcs property describe is right there with all the descriptions ✨

💖 constraint 💖

[config] [--full] [--all] [--output-format text|cmd|json] — lists every current constraint that hasn't expired. Pass --all and the expired ones come out too. Pass --full and you also get the constraint ids. Three output formats live here: cmd, json, and text — and text is the default. text is the human-friendly one. cmd prints pcs commands you could run to recreate the exact same configuration. json is the machine-oriented dump of the configuration 🤖
location <resource> prefers <node>[=<score>] [<node>[=<score>]]... — makes a location constraint on a resource that prefers the node(s) you name, with a score (default score: INFINITY 👑). The resource can be a resource id <resource_id>, or %<resource_id>, or resource%<resource_id>, or a resource name regular expression regexp%<resource_pattern>.
location <resource> avoids <node>[=<score>] [<node>[=<score>]]... — same energy but the opposite direction: a location constraint that avoids the node(s) you name, with a score (default score: INFINITY). Resource can be a resource id <resource_id>, or %<resource_id>, or resource%<resource_id>, or a resource name regular expression regexp%<resource_pattern>.
location <resource> rule [id=<rule id>] [resource-discovery=<option>] [role=Promoted|Unpromoted] [constraint-id=<id>] [score=<score> | score-attribute=<attribute>] <expression> — creates a location constraint with a rule on the resource you picked. The <expression> is giving very specific, and it looks like one of these:

defined|not_defined <node attribute>
<node attribute> lt|gt|lte|gte|eq|ne [string|integer|number|version] <value>
date gt|lt <date>
date in_range <date> to <date>
date in_range <date> to duration <duration options>...
date-spec <date-spec options>...
<expression> and|or <expression>
( <expression> )

Dates are expected to conform to ISO 8601 format 📅

Duration options are: years, months, weeks, days, hours, minutes, seconds. The value for these options is an integer.

Date-spec options are: years, weekyears, months, weeks, yeardays, monthdays, weekdays, hours, minutes, seconds. The value for these options is an integer, or a range written as integer-integer.

Resource may be either a resource id <resource_id> or %<resource_id> or resource%<resource_id>, or a resource name regular expression regexp%<resource_pattern>.

And the defaults, so you don't get caught slipping: if score is omitted it defaults to INFINITY. If id is omitted, one gets generated from the resource id. If resource-discovery is omitted it defaults to 'always'.

location [config [resources [<resource reference>...]] | [nodes [<node>...]]] [--full] [--all] [--output-format text|cmd|json] — lists all the current location constraints that aren't expired. Say resources and the location constraints get displayed per resource. Say nodes and they get displayed per node. Name specific nodes, resources, or resource name regular expressions and only the constraints containing those show up. A resource reference may be either a resource id <resource_id> or %<resource_id> or resource%<resource_id>, or a resource name regular expression regexp%<resource_pattern>. --full shows the internal constraint ids too. --all shows the expired constraints. Three formats of output available: cmd, json, and text, default is text. text is human friendly. cmd prints pcs commands which can be used to recreate the same configuration. json is a machine oriented output of the configuration 🌈
location add <id> <resource> <node> [score=<score>] [resource-discovery=<option>] — adds a location constraint with the appropriate id for the resource, node name and score you give it (default score: INFINITY). Resource may be either a resource id <resource_id> or %<resource_id> or resource%<resource_id>, or a resource name regular expression regexp%<resource_pattern>.
location delete <id>... — removes location constraints with the specified ids 🗑️
location remove <id>... — also removes location constraints with the specified ids. Same thing, different word, we love options.
order [config] [--full] [--output-format text|cmd|json] — lists all current ordering constraints (and if --full is specified, it shows the internal constraint ids too). Three formats of output available: cmd, json, and text, default is text. text is a human friendly output. cmd prints pcs commands which can be used to recreate the same configuration. json is a machine oriented output of the configuration ⭐
order [action] <resource id> then [action] <resource id> [options] — adds an ordering constraint, and you can specify the actions (start, stop, promote, demote). No action specified? Then the default action is start. Available options are kind=Optional/Mandatory/Serialize, symmetrical=true/false, require-all=true/false and id=<constraint-id>.
order set <resource1> [resourceN]... [options] [set <resourceX> ... [options]] [setoptions [constraint_options]] — creates an ordered set of resources ✨ Available options are sequential=true/false, require-all=true/false and action=start/promote/demote/stop. Available constraint_options are id=<constraint-id>, kind=Optional/Mandatory/Serialize and symmetrical=true/false.
order delete <resource1> [resourceN]... — removes the resource from any ordering constraint.
order remove <resource1> [resourceN]... — removes the resource from any ordering constraint. Yeah. Same.
colocation [config] [--full] [--output-format text|cmd|json] — lists all current colocation constraints (if --full is specified, it shows the internal constraint ids as well). Three formats of output available: cmd, json, and text, default is text. text is a human friendly output. cmd prints pcs commands which can be used to recreate the same configuration. json is a machine oriented output of the configuration 💜
colocation add [<role>] <source resource id> with [<role>] <target resource id> [score=<score>] [<options>] [id=<constraint-id>] — this asks <source resource> to run on the same node where pacemaker has determined <target resource> should run. Positive score values mean the resources should run on the same node, negative values mean they should not run on the same node. Set the score to 'INFINITY' (or '-INFINITY') and you force <source resource> to run (or not run) with <target resource> — score defaults to "INFINITY". A role can be: 'Promoted', 'Unpromoted', 'Started', 'Stopped', and if no role is specified it defaults to 'Started'.
colocation set <resource1> [resourceN]... [options] [set <resourceX> ... [options]] [setoptions [constraint_options]] — creates a colocation constraint with a resource set 🎀 Available options are sequential=true/false and role=Stopped/Started/Promoted/Unpromoted. Available constraint_options are id, influence and score.
colocation delete <source resource id> <target resource id> — removes colocation constraints with the specified resources.
colocation remove <source resource id> <target resource id> — removes colocation constraints with the specified resources. (Not me repeating myself, the manpage just has both 😭)
ticket [config] [--full] [--output-format text|cmd|json] — lists all current ticket constraints (if --full is specified, it shows the internal constraint ids as well). Three formats of output available: cmd, json, and text, default is text. text is a human friendly output. cmd prints pcs commands which can be used to recreate the same configuration. json is a machine oriented output of the configuration 🌸
ticket add <ticket> [<role>] <resource id> [<options>] [id=<constraint-id>] — creates a ticket constraint for <resource id>. Available option is loss-policy=fence/stop/freeze/demote. A role can be Promoted, Unpromoted, Started or Stopped.
ticket set <resource1> [<resourceN>]... [<options>] [set <resourceX> ... [<options>]] setoptions <constraint_options> — creates a ticket constraint with a resource set. Available options are role=Stopped/Started/Promoted/Unpromoted. The required constraint option is ticket=<ticket>. Optional constraint options are id=<constraint-id> and loss-policy=fence/stop/freeze/demote.
ticket delete <ticket> <resource id> — removes all ticket constraints with <ticket> from <resource id>.
ticket remove <ticket> <resource id> — removes all ticket constraints with <ticket> from <resource id>. Yep, again, both exist 🦋
delete <constraint id>... — removes constraint(s) or constraint rules with the specified id(s).
remove <constraint id>... — removes constraint(s) or constraint rules with the specified id(s).
ref <resource>... — lists constraints referencing the resource(s) you name 🔍

🧚 qdevice 🧚

status <device model> [--full] [<cluster name>] — shows the runtime status of the specified model of quorum device provider. Using --full gives you more detailed output. And if <cluster name> is specified, only information about that cluster gets displayed.
setup model <device model> [--enable] [--start] — configures the specified model of quorum device provider. After that, the quorum device can be added to clusters by running pcs quorum device add inside a cluster. --start will also start the provider. --enable will configure the provider to start on boot 👑
destroy <device model> — disables and stops the specified model of quorum device provider, then deletes its configuration files 💀
start <device model> — starts the specified model of quorum device provider 🔥
stop <device model> — Stops the specified model of quorum device provider. Nap time bestie 💤
kill <device model> — Forces the specified model of quorum device provider to stop — and by "forces" we mean it literally runs kill -9. No chill. ⚠️ Fair warning though: your init system (like systemd) can totally notice the qdevice isn't running and just start it right back up again. So if what you actually want is to stop the qdevice, run pcs qdevice stop instead. Periodt.
enable <device model> — Sets the specified model of quorum device provider to start on boot. ✨
disable <device model> — Sets the specified model of quorum device provider to not start on boot. 🚫

quorum 🗳️

[config] — Shows the quorum configuration. That's it, that's the whole vibe.
status — Shows the quorum runtime status. 👀
device add [<generic options>] model <device model> [<model options>] [heuristics <heuristics options>] — Adds a quorum device to the cluster.

Okay so first things first: the quorum device has to be configured before any of this, with pcs qdevice setup. Also, you literally cannot have more than one quorum device in a cluster at the same time. One. Singular. That's the rule. 🙅‍♀️

Currently the only supported model is 'net'. It requires the model options 'algorithm' and 'host' to be specified — both mandatory, no skipping. All the options are documented in the corosync-qdevice(8) man page; the generic options are 'sync_timeout' and 'timeout'. For model net options, go check the quorum.device.net section; for heuristics options, see the quorum.device.heuristics section. And pcs will automatically create and distribute the TLS certificates for you (slay 💅) and sets the 'tls' model option to its default value 'on'.

Example, because we love a demonstration:

pcs quorum device add model net algorithm=lms host=qnetd.internal.example.com

device heuristics delete — Removes all the heuristics settings of the configured quorum device. 🧹
device heuristics remove — Also removes all the heuristics settings of the configured quorum device. Twin commands, same energy. 🧹
device delete — Removes a quorum device from the cluster.
device remove — Removes a quorum device from the cluster. (Yes, same thing. They're basically twins, it's iconic.)
device status [--full] — Shows the quorum device runtime status. Pass --full and you get the extended director's cut with more detailed output. 🎬
device update [<generic options>] [model <model options>] [heuristics <heuristics options>] — Adds, removes or changes quorum device options. Anything you don't specify stays exactly how it was. Want to remove an option? Set it to an empty value, like 'option_name='. This one requires the cluster to be stopped — for real, stop it. The model and options are all documented in the corosync-qdevice(8) man page; for heuristics options check the quorum.device.heuristics subkey section, and for model options check the quorum.device.<device model> subkey sections.

WARNING: if you want to change the "host" option of qdevice model net, use pcs quorum device remove and pcs quorum device add to set the configuration up properly — unless the old and new host are the same machine.

expected-votes <votes> — Sets expected votes in the live cluster to the value you give. Live cluster only, okay? This does not change any configuration files. Not a single one. 🫶
unblock [--yes] — Cancels waiting for all nodes when establishing quorum. Useful when you already know the cluster is inquorate but you're confident the cluster should just go ahead and do resource management regardless. This command should ONLY be used when the nodes the cluster is waiting for have been confirmed to be powered off and to have no access to shared resources. Like, confirmed confirmed.

WARNING: if those nodes are not actually powered off, or they do have access to shared resources, data corruption / cluster failure can happen. 💀 And to stop you from running this by accident, --yes or an interactive user response is required in order to proceed.

update [auto_tie_breaker=[0|1]] [last_man_standing=[0|1]] [last_man_standing_window=[<time in ms>]] [wait_for_all=[0|1]] — Adds, removes or changes quorum options. At least one option has to be specified. Anything unspecified stays unchanged. Want to remove an option? Set it to an empty value, like 'option_name='. The options are documented in corosync's votequorum(5) man page. Requires the cluster to be stopped.

booth 🎪

setup sites <address> <address> [<address>...] [arbitrators <address> ...] [--force] — Writes a brand new booth configuration with the sites and arbitrators you list. The total number of peers (sites and arbitrators together) must be odd — that's the math, bestie. If the configuration file already exists, the command fails unless you pass --force.
destroy — Removes the booth configuration files. Gone. Poof. 🗑️
ticket add <ticket> [<name>=<value> ...] — Adds a new ticket to the local site configuration. Ticket options are specified in the booth manpage.
ticket delete <ticket> — Removes the specified ticket from the local site configuration. Heads up though: the ticket is still loaded in the current CIB, so you should clean it up with the pcs ticket cleanup command.
ticket remove <ticket> — Removes the specified ticket from the local site configuration. Same situation — it stays loaded in the current CIB and should be cleaned up using pcs ticket cleanup.
ticket cleanup [ticket] — Removes tickets from the CIB at the local site. If you don't give a ticket name, it removes all the tickets present in the CIB but not in the booth configuration. If you do give a ticket name, then it removes that specified ticket from the CIB.
ticket standby <ticket> — Tells the cluster on the local site that this ticket is standby. The dependent resources will be stopped or demoted gracefully, without triggering loss-policies. So polite. So elegant. ✨
ticket unstandby <ticket> — Tells the cluster on the local site that this ticket is no longer standby.
config [<node>] — Shows the booth configuration from the specified node, or from the current node if you don't specify one.
create ip <address> — Makes the cluster run the booth service on the specified ip address as a cluster resource. Typically this is how you run a booth site.
delete [--no-stop] [--future] — Removes booth resources created by the pcs booth create command.

If --no-stop is specified, the resources will not be stopped before their deletion. That may result in orphaned resources being left behind in case the deleted resources aren't already stopped. 😬

Using --force currently also means the resources will not be stopped before their deletion. So if you need to use --force and still want the resources stopped, you need to combine it with the --future flag.

remove [--no-stop] [--future] — Removes booth resources created by the pcs booth create command.

If --no-stop is specified, the resources will not be stopped before their deletion. This may result in orphaned resources being left behind in case the deleted resources are not already stopped.

restart — Restarts booth resources created by the pcs booth create command. 🔄
ticket grant <ticket> [<site address>] — Grants the ticket to the site specified by the address, hence to the booth formation that site is a member of. Omit the address and the site address that was specified with the pcs booth create command is used. Which means specifying the site address is mandatory when you're running this command at a host in an arbitrator role.

Also note: the ticket must not already be granted in the given booth formation. For an ad-hoc (and, in the worst case, abrupt — because there's a lack of direct atomicity) change of this preference, short of baring direct interventions at the sites, the ticket needs to be revoked first; only then can it be granted at another site again.

ticket revoke <ticket> [<site address>] — Revokes the ticket in the booth formation as identified by one of its member sites, specified by the address. When this specification is omitted, the site address specified with a prior pcs booth create command is used. So specifying the site address is mandatory when running this command at a host in an arbitrator role.
status — Prints the current status of booth on the local node.
pull <node> — Pulls the booth configuration from the specified node. Pull booth configuration from the specified node. After pulling the configuration, the booth should be restarted. And in case any tickets were removed, you should use the pcs ticket cleanup command to remove any leftover tickets still loaded in the CIB at the current site.
sync [--skip-offline] — Sends the booth configuration from the local node to all nodes in the cluster. Everyone gets a copy. 📬
enable — Enables the booth arbitrator service.
disable — Disables the booth arbitrator service.
start — Starts the booth arbitrator service.
stop — Stops the booth arbitrator service.

status 📊

[status] [--full] [--hide-inactive] — Views all the information about the cluster and resources. --full provides more details, --hide-inactive hides inactive resources. Pick your fighter.
resources [<resource id | tag id>] [node=<node>] [--hide-inactive] — Shows the status of all currently configured resources. If --hide-inactive is specified, only active resources get shown. If you give a resource or tag id, it only shows the status of the specified resource, or of the resources in the specified tag. If a node is specified, it only shows the status of resources configured for that node.
cluster — Views the current cluster status.
corosync — Views the current membership information as seen by corosync.
quorum — Views the current quorum status.
qdevice <device model> [--full] [<cluster name>] — Shows the runtime status of the specified model of quorum device provider. Using --full gives you more detailed output. If <cluster name> is specified, only information about that specified cluster will be displayed.
booth — Prints the current status of booth on the local node.

`nodes` [corosync | both | config]

okay so this one shows you the current status of your nodes — from pacemaker by default 💖. But you can switch it up:

pass corosync and you get the current status of the nodes from corosync instead
pass both and you get the current status of the nodes from corosync & pacemaker, both of them, at the same time
pass config and it prints the nodes from the corosync & pacemaker configuration

`pcsd` [<node>]...

Shows the current status of pcsd on the nodes you list 🫶. And if you don't list any nodes at all? It does it for every node configured in the local cluster. Easy.

`xml`

Gives you the xml version of the status ✨. That's literally the output of crm_mon -r -1 -X. No cap.

`wait` [<timeout>]

Waits for the cluster to settle into a stable state 😌. The timeout can be:

a bare number, which means that many seconds, or
a number with a unit — s or sec for seconds, m or min for minutes, h or hr for hours.

If timeout isn't specified, or it's set to zero, it defaults to 60 minutes ⏰.

Example:

pcs status wait 30min

`query resource <resource-id> exists` [--quiet]

Queries whether the resource exists 👀.

Prints True and exits with 0 if the query evaluates to true.
Exits with 1 if an error happens while performing the query.
Prints False and exits with 2 otherwise.

If --quiet is specified, it prints nothing at all and just exits with the appropriate return code 🤫.

`query resource <resource-id> is-stonith` [--quiet]

Queries whether the resource is a stonith resource 🪓.

Prints True and exits with 0 if the query evaluates to true.
Exits with 1 if an error happens while performing the query.
Prints False and exits with 2 otherwise.

If --quiet is specified, no output, just the return code. 🤫

`query resource <resource-id> is-type`

query resource <resource-id> is-type (primitive | group | clone [unique]
[promotable] | bundle [unique]) [--quiet]

Queries whether the resource is of the given type 💅. It also lets you check whether clones are globally unique or promotable, and whether bundles are globally unique.

Prints True and exits with 0 if the query evaluates to true.
Exits with 1 if an error happens while performing the query.
Prints False and exits with 2 otherwise.

If --quiet is specified, no output, just the return code. 🤫

`query resource <resource-id> get-type`

Gets the type of a resource in a pacemaker cluster. The output is one of:

primitive, group, clone, clone unique, clone promotable, clone unique promotable, bundle or bundle unique. 🎀

`query resource <resource-id> is-state`

query resource <resource-id> is-state <state> [on-node <node-name>]
[members all|any|none] [instances all|any|none] [--quiet]

Queries whether the resource is in the given state. And bestie, <state> can be any one of these:

active, blocked, demoting, disabled, enabled, failed, failure_ignored, locked_to, maintenance, managed, migrating, monitoring, orphaned, pending, promoted, promoting, started, starting, stopped, stopping, unmanaged or unpromoted.

The states starting, stopping, promoting, demoting, migrating and monitoring all describe that a resource operation — start, stop, promote, demote, migrate_from/to, or monitor — is currently in progress on the resource. And pending evaluates to true if any of those operations is currently in progress on the resource.

The state locked_to lets you specify the node name of the node that the resource is locked to 🔒.

With groups, the state is read and evaluated on the group first. If the state can't be determined from only the group, it evaluates the state of the member resources and returns true if the query is true for ALL of the members. members can be used to specify how to evaluate the states of the members. And if members is specified, then the query is always evaluated only on the member resources, without looking at the group itself. Which means — for example — queries for started and stopped on a group with one started and one stopped member will both evaluate as false at the same time, if members isn't specified or it's set to all. 😭

With clones and bundles, the state is read and evaluated on the clone or bundle first. If the state can't be determined from only the clone or bundle, it evaluates the state on the instances and returns true if the query is true for ANY of the instances. instances can be used to specify how to evaluate the state of the instances. If instances is specified, then the query is always evaluated only on the instances, without looking at the clone or bundle themselves. Which means — for example — queries for started and stopped on a clone with one started and one stopped instance will both evaluate as true at the same time, if instances isn't specified or it's set to any. 💀

on-node can be used to test whether the resource is in the given state on the node with the given name. And if on-node is used, it always checks only the member resources for groups, and the instances for clones or bundles.

Queries on the state of cloned or bundled resources are evaluated similarly to queries on clones or bundles: evaluate the state of every instance and return true if the query is true for ANY of the instances. instances can be used to specify how the query should be evaluated. And it's possible to query a single specific instance of unique clones or bundles by using the resource id together with the suffix that distinguishes instances for unique clones and bundles.

Example — query if any instance of the resource is started:

pcs status query resource resource_id is-state started

Example — query if one specific instance is started:

pcs status query resource resource_id:0 is-state started

Prints True and exits with 0 if the query evaluates to true.
Exits with 1 if an error happens while performing the query.
Prints False and exits with 2 otherwise.

If --quiet is specified, no output, just the return code. 🤫

`query resource <resource-id> is-in-group` [<group-id>] [--quiet]

Queries whether the resource is in any group, or in a group with the specified id.

Prints True and exits with 0 if the query evaluates to true.
Exits with 1 if an error happens while performing the query.
Prints False and exits with 2 otherwise.
Prints the id of the group on a new line if the resource is in any group.

If --quiet is specified, no output, just the return code. 🤫

`query resource <resource-id> is-in-clone` [<clone-id>] [--quiet]

Queries whether the resource is in any clone, or in a clone with the specified id. Heads up: a resource that's in a cloned group counts as being in the clone itself. 🦋

Prints True and exits with 0 if the query evaluates to true.
Exits with 1 if an error happens while performing the query.
Prints False and exits with 2 otherwise.
Prints the id of the clone on a new line if the resource is in any clone.

If --quiet is specified, no output, just the return code. 🤫

`query resource <resource-id> is-in-bundle` [<bundle-id>] [--quiet]

Queries whether the resource is in any bundle, or in a bundle with the specified id.

Prints True and exits with 0 if the query evaluates to true.
Exits with 1 if an error happens while performing the query.
Prints False and exits with 2 otherwise.
Prints the id of the bundle on a new line if the resource is in any bundle.

If --quiet is specified, no output, just the return code. 🤫

`query resource <resource-id> get-nodes`

Gets all the nodes on which the resource is running 🔥. With groups, it returns the nodes on which any of the members is running. For clones or bundles, it returns the nodes on which any of the instances or replicas are running.

Prints each node name on a new line. ✨

`query resource <resource-id> get-members`

Gets the ids of the member resources of the resource. Only useful for group, clone and bundle resources, ngl.

Prints each member id on a new line. ✨

`query resource <resource-id> get-index-in-group`

Gets the index of the resource in a group. The first resource in a group has an index of 0. And it's only usable for resources that are in a group. 🎀

`config` 💜

`show` [--show-secrets]

Views the full cluster configuration ✨. If --show-secrets is specified, it displays the values of secret attributes in the configuration text output. By default, only the attribute names are displayed and the values are omitted. 🙈

`backup` [filename]

Creates the tarball containing the cluster configuration files 📦. If filename isn't specified, standard output is used.

`restore` [--local] [filename]

Restores the cluster configuration files on all nodes from the backup 🫶. If filename isn't specified, standard input is used. And if --local is specified, only the files on the current node will be restored.

`checkpoint`

Lists all the available configuration checkpoints. 📋

`checkpoint view <checkpoint_number>`

Shows the specified configuration checkpoint. 👀

`checkpoint diff <checkpoint_number> <checkpoint_number>`

Shows the differences between the two specified checkpoints. And plot twist — you can use the checkpoint number live to compare a checkpoint to the current live configuration. 🔥

`checkpoint restore <checkpoint_number>`

Restores the cluster configuration to the specified checkpoint. ⏪

`pcsd` 🦋

`certkey <certificate file> <key file>`

Loads custom certificate and key files for use in pcsd 🔐.

`status` [<node>]...

Shows the current status of pcsd on the nodes you list, or on every node configured in the local cluster if you don't list any nodes. 💅

`sync-certificates`

Syncs pcsd certificates to all the nodes in the local cluster. 🔄

`deauth` [<token>]...

Deletes the locally stored authentication tokens that remote systems use to connect to the local pcsd instance 🗑️. If no tokens are specified, all tokens get deleted. And heads up, bestie — after this command runs, other nodes will need to re-authenticate against this node to be able to connect to it. 😭

host 🌐

`auth (<host name> [addr=<address>[:<port>]])... [-u <username>] [-p <password>]`

okay so this one logs your local pcs/pcsd into the pcsd running on the hosts you name 💖. And bestie, you get to be picky about how they talk: you can hand it an address and a port per host, and that's the route pcs/pcsd will use to chat with each one. Skip the address? Then the host name itself gets used, easy. Skip the port? 2224 is the default, no cap 🫶.

`deauth [<host name>]...`

this deletes the authentication tokens that let pcs/pcsd on this machine connect out to remote pcsd instances on the host names you list 🗑️. If the current system is a member of a cluster, those tokens get deleted from every node in the cluster, not just here — iconic teamwork energy. And if you name no hosts at all? All the tokens go. Heads up though: after you run this, this node has to re-authenticate against the other nodes before it can connect to them again. So like, know what you're doing 💅.

node 🖥️

`attribute [[<node>] [--name <name>] | (--output-format text|cmd|json) | <node> <name>=<value> ...]`

node attribute management, let's go ✨. The rules are lowkey a whole vibe check on how many params you pass:

No parameters at all → it shows the attributes of all nodes.
One parameter → it shows the attributes of that specified node.
--name → it shows that specified attribute's value across all nodes.
More parameters → it sets attributes on the specified node.

And the removal trick? Set an attribute with no value and it's gone, bye 👋.

Three output formats live here: 'cmd', 'json' and 'text', and the default is 'text'.

'text' is the human-friendly one, for your eyeballs 💖
'cmd' prints actual pcs commands you could run to recreate the exact same configuration
'json' is the machine-oriented output of the configuration, for the robots 🤖

`maintenance [--all | <node>...] [--wait[=n]]`

Puts the specified node(s) into maintenance mode 🛠️. No nodes and no options? The current node gets put into maintenance mode. --all? Every node goes in, periodt. And if you pass --wait, pcs will wait up to n seconds for the node(s) to actually land in maintenance mode, then return 0 on success or 1 if the operation hasn't succeeded yet. Don't specify n? It defaults to 60 minutes — yes, an hour, she's patient 😭.

`unmaintenance [--all | <node>...] [--wait[=n]]`

Takes node(s) back out of maintenance mode 🌈. No nodes or options → the current node comes out. --all → everybody comes out. --wait → pcs waits up to n seconds for the node(s) to be removed from maintenance mode, returning 0 on success or 1 if it hasn't happened yet. No n? Defaults to 60 minutes again 🫶.

`standby [--all | <node>...] [--wait[=n]]`

Puts the specified node(s) into standby mode — and bestie, that means the node specified will no longer be able to host resources 💀. No nodes or options → the current node goes into standby. --all → all of them do. --wait → pcs waits up to n seconds for the node(s) to be put into standby mode, then returns 0 on success or 1 if the operation hasn't succeeded yet. Default n is 60 minutes ✨.

`unstandby [--all | <node>...] [--wait[=n]]`

Brings node(s) back out of standby mode, which means the node specified will now be able to host resources again 👑. No nodes or options → the current node is removed from standby. --all → all nodes are. --wait → pcs waits up to n seconds for the node(s) to be removed from standby mode, returning 0 on success or 1 if it hasn't succeeded yet. And yep, default n = 60 minutes 🌸.

`utilization [[<node>] [--name <name>] | (--output-format text|cmd|json) | <node> <name>=<value> ...]`

Adds the utilization options you specify to the node you specify 🍓. If the node isn't specified, it shows utilization for all nodes. If --name is specified, it shows that specified utilization value from all nodes. If no utilization options are specified, it shows the utilization of the specified node. A utilization option has to be in name=value format, and the value has to be an integer — no decimals, no vibes-based math 🙈. Options can be removed by setting an option without a value. Same three output formats as always: 'cmd', 'json' and 'text', default 'text' — 'text' being human friendly, 'cmd' printing pcs commands that recreate the same configuration, 'json' being the machine-oriented output 💅.

Example: pcs node utilization node1 cpu=4 ram=

For the utilization configuration to be in effect, cluster property 'placement-strategy' must be configured accordingly. Not optional, not negotiable, go set it 🫶.

alert 🚨

`[config] [--output-format text|cmd|json]`

Shows all your configured alerts 📣. Three output formats: 'cmd', 'json' and 'text', default 'text'. 'text' = human friendly, 'cmd' = prints pcs commands that can recreate the same configuration, 'json' = machine-oriented output of the configuration ✨.

`create path=<path> [id=<alert-id>] [description=<description>] [options [<option>=<value>]...] [meta [<meta-option>=<value>]...]`

Defines an alert handler with the path you give it 🌟. And don't stress about the id — it gets generated automatically if you don't specify one 💖.

`update <alert-id> [path=<path>] [description=<description>] [options [<option>=<value>]...] [meta [<meta-option>=<value>]...]`

Updates an existing alert handler with the specified id 🛠️. Anything you don't specify stays exactly as it was — no surprise changes, we respect boundaries. And if you want to remove an option? Set it to an empty value, like 'option_name=' 💅.

`delete <alert-id> ...`

Removes alert handlers with the specified ids 🗑️.

`remove <alert-id> ...`

Removes alert handlers with the specified ids 🗑️. (Same energy, different word, we love options.)

`recipient add <alert-id> value=<recipient-value> [id=<recipient-id>] [description=<description>] [options [<option>=<value>]...] [meta [<meta-option>=<value>]...]`

Adds a brand new recipient to the specified alert handler 📬.

`recipient update <recipient-id> [value=<recipient-value>] [description=<description>] [options [<option>=<value>]...] [meta [<meta-option>=<value>]...]`

Updates an existing recipient identified by its id 💖. Unspecified options are kept unchanged. Want something gone? Empty value, i.e. 'option_name=' 👋.

`recipient delete <recipient-id> ...`

Removes the specified recipients 🗑️.

`recipient remove <recipient-id> ...`

Removes the specified recipients 🗑️.

client 🧚

`local-auth [<pcsd-port>] [-u <username>] [-p <password>]`

Authenticates the current user to the local pcsd 🔐. You need this for some pcs commands that require root user permissions — think stuff like 'pcs cluster start'. So yeah, do the login first, main character 💅.

dr 🩹

`config`

Displays the disaster-recovery configuration from the local node 📋.

`status [--full] [--hide-inactive]`

Displays the status of the local and the remote site cluster 🌍. --full gives you more details, and --hide-inactive hides the inactive resources (a whole mood, honestly).

`set-recovery-site <recovery site node>`

Sets up disaster-recovery with the local cluster being the primary site ✨. The recovery site is defined by a name of one of its nodes — just one node name, that's the whole ID 🫶.

`destroy`

Permanently destroys the disaster-recovery configuration on all sites 💀. Permanently. Like, gone gone. Read that twice.

tag 🎀

`[config [<tag id>...]] [--output-format text|cmd|json]`

Displays configured tags 🏷️. Three formats, you know the drill: 'cmd', 'json' and 'text', default 'text'. 'text' = human friendly, 'cmd' = pcs commands you can use to recreate the same configuration, 'json' = machine-oriented output of the configuration ⭐.

`create <tag id> <id> [<id>]...`

Creates a tag containing the specified ids 🌸.

`delete <tag id>...`

Deletes the specified tags 🗑️.

`remove <tag id>...`

Deletes the specified tags 🗑️.

`update <tag id> [add <id> [<id>]... [--before <id> | --after <id>]] [remove <id> [<id>]...]`

Updates a tag using the ids you specify ✨. Ids can be added, removed, or moved inside a tag. Use --before or --after to set where the added ids land relative to some id that's already in the tag 👑. And here's the slick part: add ids that are already in the tag and slap --after or --before on there, and congrats, you just moved them within the tag. iykyk 💅.

cib 📚

`element description <element-id>`

Gets the description of a CIB element 🔍.

`element description <element-id> <description text>`

Sets a description on a CIB element ✍️. And if you want to remove a description? Set it to an empty string, bye bye 👋.

✨ EXAMPLES ✨

Show all resources

# pcs resource config

Show options specific to the 'VirtualIP' resource

# pcs resource config VirtualIP

Create a new resource called 'VirtualIP' with options

# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.99 cidr_netmask=32 nic=eth2 op monitor interval=30s

Create a new resource called 'VirtualIP' with options

# pcs resource create VirtualIP IPaddr2 ip=192.168.0.99 cidr_netmask=32 nic=eth2 op monitor interval=30s

Change the ip address of VirtualIP and remove the nic option

# pcs resource update VirtualIP ip=192.168.0.98 nic=

Delete the VirtualIP resource

# pcs resource delete VirtualIP

Create the MyStonith stonith fence_virt device which can fence host 'f1'

# pcs stonith create MyStonith fence_virt pcmk_host_list=f1

Set the stonith-enabled property to false on the cluster (which disables stonith)

# pcs property set stonith-enabled=false

⚠️ USING `--FORCE` IN PCS COMMANDS ⚠️

okay bestie, sit down for this one 🫶. Various pcs commands accept the --force option. Its whole purpose is to override some of the checks that pcs is doing or some of the errors that may occur when a pcs command is run. When such an error happens, pcs will print the error along with a note that it may be overridden — so it's not sneaking up on you, it's telling you the door exists 🙈.

And the exact behavior of the option is different for each pcs command — no universal rules here, each command does its own thing.

Using the --force option can lead into situations that would normally be prevented by logic of pcs commands and therefore its use is strongly discouraged unless you know what you are doing. 💀

Like, truly, unless you know what you're doing. That's not me being dramatic, that's literally the manpage. Respect the logic, it's there for a reason 👑.

🌈 ENVIRONMENT VARIABLES 🌈

EDITOR — the path to a plain-text editor, bestie. pcs pulls this up when it needs to show you some text and let you edit it yourself. ✍️✨
no_proxy, https_proxy, all_proxy, NO_PROXY, HTTPS_PROXY, ALL_PROXY — these env vars (listed in their priority order, highkey important 👀) control how pcs handles proxy servers when it's connecting to cluster nodes. Want the deets? Go peek at the curl(1) man page. 🌀🦋

💫 CHANGES IN PCS-0.12 💫

Okay so this section is basically the glow-up recap: the most important command changes in pcs-0.12.x compared to pcs-0.11.x. For the full tea on current commands, look above. ☝️🍓

🦋 Pacemaker 3 changes 🦋

Following pacemaker 3, pcs has dropped support for:

nagios and upstart resource classes
rkt containers in bundle resources
multiple rules in a single location constraint

👑 Legacy role names 👑

Legacy role names, plus their derived options and keywords, are no longer accepted. Instead use 'Promoted', 'Unpromoted', --promoted, 'promotable', 'promoted-max'. That's the new main character vocabulary, periodt. 💅

🙈 Mixing resources and stonith resources 🙈

Using stonith resources in 'pcs resource' commands and resources in 'pcs stonith' commands is no longer allowed. Keep your lanes separate, bestie. 🚧

⭐ Resources validation ⭐

When you create or update a resource or stonith, its options are now validated by the resource or stonith agent. Unless --agent-validation is specified, this does not prevent misconfiguring the resource or stonith by exiting with an error. Back in pcs-0.11, validation only happened when --agent-validation was specified. So yeah, the vibe check is automatic now. ✅

🌸 Pacemaker rules 🌸

Several date-spec and duration options have been removed in pacemaker 3, so pcs doesn't support them either. The previously supported date-spec and duration options were: hours, monthdays, weekdays, yearsdays, months, weeks, years, weekyears, moon.

The new date-spec options are: seconds, minutes, hours, monthdays, weekdays, yeardays, months, weeks, years, weekyears.

The new duration options are: seconds, minutes, hours, days, weeks, months, years.

Using spaces in dates in location constraint rules is no longer allowed. Rules are supposed to be specified as a single string argument. Specifying rules as multiple arguments has been deprecated and might be removed in a future release. 👀⚠️

🎀 `--yes` instead of `--force` as an alternative to interactive confirmation 🎀

Some pcs commands require interactive confirmation to proceed. Previously, you could override that by specifying --force. Since pcs-0.12, using --force for this purpose is deprecated in favor of --yes. The --force flag is kept to override validation errors, which was its originally intended use. The affected commands are: 'pcs cluster destroy', 'pcs quorum unblock', 'pcs stonith confirm', 'pcs stonith sbd device setup' and 'pcs stonith sbd watchdog test'. Read the room and use the right flag, bestie. 🫶

💜 acl 💜

role assign | unassign — the possibility of not specifying the 'user' or 'group' keyword is now deprecated and might be removed in a future release. ⏳
show — this deprecated command has been removed. Use 'pcs acl config' instead.

🍓 alert 🍓

show — this deprecated command has been removed. Use 'pcs alert config' instead.

🧚 cluster 🧚

certkey — this deprecated command has been removed. Use 'pcs pcsd certkey' instead.
node add-remote | add-guest — the --wait option is deprecated. Instead, use the 'pcs status wait' command to wait for the cluster to settle into a stable state. Use the 'pcs status query resource' commands to verify that the resource is in the expected state after the wait. ⏲️
node remove-remote | delete-remote — these commands no longer remove location constraints referencing the node name of the removed remote node.
pcsd-status — this deprecated command has been removed. Use 'pcs status pcsd' or 'pcs pcsd status' instead.

💖 constraint 💖

colocation add — specifying score as a standalone value is deprecated in favor of score=value. This makes the command consistent with other commands for creating constraints. 🔄
list — this deprecated command, as well as its variants 'pcs constraint [location | colocation | order | ticket] list', has been removed. Use 'pcs constraint [location | colocation | order | ticket] config' instead.
location add — specifying score as a standalone value is deprecated in favor of score=value. This makes the command consistent with other commands for creating constraints. 🔄
rule add | delete | remove — these deprecated commands have been removed, as pacemaker 3 no longer allows location constraints to contain more than one rule.
show — this deprecated command, as well as its variants 'pcs constraint [location | colocation | order | ticket] show', has been removed. Use 'pcs constraint [location | colocation | order | ticket] config' instead.

🌟 property 🌟

list — this deprecated command has been removed. Use 'pcs property config' instead.
show — this deprecated command has been removed. Use 'pcs property config' instead.

🔥 resource 🔥

--wait option — this option is deprecated in all resource commands except 'pcs resource restart' and 'pcs resource move'. Instead, use the 'pcs status wait' command to wait for the cluster to settle into a stable state. Use the 'pcs status query resource' commands to verify that the resource is in the expected state after the wait. ⏲️
defaults <name>=<value>... — this deprecated command has been removed. Use 'pcs resource defaults update <name>=<value>...' if you only manage one set of defaults, or 'pcs resource defaults set' if you manage several sets of defaults.
move — since pcs-0.11, this command automatically deletes location constraints used for moving a resource. Therefore, its deprecated flag --autodelete has been removed.
op defaults <name>=<value>... — this deprecated command has been removed. Use 'pcs resource op defaults update <name>=<value>...' if you only manage one set of defaults, or 'pcs resource op defaults set' if you manage several sets of defaults.
remove | delete — removing resources representing remote and guest nodes is no longer possible. Use 'pcs cluster node remove-remote' to remove remote nodes and 'pcs cluster node remove-guest' to remove guest nodes.

💀 stonith 💀

create --group — creating stonith resources in groups is no longer allowed.
defaults <name>=<value>... — this deprecated command has been removed. Use 'pcs stonith defaults update <name>=<value>...' if you only manage one set of defaults, or 'pcs stonith defaults set' if you manage several sets of defaults.
disable — the deprecated options --brief, --no-strict, --safe and --simulate have been removed.
level add | clear | delete | remove — delimiting stonith devices with a comma is no longer allowed. The ambiguous syntax of 'pcs stonith level clear | delete | remove' is no longer supported.
op defaults <name>=<value>... — this deprecated command has been removed. Use 'pcs stonith op defaults update <name>=<value>...' if you only manage one set of defaults, or 'pcs stonith op defaults set' if you manage several sets of defaults.

🌈 tag 🌈

list — this deprecated command has been removed. Use 'pcs tag config' instead.

🌙 CHANGES IN PCS-0.11 🌙

And now the throwback section: the most important command changes in pcs-0.11.x compared to pcs-0.10.x. For the full current-command rundown, scroll up bestie. ☝️💫

👑 Legacy role names 👑

Roles 'Master' and 'Slave' are deprecated and should not be used anymore. Instead, use 'Promoted' and 'Unpromoted', respectively. Similarly, --master has been deprecated and replaced with --promoted. We don't say those old words anymore, okay? 💅

🧚 cluster 🧚

uidgid rm — this command has been replaced with 'pcs cluster uidgid delete' and 'pcs cluster uidgid remove'.

🔥 resource 🔥

move — the 'pcs resource move' now automatically removes the location constraint used for moving a resource. It is equivalent of 'pcs resource move --autodelete' from pcs-0.10.9. The legacy functionality of the 'resource move' command is still available as 'resource move-with-constraint <resource id>'. 🔁
show --full — this command has been replaced with 'pcs resource config'.
show --groups — this command has been replaced with 'pcs resource group list'.
show — this command has been replaced with 'pcs resource status'.

💀 stonith 💀

show --full — this command has been replaced with 'pcs stonith config'.
show — this command has been replaced with 'pcs stonith status'.

✨ CHANGES IN PCS-0.10 ✨

Okay bestie, this is the throwback section 💅 — it's the tea on what got glow-upped in pcs-0.10.x compared to pcs-0.9.x. For the full deets on how the current commands actually work, scroll on up ⬆️.

🎀 acl

show

The pcs acl show command has been deprecated and will be removed 😭. Please use pcs acl config instead. Applicable in pcs-0.10.9 and newer.

🔔 alert

show

The pcs alert show command has been deprecated and will be removed 😭. Please use pcs alert config instead. Applicable in pcs-0.10.9 and newer.

👑 cluster

auth

The pcs cluster auth command only authenticates nodes in a local cluster and does not accept a node list. The new command for authentication is pcs host auth. It lets you specify host names, addresses and pcsd ports ✨.

node add

Custom node names and Corosync 3.x with knet are fully supported now, so the syntax has been completely changed. The --device and --watchdog options have been replaced with device and watchdog options, respectively.

pcsd-status

The pcs cluster pcsd-status command has been deprecated and will be removed 😭. Please use pcs pcsd status or pcs status pcsd instead. Applicable in pcs-0.10.9 and newer.

quorum

This command has been replaced with pcs quorum.

remote-node add

This command has been replaced with pcs cluster node add-guest.

remote-node remove

This command has been replaced with pcs cluster node delete-guest and its alias pcs cluster node remove-guest.

setup

Custom node names and Corosync 3.x with knet are fully supported now, so the syntax has been completely changed. The --name option has been removed. The first parameter of the command is the cluster name now. The --local option has been replaced with --corosync_conf <path>.

standby

This command has been replaced with pcs node standby.

uidgid rm

This command has been deprecated, use pcs cluster uidgid delete or pcs cluster uidgid remove instead.

unstandby

This command has been replaced with pcs node unstandby.

verify

The -V option has been replaced with --full. To specify a filename, use the -f option.

🔒 constraint

list

show

🫶 pcsd

clear-auth

This command has been replaced with pcs host deauth and pcs pcsd deauth.

🌸 property

list

The pcs property list command has been deprecated and will be removed 😭. Please use pcs property config instead. Applicable in pcs-0.10.9 and newer.

set

The --node option is no longer supported 💀. Use the pcs node attribute command to set node attributes.

show

The --node option is no longer supported 💀. Use the pcs node attribute command to view node attributes. The pcs property show command has been deprecated and will be removed 😭. Please use pcs property config instead. Applicable in pcs-0.10.9 and newer.

unset

The --node option is no longer supported 💀. Use the pcs node attribute command to unset node attributes.

🦋 resource

create

The master keyword has been changed to promotable.

failcount reset

The command has been removed as pcs resource cleanup is doing exactly the same job.

master

This command has been replaced with pcs resource promotable.

show

Previously, this command displayed either status or configuration of resources depending on the parameters specified. This was confusing 🙈, therefore the command was replaced by several new commands. To display resources status, run pcs resource or pcs resource status. To display resources configuration, run pcs resource config or pcs resource config <resource name>. To display configured resource groups, run pcs resource group list.

⭐ status

groups

This command has been replaced with pcs resource group list.

💥 stonith

level add | clear | delete | remove

Delimiting stonith devices with a comma is deprecated, use a space instead. Applicable in pcs-0.10.9 and newer.

level clear

Syntax of the command has been fixed so that it is not ambiguous any more. New syntax is pcs stonith level clear [target <target> | stonith <stonith id>...]. Old syntax pcs stonith level clear [<target> | <stonith ids>] is deprecated but still functional in pcs-0.10.x. Applicable in pcs-0.10.9 and newer.

level delete | remove

Syntax of the command has been fixed so that it is not ambiguous any more. New syntax is pcs stonith level delete | remove [target <target>] [stonith <stonith id>].... Old syntax pcs stonith level delete | remove [<target>] [<stonith id>]... is deprecated but still functional in pcs-0.10.x. Applicable in pcs-0.10.9 and newer.

sbd device setup

The --device option has been replaced with the device option.

sbd enable

The --device and --watchdog options have been replaced with device and watchdog options, respectively.

show

Previously, this command displayed either status or configuration of stonith resources depending on the parameters specified. This was confusing 🙈, therefore the command was replaced by several new commands. To display stonith resources status, run pcs stonith or pcs stonith status. To display stonith resources configuration, run pcs stonith config or pcs stonith config <stonith name>.

🎀 tag

list

The pcs tag list command has been deprecated and will be removed 😭. Please use pcs tag config instead. Applicable in pcs-0.10.9 and newer.

🌈 SEE ALSO

http://clusterlabs.org/doc/
pcsd(8), pcs_snmp_agent(8)
corosync_overview(8), votequorum(5), corosync.conf(5), corosync-qdevice(8), corosync-qdevice-tool(8), corosync-qnetd(8), corosync-qnetd-tool(8)
pacemaker-controld(7), pacemaker-fenced(7), pacemaker-schedulerd(7), crm_mon(8), crm_report(8), crm_simulate(8)
boothd(8), sbd(8)

And that's the whole page bestie!! 🥳💖 you literally read all of it, main character energy fr fr ✨

This one's from pcs 0.12.3+0.12.3.1, dated 2026-09-08 — go forth and cluster slay 💅👑🌸

📦 where this page comes from

fedora 43: pcs 0.12.3-1.fc43 · GPL-2.0-only AND MIT
fedora 44: pcs 0.12.3-1.fc44 · GPL-2.0-only AND MIT
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-18: a language model's rewrite of the original, under its terms