How to Migrate Existing Resources
to a New Version of the Resource Type

The instructions that follow explain how to use the clresource(1CL) command to perform this task. However, you are not restricted to using the clresource command for this task. Instead of the clresource command, you can use SunPlex Manager or the Resource Group option
of the clsetup(1CL) command to perform this task.

Before You Begin

Consult the instructions for upgrading the resource type to determine
when you can migrate resources to a new version of the resource type.

Any time

Only when the resource is unmonitored

Only when the resource is offline

Only when the resource is disabled

Only when the resource group is unmanaged

The instructions might state that you cannot upgrade your existing version
of the resource. If you cannot migrate the resource, consider the following
alternatives:

Deleting the resource and replacing it with a new resource
of the upgraded version

Leaving the resource at the old version of the resource type

On a cluster member, become superuser or assume a role
that provides solaris.cluster.modify RBAC authorization.

For each resource of the resource
type that is to be migrated, change the state of the resource or its resource
group to the appropriate state.

If you can migrate the resource at any time, no action is required.

If you can migrate the resource only when the resource is unmonitored,
type the following command:

# clresource unmonitor resource

If you can migrate the resource only when the resource is offline,
type the following command:

# clresource disable resource

Note –

If other resources depend on the resource that you are migrating,
this step fails. In this situation, consult the error message that is printed
to determine the names of the dependent resources. Then repeat this step,
specifying a comma-separated list that contains the resource that you are
migrating and any dependent resources.

If you can migrate the resource only when the resource is disabled,
type the following command:

# clresource disable resource

Note –

If other resources depend on the resource that you are migrating,
this step fails. In this situation, consult the error message that is printed
to determine the names of the dependent resources. Then repeat this step,
specifying a comma-separated list that contains the resource that you are
migrating and any dependent resources.

If you can migrate the resource only when the resource group is
unmanaged, type the following commands:

If the existing version of the resource type does not support
upgrades to the new version, this step fails.

Restore the previous state
of the resource or resource group by reversing the command that you typed
in Step 2.

If you can migrate the resource at any time, no action is required.

Note –

After migrating a resource that can be migrated at any time, the
resource probe might not display the correct resource type version. In this
situation, disable and re-enable the resource's fault monitor to ensure that
the resource probe displays the correct resource type version.

If you can migrate the resource only when the resource is unmonitored,
type the following command:

# clresource monitor resource

If you can migrate the resource only when the resource is offline,
type the following command:

# clresource enable resource

Note –

If you disabled in Step 2 other resources that depend on the resource that you are
migrating, enable the dependent resources also.

If you can migrate the resource only when the resource is disabled,
type the following command:

# clresource enable resource

Note –

If you disabled in Step 2 other resources that depend on the resource that you are
migrating, enable the dependent resources also.

If you can migrate the resource only when the resource group is
unmanaged, type the following commands:

Example 2–2 Migrating a Resource That Can Be Migrated Only When Offline

This example shows the migration of a resource that can be migrated
only when the resource is offline. The new resource type package contains
methods that are located in new paths. Because the methods are not overwritten
during the installation, the resource does not need to be disabled until after
the upgraded resource type is installed.

The characteristics of the resource in this example are as follows:

The new resource type version is 2.0.

The resource name is myresource.

The resource type name is myrt.

The new RTR file is in /opt/XYZmyrt/etc/XYZ.myrt.

No dependencies on the resource that is to be migrated exist.

The resource that is to be migrated can be taken offline while
leaving the containing resource group online.

This example assumes that the upgrade package is already installed on
all cluster nodes according to the supplier's directions.

Example 2–3 Migrating a Resource That Can Be Migrated Only When Unmonitored

This example shows the migration of a resource that can be migrated
only when the resource is unmonitored. The new resource type package contains
only the monitor and RTR file. Because the monitor is overwritten during installation,
monitoring of the resource must be disabled before the upgrade package is
installed.

The characteristics of the resource in this example are as follows:

The new resource type version is 2.0.

The resource name is myresource.

The resource type name is myrt.

The new RTR file is in /opt/XYZmyrt/etc/XYZ.myrt.

The following operations are performed in this example.

Before the upgrade package is installed, the following command
is run to disable monitoring of the resource:

# clresource unmonitor myresource

The upgrade package is installed on all cluster nodes according
to the supplier's directions.

To register the new version of the resource type, the following
command is run:

# clresourcetype register -f /opt/XYZmyrt/etc/XYZ.myrt myrt

To change the Type_version property to
the new version, the following command is run:

# clresource set -p Type_version=2.0 myresource

To enable monitoring of the resource after its migration,
the following command is run: