* * * READ ME * * *
             * * * Veritas Cluster Server 5.1 SP1 RP3 * * *
                         * * * P-patch 2 * * *
                         Patch Date: 2013-01-22


This document provides the following information:

   * PATCH NAME
   * OPERATING SYSTEMS SUPPORTED BY THE PATCH
   * PACKAGES AFFECTED BY THE PATCH
   * BASE PRODUCT VERSIONS FOR THE PATCH
   * SUMMARY OF INCIDENTS FIXED BY THE PATCH
   * DETAILS OF INCIDENTS FIXED BY THE PATCH
   * INSTALLATION PRE-REQUISITES
   * INSTALLING THE PATCH
   * REMOVING THE PATCH


PATCH NAME
----------
Veritas Cluster Server 5.1 SP1 RP3 P-patch 2


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
AIX 5.3 ppc
AIX 6.1 ppc
AIX 7.1 ppc


PACKAGES AFFECTED BY THE PATCH
------------------------------
VRTSvxfen


BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * Veritas Cluster Server 5.1 SP1
   * Veritas Cluster Server 5.1 SP1 PR1
   * Veritas Storage Foundation Cluster File System 5.1 SP1
   * Veritas Storage Foundation Cluster File System 5.1 SP1 PR1
   * Veritas Storage Foundation for Oracle RAC 5.1 SP1 PR1
   * Veritas Storage Foundation for Oracle RAC 5.1 SP1
   * Veritas Storage Foundation HA 5.1 SP1 PR1
   * Veritas Storage Foundation HA 5.1 SP1


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: 5.1.113.200
* 3009882 (3002932) vxfen stop failed when rebooting node with command "shutdown -r now", leading to the keys failed to be removed.
* 3035026 (3042545) support protocol 30 in 5.1SP1RP3 for enabling RU from 5.1SP1RP3 to 6.0.1


DETAILS OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
This patch fixes the following Symantec incidents:

Patch ID: 5.1.113.200

* 3009882 (Tracking ID: 3002932)

SYMPTOM:
vxfen module fails to stop when you manually restart a node by issuing 
the shutdown -r now command

DESCRIPTION:
You cannot stop the vxfen module by restarting the node if any of 
its client processes, such as Veritas Cluster Server and so on, are running. 
Typically, a node reboot stops all the client processes of vxfen and 
subsequently stops the vxfen module. For some reason if the node restart does 
not stop the client processes, then the attempt to stop vxfen module also fails 
because client processes are still running.

RESOLUTION:
Symantec has implemented a retry logic such that after a node 
restart happens the vxfen module periodically tries to   stop itself for a 
specific number of times. The retry  logic gives client processes enough time 
to stop.

* 3035026 (Tracking ID: 3042545)

SYMPTOM:
Rolling upgrade of Veritas Cluster Server (VCS) from release 5.1SP1RP3
to 6.0 or 6.0.1 might result in a failure.

DESCRIPTION:
The fencing module (VRTSvxfen) from release 5.1SP1RP3 functions on
protocol version 23. However, in releases 6.0 or 6.0.1, the fencing module can
only run on protocol version 10, 20, or 30 and not on protocol version 23. So,
after you upgrade VCS from release 5.1SP1RP3 to 6.0 or 6.0.1, the fencing module
does not start.

RESOLUTION:
Symantec has added a patch that supports the fencing module to be
run on protocol version 30 in release 5.1SP1RP3. Installation of the patch makes
the fencing module in the cluster to operate on protocol version 30.  The patch
ensures that the rolling upgrade from release 5.1SP1RP3 to 6.0 or 6.0.1 is
successful.



INSTALLING THE PATCH
--------------------
1. Review the cluster's system list. Divide the cluster in two sub-clusters in such a way that each service group has at least one system belonging to each subcluster.

2. On the subcluster that you plan to upgrade first, stop all the applications and resources that are not under VCS control but still use the CVM and CFS stack.

3. Switch the failover service groups to the subcluster that you plan to upgrade later. For each failover service group that is online on the first subcluster, switch the group to a system in the second subcluster Downtime exists for each failover service group at this stage as part of the switch.

# hagrp -switch service_group -to target_system_name

4. Stop HAD on the subcluster that you plan to upgrade first, and switch any remaining failover service groups on this subcluster.
# hastop -local -evacuate

Review the following information about the hastop -local -evacuate
command:
o Performing this step ensures that if one of the nodes in the remaining subclusters goes down at this stage, the service groups that have already been moved do not attempt to switch back to any of the nodes on the subcluster that you are upgrading. Any pending switches can also occur
in this step.
o Bring down the parallel service groups on the nodes of the subcluster that
you are upgrading. They continue to be available on the remaining
subcluster.
o VCS stops CVM and CFS on the nodes of the subcluster that you are
upgrading. They continue to be available on the remaining subcluster.

5. Stop VXFEN.
# /etc/init.d/vxfen.rc stop
# /etc/methods/vxfenext -stop
   
6. Simultaneously install VXFEN patch in the first subcluster. Please go to the directory where the patch is downloaded and run the following command.
# installp -a -d VRTSvxfen.bff VRTSvxfen

7. Manually update the /etc/vxfenmode. Append "vxfen_protocol_version=23" to /etc/vxfenmode file

8. After installing the patch successfully, start VXFEN and HAD.
# /etc/methods/vxfenext -start
# /etc/init.d/vxfen.rc start
# hastart

9. Switch back the failover service groups from the remaining subcluster to
the upgraded subcluster. Downtime exists for failover service groups
during the switch.
# hagrp -switch service_group -to target_system_name

10. Follow steps 4 to 8 to upgrade the second subcluster.

11. Run vxfenconfig -R on the node with lowest node ID in the cluster that you are upgrading. Wait until the command executes successfully.

12. Remove "vxfen_protocol_version=23" from /etc/vxfenmode" file on all the nodes.


REMOVING THE PATCH
------------------
Perform the following steps on all the nodes together. In other words, all the steps should be performed on all the nodes before going to next step:

1. Stop VCS:
# hastop -all

2. Stop VXFEN:
# /etc/init.d/vxfen.rc stop
# /etc/methods/vxfenext -stop

3. Rollback VRTSvxfen Point Patch:
# installp -r VRTSvxfen 5.1.113.200

   Note: Any patches that are in COMMITTED state cannot be rejected (undone).
   You must remove each one and then re-install it.

4. Start VXFEN:
# /etc/methods/vxfenext -start
# /etc/init.d/vxfen.rc start

6. Start VCS:
# hastart


SPECIAL INSTRUCTIONS
--------------------
NONE


OTHERS
------
NONE