* * * READ ME * * * * * * Veritas Volume Manager 6.0.1 * * * * * * Public Hot Fix 2 * * * Patch Date: 2012-10-10 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 Volume Manager 6.0.1 Public Hot Fix 2 BASE PRODUCT VERSIONS FOR THE PATCH ----------------------------------- 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: 6.0.100.200 * 2860207 (Tracking ID: 2859470) SYMPTOM: The EMC SRDF-R2 disk may go in error state when you create EFI label on the R1 disk. For example: R1 site # vxdisk -eo alldgs list | grep -i srdf emc0_008c auto:cdsdisk emc0_008c SRDFdg online c1t5006048C5368E580d266 srdf-r1 R2 site # vxdisk -eo alldgs list | grep -i srdf emc1_0072 auto - - error c1t5006048C536979A0d65 srdf-r2 DESCRIPTION: Since R2 disks are in write protected mode, the default open() call (made for read-write mode) fails for the R2 disks, and the disk is marked as invalid. RESOLUTION: As a fix, DMP was changed to be able to read the EFI label even on a write protected SRDF-R2 disk. * 2876865 (Tracking ID: 2510928) SYMPTOM: The extended attributes reported by "vxdisk -e list" for the EMC SRDF luns are reported as "tdev mirror", instead of "tdev srdf-r1". Example, # vxdisk -e list DEVICE TYPE DISK GROUP STATUS OS_NATIVE_NAME ATTR emc0_028b auto:cdsdisk - - online thin c3t5006048AD5F0E40Ed190s2 tdev mirror DESCRIPTION: The extraction of the attributes of EMC SRDF luns was not done properly. Hence, EMC SRDF luns are erroneously reported as "tdev mirror", instead of "tdev srdf- r1". RESOLUTION: Code changes have been made to extract the correct values. * 2892499 (Tracking ID: 2149922) SYMPTOM: Record the diskgroup import and deport events in the /var/log/messages file. Following type of message can be logged in syslog: vxvm: vxconfigd: V-5-1-16254 Disk group import of succeeded. DESCRIPTION: With the diskgroup import or deport, appropriate success message or failure message with the cause for failure should be logged. RESOLUTION: Code changes are made to log diskgroup import and deport events in syslog. * 2892621 (Tracking ID: 1903700) SYMPTOM: vxassist remove mirror does not work if nmirror and alloc is specified, giving an error "Cannot remove enough mirrors" DESCRIPTION: During remove mirror operation, VxVM does not perform correct analysis of plexes. Hence the issue. RESOLUTION: Necessary code changes have been done so that vxassist works properly. * 2892643 (Tracking ID: 2801962) SYMPTOM: Operations that lead to growing of volume, including 'vxresize', 'vxassist growby/growto' take significantly larger time if the volume has version 20 DCO(Data Change Object) attached to it in comparison to volume which doesn't have DCO attached. DESCRIPTION: When a volume with a DCO is grown, it needs to copy the existing map in DCO and update the map to track the grown regions. The algorithm was such that for each region in the map it would search for the page that contains that region so as to update the map. Number of regions and number of pages containing them are proportional to volume size. So, the search complexity is amplified and observed primarily when the volume size is of the order of terabytes. In the reported instance, it took more than 12 minutes to grow a 2.7TB volume by 50G. RESOLUTION: Code has been enhanced to find the regions that are contained within a page and then avoid looking-up the page for all those regions. * 2892650 (Tracking ID: 2826125) SYMPTOM: VxVM script daemons are not up after they are invoked with the vxvm-recover script. DESCRIPTION: When the VxVM script daemon is starting, it will terminate any stale instance if it does exist. When the script daemon is invoking with exactly the same process id of the previous invocation, the daemon itself is abnormally terminated by killing one own self through a false-positive detection. RESOLUTION: Code changes are made to handle the same process id situation correctly. * 2892660 (Tracking ID: 2000585) SYMPTOM: If 'vxrecover -sn' is run and at the same time one volume is removed, vxrecover exits with the error 'Cannot refetch volume', the exit status code is zero but no volumes are started. DESCRIPTION: vxrecover assumes that volume is missing because the diskgroup must have been deported while vxrecover was in progress. Hence, it exits without starting remaining volumes. vxrecover should be able to start other volumes, if the DG is not deported. RESOLUTION: Modified the source to skip missing volume and proceed with remaining volumes. * 2892689 (Tracking ID: 2836798) SYMPTOM: 'vxdisk resize' fails with the following error on the simple format EFI (Extensible Firmware Interface) disk expanded from array side and system may panic/hang after a few minutes. # vxdisk resize disk_10 VxVM vxdisk ERROR V-5-1-8643 Device disk_10: resize failed: Configuration daemon error -1 DESCRIPTION: As VxVM doesn't support Dynamic Lun Expansion on simple/sliced EFI disk, last usable LBA (Logical Block Address) in EFI header is not updated while expanding LUN. Since the header is not updated, the partition end entry was regarded as illegal and cleared as part of partition range check. This inconsistent partition information between the kernel and disk causes system panic/hang. RESOLUTION: Added checks in VxVM code to prevent DLE on simple/sliced EFI disk. * 2892702 (Tracking ID: 2567618) SYMPTOM: VRTSexplorer coredumps in checkhbaapi/print_target_map_entry which looks like: print_target_map_entry() check_hbaapi() main() _start() DESCRIPTION: checkhbaapi utility uses HBA_GetFcpTargetMapping() API which returns the current set of mappings between operating system and fibre channel protocol (FCP) devices for a given HBA port. The maximum limit for mappings was set to 512 and only that much memory was allocated. When the number of mappings returned was greater than 512, the function that prints this information used to try to access the entries beyond that limit, which resulted in core dumps. RESOLUTION: The code has been changed to allocate enough memory for all the mappings returned by HBA_GetFcpTargetMapping(). * 2922798 (Tracking ID: 2878876) SYMPTOM: vxconfigd, VxVM configuration daemon dumps core with the following stack. vol_cbr_dolog () vol_cbr_translog () vold_preprocess_request () request_loop () main () DESCRIPTION: This core is a result of a race between two threads which are processing the requests from the same client. While one thread completed processing a request and is in the phase of releasing the memory used, other thread is processing a request "DISCONNECT" from the same client. Due to the race condition, the second thread attempted to access the memory which is being released and dumped core. RESOLUTION: The issue is resolved by protecting the common data of the client by a mutex. * 2924117 (Tracking ID: 2911040) SYMPTOM: Restore operation from a cascaded snapshot succeeds even when it's one of the source is inaccessible. Subsequently, if the primary volume is made accessible for operation, IO operations may fail on the volume as the source of the volume is inaccessible. Deletion of snapshots would as well fail due to dependency of the primary volume on the snapshots. In such case, following error is thrown when try to remove any snapshot using 'vxedit rm' command: ""VxVM vxedit ERROR V-5-1-XXXX Volume YYYYYY has dependent volumes" DESCRIPTION: When a snapshot is restored from any snapshot, the snapshot becomes the source of data for regions on primary volume that differ between the two volumes. If the snapshot itself depends on some other volume and that volume is not accessible, effectively primary volume becomes inaccessible after restore operation. In such case, the snapshots cannot be deleted as the primary volume depends on it. RESOLUTION: If a snapshot or any later cascaded snapshot is inaccessible, restore from that snapshot is prevented. * 2924188 (Tracking ID: 2858853) SYMPTOM: In CVM(Cluster Volume Manager) environment, after master switch, vxconfigd dumps core on the slave node (old master) when a disk is removed from the disk group. dbf_fmt_tbl() voldbf_fmt_tbl() voldbsup_format_record() voldb_format_record() format_write() ddb_update() dg_set_copy_state() dg_offline_copy() dasup_dg_unjoin() dapriv_apply() auto_apply() da_client_commit() client_apply() commit() dg_trans_commit() slave_trans_commit() slave_response() fillnextreq() vold_getrequest() request_loop() main() DESCRIPTION: During master switch, disk group configuration copy related flags are not cleared on the old master, hence when a disk is removed from a disk group, vxconfigd dumps core. RESOLUTION: Necessary code changes have been made to clear configuration copy related flags during master switch. * 2924207 (Tracking ID: 2886402) SYMPTOM: When re-configuring dmp devices, typically using command 'vxdisk scandisks', vxconfigd hang is observed. Since it is in hang state, no VxVM(Veritas volume manager)commands are able to respond. Following process stack of vxconfigd was observed. dmp_unregister_disk dmp_decode_destroy_dmpnode dmp_decipher_instructions dmp_process_instruction_buffer dmp_reconfigure_db gendmpioctl dmpioctl dmp_ioctl dmp_compat_ioctl compat_blkdev_ioctl compat_sys_ioctl cstar_dispatch DESCRIPTION: When DMP(dynamic multipathing) node is about to be destroyed, a flag is set to hold any IO(read/write) on it. The IOs which may come in between the process of setting flag and actual destruction of DMP node, are placed in dmp queue and are never served. So the hang is observed. RESOLUTION: Appropriate flag is set for node which is to be destroyed so that any IO after marking flag will be rejected so as to avoid hang condition. * 2933468 (Tracking ID: 2916094) SYMPTOM: These are the issues for which enhancements are done: 1. All the DR operation logs are accumulated in one log file 'dmpdr.log', and this file grows very large. 2. If a command takes long time, user may think DR operations have stuck. 3. Devices controlled by TPD are seen in list of luns that can be removed in 'Remove Luns' operation. DESCRIPTION: 1. All the logs of DR operations accumulate and form one big log file which makes it difficult for user to get to the current DR operation logs. 2. If a command takes time, user has no way to know whether the command has stuck. 3. Devices controlled by TPD are visible to user which makes him think that he can remove those devices without removing them from TPD control. RESOLUTION: 1. Now every time user opens DR Tool, a new log file of form dmpdr_yyyymmdd_HHMM.log is generated. 2. A messages is displayed to inform user if a command takes longer time than expected. 3. Changes are made so that devices controlled by TPD are not visible during DR operations. * 2933469 (Tracking ID: 2919627) SYMPTOM: While doing 'Remove Luns' operation of Dynamic Reconfiguration Tool, there is no feasible way to remove large number of LUNs, since the only way to do so is to enter all LUN names separated by comma. DESCRIPTION: When removing luns in bulk during 'Remove Luns' option of Dynamic Reconfiguration Tool, it would not be feasible to enter all the luns separated by comma. RESOLUTION: Code changes are done in Dynamic Reconfiguration scripts to accept file containing luns to be removed as input. * 2934259 (Tracking ID: 2930569) SYMPTOM: The LUNs in 'error' state in output of 'vxdisk list' cannot be removed through DR(Dynamic Reconfiguration) Tool. DESCRIPTION: The LUNs seen in 'error' state in VM(Volume Manager) tree are not listed by DR(Dynamic Reconfiguration) Tool while doing 'Remove LUNs' operation. RESOLUTION: Necessary changes have been made to display LUNs in error state while doing 'Remove LUNs' operation in DR(Dynamic Reconfiguration) Tool. * 2942166 (Tracking ID: 2942609) SYMPTOM: You will see following message as error message when quiting from Dynamic Reconfiguration Tool. "FATAL: Exiting the removal operation." DESCRIPTION: When user quits from an operation, Dynamic Reconfiguration Tool displays it is quiting as error message. RESOLUTION: Made changes to display the message as Info. INSTALLING THE PATCH -------------------- o If Veritas Volume Manager has already been patched, make sure that you have a copy of the VRTSvxvm package which is currently installed. Should it be necessary to remove the patch after its installation, you will need to re-install the current version of Volume Manager to revert your system to its present state. o Prior to beginning the upgrade, perform the steps listed below: (a) Stop applications using any VxVM volumes. (b) Stop I/Os to all the VxVM volumes. (c) Unmount any filesystems with VxVM volumes. Confirm that all filesystems with VxVM volumes are unmounted before continuing to the next step. o Patching may be performed either manually or with the use of the included hotfix installer. Select one of the methods below to continue. Patch using hotfix installer ---------------------------- The hotfix installer can apply this upgrade on some or all nodes within a cluster in a single operation. You can specify the nodes to be patched as arguments on the command line, or in response to an interactive prompt. To apply the patch using the installer, enter the commands below: # cd && \ ./installVM601P2 [ [ ... ]] where ... are the names or IP addresses of the nodes to be patched, separated by white space. Patch manually -------------- To apply the patch manually, select the appropriate RPM for each of your systems, and upgrade to the new patch: Red Hat Enterprise Linux Server 5.*: # rpm -Uhv VRTSvxvm-6.0.100.200-RHEL5.x86_64.rpm Red Hat Enterprise Linux Server 6.*: # rpm -Uhv VRTSvxvm-6.0.100.200-RHEL6.x86_64.rpm SUSE Linux Enterprise Server 10: # rpm -Uhv VRTSvxvm-6.0.100.200-SLES10.x86_64.rpm SUSE Linux Enterprise Server 11: # rpm -Uhv VRTSvxvm-6.0.100.200-SLES11.x86_64.rpm To complete the manual patching task, you must restart all Volume Manager services and their dependents. You can do this directly, or you may opt to reboot nodes once cluster-wide installation of the patch is complete. o Once all Veritas Volume Manager services and dependents are running the upgraded version of VRTSvxvm, you may remount the filesystems which were unmounted in preliminary step (c) above, if necessary. REMOVING THE PATCH ------------------ Since the patch package replaces the extant version of the VRTSvxvm package when installed, after removing the patch it is necessary to re-install the pre-patch version of VRTSvxvm. Your installation media should contain the VRTSvxvm package which you will re-install, or you may have made a copy of the installed package as suggested above. o Prior to beginning the rollback, perform the steps listed below: (a) Stop applications using any VxVM volumes. (b) Stop I/Os to all the VxVM volumes. (c) Umount any filesystems with VxVM volumes. Confirm that all filesystems with VxVM volumes are unmounted before continuing to the next step. o Uninstall the VRTSvxvm 6.0.100.200 package which you installed during patch installation: # rpm -ehv VRTSvxvm-6.0.100.200-..rpm o Reinstall the pre-patch version of VRTSvxvm: # rpm -ihv VRTSvxvm-6.0.100.000--.rpm You will need to reboot your system(s) after completing this operation. SPECIAL INSTRUCTIONS -------------------- NONE