Moving a Pacemaker resource is a controlled way to shift an application, IP, or service off a node during maintenance or troubleshooting while keeping the cluster scheduler responsible for the final placement decision.
The pcs move operation influences scheduling by applying a location constraint to the selected resource, typically forcing it away from its current node or preferring a specific destination node. The scheduler then stops and starts the resource as needed to satisfy the updated placement rules and the resource’s own constraints.
Move constraints can persist if relocation cannot be verified or when older behavior is in use, which can prevent normal failover until cleared. Clearing a move constraint can also allow immediate re-placement if existing constraints or resource-stickiness make another node preferable.
Steps to move a Pacemaker resource:
- Check the current state and location of the resource.
$ sudo pcs resource status web-service web-service (systemd:nginx): Started node-01
- Move the resource to the destination node.
$ sudo pcs resource move web-service node-02 --wait=120 Location constraint to move resource 'web-service' has been created Waiting for the cluster to apply configuration changes (timeout: 120 seconds)... Location constraint created to move resource 'web-service' has been removed Waiting for the cluster to apply configuration changes (timeout: 120 seconds)... resource 'web-service' is running on node 'node-02'
pcs may remove the temporary move constraint automatically after the resource is running on the new node, depending on version and policy.
- Verify the resource is started on the destination node.
$ sudo pcs resource status web-service web-service (systemd:nginx): Started node-02
- Clear any remaining move constraint for the resource.
$ sudo pcs resource clear web-service --wait=120 Waiting for the cluster to apply configuration changes (timeout: 120 seconds)... resource 'web-service' is running on node 'node-02'
Clearing constraints can allow immediate relocation if the scheduler prefers a different node based on existing constraints and scoring.
- Confirm the resource is in the expected state after clearing constraints.
$ sudo pcs resource status web-service web-service (systemd:nginx): Started node-02
If the resource moves after clearing, placement control has returned to the scheduler and the new location reflects current cluster rules.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
