This page lists publically-released patches for Veritas Enterprise Products.
For Product GA build, see Veritas Entitlement Management System(VEMS) by clicking the Veritas Support 'Licensing' option.
For information on private patches, contact Veritas Technical Support.
For NetBackup Enterprise Server and NetBackup Server patches, see the NetBackup Downloads.
Patches for your product can have a variety of names. These names are based on product, component, or package names. For more information on patch naming conventions and the relationship between products, components, and packages, see the SORT online help.
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP3P2
Obsolete
The latest patch(es) : sfha-rhel5_x86_64-5.1SP1RP4 
Sign in if you want to rate this patch.

 Basic information
Release type: P-patch
Release date: 2013-01-14
OS update support: None
Technote: None
Documentation: None
Popularity: 1468 viewed    201 downloaded
Download size: 429.55 KB
Checksum: 2886002118

 Applies to one or more of the following products:
VirtualStore 5.1SP1 On RHEL5 x86-64
Cluster Server 5.1SP1 On RHEL5 x86-64
Storage Foundation Cluster File System 5.1SP1 On RHEL5 x86-64
Storage Foundation Cluster File System for Oracle RAC 5.1SP1 On RHEL5 x86-64
Storage Foundation for Oracle RAC 5.1SP1 On RHEL5 x86-64
Storage Foundation HA 5.1SP1 On RHEL5 x86-64

 Obsolete patches, incompatibilities, superseded patches, or other requirements:

This patch is obsolete. It is superseded by: Release date
sfha-rhel5_x86_64-5.1SP1RP4 2013-08-21

This patch supersedes the following patches: Release date
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP3P1 (obsolete) 2012-12-05
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP2P2 (obsolete) 2012-05-21
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP2P1a (obsolete) 2012-04-02
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP1P2 (obsolete) 2011-05-06
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP1P1 (obsolete) 2011-03-18

This patch requires: Release date
sfha-rhel5_x86_64-5.1SP1RP3 (obsolete) 2012-10-02

 Fixes the following incidents:
3009882, 3035026

 Patch ID:
VRTSvxfen-5.1.133.200-SP1RP3P2_RHEL5

 Readme file  [Save As...]
                          * * * 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
   * Veritas Storage Foundation Cluster File System for Oracle RAC 5.1 SP1
   * Symantec VirtualStore 5.1 SP1


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
RHEL5 x86-64
RHEL6 x86-64
SLES10 x86-64
SLES11 x86-64


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

Patch ID: 5.1.133.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 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.
i. For RHEL5:
# rpm -Uvh VRTSvxfen-5.1.133.200-SP1RP3P2_RHEL5.x86_64.rpm
ii. For RHEL6:
# rpm -Uvh VRTSvxfen-5.1.133.200-SP1RP3P2_RHEL6.x86_64.rpm
iii. For SLES10:
# rpm -Uvh VRTSvxfen-5.1.133.200-SP1RP3P2_SLES10.x86_64.rpm
iv. For SLES11:
# rpm -Uvh VRTSvxfen-5.1.133.200-SP1RP3P2_SLES11.x86_64.rpm

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/init.d/vxfen 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 stop

3. Uninstall VRTSvxfen package:
# rpm -ev VRTSvxfen

4. Install previous version of VRTSvxfen package.

5. Start VXFEN:
# /etc/init.d/vxfen start

6. Start VCS:
# hastart


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


OTHERS
------
NONE



Read and accept Terms of Service