This procedure can also be performed using the Resource Group option of scsetup. For information on scsetup, see the scsetup(1M) man page.
The existing resource type version and the changes in the new version determine how to migrate to the new version type. The resource type upgrade documentation will tell you whether the migration can occur. If a migration is not supported, consider deleting the resource and replacing it with a new resource of the upgraded version or leaving the resource at the old version of the resource type.
When you migrate the existing resource, the following values may change.
If an upgraded version of the resource type declares a new default value for a defaulted property, the new default value will be inherited by existing resources.
The new resource type version's VALIDATE method checks to make sure that existing property settings are appropriate. If the settings are not appropriate, edit the properties of the existing resource to appropriate values. To edit the properties, see Step 3 .
The RTR file contains the following properties that are used to form the fully qualified name of the resource type.
Vendor_id
Resource_type
RT_Version
When you register the upgraded version of the resource type, its name will be stored as vendor_id.rtname:version. A resource that has been migrated to a new version will have a new Type property, composed of the properties listed above.
The standard resource property Type_version stores the RT_Version property of a resource's type. The Type_Version property does not appear in the RTR file. Edit the Type_Version property using the following command.
scrgadm -c -j resource -y Type_version=new_version |
Before migrating an existing resource to a new version of the resource type, read the upgrade documentation accompanying the new resource type to determine whether the migration can take place.
The documentation will specify when the migration must take place.
Any time
When the resource is unmonitored
When the resource is offline
When the resource is disabled
When the resource group is unmanaged
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 the migration is not supported, you must delete the resource and replace it with a new resource of the upgraded version, or leave the resource at the old version of the resource type.
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 as dictated by the upgrade documentation.
For example, if the resource needs to be unmonitored
scswitch -M -n -j resource |
If the resource needs to be offline
scswitch -n -j resource |
If the resource needs to be disabled
scswitch -n -j resource |
If the resource group needs to be unmanaged
scsswitch -n -j resource-group scswitch -F -g resource_group scswitch -u -g resource_group |
For each resource of the resource type that is to be migrated, edit the resource, changing its Type_version property to the new version.
scrgadm -c -j resource -y Type_version=new_version \ -x extension_property=new_value -y extension_property=new_value |
If necessary, edit other properties of the same resource to appropriate values in the same command by adding additional -x or -y options on the command line.
Restore the previous state of the resource or resource group by reversing the command typed in Step 2.
For example, to make the resource monitored again
scswitch -M -e -j resource |
To re-enable the resource
scswitch -e -j resource |
To make the resource group managed and online
scswitch -o -g resource_group scswitch -Z -g resource_group |
This example shows the migration of an existing resource to a new resource type version. Note that the new resource type package contains methods located in new paths. Because the methods will not be overwritten during the installation, the resource does not need to be disabled until after the upgraded resource type is installed.
This examples assumes the following.
New resource type version is 2.0
Tunability from previous version is “when_offline”
Resource name is “myresource”
Resource type name is “myrt”
New RTR file is in /opt/XYZmyrt/etc/XYZ.myrt
There are no dependencies on the resource to be migrated
The resource to be migrated can be taken offline while leaving the containing resource group online
(Install the new package on all nodes according to vendor's directions.) # scrgadm -a -t myrt -f /opt/XYZmyrt/etc/XYZ.myrt # scswitch -n -j myresource # scrgadm -c -j myresource -y Type_version=2.0 # scswitch -e -j myresource |
This example shows the migration of an existing resource to a new resource type version. Note that the new resource type package contains only the monitor and RTR file. Because the monitor will be overwritten during installation, the resource must be disabled before the upgraded resource type is installed.
This example assumes the following.
New resource type version is 2.0
Tunability from previous version is “when_unmonitored”
Resource name is “myresource”
Resource type name is “myrt”
New RTR file is in /opt/XYZmyrt/etc/XYZ.myrt
# scswitch -M -n -j myresource (Install the new package according to vendor's directions.) # scrgadm -a -t myrt -f /opt/XYZmyrt/etc/XYZ.myrt # scrgadm -c -j myresource -y Type_version=2.0 # scswitch -M -e -j myresourcee |