* * * 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 * OPERATING SYSTEMS SUPPORTED BY THE PATCH * PACKAGES AFFECTED BY THE PATCH * BASE PRODUCT VERSIONS FOR THE PATCH * SUMMARY OF INCIDENTS FIXED BY THE PATCH * DETAILS OF 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 OPERATING SYSTEMS SUPPORTED BY THE PATCH ---------------------------------------- AIX 5.3 ppc AIX 6.1 ppc AIX 7.1 ppc PACKAGES AFFECTED BY THE PATCH ------------------------------ VRTSvxfen BASE PRODUCT VERSIONS FOR THE PATCH ----------------------------------- * Veritas Cluster Server 5.1 SP1 * Veritas Cluster Server 5.1 SP1 PR1 * Veritas Storage Foundation Cluster File System 5.1 SP1 * Veritas Storage Foundation Cluster File System 5.1 SP1 PR1 * Veritas Storage Foundation for Oracle RAC 5.1 SP1 PR1 * Veritas Storage Foundation for Oracle RAC 5.1 SP1 * Veritas Storage Foundation HA 5.1 SP1 PR1 * Veritas Storage Foundation HA 5.1 SP1 SUMMARY OF INCIDENTS FIXED BY THE PATCH --------------------------------------- Patch ID: 5.1.113.200 * 3009882 (3002932) vxfen stop failed when rebooting node with command "shutdown -r now", leading to the keys failed to be removed. * 3035026 (3042545) support protocol 30 in 5.1SP1RP3 for enabling RU from 5.1SP1RP3 to 6.0.1 DETAILS OF INCIDENTS FIXED BY THE PATCH --------------------------------------- This patch fixes the following Symantec incidents: Patch ID: 5.1.113.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.rc stop # /etc/methods/vxfenext -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. # installp -a -d VRTSvxfen.bff VRTSvxfen 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/methods/vxfenext -start # /etc/init.d/vxfen.rc 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.rc stop # /etc/methods/vxfenext -stop 3. Rollback VRTSvxfen Point Patch: # installp -r VRTSvxfen 5.1.113.200 Note: Any patches that are in COMMITTED state cannot be rejected (undone). You must remove each one and then re-install it. 4. Start VXFEN: # /etc/methods/vxfenext -start # /etc/init.d/vxfen.rc start 6. Start VCS: # hastart SPECIAL INSTRUCTIONS -------------------- NONE OTHERS ------ NONE