README VERSION : 1.1 README CREATION DATE : 2012-09-20 PATCH-ID : PHKL_43068 PATCH NAME : VRTSvxfen 5.1 SP1RP2 BASE PACKAGE NAME : Veritas I/O Fencing by Symantec BASE PACKAGE VERSION : VRTSvxfen 5.1SP1 SUPERSEDED PATCHES : NONE REQUIRED PATCHES : NONE INCOMPATIBLE PATCHES : NONE SUPPORTED PADV : hpux1131 (P-PLATFORM , A-ARCHITECTURE , D-DISTRIBUTION , V-VERSION) PATCH CATEGORY : OTHER PATCH CRITICALITY : OPTIONAL HAS KERNEL COMPONENT : YES ID : NONE REBOOT REQUIRED : NO PATCH INSTALLATION INSTRUCTIONS: -------------------------------- Please refer the release notes for installation instructions PATCH UNINSTALLATION INSTRUCTIONS: ---------------------------------- Please refer the release notes for un-installation instructions. SPECIAL INSTRUCTIONS: --------------------- NONE SUMMARY OF FIXED ISSUES: ----------------------------------------- 2708626 (2710892) Node is unable to join the fencing cluster after reboot, due to a snapshot mismatch. 2814826 (2812400) If the agile disk naming scheme is used, vxfen fails to start. 2815240 (2531558) graceful shutdown of node should not trigger race condition on peer 2855757 (2855755) VxFEN might fail to start or online coordination point replacement (OCPR) might fail if a CP server used as a coordination point for the first time and not reachable that time. SUMMARY OF KNOWN ISSUES: ----------------------------------------- KNOWN ISSUES : -------------- FIXED INCIDENTS: ---------------- PATCH ID:PHKL_43068 * INCIDENT NO:2708626 TRACKING ID:2710892 SYMPTOM: One or more nodes may not be able to join an already running fencing cluster. DESCRIPTION: One or more nodes may not be able to join an already running fencing cluster. This is because, at startup, fencing verifies whether the node that is joining sees exactly the same coordination points and in the same sequence as the nodes already in the cluster. If the locale of the node that is joining is different from the locale of nodes already in the cluster, then the sequence of coordination points in the coordination point snapshot can differ, which leads to a snapshot mismatch error and fencing does not start. RESOLUTION: In order to make sure that any node can join an already running cluster irrespective of its locale, Symantec has added checks which ensure that the sequence of coordination points in the snapshot does not change across locales. * INCIDENT NO:2814826 TRACKING ID:2812400 SYMPTOM: vxfen fails to start if the agile disk naming scheme is used. DESCRIPTION: vxfen fails to start if the agile disk naming scheme is used in HP- UX. This is because the disk access name displayed in the first column of the 'vxdisk list' command output was used to find the name of coordinator disk. The disk access name in this output was prepended with the vxdmp device path ('/dev/vx/rdmp') and was used as the coordinator disk. This disk access name differs from the actual name of the disk in the '/dev/vx/rdmp/' location and so the SCSI ioctl system call fails. RESOLUTION: This issue is fixed and now the 'devicetag' field of the disk from the 'vxdisk list ' command output is used. This is the name of the device without any slice information and it is also the same name that is present in the 'dev/vx/rdmp' location. * INCIDENT NO:2815240 TRACKING ID:2531558 SYMPTOM: Graceful shutdown of a node no longer triggers I/O fencing race condition on peer nodes DESCRIPTION: In the earlier releases, a gracefully leaving node clears its I/O fencing keys from coordination points. But the remaining sub-cluster races against the gracefully leaving node to remove its registrations from the data disks. During this operation, if the sub-cluster loses access to the coordination points, the entire cluster may panic if the racer loses the race for coordination points. RESOLUTION: In this release, this behavior has changed. When a node leaves gracefully, the CVM or other clients on that node are stopped before the VxFEN module is unconfigured. Hence, data disks are already clear of its keys. The remaining sub-cluster tries to clear the gracefully leaving node's keys from the coordination points but does not panic if it is not able to clear the keys. * INCIDENT NO:2855757 TRACKING ID:2855755 SYMPTOM: vxfen might fail to start or online coordination point migration might fail if CP server is used as a coordination point for the first time for a node. DESCRIPTION: The UID database file used to cache the CP server information locally in a node of a cluster. If the UID database file is absent in the system some operation on that file fails. This is true when for the first time the file is created in the node. RESOLUTION: In this release, this behavior has changed. We now handle the absence of the file by creating the file before accessing it for the first time. INCIDENTS FROM OLD PATCHES: --------------------------- Patch Id::PHKL_42252 * Incident no::2400485 Tracking ID ::2400473 Symptom::When the Veritas fencing module (VxFEN) starts, it may encounter issues in reading coordination point information. VxFEN may display an error such as: V-11-2-1036 Unable to configure VxFEN since daemon failed to talk to the driver. The user mode process that processes coordination point information may abort. If you then try to configure the driver in another fencing mode, VxFEN displays the following error: V-11-2-1050 Mismatched modes on local node and running cluster. Unable to configure vxfen Description::The problem occurs because the variable that tracks the fencing mode is incorrectly passed from the user land configuration files to the VxFEN kernel driver. Resolution::Symantec has modified the VxFEN kernel driver to properly reset the fencing mode variables when it receives an error from the user land. * Incident no::2426663 Tracking ID ::2426659 Symptom::If you run the 'vxfenswap' command to change the fencing mode from 'customized' to 'scsi3', the vxfend process continues to run. Description::The kernel driver of the Veritas fencing module (VxFEN) starts the vxfend process only when VxFEN is configured in a customized mode. However, when you change the fencing mode to 'scsi3', the VxFEN kernel driver fails to terminate the vxfend process. Resolution::Symantec has modified the VxFEN kernel driver to appropriately terminate the vxfend process.