vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP1P2
Obsolete
The latest patch(es) : sfha-rhel5_x86_64-5.1SP1RP4 

 Basic information
Release type: P-patch
Release date: 2011-05-06
OS update support: None
Technote: None
Documentation: None
Popularity: 1115 viewed    downloaded
Download size: 421.66 KB
Checksum: 1254321547

 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
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP3P2 (obsolete) 2013-01-14
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP3P1 (obsolete) 2012-12-05
sfha-rhel5_x86_64-5.1SP1RP3 (obsolete) 2012-10-02
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP2P2 (obsolete) 2012-05-21
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP2P1a (obsolete) 2012-04-02
sfha-rhel5_x86_64-5.1SP1RP2 (obsolete) 2011-09-28

This patch supersedes the following patches: Release date
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP1P1 (obsolete) 2011-03-18

This patch requires: Release date
sfha-rhel5_x86_64-5.1SP1RP1 (obsolete) 2011-02-11

 Fixes the following incidents:
2365402

 Patch ID:
VRTSvxfen-5.1.101.200-SP1RP1P2_RHEL5

Readme file
                          * * * READ ME * * *
             * * * Veritas Cluster Server 5.1 SP1 RP1 * * *
                         * * * P-patch 2 * * *
                         Patch Date: 2011.05.06


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 RP1 P-patch 2


PACKAGES AFFECTED BY THE PATCH
------------------------------
Veritas I/O Fencing


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


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
RHEL5 x86-64


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

Patch ID: 5.1.101.200

* 2365402 (Tracking ID: 2365394)

SYMPTOM:
When a VCS node starts up, if even one of the coordination points for the 
Veritas fencing module (VxFEN) is inaccessible to the node, then VxFEN fails to 
start on that node. 

It is desirable that VxFEN must be able to start on the node as long as a 
majority of the coordination points are accessible to the node when the node 
starts up.

DESCRIPTION:
When a node starts up, the following conditions must occur before VxFEN starts 
on that node:
aC/	VxFEN must be able to get the Universal Unique Identifier (UUID) or 
serial number of each coordination point specified in the /etc/vxfenmode file.  
aC/	VxFEN must be able to register the node with a majority of CPs 
specified in the /etc/vxfenmode file.  
However, due to accessibility issues, if VxFEN fails to get the UUID or serial 
number of one of the specified CPs, then VxFEN treats it as a fatal failure. 
The node cannot then join a cluster or start a cluster.  
As a result, every coordination point becomes a potential single point of 
failure, and compromises high availability (HA).

RESOLUTION:
Symantec has modified the fencing module to fix the issue. Each VCS node now 
stores the UUIDs or serial numbers of all the coordination points that the node 
registers with. As a result, if a node is later unable to access a specified 
coordination point, VxFEN can use the stored UUIDs/serial numbers.

By design, the fix works only when a majority of coordination points are 
accessible to the node when the node starts. At the time of a fencing race, the 
racer needs to have its keys registered on a majority of coordination points in 
order to be able to win the race. In order to enable this, fencing is designed 
to not start if a majority of coordination points are not available at the time 
of startup. 

This fix applies only to clusters that use customized fencing.

As part of the fix, Symantec has introduced two optional attributes to 
the /etc/vxfenmode file. 

db_ignore_list :  Specifies the type/s of coordination points for which a node 
must not store the UUID/serial number. To specify multiple values, use a comma-
separated list. VxFEN supports the values "none", "disk", and "server". 
Note: By default, this feature is available only for coordination point 
servers.  To turn it on for disks, you must set the value of the db_ignore_list 
to "none".

db_entries_limit: Specifies the maximum number of UUIDs/serial numbers that a 
node can store. The default value for this attribute is 1000. If the default 
value is used, the node approximately requires 1MB of disk space to store the 
UUIDs/serial numbers.


INSTALLING THE PATCH
--------------------
/etc/init.d/vcs stop
/etc/init.d/vxfen stop
rpm -ev VRTSvxfen
rpm -ivh <full path to new VRTSvxfen RPM> 
/etc/init.d/vxfen start
/etc/init.d/vcs start


REMOVING THE PATCH
------------------
/etc/init.d/vcs stop
/etc/init.d/vxfen stop
rpm -ev VRTSvxfen


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