|Index|Manually Moving High Availability Cluster Resources
SUSE Linux Enterprise High Availability 16.0

Manually Moving High Availability Cluster Resources

Publication Date: 14 Jul 2026

Although the cluster automatically moves resources when necessary, you might want to move resources manually, either to a specific node or just away from the current node. For example, you might move resources to other nodes to distribute the workload more evenly across the cluster, or to help isolate and troubleshoot a hardware or software issue.

1 What are cluster resources?

 

In a High Availability cluster, the applications and services that need to be highly available are called resources. Cluster resources can include Web sites, e-mail servers, databases, file systems, virtual machines or any other applications or services that need to be available to users at all times. You can start, stop, monitor and move resources as needed. You can also specify whether resources should run together on the same node, or start and stop in sequential order. If a node fails, the resources running on it fail over (move) to another node instead of being lost.

In SUSE Linux Enterprise High Availability, the cluster resource manager (CRM) is Pacemaker, which manages and coordinates all cluster services. Pacemaker uses resource agents (RAs) to start, stop and monitor resources. A resource agent abstracts the resource and presents its status to the cluster. This means that Pacemaker only interacts with the resource agent, not with the actual application or service. SUSE Linux Enterprise High Availability supports many different resource agents that are designed to manage specific types of resources.

1.1 Primitive resources

 

Primitive resources represent the applications or services that need to be highly available. Configuring a primitive specifies the resource agent and any other information required for the cluster to manage a resource. To see the supported resource agent classes, run crm ra classes. To see the resource agents available within a class, run crm ra list CLASS.

Primitive resources can have the following settings:

Properties

Resource properties are the basic details required by the cluster: a unique name for the resource, and the resource agent that manages the application or service.

Parameters

Parameters are specific to each resource agent and determine the details and behavior of an application or service. To show all the parameters available for a resource agent, run crm ra info RESOURCE_AGENT.

Operations

Operations are actions that the cluster can perform on a resource, such as start, stop and monitor. To show the supported operations for a resource agent, run crm ra info RESOURCE_AGENT and scroll to the bottom of the output.

Meta attributes

Meta attributes change how the cluster treats a resource. To show all the meta attributes available for primitives, run crm_resource --list-options primitive.

Utilization attributes

If the cluster nodes have utilization attributes configured, you can add these attributes to cluster resources to help with load balancing. For more information, see https://clusterlabs.org/projects/pacemaker/doc/3.0/Pacemaker_Explained/html/utilization.html.

1.2 Resource groups

 

Cluster resources might depend on other resources, such as a Web server that requires an IP address and a file system. You can combine these resources into a resource group. Groups contain multiple primitives that need to be located together, started sequentially and stopped in the reverse order.

This diagram shows a box representing a node. The box contains four individual resources and a smaller box containing three more resources. The smaller box represents a resource group. A zoomed-in view of the resource group shows that the resources are an IP address, an XFS file system and an Apache Web server. The resources are numbered to show the start order in one direction and the reversed stop order in the other direction.
Figure 1: Resource group
 

Groups have the following properties:

Contents

Groups can only contain primitive resources, not clones or other groups.

Starting and stopping

Resources start in the order they appear and stop in the reverse order.

Location

Resources in the group must all run on the same node.

Dependency

If one of the resources can't run anywhere, then the resources that appear after it in the group can't run anywhere either.

Meta attributes

The meta attributes target-role, priority, maintenance and is-managed can be added directly to the group. All other attributes are inherited from the group's resources.

Resource stickiness

Stickiness in groups is additive. Every active resource in the group contributes its stickiness value to the group's total.

1.3 Resource clones

 

Resource clones can run simultaneously on multiple nodes. This is required for cluster file systems like GFS2, for example. You can clone a primitive or a group if the resource agent supports it. Clones can also have additional clone-specific meta attributes to change their behavior.

Clones can be one of the following types:

Anonymous clones

Anonymous clones are the simplest type. All instances of the clone behave identically. Therefore, only one instance of an anonymous clone can be active on each node.

Globally unique clones

Globally unique clones are distinct entities. An instance of the clone running on one node is not necessarily equivalent to another instance on another node.

Promotable clones

Promotable clones allow the instances to be in one of two operating modes: promoted or unpromoted (also known as primary and secondary, or active and passive). Promotable clones can be either anonymous or globally unique.

To make a clone promotable, the resource agent must support the promote and demote operations. The cluster determines which instance of the clone to promote using one of the following methods (or a combination of both):

  • If a resource agent supports promotable clones, it might automatically set promotion scores based on its own preference for which instance to promote.

  • You can manually set promotion rules or preferences by creating location or colocation constraints.

For more information, see https://clusterlabs.org/projects/pacemaker/doc/3.0/Pacemaker_Explained/html/collective.html#determining-which-instance-is-promoted

1.4 For more information

 

2 What are relocation constraints?

 

Cluster resources automatically fail over (move) to another node during hardware or software failures. However, you can also choose to manually move a resource, either to a specific node or just away from the current node. A relocation constraint is a location constraint used specifically for moving a resource. The cluster creates the relocation constraint automatically when you move a resource with crmsh or Hawk.

The type of relocation constraint depends on where you move the resource:

  • If you move the resource to a specific node, the cluster creates a relocation constraint with an INFINITY score for the destination node.

  • If you move the resource away from the current node, the cluster creates a relocation constraint with a -INFINITY score for the current node.

To allow the resource to move back to the original node, you must remove the relocation constraint. When you remove the constraint, the resource might move back to the original node automatically or it might stay on the destination node, depending on the resource's stickiness.

Note
Note: Moving a resource vs live migration

Usually when the cluster moves a resource, it stops the resource on the current node and starts it on the destination node. This is not the same thing as live migration, where the cluster moves a resource from one node to another without stopping it. Live migration is only supported for certain resources and must be enabled for each individual resource.

3 Adding relocation constraints to resources

 

A relocation constraint is a location constraint used specifically for moving a resource. The cluster creates the relocation constraint automatically when you move a resource with crmsh or Hawk.

Requirements
 

  • The resource doesn't have any other constraints that would prevent it from moving.

  • CRM Shell
  • Hawk

You can perform this procedure on any node in the cluster.

  1. Log in either as the root user or as a user with sudo privileges.

  2. Check which node the resource is currently running on: 

    > sudo crm status

  3. Move the resource to another node: 

    > sudo crm resource move RESOURCE NODE

    Alternatively, you can move the resource away from the current node without specifying a specific node to move to: 

    > sudo crm resource move RESOURCE force

  4. Check the status again to make sure the resource is now running on the other node: 

    > sudo crm status
For more information
 

  • crm resource help move

4 Removing relocation constraints from resources

 

A relocation constraint is a location constraint used specifically for moving a resource. The cluster creates the relocation constraint automatically when you move a resource with crmsh or Hawk. To allow the resource to move back to the previous node, you must remove the relocation constraint. When you remove the constraint, the resource might move back to the original node automatically or it might stay on the current node, depending on the resource's stickiness.

  • CRM Shell
  • Hawk

You can perform this procedure on any node in the cluster.

  1. Log in either as the root user or as a user with sudo privileges.

  2. Show the existing location constraints: 

    > sudo crm configure show type:location

    Relocation constraints are named either cli-prefer-RESOURCE or cli-ban-RESOURCE-on-NODE.

  3. Remove any relocation constraints from a specific resource: 

    > sudo crm resource clear RESOURCE

  4. Check the status to see which node the resource is now running on: 

    > sudo crm status
For more information
 

  • crm resource help clear