* * * 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
   * PACKAGES AFFECTED BY THE PATCH
   * BASE PRODUCT VERSIONS FOR THE PATCH
   * OPERATING SYSTEMS SUPPORTED BY THE PATCH
   * 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


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


BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * Veritas Cluster Server 5.1 SP1
   * Veritas Storage Foundation for Oracle RAC 5.1 SP1
   * Veritas Storage Foundation Cluster File System 5.1 SP1
   * Veritas Storage Foundation High Availability 5.1 SP1
   * Symantec VirtualStore 5.1 SP1


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
Solaris 10 SPARC
Solaris 10 X86
Solaris 9 SPARC


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

Patch ID: 149770-01, 149771-01, 149772-01

* 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.
i. For Solaris 9 on Sparc:
# /etc/init.d/vxfen stop
ii. For Solaris 10 on Sparc/Opteron
# svcadm disable vxfen

Unload the VxFEN module (This is an additional step)
# modinfo | grep vxfen
# modunload -i <vxfen_module_id>   

6. Install VXFEN patch in the first subcluster. Please go to the directory where the patch is downloaded and run the following command.
i. For Solaris 9 on Sparc:
# patchadd  149770-01
ii. For Solaris 10 on Sparc
# patchadd  149771-01
iii. For Solaris 10 on Opteron
# patchadd  149772-01

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.
i. For Solaris 9 on Sparc-
# /etc/init.d/vxfen start
ii. For Solaris 10 on Sparc/Opteron-
# svcadm enable vxfen

# 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:
i. For Solaris 9 on Sparc-
# /etc/init.d/vxfen stop
ii. For Solaris 10 on Sparc/Opteron-
# svcadm disable vxfen

Unload the VxFEN module (This is an additional step)
#modinfo | grep vxfen
# modunload -i  <vxfen_module_id>   

3. Remove VRTSvxfen patch:
i. For Solaris 9 on Sparc-
# patchrm 149770-01
ii. For Solaris 10 on sparc- 
# patchrm  149771-01
iii. For Solaris 10 on Opteron-
# patchrm 149772-01

4. Start VXFEN:
i. For Solaris 9 on Sparc-
# /etc/init.d/vxfen start
ii. For Solaris 10 on Sparc/Opteron-
# svcadm enable vxfen

5. Start VCS:
# hastart


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


OTHERS
------
NONE