SORT

Veritas™ Services and Operations Readiness Tools (SORT)

vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP1P1
Obsolete
Go to Download Center to download.
The latest patch(es) : sfha-rhel5_x86_64-5.1SP1RP4 

 Basic information
Release type: P-patch
Release date: 2011-03-18
OS update support: None
Technote: None
Documentation: None
Popularity: 1266 viewed    downloaded
Download size: 421.78 KB
Checksum: 138651760

 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
vcs-rhel5_x86_64-VRTSvxfen-5.1SP1RP1P2 (obsolete) 2011-05-06

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

 Fixes the following incidents:
2276622

 Patch ID:
VRTSvxfen-5.1.101.100-SP1RP1P1_RHEL5

Readme file
README VERSION		: 1.0
README Creation Date	: 2011.03.18
Patch-ID 		: LINUX 5.1.101.100 
Patch Name		: VRTSvxfen 5.1SP1RP1P1
BASE PACKAGE NAME	: VRTSvxfen 5.1SP1RP1
BASE PACKAGE VERSION	: 5.1SP1RP1
Obsolete Patches	: NONE
Superseded Patches	: NONE
Required Patches	: NONE
Incompatible Patches	: NONE
Supported PADV		: rhel5_x86_64
(P-Platform , A-Architecture , D-Distribution , V-Version)
Patch Category		: OTHER
Reboot Required		: NO

Patch Installation Instructions:
--------------------------------
/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


Patch Uninstallation Instructions:
----------------------------------
/etc/init.d/vcs stop
/etc/init.d/vxfen stop
rpm -ev VRTSvxfen


Special Install Instructions:
-----------------------------
NONE

KNOWN ISSUES : 


FIXED INCIDENTS: 
----------------


 Patch Id::LINUX 5.1.101.100

 Incident no::2276622	 Tracking ID ::2252385

 Symptom::The VxFEN (fencing) component of Veritas Cluster Server (VCS) fails to start
using coordinator disks from certain disk arrays. Even if you configure multiple
coordinator disks, the component displays the following error message: 
"V-11-2-1003 At least three coordinator disks must be defined"

The vxfentsthdw utility does not report any problem with the coordinator disks.
However, if you run the SCSI-extended inquiry command "vxfenadm -i <disk_name>"
on the disks, it reports same serial number for all the coordinator disks. In
contrast, the VxVM component's utilities report different and unique serial
numbers for the same coordinator disks.

 Description:: You may face this problem with some disk arrays that are running more recent
firmware. On such disk arrays, the fencing component does not retrieve the
correct serial number of a disk via SCSI-extended inquiry command. 

The SCSI-extended inquiry from the fencing component is based on an old SPC-3
specification. According to the old specification, vendor-specific information
on page 0x83 of a disk may contain multiple, but globally unique serial numbers
associated with the addressed logical unit.
The fencing component picks one serial number out of all available serial
numbers for a disk.

On disk arrays with new firmware, the SCSI information on page 0x83 of a disk
may contain several serial numbers associated with different entities. These
entities include: 
    o The addressed logical unit
    o The SCSI target device that contains the addressed logical unit
    o The target port that receives the request

The current issue occurs when the fencing component incorrectly picks up the
serial number associated with the target port, which is the same for all the
configured coordinator disks. 

 Resolution::Symantec has updated the fencing library code to pick the serial number
associated with the addressed logical unit, when running an SCSI-extended
inquiry on a disk array. The fencing component now ignores the serial numbers
associated with the other entities in the array.

Incidents from old Patches:
---------------------------
NONE