Introduction

To convert haresources files to a CIB, please use the haresources2cib.py[1] script. Use it like this:

/usr/lib/heartbeat/haresources2cib.py --stdout -c ha.cf \
  haresources > cib.xml

Run the script with --help to get usage.

Note that if you installed Linux-HA somewhere else, then the pathnames need to change to match your installation.

haresources2cib.py converts heartbeat RAs such as IPaddr or apache to OCF RAs. To disable the conversion, use the --no-ocf option.

haresources2cib.py monitors each resource in the original haresources file. To disable adding any monitoring operations, use the --no-monitor option. To selectively disable certain monitoring, or to change the monitoring interval and timeout values, you have to modify the output file manually.

If you've used the haresources2cib.py command, you're mostly done. However, if you want to understand your configuration better by seeing how to do this by hand, then by all means read on!

General Principles

Entries in haresources[2] files follow this format:

{hostname} {resource_type}::{parameter_value}::{parameter_value}::... \
    {resource_type}::{parameter_value}::{parameter_value}::...        \
    {resource_type}::{parameter_value}::{parameter_value}::...

For each line in haresources[2]:

• Create a <group id="group_N"> block, where N is an unused integer
  (this declares the resource group to the CRM[3])

• Add a <rsc_location> child block to the <group> block:
  (this tells the CRM where the resource group is supposed to run)

  • Add a <rule> child block as to the <resource_location> block.
    (this provides a place to hold the expressions that make up this location rule)

    • Add an <expression/> tag as a child to the <rule> block.
      (this tells the CRM[3] exactly where you want the resource group to run)

• For each resource:

  • Add a <resource> child block to the <group> block:
    (this tells the CRM[3] that this <resource> is part of this <group>)

  • Add a child <attributes> tag to the <resource> block.

    • (this provides a place to hold all the parameters to the resource group)

    • For each parameter you want to pass to this particular resource agent:

      • Add an <nvpair/> child tag to the <attributes> block.
        (this tells what parameter you want to pass to the resource agent)

<rsc_location> XML blocks looks like this:

<rsc_location id="loc_group_N" rsc="group_N">
  <rule id="pref_loc_group_N" score="100">
    <--! Change __hostname__ to the host you want this resource on -->
    <expression id="pref_loc_group_N_expr" attribute="#uname" operation="eq" value="__hostname__"/>
  </rule>
</rsc_location>

<rule> XML blocks look like this:

<rule id="pref_run_ip_resource" score="100">
  <!-- expression tags go here --> 
</rule>

<expression> XML tags look like this:

     <!-- Replace __hostname__ with the hostname you want this group to run on -->
      <expression id="pref_loc_group_N_expr" attribute="#uname" operation="eq" value="__hostname__"/>

<resource> XML blocks look like this.

<--! Change __resource_type__ to the heartbeat resource script name -->
<primitive id="group_N_rsc_M" class="heartbeat" type="__resource_type__">
  <instance_attributes>
    <attributes>
    </attributes>
  </instance_attributes>
</primitive>

<nvpair/> tags look like this:

<!-- "N" values are consecutive integers starting from 1 -->
<!-- __parameter_value__ is the value you want argument "N" to have -->
<nvpair name="N" value="__parameter_value__"/>

The net effect is like this:

<cib>
  <configuration>
    <resources>
      <group id="group_N">
         <!-- Change __resource_type__ to the heartbeat resource script name
                 for this particular /etc/ha.d/resource.d resource
          -->
        <primitive id="group_N_rsc_M" class="heartbeat" type="__resource_type__">
          <instance_attributes>
            <attributes>
             <!-- "N" values count up consecutively starting from 1.
               __parameter_value__ is the value you want argument "N" to
               resource agent "__resource_type" to have.
               Leave the <nvpair>s out if there are no parameters.
               OCF resource agents are similar.
              -->
              <nvpair name="N" value="__parameter_value__"/>
            </attributes>
          </instance_attributes>
        </primitive>
      </group>
    </resources>
    <constraints>
      <rsc_location id="run_group_N" rsc="group_N">
        <rule id="pref_run_group_N" score="100">
          <!-- Change __hostname__ to the host you want this resource on -->
          <expression attribute="#uname" operation="eq" value="__hostname__"/>
        </rule>
      </rsc_location>
    <constraints>
  </configuration>
</cib>

Extra features

Groups may be named by appending #groupname to the end of the haresources line:

{node} {resource_1} {resource_2} ... #{groupname}

Individual resources still get autogenerated names.

Basic clones configuration:

anywhere {resource_1} {resource_2} ... #clone:{clonename}

Stonith clones are generated from the ha.cf[4] stonith_host lines.

In addition to the autogenerated constraints, it is possible to create additional constraints:

#rsc_order {resource_from} {action} {before|after} {resource_to}
#rsc_colocation {resource_1} {resource_2} {score}

Generated order constraints are symmetrical.

Conversion Examples

• Basic Configurations

  • Basic Active/Passive One IP address configuration[5]

  • Active/Active Two IP address configuration[6]

  • A single Active/Passive Apache Server configuration[7]

  • Active/Active Two Apache Configuration[8]

---

This information provided courtesy of the Linux-HA project at http://linux-ha.org/