* * * READ ME * * * * * * Veritas Volume Manager 5.1 SP1 RP3 * * * * * * P-patch 9 * * * Patch Date: 2018-09-20 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 Volume Manager 5.1 SP1 RP3 P-patch 9 OPERATING SYSTEMS SUPPORTED BY THE PATCH ---------------------------------------- HP-UX 11i v3 (11.31) PACKAGES AFFECTED BY THE PATCH ------------------------------ VRTSvxvm BASE PRODUCT VERSIONS FOR THE PATCH ----------------------------------- * Veritas Dynamic Multi-Pathing 5.1 SP1 * Veritas Storage Foundation 5.1 SP1 * Veritas Storage Foundation Cluster File System 5.1 SP1 * Veritas Storage Foundation for Oracle RAC 5.1 SP1 * Veritas Storage Foundation HA 5.1 SP1 SUMMARY OF INCIDENTS FIXED BY THE PATCH --------------------------------------- Patch ID: PHCO_44714 * 3680388 (3680386) 'vxconfigd' process is stopped after upgrading the command only patch from 'VxVM 5.1SP1RP3P8' to 'VxVM 5.1SP1RP3P9'. * 3932586 (3934324) Optimize the VxVM device discovery time by reducing few un-necessary io_search API calls. * 3938065 (3903441) When using ignite/UX to restore an image of a system using an ignite archive, enabled with HP native multipathing (NMP) mode, the recovered system hangs while booting. * 3945014 (3945375) "vxassist" command with "remove mirror" option can fail on site configured cluster. * 3946329 (3946328) HPUX installer may select a VxVM versions that may lead to unsupported configuration. * 3952857 (3926067) vxassist relayout /vxassist commands may fail in Campus Cluster environment. Patch ID: PHCO_44660 * 3913086 (3898090) VxVM vxvmconvert utility may corrupt HP-UX LVM logical volume due to incorrect subdisk length during conversion. * 3922019 (3922018) Shared DG(Diskgroup) import fails when minor number of shared DG conflicts with minor number of private DG on slave. * 3922021 (3922020) After performing 'vxdisk resize', size of disk is not updated on slave nodes. Patch ID: PHCO_44586 * 3902801 (3902793) The VxVM diagnostic utility vxdmpdbprint may fail with error 71. Patch ID: PHCO_44553 * 3895494 (3895493) More history of DDL reconfiguration is desired to help isolate problems concerning dynamic reconfiguration. * 3895678 (3892775) When installing patches from QPK [Quality patch bundle] on a system with a VxVM version before VxVM51SP1, the installation fails with an error message. * 3895777 (2165920) The vxrelocd(1M) daemon creates a defunct (zombie) process. * 3897044 (3880212) The vxreattach(1M) command always performs full resync operation despite FastResync license. * 3898670 (3898171) System hangs in booting process while restoring the system with the help of an ignite archive, which is created with HP's native multipathing (nMP) mode enabled. Patch ID: PHCO_44243 * 3273164 (3281160) While importing a disk group that has a base-minor number same as that of an existing imported disk group and when auto-reminor setting is turned off, no warning message is issued. * 3694561 (2990967) Minor numbers are incorrectly assigned after the volumes are created. * 3699305 (3317125) A disk group may get imported as shared disk group on a CVM(Clustered Volume Manager) slave node, such that its 'base_minor' number is similar to an existing private disk group on that slave node. * 3699311 (3139180) The node join operation fails, if the device-minor numbers of the node-join operation are similar to the device-minor numbers of the currently imported disk groups in the cluster. * 3699313 (3028704) When a disk group that has cloned disks is imported, warning messages related to minor number conflicts are displayed. * 3741460 (2721644) The vxconfigd(1M) daemon dumps core. * 3741485 (3162418) The vxconfigd(1M) command dumps core when VxVM tries to find certain devices by their device numbers. * 3741725 (3247040) The vxdisk(1M) scandisks inadvertently re-enables PowerPath (PP) enclosures disabled earlier. * 3741882 (3134118) The vxdmpadm -q iostat show interval = command reports incorrect QUEUED I/Os and PENDING I/Os after the first interval. * 3742610 (3134882) Disk re-online operation is not performed on slave node for auto-imported disk groups containing clone disks. * 3756607 (3090097) While the disk group is imported in the shared mode, if its base_minor number conflicts with base_minor number of an existing private disk group on slave node, then the minor numbers for the disk group may get allocated from a private pool. * 3762780 (3605612) When auto-reminor setting is turned on, a disk group may get imported with the same base-minor number as that of an existing imported disk group. * 3814123 (3045033) The "vxdg init" command should not create a disk group on the clone disks. * 3814134 (3734606) As per the current design, all disks are re-onlined for every clone or tagged disk group to be imported. As a result, the node join operation takes time. * 3851289 (3851287) While installing patches from QPK [Quality patch bundle], installation may get aborted if the VxVM command patch is part of QPK, but base VxVM package is not installed. * 3851574 (1726349) In the Cluster Volume Manager (CVM) environment, the shared disk group creation may fail if a private disk group was previously created on the same disks. Patch ID: PHCO_44219 * 3597496 (2965910) Volume creation with the vxassist(1M) command dumps core when the non-disk parameters are specified along with '-o ordered' option. * 3674615 (3674614) Restarting the vxconfigd(1M) daemon on the slave (joiner) node, when the node- join operation is in progress, may cause the vxconfigd(1M) daemon to hang on the master and the joiner node. Patch ID: PHCO_44194 * 3519134 (3518470) The 'vxdg adddisk' command fails with the following message: " previous removed using -k option" Even though the disk was not removed using the -k option. * 3612710 (2190632) High memory consumption is observed with the vxconfigd(1M) daemon when large number of events are generated. Patch ID: PHCO_44058 * 3249204 (3145359) On the IA architecture systems, the "vxres_lvmroot -v -b " command fails with the following error message: "ERROR V-5-2-4699 Error creating Physical Volume /dev/vx/rdmp/c#t#d#s2" * 3387294 (2152830) A diskgroup (DG) import fails with a non-descriptive error message when multiple copies (clones) of the same device exist and the original devices are either offline or not available. * 3407766 (3263105) The disk evacuation operation (vxevac()) fails for a volume with Data Change Object (DCO). * 3412839 (2515070) When the I/O fencing is enabled, the Cluster Volume Manager (CVM) slave node may fail to join the cluster node. * 3482535 (3482001) The 'vxddladm addforeign' command renders the system unbootable, after the reboot, for a few cases. * 3500353 (3500350) An option is not available to identify if the disk group (DG) is imported using the CLONE flag or not, when the clone flag on the disk is reset using the vxdisk (1M) command. * 3507677 (3293139) The verifydco utility fails with an error. * 3507679 (3455460) The vxfmrshowmap and verify_dco_header utilities fail with an error. * 3524141 (3524139) The checkinstall script for the PHCO_43824 fails, even when the dependencies are in the depot. * 3527676 (3527674) After upgrading to 5.1SP1RP3P1, the configuration daemon (vxconfigd(1M)) dumps core because the unique identifier of the disk (UDID) is not found for EMC LUNs, when the older VRTSaslapm is installed on the system. * 3528614 (3461383) The vxrlink(1M) command fails when the "vxrlink -g -a att " command is executed. * 3596439 (3596425) During patch installation, the checkinstall script fails with error "FC-COMMON.FC-SNIA filesets with revision B.11.31.1311 or Higher is required for VxVM to work correctly.". Patch ID: PHCO_43824 * 2982085 (2976130) Multithreading of the vxconfigd (1M) daemon for HP-UX 11i v3 causes the DMP database to be deleted as part of the device-discovery commands. * 3326516 (2665207) Improve messaging on "vxdisk updateudid" failure on an imported disk group. Patch ID: PHCO_43526 * 2233987 (2233225) Growing a volume to more than a limit, the default being 1G, does not synchronize plexes for the newly allocated regions of the volume. * 2245645 (2255018) The vxplex(1M) command core dumps during the relayout operation from concat to RAID 5. * 2366130 (2270593) Shared disk group enters the disabled state when the vxconfigd(1M) daemon is restarted on the master node followed by the node join operation. * 2437840 (2283588) Initialization of the mirror on the root disk gives an error message on the IA machine. * 2567623 (2567618) The VRTSexplorer dumps core in vxcheckhbaapi/print_target_map_entry. * 2570739 (2497074) The "Configuration daemon error 441" error occurs while trying to stop a volume that uses the vxvol(1M) command on the Cross Platform Data Sharing - Extensible Firmware Interface (CDS-EFI) disks. * 2703384 (2692012) When moving the subdisks by using the vxassist(1M) command or the vxevac(1M) command, if the disk tags are not the same for the source and the destination, the command fails with a generic error message. * 2836974 (2743926) The DMP restore daemon fails to restart during the system boot. * 2847333 (2834046) NFS migration failed due to device reminoring. * 2851354 (2837717) "vxdisk(1M) resize" command fails if 'da name' is specified. * 2881862 (2878876) The vxconfigd daemon dumps core in vol_cbr_dolog() due to race between two threads processing requests from the same client. * 2883606 (2189812) When the 'vxdisk updateudid' command is executed on a disk which is in the 'online invalid' state, the vxconfigd(1M) daemon dumps core. * 2916915 (2916911) The vxconfigd(1M) daemon sends a VOL_DIO_READ request before the device is open. This may result in a scenario where the open operation fails but the disk read or write operations proceeds. * 2919718 (2919714) On a thin Logical Unit Number (LUN), the vxevac(1M) command returns 0 without migrating the unmounted-VxFS volumes. * 2946948 (2406096) The vxconfigd daemon dumps core in vol_cbr_oplistfree() function. * 2957608 (2671241) When the Dirty Region Logging (DRL) log plex is configured in a volume, the vxnotify(1M) command does not report the volume enabled message. * 2960650 (2932214) After performing the "vxdisk resize" operation from less than 1TB to greater than or equal to 1TB on a disk with SIMPLE or SLICED format, that has the Sun Microsystems Incorporation (SMI) label, the disk enters the "online invalid" state. * 2973632 (2973522) At cable connect on port1 of dual-port Fibre Channel Host Bus Adapters (FC HBA), paths via port2 are marked as SUSPECT. * 2983901 (2907746) File Descriptor leaks are observed with the device-discovery command of VxVM. * 2986939 (2530536) When any path of the ASM disk is disabled, this results in multiple DMP reconfigurations. * 2990730 (2970368) Enhance handling of SRDF-R2 Write-Disabled devices in DMP. * 3000033 (2631369) In a Cluster Volume Manager (CVM) environment, when the vxconfigd(1M) daemon is started in the single-threaded mode, a cluster reconfiguration such as a node join and Veritas Volume Manager(VxVM) operations on shared disk group take more time to complete. * 3012938 (3012929) The vxconfigbackup(1M) command gives errors when disk names are changed. * 3041018 (3041014) Beautify error messages seen during relayout operation. * 3047474 (3047470) The device /dev/vx/esd is not recreated on reboot with the latest major number, if it is already present on the system. * 3047803 (2969844) The device discovery failure should not cause the DMP database to be destroyed completely. * 3059145 (2979824) The vxdiskadm(1M) utility bug results in the exclusion of the unintended paths. * 3077756 (3077582) Interfaces to get and reset the failio flag on disk after path failure recovered. * 3083189 (3025713) In a Veritas Volume Replicator (VVR) environment, adddisk / rmdisk taking time and I/O hang during the command execution. * 3087777 (3076093) The patch upgrade script "installrp" can panic the system while doing a patch upgrade. * 3100378 (2921147) The udid_mismatch flag is absent on a clone disk when source disk is unavailable. * 3139302 (3139300) Memory leaks are observed in the device discovery code path of VxVM. * 3140407 (2959325) The vxconfigd(1M) daemon dumps core while performing the disk group move operation. * 3140735 (2861011) The "vxdisk -g resize " command fails with an error for the Cross-platform Data Sharing(CDS) formatted disk. * 3142325 (3130353) Continuous disable or enable path messages are seen on the console for EMC Not Ready (NR) devices. * 3144794 (3136272) The disk group import operation with the "-o noreonline" option takes additional import time. * 3158781 (2495338) The disks having the hpdisk format can't be initialized with private region offset other than 128. * 3158790 (2779580) Secondary node gives configuration error (no Primary RVG) after reboot of master node on Primary site. * 3158793 (2911040) The restore operation from a cascaded snapshot leaves the volume in unusable state if any cascaded snapshot is in the detached state. * 3158794 (1982965) The vxdg(1M) command import operation fails if the disk access) name is based on the naming scheme which is different from the prevailing naming scheme on the host. * 3158799 (2735364) The "clone_disk" disk flag attribute is not cleared when a cloned disk group is removed by the "vxdg destroy " command. * 3158800 (2886333) The vxdg(1M) join operation should not allow mixing of clone and non-clone disks in a disk group. * 3158802 (2091520) The ability to move the configdb placement from one disk to another using "vxdisk set keepmeta=[always|skip|default]" command. * 3158804 (2236443) Disk group import failure should be made fencing aware, in place of VxVM vxdmp V-5-0-0 i/o error message. * 3158809 (2969335) The node that leaves the cluster node while the instant operation is in progress, hangs in the kernel and cannot join back to the cluster node unless it is rebooted. * 3158813 (2845383) The site gets detached if the plex detach operation is performed with the site- consistency set to off. * 3158818 (2909668) In case of multiple sets of the cloned disks of the same source disk group, the import operation on the second set of the clone disk fails, if the first set of the clone disks were imported with "updateid". * 3164583 (3065072) Data loss occurs during the import of a clone disk group, when some of the disks are missing and the import "useclonedev" and "updateid" options are specified. * 3164601 (2957555) The vxconfigd(1M) daemon on the CVM master node hangs in the userland during the vxsnap(1M) restore operation. * 3164613 (2814891) The vxconfigrestore(1M) utility does not work properly if the SCSI page 83 inquiry returns more than one FPCH name identifier for a single LUN. * 3164615 (3102114) A system crash during the 'vxsnap restore' operation can cause the vxconfigd (1M) daemon to dump core after the system reboots. * 3164617 (2938710) The vxassist(1M) command dumps core during the relayout operation . * 3164619 (2866059) The error messages displayed during the resize operation by using the vxdisk (1M) command needs to be enhanced. * 3164620 (2993667) Veritas Volume Manager (VxVM) allows setting the Cross-platform Data Sharing (CDS) attribute for a disk group even when a disk is missing, because it experienced I/O errors. * 3164626 (3067784) The grow and shrink operations by the vxresize(1M) utility may dump core in vfprintf() function. * 3164627 (2787908) The vxconfigd(1M) daemon dumps core when the slave node joins the CVM cluster node. * 3164628 (2952553) Refresh of a snapshot should not be allowed from a different source volume without force option. * 3164631 (2933688) When the 'Data corruption protection' check is activated by Dynamic Mult- Pathing (DMP), the device- discovery operation aborts, but the I/O to the affected devices continues, this results in data corruption. * 3164633 (3022689) The vxbrk_rootmir(1M) utility succeeds with the following error message: " ioscan: /dev/rdsk/eva4k6k0_48s2: No such file or directory". * 3164639 (2898324) UMR errors reported by Purify tool in "vradmind migrate" command. * 3164643 (2815441) The file system mount operation fails when the volume is resized and the volume has a link to volume. * 3164645 (3091916) The Small Computer System Interface (SCSI) I/O errors overflow the syslog. * 3164759 (2635640) The "vxdisksetup(1M) -ifB" command fails on Enclosuer Based Naming (EBN) with the legacy tree removed. * 3164790 (2959333) The Cross-platform Data Sharing (CDS) flag is not listed for disabled CDS disk groups. * 3164874 (2986596) The disk groups imported with mix of standard and clone Logical Unit Numbers (LUNs)s may lead to data corruption. * 3164880 (3031796) Snapshot reattach operation fails if any other snapshot of the primary volume is not accessible. * 3164881 (2919720) The vxconfigd(1M) command dumps core in the rec_lock1_5() function. * 3164883 (2933476) The vxdisk(1M) command resize fails with a generic error message. Failure messages need to be more informative. * 3164911 (1901838) After installation of a license key that enables multi-pathing, the state of the controller is shown as DISABLED in the command- line-interface (CLI) output for the vxdmpadm(1M) command. * 3164916 (1973983) The vxunreloc(1M) command fails when the Data Change Object (DCO) plex is in DISABLED state. * 3181315 (2898547) The 'vradmind' process dumps core on the Veritas Volume Replicator (VVR) secondary site in a Clustered Volume Replicator (CVR) environment, when Logowner Service Group on VVR Primary Site is shuffled across its CVM (Clustered Volume Manager) nodes. * 3182750 (2257733) Memory leaks are observed in the device discovery code path of VxVM. * 3189869 (2959733) Handling the device path reconfiguration in case the device paths are moved across LUNs or enclosures to prevent the vxconfigd(1M) daemon coredump. * 3238094 (3243355) The vxres_lvmroot(1M) utility which restores the Logical Volume Manager (LVM) root disk from the VxVM root disk fails. * 3240788 (3158323) In a VVR environment, with multiple secondaries, if SRL overflows for rlinks at different times, it may result in the vxconfigd(1M) daemon to hang on the primary node. * 3242839 (3194358) The continuous messages displayed in the syslog file with EMC not-ready (NR) LUNs. * 3245608 (3261485) The vxcdsconvert(1M) utility failed with the error "Unable to initialize the disk as a CDS disk". * 3247983 (3248281) When the "vxdisk scandisks" or "vxdctle enable" commands are run consecutively the "VxVM vxdisk ERROR V-5-1-0 Device discovery failed." error is encountered. * 3253306 (2876256) The "vxdisk set mediatype" command fails with the new naming scheme. * 3256806 (3259926) The vxdmpadm(1M) command fails to enable the paths when the '-f' option is provided. Patch ID: PHCO_43295 * 3057916 (3056311) For release < 5.1 SP1, allow disk initialization with CDS format using raw geometry. * 3175698 (3175778) Support for listener in 51SP1 Patch ID: PHCO_43065 * 2070079 (1903700) Removing mirror using vxassist does not work. * 2205574 (1291519) After multiple VVR migrate operations, vrstat fails to output statistics. * 2427560 (2425259) vxdg join operation fails with VE_DDL_PROPERTY: Property not found in the list * 2442751 (2104887) vxdg import error message needs improvement for cloned diskgroup import failure. * 2442827 (2149922) Record the diskgroup import and deport events in syslog * 2485261 (2354046) man page for dgcfgrestore is incorrect. * 2492568 (2441937) vxconfigrestore precommit fails with awk errors * 2495590 (2492451) vxvm-startup2 launches vxesd without checking install-db. * 2513457 (2495351) VxVMconvert utility was incompatible to migrate data across platforms from native LVM configurations. * 2515137 (2513101) User data corrupted with disk label information * 2560539 (2252680) vxtask abort does not cleanup tasks properly. * 2567623 (2567618) VRTSexplorer coredumps in checkhbaapi/print_target_map_entry. * 2576605 (2576602) 'vxdg listtag' should give error message and display correct usage when executed with wrong syntax * 2626742 (2626741) Using vxassist -o ordered and mediatype:hdd options together do not work as expected * 2626745 (2626199) "vxdmpadm list dmpnode" printing incorrect path-type * 2627000 (2578336) Failed to online the cdsdisk. * 2627004 (2413763) Uninitialized memory read results in a vxconfigd coredump * 2641932 (2348199) vxconfig dumps core while importing a Disk Group * 2646417 (2556781) In cluster environment, import attempt of imported disk group may return wrong error. * 2652161 (2647975) Customer ran hastop -local and shared dg had splitbrain * 2677025 (2677016) Veritas Event Manager(vxesd(1M)) daemon dumps core when main thread tries to close one of its thread (which hold connection with HP Event Manager). * 2690959 (2688308) When re-import of disk group fails during master takeover, other shared disk groups should not be disabled. * 2695231 (2689845) Data disk can go in error state when data at the end of the first sector of the disk is same as MBR signature * 2705101 (2216951) vxconfigd dumps core because chosen_rlist_delete() hits NULL pointer in linked list of clone disks * 2706024 (2664825) DiskGroup import fails when disk contains no valid UDID tag on config copy and config copy is disabled. * 2706038 (2516584) startup scripts use 'quit' instead of 'exit', causing empty directories in /tmp * 2737373 (2556467) DMP-ASM: disabling all paths and reboot of the host causes losing of /etc/vx/.vxdmprawdev records * 2747340 (2739709) Disk group rebuild fails as the links between volume and vset were missing from 'vxprint -D -' output. * 2759895 (2753954) When a cable is disconnected from one port of a dual-port FC HBA, the paths via another port are marked as SUSPECT PATH. * 2763211 (2763206) "vxdisk rm" command dumps core when disk name of very large length is given * 2768492 (2277558) vxassist outputs a misleading error message during snapshot related operations. * 2802370 (2585239) VxVM commands run very slow on setup with tape devices * 2804911 (2637217) Document new storage allocation attribute support in vradmin man page for resizevol/resizesrl. * 2821143 (1431223) "vradmin syncvol" and "vradmin syncrvg" commands do not work if the remote diskgroup and vset names are specified when synchronizing vsets. * 2821452 (2495332) vxcdsconvert fails if the private region of the disk to be converted is less than 1 MB. * 2821515 (2617277) Man pages for the vxautoanalysis and vxautoconvert commands are missing from the base package. * 2821537 (2792748) Node join fails because of closing of wrong file descriptor * 2821678 (2389554) vxdg listssbinfo output is incorrect. * 2826129 (2826125) VxVM script daemon is terminated abnormally on its invocation. * 2826607 (1675482) "vxdg list " command shows configuration copy in new failed state. * 2827939 (2088426) Re-onlining of disks in DG during DG deport/destroy. * 2836910 (2818840) Enhance the vxdmpasm utility to support various permissions and "root:non- system" ownership can be set persistently. * 2852270 (2715129) Vxconfigd hangs during Master takeover in a CVM (Clustered Volume Manager) environment. * 2858859 (2858853) After master switch, vxconfigd dumps core on old master. * 2859390 (2000585) vxrecover doesn't start remaining volumes if one of the volumes is removed during vxrecover command run. * 2860449 (2836798) In VxVM, resizing simple EFI disk fails and causes system panic/hang. * 2860451 (2815517) vxdg adddisk allows mixing of clone & non-clone disks in a DiskGroup. * 2882488 (2754819) Diskgroup rebuild through 'vxmake -d' loops infinitely if the diskgroup configuration has multiple objects on a single cache object. * 2886083 (2257850) vxdiskadm leaks memory while performing operations related to enclosures. * 2911009 (2535716) VxVMconvert doesn't support migration of data for large number of LVM/VG configuration since it always creates private region at static offsets - 128th block * 2911010 (2627056) 'vxmake -g DGNAME -d desc-file' fails with very large configuration due to memory leaks Patch ID: PHCO_42992 * 2621549 (2621465) When detached disk after connectivity restoration is tried to reattach gives 'Tagid conflict' error * 2626915 (2417546) Raw devices are lost after reboot and cause permissions problem. * 2626920 (2061082) vxddladm -c assign names should work for devices with native support not enabled (VxVM labeled or TPD) * 2643651 (2643634) Message enhancement for a mixed(non-cloned and cloned) dg import * 2666175 (2666163) A small portion of possible memory leak incase of mix (clone and non-cloned) diskgroup import * 2695225 (2675538) vxdisk resize may cause data corruption * 2695227 (2674465) Adding/removing new LUNs causes data corruption * 2701152 (2700486) vradmind coredumps when Primary and Secondary have the same hostname and an active Stats session exists on Primary. * 2702110 (2700792) The VxVM volume configuration daemon may dump a core during the Cluster Volume Manager(CVM) startup. * 2703370 (2700086) EMC BCV (NR) established devices are resulting in multiple dmp events messages (paths being disabled/enabled) * 2703373 (2698860) vxassist mirror failed for thin LUN because statvfs failed. * 2711758 (2710579) Do not write backup labels for CDS disk - irrespective of disk size * 2744219 (2729501) vxdmpadm exclude vxvm path=<> results in excluding unexpected set of paths. * 2750454 (2423701) Upgrade of VxVM caused change in permissions. * 2752178 (2741240) Invoking "vxdg join" operation during heavy IO load results in a transaction failure and leaves disks in an intermediate state. Patch ID: PHCO_42807 * 2477272 (2169726) CLONE : Disk group is imported using a Non-cloned and cloned disks, it can lead to data corruption * 2507120 (2438426) VxVM is failing to correctly discover ZFS LUNs presented via PP after excluding/including libvxpp.so * 2508294 (2419486) Data corruption occurs on changing the naming scheme * 2511928 (2420386) Data corruption creating data in a vxfs filesystem, while being grown with vxresize on efi thinrclm disks. * 2515137 (2513101) User data corrupted with disk label information * 2517819 (2530279) vxesd has been built without any thread locking mechanism. * 2525333 (2148851) vxdisk resize failed to resize the disk which is expanded physically from array console. * 2528144 (2528133) vxdisk ERROR V-5-1-0 - Record in multiple disk groups * 2531993 (2524936) DG disabled after vold found the process file table is full. * 2574840 (2344186) Volume recovery is not clearing the need sync flag from volumes with DCO in BADLOG state. Thus nodes are unable to join the cluster. * 2676703 (2553729) Disk groups do not get imported and 'clone_disk' flag is seen on non-clone disks after uprade of VxVM. Patch ID: PHCO_42245 * 2163809 (2151894) vmtest/tc/scripts/switchout/raid5/volume/start/wlog.tc#2 fails in the ss_tot nightly TC run * 2198041 (2196918) Snapshot creation with cachesize fails, as it doesn't take into account diskgroup alignment. * 2204146 (2200670) vxattachd does not recover disks if disk group not imported * 2214184 (2202710) VVR:During SRL to DCM flush, commands should not hang and come out with proper error. * 2232829 (2232789) NetApp Metro Cluster dmp failed and vxio write erorrs * 2234292 (2152830) In multilevel clone disks environment, regular DG import should be handled properly and in case of DG import failure, it should reports correct error message * 2241149 (2240056) 'vxdg move' transaction not completing and backups fail. * 2247645 (2243044) VxVM vxislvm ERROR V-5-1-2604 cannot open /dev/rdsk/c64t0d1s2 error seen on running vxdisksetup * 2253269 (2263317) CLONE: Diskgroup import with dgid needs to be clearly documented in manual for the case in which original dg was destroyed and cloned disks are present. * 2256728 (2248730) vxdg import command hangs as vxrecover daemon (spawned by vxdg) doesn't close standard error stream * 2316309 (2316297) FMI: After applying 5.1SP1RP1 error message "Device is in use" appears during boot time * 2323999 (2323925) If rootdisk is encapsulated and if install-db is present, clear warning should be displayed on system boot. * 2328219 (2253552) Leak in vxsfdefault_parse.y at function vxsf_getdefault (*val) * 2328286 (2244880) hxrt5.1sp1:sfcfs:HP-UX11.31:initialize (vxdisksetup -fi) 1TB thin reclaimable luns failed * 2337091 (2255182) Handling misconfiguration of CLARiiON array reporting one failovermode value through one HBA and different from other HBA * 2349653 (2349352) New LUN addition on the host caused Data corruption. * 2353327 (2179259) DMP SCSI bypass needs to be enhanced to handle I/O > 2TB * 2353328 (2194685) LxRT, 5.1SP1PR2, SFCFSRAC, RHEL6: vxconfigd daemon core dump during array side switch ports disable and re-enable. * 2353403 (2337694) TP/lxrt5.1sp1: "vxdisk -o thin list" showing size 0 for over 2TB LUNs on RHEL5 * 2353404 (2334757) memory consumption for the vxconfigd grows because of a lot of DMP_IDLE, DMP_UNIDLE events. * 2353421 (2334534) In CVM environment, vxconfigd level join is hung when Master returns error "VE_NO_JOINERS" to a joining node and cluster nidmap is changed in new reconfiguration * 2353425 (2320917) VXVM 5.1RP2 Solaris10: Lost disk groups - lost two disk group during routine operation:vxconfigd also crashed. * 2353427 (2337353) vxdmpadm include vxvm dmpnodename=<emcpower#> includes all excluded dmpnodes along with the requested one * 2353464 (2322752) Duplicate DA records seen for NR devices upon restart of vxconfigd * 2353922 (2300195) vxdiskunsetup fails on hp-ia64 for cds-efi * 2360419 (2237089) vxrecover might start the recovery of data volumes before the recovery of the associated cache volume is recovered. * 2360719 (2359814) vxconfigbackup doesn't handle errors well * 2377317 (2408771) vxconfigd does not scan and discover all the storage device; some storage devices are skipped. * 2379034 (2379029) Changing of enclosure name is not working for all devices in enclosure * 2382705 (1675599) Excluding and including a LUN in a loop triggers a huge memory leak for vxconfigd when EMC PowerPath is configured * 2382710 (2139179) SSB check invalid when lun copy * 2382717 (2197254) While creating volumes on thinrclm disks, the option "logtype=none" does not work with vxassist command. * 2383705 (2204752) getting error message "VxVM ERROR V-5-3-12240: GPT entries checksum mismatch" atfer creating diskgroup * 2384473 (2064490) Ensure vxcdsconvert works with support for > 1 TB CDS disks * 2384844 (2356744) VxVM script daemons should not allow its duplication instance in itself * 2386763 (2346470) Excluding and including a LUN in a loop triggers a huge memory leak * 2389095 (2387993) vxconfigd -k goes into disabled state in case of NR devices * 2397663 (2165394) CLONE: dg imported by selecting wrong disks. After destroying original dg, when try to import clone devices without useclonedev option with dgname, then it import dg with original disks. * 2405446 (2253970) Support per-disk maxiosize for private region I/Os * 2408209 (2291226) Multiple Oracle database's experienced block level corruption * 2409212 (2316550) DMP: warning messages seen on setup with ALUA array "VxVM vxconfigd WARNING V-5-1-0 ddl_add_disk_instr: Turning off NMP Alua mode failed for dmpnode 0xffffffff with ret = 13 " * 2411052 (2268408) suppressing a powerpath disk's path using vxdiskadm 17-2 causes the disk to go in error state * 2411053 (2410845) Lots of 'reservation conflict' messages seen on 5.1SP1RP1P1 clusters with XIV arrays. * 2413908 (2413904) Multiple issues are seen with AxRT5.0MP3RP3 while performing Dynamic LUN reconfiguration. * 2415566 (2369177) DDL: do_diskio function should be able to handle offset > 2TB * 2415577 (2193429) IO policy not getting preserved when vold is restarted and migration from one devlist to other is taking place. * 2417205 (2407699) vxassist core dump if /etc/default/vxassist have wantmirror=ctlr * 2421491 (2396293) HxRT SF6.0 : I/Os loaded, sanboot failed with vxconfigd core dump. * 2428179 (2425722) vxsd move operation failed for disk size >= 2TB * 2440351 (2440349) DCO volume may grow into any 'site' even when 'alloc=site:xxxx' is specified by a list of 'site' to be limited. * 2442850 (2317703) Vxesd/Vxconfigd leaks file descriptors. * 2477291 (2428631) Allow same fence key to be used for all Disk groups * 2480006 (2400654) Stale array.info file can cause vxdmpadm commands to hang. * 2483476 (2491091) vxdisksetup failing with stale EFI entries * 2485230 (2481938) QXCR1001120138: vxconfigbackup throwing an error when DG contains a sectioned disk * 2485278 (2386120) Enhancement request to add diagnostic logging to help triage a CVM master takeover failure situation * 2485288 (2431470) "vxdisk set" command operates on a wrong VxVM device and does not work with DA (Disk Access) name correctly. * 2492016 (2232411) Pinnacle[NIGHTLY]:vmcert:/vmtest/tc/scripts/admin/volassist/align/subdisk.tc#2 & #4 failed in 01_02 nightly build DETAILS OF INCIDENTS FIXED BY THE PATCH --------------------------------------- This patch fixes the following incidents: Patch ID: PHCO_44714 * 3680388 (Tracking ID: 3680386) SYMPTOM: 'vxconfigd' process gets stopped after command only patch upgrade. DESCRIPTION: At the start of command patch upgrade, the 'vxconfigd' process is stopped in order to build a new vxconfigd binary. However, new 'vxconfigd' process is not started after the patch upgrade completes. RESOLUTION: Code changes are implemented to re-start the 'vxconfigd' during the command patch upgrade. * 3932586 (Tracking ID: 3934324) SYMPTOM: Optimize the VxVM device discovery time by reducing few un-necessary io_search API calls. DESCRIPTION: During VxVM (Veritas Volume Manager) device discovery, io_search() API provided by HP was used multiple times, which increases the overall device discovery time. To optimize the device discovery process, few of the unnecessary io_search() API calls have been removed. RESOLUTION: Code fix is implemented in order to reduce the device discovery time. * 3938065 (Tracking ID: 3903441) SYMPTOM: When restoring an Ignite-UX system recovery archive created of a system having a VxVM root disk that bypass DMP (i.e. using only HP-UX native multipathing or NMP), the restored system hangs while booting with the following error message: UX:vxfs fsck: ERROR: V-3-20945: /dev/vx/dsk/rootdg/standvol:cannot stat /dev/vx/dsk/rootdg/standvol DESCRIPTION: The bootdg entry in the /etc/vx/volboot file was not properly restored. In the case of a VxVM root disk which bypasses DMP, the issue can cause failures when starting the volumes in rootdg and eventually lead to a hang during booting. RESOLUTION: The code is modified to update the missing bootdg entry in the volboot file while booting the system after recovery. * 3945014 (Tracking ID: 3945375) SYMPTOM: "vxassist" command with "remove mirror" can fail on node on site configured cluster. VxVM vxassist ERROR V-5-1-3242 Subvolume : Cannot remove enough mirrors DESCRIPTION: For each mirror record we check if there is atleast one active mirror on site apart from the mirror we are marking to remove. Due to a bug in the code to the number of active mirror configured on the site is reported incorrectly. Hence the "vxassist remove" option fails displaying the above error message. RESOLUTION: Appropriate code changes are done to handle the bug. * 3946329 (Tracking ID: 3946328) SYMPTOM: "update-ux -s <1805 OE Depot> !Base-VxFS-61 !Base-VxVM-61 !Base-VxTools-61 !B3929IB" command may lead to unsupported configuration. DESCRIPTION: The above "update-ux" may fail if system is not at the latest VxVM 5.1SP1 patch level (PHCO_44243 & PHKL_44244 or superseding patches). "update-ux" would auto select the VxVM patches (PHCO_44243 & PHKL_44244). These patches have a dependency on VRTSaslapm whose revision string should be r>=5.1.103.001. The 1805 OE depot has 6.1 VRTSaslapm product whose revision string is 6.1.0.000. Therefore SD automatically selects 6.1 VRTSaslapm as 6.1.0.000 > 5.1.103.001. System would have VRTSvxfs 5.1 SP1 & VRTSvxvm 6.1 (incompatible & unsupported configuration) The system would not boot if it is VxVM rooted. RESOLUTION: Changes have been done in VRTSaslapm dependencies to handle this scenario. * 3952857 (Tracking ID: 3926067) SYMPTOM: In a Campus Cluster environment, vxassist relayout command may fail with following error: VxVM vxassist ERROR V-5-1-13124 Site offline or detached VxVM vxassist ERROR V-5-1-4037 Relayout operation aborted. (20) vxassist convert command also might fail with following error: VxVM vxassist ERROR V-5-1-10128 No complete plex on the site. DESCRIPTION: For vxassist "relayout" and "convert" operations in Campus Cluster environment, VxVM (Veritas Volume Manager) needs to sort the plexes of volume according to sites. When the number of plexes of volumes are greater than 100, the sorting of plexes fail due to a bug in the code. Because of this sorting failure, vxassist relayout/convert operations fail. RESOLUTION: Code changes are done to properly sort the plexes according to site. Patch ID: PHCO_44660 * 3913086 (Tracking ID: 3898090) SYMPTOM: VxVM (Veritas Volume Manager) vxvmconvert utility may corrupt HP-UX LVM logical volume due to incorrect subdisk length during conversion DESCRIPTION: When converting HP-UX LVM logical volume to VxVM volume by vxvmconvert utility, in case volume is pretty large, multiplication of logical volume's PE (Physical Extent) size, block size and extent count can overflow 32bit value hence subdisk length becomes incorrect. Consequently, converted VxVM volume content is corrupt. RESOLUTION: Code changes have been done to address the issue. * 3922019 (Tracking ID: 3922018) SYMPTOM: Shared DG import fails when minor number of shared DG conflicts with minor number of private DG on slave with the below error: VxVM vxdg ERROR V-5-1-10978 Disk group : import failed: Error in cluster processing DESCRIPTION: During shared DG import minor number is first checked on master node and then the request to import the DG is sent to slave node. If there is a private DG on the slave node with same minor number as the shared DG getting imported then slave node fails the import with minor conflict error. Master node retries the import of the DG with new minor number and sends the request to slave node for DG import retrial. There are some stale entries which are still kept in vxconfigd in-core database as part of first DG import failure and vxconfigd database is not cleaned up. The stale entries lead to vxconfigd core dump on slave which in turn results into DG import failure. RESOLUTION: Code change are done to clear the entries which are created as part of first DG import trial. * 3922021 (Tracking ID: 3922020) SYMPTOM: 'vxdisk resize' operation is not propagating the new DA sizes to slave nodes in a cluster. The volume and filesystem sizes are correctly propagated, but the vxdisk list output shows the size on the slaves which is unchanged. DESCRIPTION: For propagating the new DA sizes to slave nodes, one of the functions reads the required magic string at a wrong offset, because magic string is overwritten by the local disk attributes offset. The reason for the over-writing is Disabled config copies. They are explicitly disabled for disks requiring VTOC to GPT conversion and which have a size greater than 1 TB. Hence the issue. RESOLUTION: Code changes have been done to refresh the DA records on SLAVES, by reading the private region. Patch ID: PHCO_44586 * 3902801 (Tracking ID: 3902793) SYMPTOM: The VxVM diagnostic utility vxdmpdbprint fails with the following error 71 error message: # /etc/vx/diag.d/vxdmpdbprint dmp_get_dmp_nodes_on_da() failed with error 71 DESCRIPTION: This error occurs when the disk array name is greater than 15 characters. The array-name field is an internal data structure, pre-allocated by the vxdmpdbprint utility. If the disk array name is greater than 15 characters, it will overflow and overwrite the subsequent fields in the data structure, leading to error 71. RESOLUTION: Modify the pre-allocated space in the VxVM structure using the vxdmpdbprint utility. Patch ID: PHCO_44553 * 3895494 (Tracking ID: 3895493) SYMPTOM: More history of DDL reconfiguration is desired to help isolate problems concerning dynamic reconfiguration. DESCRIPTION: In 5.1SP1 release, 10 ddl.log files are collected to record the dynamic reconfiguration of the vxconfigd(1M) command. In some cases, the ddl.log files are overwritten which leads to loss of important data required to complete the Root Cause Analysis (RCA) of the issue encountered. RESOLUTION: For 5.1SP1 release, in order to safeguard important data for RCA efforts, the number of ddl.log files before getting overwritten has been increased to 50. * 3895678 (Tracking ID: 3892775) SYMPTOM: When installing patches from QPK [Quality patch bundle] on a system with a VxVM version before VxVM 51SP1, the installation fails with the following error message: ERROR: The "checkinstall" script for "PHCO_44243" failed (exit code "1"). The script location was "/var/tmp/BAA005510/catalog/PHCO_44243/pfiles/checkinstall". DESCRIPTION: VxVM 5.1SP1 command patch included in the QPK bundle and the patchs checkinstall script will verify the installation of the required versions of the CommonIO and FC drivers. Such verification is needed only if the system is running VxVM 5.1SP1. Due to some bad logic in the checkinstall script, a system having a VxVM version other than 5.1SP still can fail the QPK installation if the required versions of CommonIO and FC drivers are not present. RESOLUTION: The checkinstall script is modified to return an error message for the missing pre-requisite drivers only when base 5.1SP1 VxVM package is installed in the system. * 3895777 (Tracking ID: 2165920) SYMPTOM: The vxrelocd(1M) daemon creates a defunct (zombie) process. DESCRIPTION: Daemon vxrelocd(1M) create child processes to help in reclaiming disks. But vxrelocd(1M) does not check the exit status of its child process. As the child process is forked in the background, it causes a defunct child process of the vxrelocd(1M) daemon. RESOLUTION: The code is modified such that the background process is branched only when it is necessary and vxrelocd(1M) will wait for child process to complete. * 3897044 (Tracking ID: 3880212) SYMPTOM: The vxreattach(1M) command always performs full resync operation despite FastResync license. DESCRIPTION: By default, the command vxreattach(1M), uses "nofmr" option while reattaching the disk back. To use FastResync with vxreattach operation, it needs to be mentioned in /etc/default/vxreattach file (usefmr=yes). This RESOLUTION: The man page for command vxreattach(1M) is modified to include usage of /etc/default/vxreattach file. * 3898670 (Tracking ID: 3898171) SYMPTOM: When using ignite/UX to restore an image of a system having VxVM foreign disks (i.e. VxVM disks bypassing DMP) as root disks, the recovered system hangs while booting with the following error message: UX:vxfs fsck: ERROR: V-3-20945: /dev/vx/dsk/rootdg/standvol:cannot stat /dev/vx/dsk/rootdg/standvol DESCRIPTION: When restoring the ignite archive, it is found that the bootdg entry is missing from /etc/vx/volboot. At the same time, due to a bug, vxconfigd cannot recover the missing bootdg entry at rootdg import. RESOLUTION: The code is modified to correct the missing bootdg entry while booting the system. Patch ID: PHCO_44243 * 3273164 (Tracking ID: 3281160) SYMPTOM: While importing a disk group that has a base-minor number same as that of an existing imported disk group and when auto-reminor setting is turned off, the import proceeds successfully without issuing a warning suggesting disk group should be re-minored whenever possible. Thus two imported disk groups may be assigned same base_minor, as shown below. vxprint -g -F "%base_minor" 10000 vxprint -g -F "%base_minor" 10000 DESCRIPTION: When auto-reminor is set to off, the base-minor number conflict is not properly detected when importing the disk group. As a result, multiple disk groups may be imported using the same base_minor number. After volumes are created in such disk groups, available minor numbers in the range of (base_minor) to (base_minor+1000) will be allocated to these volumes. This may cause potential minor number conflicts when such disk groups are deported and imported again. RESOLUTION: The code is modified to issue following warning while importing the disk group having same base-minor as that of existing disk groups: VxVM vxconfigd WARNING V-5-1-0 Disk group has base-minor number conflicts, it should be reminored when volumes are not in use. * 3694561 (Tracking ID: 2990967) SYMPTOM: The volume device numbers are not assigned as per the disk group base-minor range while the volumes are created. For example, in below output, base_minor number is 6812000; but minor number 5 is assigned to the volume. Minor numbers are expected to be assigned within the range base_minor to base_minor+1000. vxprint -l synpdg | grep minor minors: >= 6812000 device: minor=5 bdev=2/5 cdev=134/5 path=/dev/vx/dsk/synpdg/ora_synp_log_vol During import following warning message is displayed: VxVM vxdg WARNING V-5-1-1328 Volume ora_synp_log_vol: Temporarily renumbered due to conflict" DESCRIPTION: To avoid the minor number conflicts, minor-number space is divided into two pools, one for the private-disk groups, and the other for the shared-disk groups. Further, a base-minor number is assigned to a disk group while importing it and the volumes created in the disk group are assigned device numbers based on the disk group base-minor number, the minor number range falls between base-minor to base-minor +1000. Now, if a shared disk group is created and later if it is imported back as the private disk group, the volumes minor numbers are expected to be assigned starting with the disk group base-minor number. However, the minor numbers were incorrectly getting assigned from the private pool of minor number space. The issue occurred because an internal map was incorrectly used for assigning the minor numbers to the volume. RESOLUTION: The code is modified to correctly assign the device numbers to the volumes based on the disk group base-minor range. Further, the vxdg (1M) command is enhanced to provide a way to import the disk group if there are minor number conflicts. Disk group is permanently re-minored using following command: vxdg [-t] -o reminor[=new_base_minor] import In the above command, if a new_base_minor is specified, then disk group will be imported and re-minored using the new_base_minor. If new_base_minor is not specified, then VxVM will assign an appropriate new_base_minor. * 3699305 (Tracking ID: 3317125) SYMPTOM: A disk group may get imported as shared disk group on a CVM(Clustered Volume Manager) slave node, such that its 'base_minor' number is similar to an existing private disk group on that slave node, as shown below: > vxprint -g -F "%base_minor" 20000 > vxprint -g -F "%base_minor" 20000 DESCRIPTION: When an earlier private disk group is imported in shared mode and if its base_minor number conflicts with the base_minor number of an existing private disk group on on of the slave nodes, the import should issue some warning message so that user can re-minor the disk group whenever volumes are not in use. However, the disk group was getting imported with base_minor number similar to existing private disk group on the slave node without issuing any waning message. Resolving such base-minor number conflicts may help to avoid minor number conflicts in future. RESOLUTION: The code has been fixed to issue following warning message while importing disk group on slave node: VxVM vxconfigd WARNING V-5-1-0 Disk group has base-minor number conflicts, it should be reminored when volumes are not in use.. * 3699311 (Tracking ID: 3139180) SYMPTOM: The node join operation fails, if the device-minor numbers of the node-join operation are similar to The device-minor numbers of the currently imported disk groups in the cluster. Following messages are displayed in the system logs: vxvm:vxconfigd: V-5-1-8066 minor number disk group in use vxvm:vxconfigd: V-5-1-11092 cleanup_client: (Cannot assign minor number) vmunix: WARNING: VxVM vxio V-5-0-164 Failed to join cluster , aborting DESCRIPTION: VxVM does not re-minor a disk group that is already imported, regardless of whether the "autoreminor" is set to "on". In this case, a node attempts to join the cluster, however, the joining node has minor numbers that conflict with a disk group in the cluster. As a result, the join operation fails. The disk group that has conflicting minor numbers, needs to be re-minored manually before performing the node-join operation. RESOLUTION: The behavior and work-around is documented in the vxdg(1M) commands manual page. * 3699313 (Tracking ID: 3028704) SYMPTOM: When a disk group that has cloned disks is imported, warning messages related to minor number conflicts are displayed. The warning message that is displayed is as follows: "VxVM vxdg WARNING V-5-1-1328 Volume : Temporarily renumbered due to conflict" DESCRIPTION: When a disk group that has clone disks is imported using the '-o useclonedev' and the '-o updateid' options, minor number conflict occurs since the volumes in the cloned disk group have same minor number. If the autoreminor setting has been turned on, this conflict is avoided by performing dynamic reminoring during the disk group import operation. However, the function which handles the 'updateid' task does not check if the disk group has already been reminored. due to a minor number conflict earlier during the disk group import process, and subsequently assigns a new base minor number to the disk group. As a result, a warning message is displayed. RESOLUTION: The code is modified such that the function that handles the disk group reminoring when 'updateid' option is provided is fixed. Reminoring is not performed when the minor number has already been changed due to a minor number conflict. * 3741460 (Tracking ID: 2721644) SYMPTOM: The vxconfigd(1M) daemon dumps core with the following stack trace: #0 strstr () from /lib/libc.so.6 #1 ddl_get_tgttype () #2 ddl_update_port_prop () #3 ddl_set_config () #4 req_set_ddl_config () #5 request_loop () #6 main () The core dump may be observed after the disks are removed from the storage layer. DESCRIPTION: The vxconfigd (1M) daemon sets the information about the Device Discovery Layer (DDL) discovered entities. While reading the entity database, if disks are removed from storage layer, an internal unsigned variable corresponding to the number of sub-paths under a DMP node gets assigned a negative value as an error condition. Due to the incorrect data type, the program fails to identify the error to retrieve the number of sub-paths and incorrectly goes ahead. As a result, vxconfigd(1M) daemon subsequently dumps core due to an illegal operation. RESOLUTION: The code change defines the local variable as signed type to prevent the core dump. * 3741485 (Tracking ID: 3162418) SYMPTOM: When handing a device discovery request, such as vxdisk scandisks, vxconfigd (1M) failed the discovery due to some issue, leaving the device list empty. Subsequently, vxconfigd(1M) dumps core when trying to access the device list. A probable stack trace is as follows. ddi_hash_devno() ddl_find_cdevno() ddl_find_path_cdevno() req_daname_get() vold_process_request() start_thread() DESCRIPTION: In trying to find a device from the emptied device list, NULL values are returned, but vxconfigd(1M) attempts to deference those NULL values leading to a core dump. Ideally, vxconfigd(1M) should detect the NULL values before accessing to avoid the core dump. RESOLUTION: The code changes are made to detect the NULL value correctly. * 3741725 (Tracking ID: 3247040) SYMPTOM: The execution of the vxdisk scandisks command inadvertently re- enables Powerpath(PP) enclosures earlier disabled using the following command: "vxdmpadm disable enclosure=" DESCRIPTION: During the device discovery process, due to a wrong check for the PP enclosure, Dynamic Multi-pathing (DMP) destroys the old PP enclosure from the device discovery layer (DDL) database, and adds it as a new enclosure. This process removes all the old flags that are set on the PP enclosure, and then DMP treats the enclosure as enabled due to the absence of required flags. RESOLUTION: The code is modified to keep the PP enclosure in the DDL database during the device discovery, and to verify that the existing flags on the paths of the PP enclosure are not reset. * 3741882 (Tracking ID: 3134118) SYMPTOM: The vxdmpadm -q iostat show interval = command reports incorrect QUEUED I/Os and PENDING I/Os after the first interval. Consider the example below. PENDING I/Os should display 200 instead of 0 for second interval, because they are still pending since the first interval. $ vxdmpadm -qz iostat show interval=1 cpu usage = 0us per cpu memory = 831488b QUEUED I/Os PENDING I/Os PATHNAME READS WRITES 0 0 200 0 0 0 DESCRIPTION: QUEUED I/Os and PENDING I/Os should report the outstanding I/Os for each interval. But the code incorrectly reports the difference between the I/O counts for the current interval and the previous one. As a result, if no I/O occurred between the two intervals, the difference, which is 0, will be printed instead of the actual number of outstanding I/Os. RESOLUTION: The code is modified so that for any time interval, the DMP driver would always report the outstanding I/O count for that time frame. * 3742610 (Tracking ID: 3134882) SYMPTOM: For a node join scenario, disk re-online operation is not performed on slave node for auto-imported disk groups containing clone disks. DESCRIPTION: During node join case, re-online operation is not done on slave node if the disk group containing clone disks is auto-imported on master node. For a disk group containing clone disks, the disk re-online operation must be performed before importing the disk group. If the re-online is not performed, there can be possibility that the disk group is imported with stale private region data. The re-online operation ensures that the disk private region is updated with correct information. RESOLUTION: Code changes are done to re-online the disks on the slave node. * 3756607 (Tracking ID: 3090097) SYMPTOM: While a disk group with auto-reminor enabled is imported in shared mode, but its base_minor number conflicts with the base_minor number of an existing private disk group on one of the slave nodes in cluster, the disk group will be imported with base_minor=0 and the minor numbers assigned to its associated volumes will then come from the private pool, as shown below. vxdg -s import vxprint -g -m base_minor=0 vol vol_concat1 minor=6 vol vol_stripe1 minor=5 DESCRIPTION: When auto_reminor setting has been enabled, a base-minor conflict should be resolved by retrying the disk group import operation using a different base- minor. Due to an internal flag not properly set for the retry, auto-reminoring does not happen, leaving the base_minor at 0. Minor numbers assigned to associated volumes will then fall into the private pool of minor numbers from 0 to 32999. RESOLUTION: The code is modified to set the 'auto-reminor' flag, while it retries the disk group import operation. * 3762780 (Tracking ID: 3605612) SYMPTOM: When auto-reminor setting is enabled, a disk group may get imported such that its 'base_minor' number is similar to another imported disk group, as shown below: vxprint -g -F "%base_minor" 20000 vxprint -g -F "%base_minor" 20000 DESCRIPTION: If the 'autoreminor' tunable is enabled and 'base_minor' number of disk group to be imported is similar to another disk group, then the disk group should be ideally automatically re-minored during import. The re-minoring helps to avoid minor number conflicts in future. However, the disk group to be imported was not getting re-minored if there are no volume records in disk group. As a result, multiple disk groups with similar 'base_minor' number were imported. RESOLUTION: The code is fixed to correctly re-minor the disk group during disk group import in order to handle the base_minor number conflicts. * 3814123 (Tracking ID: 3045033) SYMPTOM: The "vxdg init" command should not create a disk group on the clone disks. DESCRIPTION: If the disk contains copy of data from some other VxVM disk, an attempt to create the disk groups (dgs) on such disks may result in data loss. Hence, the vxdg init command fails and a disk group will not be created on the clone disks. If the disk has 'udid_mismatch' or 'clone_disk' flag, but is not a clone disk, the flag can be manually cleared using the following commands: vxdisk updateudid vxdisk set clone=off For more information, see the vxdg(1M) commands manual page. RESOLUTION: The code is modified to fail the "vxdg init" command for the clone disks. Additionally, the behavior of the vxdg init command for the clone disks and steps to clear the 'udid_mismatch' or 'clone_disk' flags are documented in the vxdg(1M) commands manual page. * 3814134 (Tracking ID: 3734606) SYMPTOM: As per the current design, all disks are re-onlined for every clone or tagged disk group to be imported. As a result, the node join operation takes time. DESCRIPTION: During the slave node join operation, all the disks are re-onlined for every clone or tagged disk group to be imported. As a result, the node join time may increase if a large number of disk groups (dgs) have cloned or tagged disks on the system. RESOLUTION: The code is modified to reduce the redundant disk re-onlines during the node join operation. Earlier, all disks were re-onlined while importing each clone or tagged disk group during the node join operation. With the fix, all disks will be re-onlined once during the node join operation, if there exists at least one clone or tagged disk group. * 3851289 (Tracking ID: 3851287) SYMPTOM: While installing patches from QPK [Quality patch bundle], installation may get aborted if the VxVM command patch is part of QPK, but base VxVM package is not installed. DESCRIPTION: If the VxVM command patch is included in the QPK bundle, then it gets marked for the installation. While installing the VxVM patch, checkinstall script verifies if the pre-requisites like CommonIO bundle FC drivers of the required versions are installed in the system. If the pre-requisites of required version are not installed in the system, then the checkinstall script returns failure irrespective of whether base VxVM package is installed. As a result, installation of other patches from QPK bundle also gets aborted. RESOLUTION: The checkinstall script is modified to return error for missing pre-requisite packages only when base VxVM package is installed in the system. * 3851574 (Tracking ID: 1726349) SYMPTOM: In the CVM environment, the shared disk group creation may fail if a private disk group was previously created and destroyed using the same disks. The following error message is displayed: vxdg -s init VxVM vxdg ERROR V-5-1-585 Disk group : cannot create: Disk in use by another cluster DESCRIPTION: When a shared disk group is created, the disks are not compulsorily re-onlined on the slave node. As a result, if the in-core database of the slave node contains the stale disk information, the disk group creation may fail. The problem was observed when a private disk group was created on the master node and 'vxdisk scandisks' was performed on the slave node. Later, the private disk group was destroyed from the master node and a new shared disk group was created on the same disks. However, the disk group creation failed due to the stale disk information on the slave node. RESOLUTION: The code is modified to re-online the required disks on the slave node during the disk group creation. Patch ID: PHCO_44219 * 3597496 (Tracking ID: 2965910) SYMPTOM: Volume creation with the vxassist(1M) command dumps core when the non-disk parameters like enclosures are specified along with "-o ordered" option. The following stack trace is observed: setup_disk_order() volume_alloc_basic_setup() fill_volume() setup_new_volume() make_trans() vxvmutil_trans() trans() transaction() do_make() main() DESCRIPTION: When the volume creation triggers using the vxassist(1M) command with the "-o ordered" option, the vxassist(1M) command sets up the disk order, in order to allocate storage in the order that is specified by the vxassist(1M) command arguments. Before setting up the disk order, the vxassist(1M) command filters out all the non-disk parameters, in order to avoid mixing of the disk classes such as mediatype. As a result, valid parameters like controllers or enclosures are also filtered out. Due to this, invalid pointer gets accessed while setting up the disk order. This results in segfault. RESOLUTION: The code is modified to remove the filtering of the disk classes while setting up the disk order. The steps to use mediatype for ordered allocation have been documented in the tech-note: http://www.symantec.com/business/support/index?page=content&id=HOWTO107386 * 3674615 (Tracking ID: 3674614) SYMPTOM: Restarting the vxconfigd(1M) daemon on the slave (joiner) node, when the node- join operation is in progress, may cause the vxconfigd(1M) daemon to hang on the master and the joiner node. DESCRIPTION: When a node is in process of joining the cluster and due to some reason the vxconfigd(1M) daemon of this node is restarted, it may cause the vxconfigd(1M) daemon to hang on the master and the joiner node. When vxconfigd(1M) daemon is restarted in the middle of the node join process, it wrongly assumes that this is a slave rejoin case, and sets the rejoin flag. Because the rejoin flag is wrongly set, the import operation of the disk groups on the slave node fail, and the join process is not terminated smoothly. As a result, the vxconfigd(1M) daemon hangs on the master and the slave node. RESOLUTION: The code is modified to differentiate between the rejoin scenario and the vxconfigd(1M) daemon restart scenario. Patch ID: PHCO_44194 * 3519134 (Tracking ID: 3518470) SYMPTOM: The 'vxdg adddisk' command fails with following message: " previous removed using -k option" Even though the disk was not removed using the -k option. DESCRIPTION: This is a unique kind of setup where disk access (DA) names of one node are same as the DA names of the other physical devices on other node in Cluster Volume Manager (CVM). When the disk group that has one of the DA, and the master switch to the node that has the same DA name(different physical device) is not under any disk group, and the user tries to add the disk to the disk group the 'adddisk' operation fails. This occurs because one of the condition gets success, which is only a partial check to the scenario. That is the DA name matches with the last_da_name. As this condition is successful it returns the error message " previous removed using -k option. RESOLUTION: The code is modified to add another condition 'DA name should be null' along with the existing check. This resolves the issue at the time of the 'adddisk' operation. * 3612710 (Tracking ID: 2190632) SYMPTOM: High memory consumption is observed with the vxconfigd(1M) daemon when large number of events are generated. DESCRIPTION: Under certain conditions, large number of events can be generated for the vxconfigd clients. There is no limit on the number of event for clients at a time. This can result in high memory consumption of the vxconfigd(1M) daemon as the memory gets allocated for every event. RESOLUTION: The code is modified to limit the number of events for the client at a time. Patch ID: PHCO_44058 * 3249204 (Tracking ID: 3145359) SYMPTOM: On the IA architecture systems, the "vxres_lvmroot -v -b " command fails with the following error message: "ERROR V-5-2-4699 Error creating Physical Volume /dev/vx/rdmp/c#t#d#s2" DESCRIPTION: The vxres_lvmroot utility fails on the IA architecture for HP-UX 11.31 1003 update, because HPs pvcreate command fails to create LVM volumes on DMP DSFs for the 11.31 1003 OS release, and only allows it on the new NMP node. RESOLUTION: The code is modified to create the LVM physical volumes on the new NMP node, instead of the legacy DMP DSF. * 3387294 (Tracking ID: 2152830) SYMPTOM: A diskgroup (DG) import fails with a non-descriptive error message when multiple copies (clones) of the same device exist and the original devices are either offline or not available. For example: # vxdg import mydg VxVM vxdg ERROR V-5-1-10978 Disk group mydg: import failed: No valid disk found containing disk group DESCRIPTION: If the original devices are offline or unavailable, the vxdg(1M) command picks up cloned disks for import.DG import fails unless the clones are tagged and the tag is specified during the DG import. The import failure is expected, but the error message is non-descriptive and does not specify the corrective action to be taken by the user. RESOLUTION: The code is modified to give the correct error message when duplicate clones exist during import. Also, details of the duplicate clones are reported in the system log. * 3407766 (Tracking ID: 3263105) SYMPTOM: The disk evacuation operation (vxevac()) fails for a volume with Data Change Object (DCO). DESCRIPTION: During the vxevac() operation, all sub-disks of a volume that reside on the specified source disk are moved to the destination disk. As part of the disk evacuation of the volume, its corresponding Data Change Log volume's (DCL's) sub-disks are also moved. The vxevac() operation re-tries to move the sub-disks of the DCL volume. This fails because the sub-disks are already moved. RESOLUTION: The code is modified to exclude the DCL volumes, for which the disk evacuation is already completed as a part of the parent-volume-disk evacuation. * 3412839 (Tracking ID: 2515070) SYMPTOM: When the I/O fencing is enabled, the Cluster Volume Manager (CVM) slave node may fail to join the cluster node. The following error message is displayed: In Veritas Cluster Server(VCS) engine log: VCS ERROR V-16-20006-1005 (abc) CVMCluster:cvm_clus:monitor:node - state: out of cluster reason: SCSI-3 PR operation failed: retry to add a node failed In syslog: V-5-1-15908 Import failed for dg ebap01dg. Local node has data disk fencing enabled, but master does not have PGR key set DESCRIPTION: Whenever a fix transaction is performed during disk group (DG) import, the SCSI- 3 Persistent Group Reservation (PGR) key is not uploaded from "vxconfigd" to the kernel DG record. This leads to a NULL-PGR key in the kernel DG record. If subsequently, "vxconfigd" gets restarted, it reads the DG configuration record from the kernel. This leads to the PGR key being NULL in "vxconfigd" also. This configuration record is sent to the node, when it wants to join the cluster. The slave node fails to import the shared DG, because of the missing PGR key, and therefore it fails to join the cluster node. RESOLUTION: The code is modified to copy the disk group PGR key from "vxconfigd" to the kernel, when a new disk group record is loaded to the kernel. * 3482535 (Tracking ID: 3482001) SYMPTOM: The 'vxddladm addforeign' command renders the system unbootable, after the reboot, for a few cases. DESCRIPTION: As part of the execution of the 'vxddladm addforeign' command, VxVM incorrectly identifies the specified disk as the root disk. As a result, it replaces all the entries pertaining to the 'root disk', with the entries of the specified disk, thus rendering the system unbootable. RESOLUTION: The code is modified to detect the root disk appropriately when it is specified, as a part of the 'vxddladm addforeign' command. * 3500353 (Tracking ID: 3500350) SYMPTOM: An option is not available to identify if the disk group (DG) is imported using the CLONE flag or not, when the clone flag on the disk is reset using the command: vxdisk set clone=off DESCRIPTION: When all the disks in the DG are clone disks (udid_mismatch or clone_disk flag set) then the DG is imported using the "clone" flag and set the clone_disk flag on the disk. The clone flag can be cleared on the disk using the "vxdisk set" command. But the DG remains imported using the "clone" flag. Once the clone flag is reset on the disk, there is no option to determine if the DG is imported with the "clone" flag or not. This results in confusion. RESOLUTION: The code is modified so that the 'STATE' field of the "vxdg list" command displays the "clone" attribute if the disk group is imported using the '-o useclonedev=on' option. An example is as follows: # vxdg list NAME STATE ID enabled, cds, clone * 3507677 (Tracking ID: 3293139) SYMPTOM: The verifydco utility fails with the following error message: VxVM vxprint ERROR V-5-1-924 Record not found DESCRIPTION: If the name of the volume is not the prefix for the corresponding Data Change Object (DCO) volume, the name of the DCO volume cannot be obtained. This results in the failure. RESOLUTION: The code is modified to handle the conditions where the name of the volume is not the prefix for the corresponding DCO, and get the appropriate DCO volume name. * 3507679 (Tracking ID: 3455460) SYMPTOM: The vxfmrshowmap and verify_dco_header utilities fail with the following error message: vxfmrshowmap: VxVM ERROR V-5-1-15443 seek to for FAILED:Error 0 verify_dco_header: Cannot lseek to offset: DESCRIPTION: The issue occurs because the large offsets are not handled properly while seeking using 'lseek', as a part of the vxfmrshowmap and verify_dco_header utilities. RESOLUTION: The code is modified to properly handle large offsets as a part of the vxfmrhsowmap and verify_dco_header utilities. * 3524141 (Tracking ID: 3524139) SYMPTOM: The checkinstall script for the PHCO_43824 fails, in case of the combined installation of the patch and the dependent package, even when the dependent package has a value greater than or equal to 1311. The following message is displayed: ERROR: FC-TACHYON-TL.FC-TL-RUN, FC-FCLP.FC-FCLP-RUN, FC-FCOC.FC-FCOC-RUN, FC-FCQ.FC-FCQ-RUN filesets with revision B.11.31.1311 or Higher is required for VxVM to work correctly. DESCRIPTION: The checkinstall script checks for the list of filesets that have a version greater than or equal to 1311. An incorrect field filter is used at the time of extracting the version information from the dependent filesets. This leads to the installation failure. An example of the cut(1M) command is as following: "cut -d . -f 4" "FC-COMMON.FC-SNIA, r=B.11.31.1403" The cut command returns "31" instead of "1403" from the fileset. This leads to the installation failure. RESOLUTION: The code is modified to extract the field "5" by using the cut(1) command, instead of extracting the field "4", from the dependent filesets. An example of the cut(1) command executed is as following: "cut -d . -f 5" * 3527676 (Tracking ID: 3527674) SYMPTOM: After upgrading to 5.1SP1RP3P1, the vxconfigd(1M) daemon dumps core, because the UDID is not found for EMC LUNs. The following stack trace is observed: ddi_hash_devno() ddl_find_cdevno() ddl_find_disk_cdevno() daname_get() req_daname_get() request_loop() main() DESCRIPTION: The 5.1SP1RP3P1 patch release depends on the VRTSaslapm package with version 5.1.103.001 or above. This dependency is not followed. As a result, a list of disks are found uninitialized. The reason for un-initialization is the failure in the reconfiguration due to the change in the array type from 'CRL-ALUA' to 'ALUA' for Clariion array, while upgrading to 5.1SP1RP3P1. This causes the core dump. RESOLUTION: The code is modified to introduce the 'co-requisites VRTSaslapm.VXASLAPM- KRN, r>=5.1.103.001' on the VxVM patches. This allows patch installation only when the current VRTSaslapm is installed or is being installed on the system with version '5.1.103.001' or greater. Otherwise, the VxVM patch fails to install. * 3528614 (Tracking ID: 3461383) SYMPTOM: The vxrlink(1M) command fails, when the "vxrlink -g -a att " command is executed. On PA machines the following error message is displayed: VxVM VVR vxrlink ERROR V-5-1-5276 Cannot open shared library/usr/lib/libvrascmd.sl, error: Can't dlopen() a library containing Thread Local Storage: /usr/lib/libvrascmd.sl DESCRIPTION: To make "vxconfigd" and other VxVM binaries thread safe, these binaries are now linked with HP's thread safe "libIOmt" library. The vxrlink(1M) command opens a shared library, which is linked with the thread safe "libIOmt" library. There is a limitation onHP-UX, that a shared library that contains Thread Local Storage (TLS) cannot be loaded dynamically. This results in an error. RESOLUTION: The code is modified, so that the library that is dynamically loaded through the vxrlink(1M) command, is not linked with the "libIOmt" library, as the vxrlink(1M) command and the library do not invoke any routines from the "libIOmt" library. * 3596439 (Tracking ID: 3596425) SYMPTOM: While upgrading from HP-UX September 2010 release to OE containing PHCO_43824, following error may be seen in /var/adm/sw/swm.log file: * Running "checkinstall" for "PHCO_43824, r=1.0". NOTE: Command output: - /var/opt/swm/tmp/swmZ3Hj3uh/SDcat2tGfRnd/catalog/PHCO_43824/pfiles/checkinstall[8]: 1009 01: Syntax error ERROR: FC-COMMON.FC-SNIA filesets with revision B.11.31.1311 or Higher is required for VxVM to work correctly. ERROR: The "checkinstall" for "PHCO_43824, r=1.0" failed (exit code "1"). The script location was "/var/opt/swm/tmp/swmZ3Hj3uh/SDcat2tGfRnd/catalog/ PHCO_43824/pfiles/checkinstall". DESCRIPTION: The checkinstall script was wrongly parsing the revision string for FC-COMMON product which was resulting into this syntax error. RESOLUTION: The checkinstall script has been modified to correctly parse the revision string. Patch ID: PHCO_43824 * 2982085 (Tracking ID: 2976130) SYMPTOM: The device-discovery commands such as "vxdisk scandisks" and "vxdctl enable" may cause the entire DMP database to be deleted. This causes the VxVM I/O errors and file systems to get disabled. For instances where VxVM manages the root disk(s), a system hang occurs. In a Serviceguard/SGeRAC environment integrated with CVM and/or CFS, VxVM I/O failures would typically lead to a Serviceguard INIT and/or a CRS TOC (if the voting disks sit on VxVM volumes). Syslog shows the removal of arrays from the DMP database as following: vmunix: NOTICE: VxVM vxdmp V-5-0-0 removed disk array 000292601518, datype = EMC In addition to messages that indicate VxVM I/O errors and file systems are disabled. DESCRIPTION: VxVM's vxconfigd(1M) daemon uses HP's libIO(3X) APIs such as io_search() and io_search_array() functions to claim devices that are attached to the host. Although, vxconfigd(1M) is multithreaded, it uses a non-thread safe version of the libIO(3X) APIs. A race condition may occur when multiple vxconfigd threads perform device discovery. This results in a NULL value returned to the libIO (3X) APIs call.VxVM interprets the NULL return value as an indication of none of the devices being attached and proceeds to delete all the devices previously claimed from the DMP database. RESOLUTION: The vxconfigd(1M) daemon, as well as the event source daemon vxesd(1M), is now linked with HP's thread-safe libIO(3X) library. This prevents the race condition among multiple vxconfigd threads that perform device discovery. Please refer to HP's customer bulletin c03585923 for a list of other software components required for a complete * 3326516 (Tracking ID: 2665207) SYMPTOM: When a user tries to update the "udid" on a disk that is an imported disk group, no message is displayed to convey that the operation is not allowed. DESCRIPTION: The code exits without displaying the error message, and the user is unaware of the restriction imposed on an imported disk group. RESOLUTION: The code has been modified to display a message that conveys to the user that the operation is not allowed. The following error message is displayed: "VxVM vxdisk ERROR V-5-1-17080 The UDID for device emc0_0f36 cannot be updated because the disk is part of an imported diskgroup VxVM vxdisk INFO V-5-1-17079 If you require the UDID to be updated, please deport the diskgroup. The DDL and on-disk UDID content can be inspected by issuing the 'vxdisk -o udid list' command" Patch ID: PHCO_43526 * 2233987 (Tracking ID: 2233225) SYMPTOM: Growing a volume to more than a limit, the default being 1 GB does not synchronize plexes for the newly allocated regions of the volume. DESCRIPTION: There was a coding issue that skipped setting the hint to re-synchronize the plexes for certain scenarios. Any further reads on the newly allocated regions returns different results, this depends upon the plex that is considered for the read operation. RESOLUTION: The code is modified to set the re-synchronize hint correctly for any missed scenarios. * 2245645 (Tracking ID: 2255018) SYMPTOM: The vxplex(1M) command dumps core during the relayout operation from "concat" to RAID 5. The following stack trace is observed: _int_malloc () from /lib/libc.so.6 malloc () from /lib/libc.so.6 vxvmutil_xmalloc () xmalloc () raid5_clear_logs () do_att () main () DESCRIPTION: During the relayout operation when the vxplex(1M) utility builds the configuration, it retries the transaction. The transaction gets restarted. However, the cleanup is not done correctly before the restart. Thus, the vxplex (1M) command dumps core. RESOLUTION: The code is modified so that the proper cleanup is done before the transaction is restarted. * 2366130 (Tracking ID: 2270593) SYMPTOM: In a CVM environment, during the node join operation if the vxconfigd(1M) daemon on the master node is restarted, the shared disk groups may get disabled. The error is displayed in syslog is as following: "Error in cluster processing" DESCRIPTION: When the vxconfigd(1M) daemon is restarted on the CVM master, all the shared disk groups are re-imported. During this process, if a cluster reconfiguration happens and not all the slave nodes have re-established the connection to the master's vxconfigd, the re-import of the shared disk groups may fail with error, leaving the disk groups in the disabled state. RESOLUTION: The code is modified so that during the vxconfigd(1M) demon restart operation, if the re-import of the disk groups encounters the "Error in cluster processing" error, then the re-import operation of the disk group is deferred until all the slave nodes re-establish the connection to the master node. * 2437840 (Tracking ID: 2283588) SYMPTOM: The vxdisksetup (1M) command used for the initialization of the mirror on the root disk fails with the following error message on the IA machine: VxVM vxislvm ERROR V-5-1-2604 cannot open /dev/rdisk/disk*_p2 DESCRIPTION: The reported error occurs due to the unavailability of the OS disk-device node corresponding to the disk slice. The situation can occur when the Logical Volume Manager (LVM) rooted disk is copied as the VxVM rooted disk, using the vxcp_lvmroot(1M) command. Later, a root mirror is created using the vxrootmir (1M) command when the system is booted from the created VxVM rootdisk. The vxrootmir(1M) command is executed on the VxVM rooted disk. After creating slices for the target disk, the device-node files are created on the VxVM rooted disk. However, the OS on the LVM rooted disk is unaware of the newly created slices of the disk initialized during 'vxrootmir' on the VxVM rooted disk. Thus, the OS on the LVM rooted disk does not contain or create the device nodes for the new slices of the 'vxrootmir'ed 'disk. When booted from the LVM rooted disk, the vxdisksetup(1M) command uses the idisk(1M) command to detect if the disk is a sliced disk, and tries to access the corresponding slices through the OS device nodes. Assuming, that the device nodes are present. Thereby, an error is encountered. RESOLUTION: The code is modified such that the vxdisksetup(1M) command uses the DMP devices to access the disk slices. Since, DMP creates the device nodes by reading the disk format after the boot, the DMP disk nodes are always created for the disk slices. * 2567623 (Tracking ID: 2567618) SYMPTOM: The VRTSexplorer dumps core with the segmentation fault in checkhbaapi/print_target_map_entry. The stack trace is observed as follows: print_target_map_entry() check_hbaapi() main() _start() DESCRIPTION: The checkhbaapi utility uses the HBA_GetFcpTargetMapping() API which returns the current set of mappings between the OS and the Fiber Channel Protocol (FCP) devices for a given Host Bus Adapter (HBA) port. The maximum limit for mappings is set to 512 and only that much memory is allocated. When the number of mappings returned is greater than 512, the function that prints this information tries to access the entries beyond that limit, which results in core dumps. RESOLUTION: The code is modified to allocate enough memory for all the mappings returned by the HBA_GetFcpTargetMapping() API. * 2570739 (Tracking ID: 2497074) SYMPTOM: If the resize operation is performed on disks of size greater than 1 TB, the Cross Platform Data Sharing -Extensible Firmware Interface (CDS-EFI) disks and the "vxvol stop all" command is executed. The following error message is displayed: "VxVM vxvol ERROR V-5-1-10128 Configuration daemon error 441" DESCRIPTION: The issue is observed only on the CDS-EFI disks. The correct EFI flags are not set when the resize operation is in the commit phase. As a result, the disk offset which is 24 K for the CDS-EFI disks is not taken into account for the private region I/Os. The entire write I/Os are shifted to 24 K . This results in the private region corruption. RESOLUTION: The code is modified to set the required flags for the CDS-EFI disks. * 2703384 (Tracking ID: 2692012) SYMPTOM: When moving the subdisks by using the vxassist(1M) command or the vxevac(1M) command, if the disk tags are not the same for the source and the destination, the command fails with a generic error message. The error message does not provide the reason for the failure of the operation. The following error message is displayed: VxVM vxassist ERROR V-5-1-438 Cannot allocate space to replace subdisks DESCRIPTION: When moving the subdisks using the "vxassist move" command, if no target disk is specified, it uses the available disks from the disk group to move. If the disks have the site tag set and the value of the site- tag attribute is not the same, the subsequent move operation using the vxassist(1M) command is expected to fail. However, it fails with the generic message that does not provide the reason for the failure of the operation. RESOLUTION: The code is modified so that a new error message is introduced to specify that the disk failure is due to the mismatch in the site-tag attribute. The enhanced error message is as follows: VxVM vxassist ERROR V-5-1-0 Source and/or target disk belongs to site, can not move over sites * 2836974 (Tracking ID: 2743926) SYMPTOM: During the system boot, the DMP restore daemon fails to restart. The following error message is displayed: "VxVM vxdmpadm ERROR V-5-1-2111 Invalid argument". DESCRIPTION: During the system boot, 'vxvm-sysboot' performs the 'vxdmpadm stop restore' operation and then the 'vxdmpadm start restore' operation. Without the "/etc/vx/dmppolicy.info" file, this restart fails. As the file system is read only during the system boot, creation of the "/etc/vx/dmppolicy.info" file fails with the invalid return values. These invalid return values are used as arguments for starting the restore daemon. This results in the invalid argument error and the restore daemon fails to start. RESOLUTION: The code is modified to return the appropriate value so that the restore daemon is started with the default values. * 2847333 (Tracking ID: 2834046) SYMPTOM: Beginning from the 5.1 release, VxVM automatically reminors the disk group and its objects in certain cases, and displays the following error message: vxvm:vxconfigd: V-5-1-14563 Disk group mydg: base minor was in private pool, will be change to shared pool. NFS clients that attempt to reconnect to a file system on the disk group's volume fail because the file handle becomes stale. The NFS client needs to re- mount the file system and probably a reboot to clear this. The issue is observed under the following situations: aC/ When a private disk group is imported as shared, or a shared disk group is imported as private. aC/ After upgrading from a version of VxVM prior to 5.1 DESCRIPTION: Since the HxRT 5.1 SP1 release, the minor-number space is divided into two pools, one for the private disk groups and the other for the shared disk groups. During the disk group import operation, the disk group base- minor numbers are adjusted automatically, if not in the correct pool. In a similar manner, the volumes in the disk groups are also adjusted. This behavior reduces many minor conflicting cases during the disk group import operation. However, in the NFS environment, it makes all the file handles on the client side stale. Subsequently, customers had to unmount files systems and restart the applications. RESOLUTION: The code is modified to add a new tunable "autoreminor". The default value of the autoreminor tunable is "on". Use "vxdefault set autoreminor off" to turn it off for NFS server environments. If the NFS server is in a CVM cluster, make the same change on all the nodes. * 2851354 (Tracking ID: 2837717) SYMPTOM: The "vxdisk resize" command fails if 'da name' is specified. An example is as following: # vxdisk list eva4k6k1_46 | grep ^pub pubpaths: block=/dev/vx/dmp/eva4k6k1_46 char=/dev/vx/rdmp/eva4k6k1_46 public: slice=0 offset=32896 len=680736 disk_offset=0 # vxdisk resize eva4k6k1_46 length=813632 # vxdisk list eva4k6k1_46 | grep ^pub pubpaths: block=/dev/vx/dmp/eva4k6k1_46 char=/dev/vx/rdmp/eva4k6k1_46 public: slice=0 offset=32896 len=680736 disk_offset=0 After resize operation len=680736 is not changed. DESCRIPTION: The scenario for 'da name' is not handled in the resize code path. As a result, the "vxdisk(1M) resize" command fails if the 'da name' is specified. RESOLUTION: The code is modified such that if 'dm name' is not specified to resize, then only the 'da name' specific operation is performed. * 2881862 (Tracking ID: 2878876) SYMPTOM: The vxconfigd(1M) daemon dumps core with the following stack trace: vol_cbr_dolog () vol_cbr_translog () vold_preprocess_request () request_loop () main () DESCRIPTION: This core is a result of a race between the two threads which are processing the requests from the same client. While one thread completes processing a request and is in the phase of releasing the memory used, the other thread processes a "DISCONNECT" request from the same client. Due to the race condition, the second thread attempts to access the memory released and dumps core. RESOLUTION: The code is modified by protecting the common data of the client by a mutex. * 2883606 (Tracking ID: 2189812) SYMPTOM: When the 'vxdisk updateudid' command is executed on a disk which is in the 'online invalid' state, the vxconfigd(1M) daemon dumps core with the following stack trace: priv_join() req_disk_updateudid() request_loop() main() DESCRIPTION: When 'udid' is updated, the null check is not done for an internal data structure. As a result, the vxconfigd(1M) daemon dumps core. RESOLUTION: The code is modified to add null checks for the internal data structure. * 2916915 (Tracking ID: 2916911) SYMPTOM: The vxconfigd(1M) deamon triggered a Data TLB Fault panic with the following stack trace: _vol_dev_strategy volsp_strategy vol_dev_strategy voldiosio_start volkcontext_process volsiowait voldio vol_voldio_read volconfig_ioctl volsioctl_real volsioctl vols_ioctl spec_ioctl vno_ioctl ioctl syscall DESCRIPTION: The kernel_force_open_disk() function checks if the disk device is open. The device is opened only if not opened earlier. When the device is opened, it calls the kernel_disk_load() function which in-turn calls the VOL_NEW_DISK ioctl () function. If the VOL_NEW_DISK ioctl fails, the error is not handled correctly as the return values are not checked. This may result in a scenario where the open operation fails but the disk read or write operation proceeds. RESOLUTION: The code is modified to handle the VOL_NEW_DISK ioctl. If the ioctl fails during the open operation of the device that does not exist, then the read or write operations are not allowed on the disk. * 2919718 (Tracking ID: 2919714) SYMPTOM: On a thin Logical Unit Number (LUN), the vxevac(1M) command returns 0 without migrating the unmounted-VxFS volumes. The following error messages are displayed when the unmounted-VxFS volumes are processed: VxVM vxsd ERROR V-5-1-14671 Volume v2 is configured on THIN luns and not mounted. Use 'force' option, to bypass smartmove. To take advantage of smartmove for supporting thin luns, retry this operation after mounting the volume. VxVM vxsd ERROR V-5-1-407 Attempting to cleanup after failure ... DESCRIPTION: On a thin LUN, VxVM does not move or copy data on the unmounted-VxFS volumes unless the 'smartmove' is bypassed. The vxevac(1M) command error messages need to be enhanced to detect the unmounted-VxFS volumes on thin LUNs, and to support a 'force' option that allows the user to bypass the 'smartmove'. RESOLUTION: The vxevac script is modified to check for the unmounted-VxFS volumes on thin LUNs, before the migration is performed. If the unmounted-VxFS volume is detected, the vxevac(1M) command fails with a non-zero return code. Subsequently, a message is displayed that notifies the user to mount the volumes or bypass the 'smartmove' by specifying the 'force' option. The rectified error message is displayed as following: VxVM vxevac ERROR V-5-2-0 The following VxFS volume(s) are configured on THIN luns and not mounted: v2 To take advantage of smartmove support on thin luns, retry this operation after mounting the volume(s). Otherwise, bypass smartmove by specifying the '-f' force option. * 2946948 (Tracking ID: 2406096) SYMPTOM: The vxconfigd(1M) daemon dumps core with the following stack trace: vol_cbr_oplistfree() vol_clntaddop() vol_cbr_translog() vold_preprocess_request() request_loop() main() DESCRIPTION: The vxsnap utility forks a child process and the parent process exits. The child process continues the remaining work as the background process. It does not create a new connection with the vxconfigd (1M) daemon and continues to use the parents connection. Since the parent is dead, the vxconfigd(1M) daemon cleans up the client structure. Corresponding to further requests from the child process, the vxconfigd(1M) daemon tries to access the client structure that is already freed. As a result, the vxconfigd daemon dumps core. RESOLUTION: The code is modified by initiating a separate connection with the vxconfigd(1M) daemon from the forked child. * 2957608 (Tracking ID: 2671241) SYMPTOM: When the Dirty Region Logging (DRL) log plex is configured in a volume, the vxnotify(1M) command does not report the volume enabled message. DESCRIPTION: When the DRL log plex is configured in a volume, a two phase start of the volume is made. First plexes are started and the volume state is marked as DETACHED. In the second phase, after the log recovery, the volume state is marked as ENABLED. However, during the notification of the configuration change to the interested client, only the status change from DISABLED to ENABLED is checked. RESOLUTION: The code is modified to generate a notification on state change of a volume from any state to ENABLED and any state to DISABLED. * 2960650 (Tracking ID: 2932214) SYMPTOM: After the "vxdisk resize" operation is performed from less than 1 TB to greater than or equal to 1 TB on a disk with SIMPLE or SLICED format, that has the Sun Microsystems Incorporation (SMI) label, the disk enters the "online invalid" state. DESCRIPTION: VxVM code is not geared enough to resize the SIMPLE or SLICED disks beyond 1 TB. RESOLUTION: The code is modified to prevent the resize of the SIMPLE or SLICED disks with the SMI label from less than 1 TB to greater than or equal to 1 TB. * 2973632 (Tracking ID: 2973522) SYMPTOM: At cable connect on one of the ports of a dual-port Fibre Channel Host Bus Adapters (FC HBA), paths that go through the other port are marked as SUSPECT. DMP does not issue I/O on such paths until the next restore daemon cycle confirms that the paths are functioning. DESCRIPTION: When a cable is connected at one of the ports of a dual-port FC HBA, HBA- Registered State Change Notification (RSCN) event occurs on the other port. When the RSCN event occurs, DMP marks the paths as SUSPECT that goes through that port. RESOLUTION: The code is modified so that the RSCN events that goes through the other port are not marked as SUSPECT. * 2983901 (Tracking ID: 2907746) SYMPTOM: At device discovery, the vxconfigd(1M) daemon allocates file descriptors for open instances of "/dev/config", but does not always close them after use, this results in a file descriptor leak over time. DESCRIPTION: Before any API of the "libIO" library is called, the io_init() function needs to be called. This function opens the "/dev/config" device file. Each io_init() function call should be paired with the io_end() function call. This function closes the "/dev/config" device file. However, the io_end() function call is amiss at some places in the device discovery code path. As a result, the file descriptor leaks are observed with the device-discovery command of VxVM. RESOLUTION: The code is modified to pair each io_init() function call with the io_end() function call in every possible code path. * 2986939 (Tracking ID: 2530536) SYMPTOM: Disabling any path of the ASM disk causes multiple DMP reconfigurations. Multiple occurrences of the following messages are seen in the dmpevent log: Reconfiguration is in progress Reconfiguration has finished DESCRIPTION: After enabling/disabling any path/controller of the DMP node, the VxVM daemon processes events generated for that DMP node. If a DMP node is already online, the VxVM daemon avoids re-online. Otherwise, it tries to online the DMP node, four times with some delay. If all attempts to online the DMP node fails, the VxVM daemon fires `vxdisk scandisks` on all the paths of that DMP node. In case of the ASM disk, all attempts to online the DMP node fails, and so the VxVM daemon fires the 'vxdisk scandisks' on all the paths of the DMP node. This in turn results in the multiple DMP reconfigurations. RESOLUTION: The code is modified to skip the event processing of the ASM disks. * 2990730 (Tracking ID: 2970368) SYMPTOM: The SRDF-R2 WD (write-disabled) devices are shown in an error state and many enable and disable path messages that are generated in the "/etc/vx/dmpevents.log" file. DESCRIPTION: DMP driver disables the paths of the write-protected devices. Therefore, these devices are shown in an error state. The vxattachd(1M) daemon tries to online these devices and executes the partial-device discovery for these devices. As part of the partial-device discovery, enabling and disabling the paths of such write-protected devices, generates many path enable and disable messages in the "/etc/vx/dmpevents.log" file. RESOLUTION: The code is modified so that the paths of the write-protected devices in DMP are not disabled. * 3000033 (Tracking ID: 2631369) SYMPTOM: In a CVM environment, when the vxconfigd(1M) daemon is started in the single- threaded mode by specifying the "-x nothreads" option, a cluster reconfiguration such as a node join and VxVM operations on the shared disk group takes approximately five more minutes to complete, as compared to the multithreaded environment. DESCRIPTION: Each node in the cluster exchanges VxVM objects during cluster reconfiguration, and for certain VxVM operations. In the signal handler function of single threaded vxconfigd(1M) daemon, each nodes awaits for the maximum poll timeout value set within the code. RESOLUTION: The code is modified such that the signal-handler routines do not wait for the maximum timeout value, instead it return's immediately after the objects are received. * 3012938 (Tracking ID: 3012929) SYMPTOM: When a disk name is changed when a backup operation is in progress, the vxconfigbackup(1M) command gives the following error: VxVM vxdisk ERROR V-5-1-558 Disk : Disk not in the configuration VxVM vxconfigbackup WARNING V-5-2-3718 Unable to backup Binary diskgroup configuration for diskgroup . DESCRIPTION: If disk names change during the backup, the vxconfigbackup(1M) command does not detect and refresh the changed names and it tries to find the configuration database information from the old diskname. Consequently, the vxconfigbackup (1M) command displays an error message indicating that the old disk is not found in the configuration and it fails to take backup of the disk group configuration from the disk. RESOLUTION: The code is modified to ensure that the new disk names are updated and are used to find and backup the configuration copy from the disk. * 3041018 (Tracking ID: 3041014) SYMPTOM: Sometimes a "relayout" command may fail with following error messages with not much information: 1. VxVM vxassist ERROR V-5-1-15309 Cannot allocate 4294838912 blocks of disk space required by the relayout operation for column expansion: Not enough HDD devices that meet specification. VxVM vxassist ERROR V-5-1-4037 Relayout operation aborted. (7) 2. VxVM vxassist ERROR V-5-1-15312 Cannot allocate 644225664 blocks of disk space required for the relayout operation for temp space: Not enough HDD devices that meet specification. VxVM vxassist ERROR V-5-1-4037 Relayout operation aborted. (7) DESCRIPTION: In some executions of the vxrelayout(1M) command, the error messages do not provide sufficient information. For example, when enough space is not available, the vxrelayout(1M) command displays an error where it mentions less disk space available than required. Hence the "relayout" operation can still fail when the disk space is increased. RESOLUTION: The code is modified to display the correct space required for the "relayout" operation to complete successfully. * 3047474 (Tracking ID: 3047470) SYMPTOM: Cannot deport the disk group as the device "/dev/vx/esd" is not recreated on reboot with the latest major number. Consider the problem scenario as follows: The old device "/dev/vx/esd"has a major number which is now re-assigned to the "vol" driver. As the device "/dev/vx/esd" has same major number as that of the "vol" driver, it may disallow a disk group deport with the following message, until the vxesd(1M) daemon is stopped: "VxVM vxdg ERROR V-5-1-584 Disk group XXX: Some volumes in the disk group are in use" DESCRIPTION: If the device "/dev/vx/esd" is present in the system with an old major number, then the mknod(1M) command in the startup script fails to recreate the device with the new major number. This leads to change in the functionality. RESOLUTION: The code is modified to delete the device under "/dev/vx/esd," before the mknod (1M) command in the startup script, so that it gets recreated with the latest major number. * 3047803 (Tracking ID: 2969844) SYMPTOM: The DMP database gets destroyed if the discovery fails for some reason. "ddl.log shows numerous entries as follows: DESTROY_DMPNODE: 0x3000010 dmpnode is to be destroyed/freed DESTROY_DMPNODE: 0x3000d30 dmpnode is to be destroyed/freed Numerous vxio errors are seen in the syslog as all VxVM I/O's fail afterwards. DESCRIPTION: VxVM deletes the old device database before it makes the new device database. If the discovery process fails for some reason, this results in a null DMP database. RESOLUTION: The code is modified to take a backup of the old device database before doing the new discovery. Therefore, if the discovery fails we restore the old database and display the appropriate message on the console. * 3059145 (Tracking ID: 2979824) SYMPTOM: While excluding the controller using the vxdiskadm(1M) utility, the unintended paths get excluded DESCRIPTION: The issue occurs due to a logical error related to the grep command, when the hardware path of the controller to be retrieved is excluded. In some cases, the vxdiskadm(1M) utility takes the wrong hardware path for the controller that is excluded, and hence excludes unintended paths. Suppose there are two controllers viz. c189 and c18 and the controller c189 is listed above c18 in the command, and the controller c18 is excluded, then the hardware path of the controller c189 is passed to the function and hence it ends up excluding the wrong controller. RESOLUTION: The script is modified so that the vxdiskadm(1M) utility now takes the hardware path of the intended controller only, and the unintended paths do not get excluded. * 3077756 (Tracking ID: 3077582) SYMPTOM: A Veritas Volume Manager (VxVM) volume may become inaccessible causing any read/write to fail with the following error: # dd if=/dev/vx/dsk// of=/dev/null count=10 dd read error: No such device 0+0 records in 0+0 records out DESCRIPTION: If I/Os to the disks timeout due to some hardware failures like weak Storage Area Network (SAN) cable link or Host Bus Adapter (HBA) failure, VxVM assumes that disk is bad or slow and it sets failio flag on the disk. Because of this flag, all the subsequent I/Os fail with the 'No such device' error. RESOLUTION: The code is modified so that vxdisk now provides a way to clear the 'failio' flag. Use the vxkprint(1M) utility (under /etc/vx/diag.d) to check whether the 'failio' flag is set on the disks. To reset this flag, execute the 'vxdisk set failio=off' command, or deport and import the disk group that holds these disks. * 3083189 (Tracking ID: 3025713) SYMPTOM: In a VVR environment, VxVM "vxdg adddisk" and "vxdg rmdisk" commands take long time (approximately 90 seconds) to execute. DESCRIPTION: The VxVM commands on a VVR disk group does not complete until all the outstanding I/Os in that disk group are drained completely. If replication is active, the outstanding I/Os include network I/Os (the I/Os to be sent from the primary node to the secondary node). VxVM commands take a long time to complete as they wait for these network I/Os to drain or "rlink" to be disconnected. RESOLUTION: The code is modified such that, if there are outstanding network I/Os lying in the read-back pool, the 'rlink' is disconnected to allow the VxVM commands to complete. * 3087777 (Tracking ID: 3076093) SYMPTOM: The patch upgrade script "installrp" can panic the system while doing a patch upgrade. The panic stack trace looks is observed as following: devcclose spec_close vnop_close vno_close closef closefd fs_exit kexitx kexit DESCRIPTION: When an upgrade is performed, the VxVM device drivers are not loaded, but the patch-upgrade process tries to start or stop the eventsource (vxesd) daemon. This can result in a system panic. RESOLUTION: The code is modified so that the eventsource (vxesd) daemon does not start unless the VxVM device drivers are loaded. * 3100378 (Tracking ID: 2921147) SYMPTOM: The udid_mismatch flag is absent on a clone disk when source disk is unavailable. The 'vxdisk list' command does not show the udid_mismatch flag on a disk. This happens even when the 'vxdisk -o udid list' or 'vxdisk -v list diskname | grep udid' commands show different Device Discovery Layer (DDL) generated and private region unique identifier for disks (UDIDs). DESCRIPTION: When DDL generates the UDID and private region UDID of a disk do not match, Veritas Volume Manager (VxVM) sets the udid_mismatch flag on the disk. This flag is used to detect a disk as clone, which is marked with the clone-disk flag. The vxdisk (1M) utility is used to suppress the display of the udid_mismatch flag if the source Logical Unit Number (LUN) is unavailable on the same host. RESOLUTION: The vxdisk (1M) utility is modified to display the udid_mismatch flag, if it is set on the disk. Display of this flag is no longer suppressed, even when source LUN is unavailable on same host. * 3139302 (Tracking ID: 3139300) SYMPTOM: At device discovery, the vxconfigd(1M) daemon allocates memory but does not release it after use, causing a user memory leak. The Resident Memory Size (RSS) of the vxconfigd(1M) daemon thus keeps growing and may reach maxdsiz(5) in the extreme case that causes the vxconfigd(1M) daemon to abort. DESCRIPTION: At some places in the device discovery code path, the buffer is not freed. This results in memory leaks. RESOLUTION: The code is modified to free the buffers. * 3140407 (Tracking ID: 2959325) SYMPTOM: The vxconfigd(1M) daemon dumps core while performing the disk group move operation with the following stack trace: dg_trans_start () dg_configure_size () config_enable_copy () da_enable_copy () ncopy_set_disk () ncopy_set_group () ncopy_policy_some () ncopy_set_copies () dg_balance_copies_helper () dg_transfer_copies () in vold_dm_dis_da () in dg_move_complete () in req_dg_move () in request_loop () in main () DESCRIPTION: The core dump occurs when the disk group move operation tries to reduce the size of the configuration records in the disk group, when the size is large and the disk group move operation needs more space for the new- configrecord entries. Since, both the reduction of the size of configuration records (compaction) and the configuration change by disk group move operation cannot co-exist, this result in the core dump. RESOLUTION: The code is modified to make the compaction first before the configuration change by the disk group move operation. * 3140735 (Tracking ID: 2861011) SYMPTOM: The "vxdisk -g resize " command fails with an error for the Cross-platform Data Sharing(CDS) formatted disk. The error message is displayed as following: "VxVM vxdisk ERROR V-5-1-8643 Device : resize failed: One or more subdisks do not fit in pub reg" DESCRIPTION: During the resize operation, VxVM updates the VM disk's private region with the new public region size, which is evaluated based on the raw disk geometry. But for the CDS disks, the geometry information stored in the disk label is fabricated such that the cylinder size is aligned with 8KB. The resize failure occurs when there is a mismatch in the public region size obtained from the disk label, and that stored in the private region. RESOLUTION: The code is modified such the new public region size is now evaluated based on the fabricated geometry considering the 8 KB alignment for the CDS disks, so that it is consistent with the size obtained from the disk label. * 3142325 (Tracking ID: 3130353) SYMPTOM: Disabled and enabled path messages are displayed continuously on the console for the EMC NR (Not Ready) devices: I/O error occurred on Path hdisk139 belonging to Dmpnode emc1_1f2d Disabled Path hdisk139 belonging to Dmpnode emc1_1f2d due to path failure Enabled Path hdisk139 belonging to Dmpnode emc1_1f2d I/O error occurred on Path hdisk139 belonging to Dmpnode emc1_1f2d Disabled Path hdisk139 belonging to Dmpnode emc1_1f2d due to path failure DESCRIPTION: As part of the device discovery, DMP marks the paths belonging to the EMC NR devices as disabled, so that they are not used for I/O. However, the DMP- restore logic, which issues inquiry on the disabled path brings the NR device paths back to the enabled state. This cycle is repetitive, and as a result the disabled and enabled path messages are seen continuously on the console. RESOLUTION: The DMP code is modified to specially handle the EMC NR devices, so that they are not disabled/enabled repeatedly. This means that we are not just suppressing the messages, but we are also handling the devices in a different manner. * 3144794 (Tracking ID: 3136272) SYMPTOM: In a CVM environment, the disk group import operation with the "-o noreonline" option takes additional import time. DESCRIPTION: On a slave node when the clone disk group import is triggered by the master node, the "da re-online" takes place irrespective of the "-o noreonline" flag passed. This results in the additional import time. RESOLUTION: The code is modified to pass the hint to the slave node when the "-o noreonline" option is specified. Depending on the hint, the "da re-online" is either done or skipped. This avoids any additional import time. * 3158781 (Tracking ID: 2495338) SYMPTOM: Veritas Volume Manager (VxVM) disk initialization with hpdisk format fails with the following error: $vxdisksetup -ivf eva4k6k0_8 format=hpdisk privoffset=256 VxVM vxdisksetup ERROR V-5-2-2186 privoffset is incompatible with the hpdisk format. DESCRIPTION: VxVM imposes the limitation of private region offset as 128K or 256 sectors on non-boot(data) disks with the hpdisk format. RESOLUTION: The code is modified to relax the limitation to initialize a data disk with the hpdisk format with a fixed private region offset. The disks can now be initialized with a private region offset of 128K or greater. * 3158790 (Tracking ID: 2779580) SYMPTOM: In a Veritas Volume Replicator (VVR) environment, the secondary node gives the configuration error 'no Primary RVG' when the primary master node (default logowner ) is rebooted and the slave node becomes the new master node. DESCRIPTION: After the primary master node is rebooted, the new master node sends a 'handshake' request for the vradmind communication to the secondary node. As a part of the 'handshake' request, the secondary node deletes the old configuration including the 'Primary RVG'. During this phase, the secondary node receives the configuration update message from the primary node for the old configuration. The secondary node does not find the old 'Primary RVG' configuration for processing this message. Hence, it cannot proceed with the pending 'handshake' request. This results in a 'no Primary RVG' configuration error. RESOLUTION: The code is modified such that during the 'handshake' request phase, the configuration messages of the old 'Primary RVG' gets discarded. * 3158793 (Tracking ID: 2911040) SYMPTOM: The restore operation from a cascaded snapshot succeeds even when one of the source is inaccessible. Subsequently, if the primary volume is made accessible for the restore operation, the I/O operation may fail on the volume, as the source of the volume is inaccessible. Any deletion of the snapshot also fails due to the dependency of the primary volume on the snapshots. When the user tries to remove the snapshot using the "vxedit rm" command, the following error message is displayed: "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 the data for the regions on the primary volume that differ between the two volumes. If the snapshot itself depends on some other volume and that volume is not accessible, effectively the primary volume becomes inaccessible after the restore operation. For such instances, the snapshot cannot be deleted as the primary volume depends on it. RESOLUTION: The code is modified so that if a snapshot or any later cascaded snapshot is inaccessible, the restore operation from that snapshot is prevented. * 3158794 (Tracking ID: 1982965) SYMPTOM: The file system mount operation fails when the volume is resized and the volume has a link to the volume. The following error messages are displayed: # mount -V vxfs /dev/vx/dsk// UX:vxfs fsck: ERROR: V-3-26248: could not read from block offset devid/blknum . Device containing meta data may be missing in vset or device too big to be read on a 32 bit system. UX:vxfs fsck: ERROR: V-3-20694: cannot initialize aggregate file system check failure, aborting ... UX:vxfs mount: ERROR: V-3-26883: fsck log replay exits with 1 UX:vxfs mount: ERROR: V-3-26881: Cannot be mounted until it has been cleaned by fsck. Please run "fsck -V vxfs -y /dev/vx/dsk//"before mounting DESCRIPTION: The vxconfigd(1M) daemon stores disk access records based on the Dynamic Multi Pathing (DMP) names. If the vxdg(1M) command passes a name other than DMP name for the device, vxconfigd(1M) daemon cannot map it to a disk access record. As the vxconfigd(1M) daemon cannot locate a disk access record corresponding to passed input name from the vxdg(1M) command, it fails the import operation. RESOLUTION: The code is modified so that the vxdg(1M) command converts the input name to DMP name before passing it to the vxconfigd(1M) daemon for further processing. * 3158799 (Tracking ID: 2735364) SYMPTOM: The "clone_disk" disk flag attribute is not cleared when a cloned disk group is removed by the "vxdg destroy " command. DESCRIPTION: When a cloned disk group is removed by the "vxdg destroy " command, the Veritas Volume Manager (VxVM) "clone_disk" disk flag attribute is not cleared. The "clone_disk" disk flag attribute should be automatically turned off when the VxVM disk group is destroyed. RESOLUTION: The code is modified to turn off the "clone_disk" disk flag attribute when a cloned disk group is removed by the "vxdg destroy " command. * 3158800 (Tracking ID: 2886333) SYMPTOM: The vxdg(1M) join operation allows mixing of clone and non-clone disks in a disk group. The subsequent import of a new joined disk group fails. The following error message is displayed: "VxVM vxdg ERROR V-5-1-17090 Source disk group tdg and destination disk group tdg2 are not homogeneous, trying to Mix of cloned diskgroup to standard disk group or vice versa is not allowed. Please follow the vxdg (1M) man page." DESCRIPTION: Mixing of the clone and non-clone disk group is not allowed. The part of the code where the join operation is performed, executes the operation without validating the mix of the clone and the non-clone disk groups. This results in the newly joined disk group having a mix of the clone and non-clone disks. Subsequent import of the newly joined disk group fails. RESOLUTION: The code is modified so that during the disk group join operation, both the disk groups are checked. If a mix of clone and non-clone disk group is found, the join operation is aborted. * 3158802 (Tracking ID: 2091520) SYMPTOM: Customers cannot selectively disable VxVM configuration copies on the disks associated with a disk group. DESCRIPTION: An enhancement is required to enable customers to selectively disable VxVM configuration copies on disks associated with a disk group. RESOLUTION: The code is modified to provide a "keepmeta=skip" option to the vxdiskset(1M) command to allow a customer to selectively disable VxVM configuration copies on disks that are a part of the disk group. * 3158804 (Tracking ID: 2236443) SYMPTOM: In a VCS environment, the "vxdg import" command does not display an informative error message, when a disk group cannot be imported because the fencing keys are registered to another host. The following error messages are displayed: # vxdg import sharedg VxVM vxdg ERROR V-5-1-10978 Disk group sharedg: import failed: No valid disk found containing disk group The system log contained the following NOTICE messages: Dec 18 09:32:37 htdb1 vxdmp: NOTICE: VxVM vxdmp V-5-0-0 i/o error occured (errno=0x5) on dmpnode 316/0x19b Dec 18 09:32:37 htdb1 vxdmp: [ID 443116 kern.notice] NOTICE: VxVM vxdmp V-5-0-0 i/o error occured (errno=0x5) on dmpnode 316/0x19b DESCRIPTION: The error messages that are displayed when a disk group cannot be imported because the fencing keys are registered to another host, needs to be more informative. RESOLUTION: The code has been added to the VxVM disk group import command to detect when a disk is reserved by another host, and issue a SCSI3 PR reservation conflict error message. * 3158809 (Tracking ID: 2969335) SYMPTOM: The node that leaves the cluster node while the instant operation is in progress, hangs in the kernel and cannot join to the cluster node unless it is rebooted. The following stack trace is displayed in the kernel, on the node that leaves the cluster: voldrl_clear_30() vol_mv_unlink() vol_objlist_free_objects() voldg_delete_finish() volcvmdg_abort_complete() volcvm_abort_sio_start() voliod_iohandle() voliod_loop() DESCRIPTION: In a clustered environment, during any instant snapshot operation such as the snapshot refresh/restore/reattach operation that requires metadata modification, the I/O activity on volumes involved in the operation is temporarily blocked, and once the metadata modification is complete the I/Os are resumed. During this phase if a node leaves the cluster, it does not find itself in the I/O hold-off state and cannot properly complete the leave operation and hangs. An after effect of this is that the node will not be able to join to the cluster node. RESOLUTION: The code is modified to properly unblock I/Os on the node that leaves. This avoids the hang. * 3158813 (Tracking ID: 2845383) SYMPTOM: The site gets detached if the plex detach operation is performed with the site consistency set to off. DESCRIPTION: If the plex detach operation is performed on the last complete plex of a site, the site is detached to maintain the site consistency. The site should be detached only if the site consistency is set. Initially, the decision to detach the site is made based on the value of the 'allsites' flag. So, the site gets detached when the last complete plex is detached, even if the site consistency is off. RESOLUTION: The code is modified to ensure that the site is detached when the last complete plex is detached, only if the site consistency is set. If the site consistency is off and the 'allsites' flag is on, detaching the last complete plex leads to the plex being detached. * 3158818 (Tracking ID: 2909668) SYMPTOM: In case of multiple sets of the cloned disks of the same source disk group, the import operation on the second set of the clone disk fails, if the first set of the clone disks were imported with "updateid". Import fails with following error message: VxVM vxdg ERROR V-5-1-10978 Disk group firstdg: import failed: No tagname disks for import DESCRIPTION: When multiple sets of the clone disk exists for the same source disk group, each set needs to be identified with the separate tags. If one set of the cloned disk with the same tag is imported using the "updateid" option, it replaces the disk group ID on the imported disk with the new disk group ID. The other set of the cloned disk with the different tag contains the disk group ID. This leads to the import failure for the tagged import for the other sets, except for the first set. Because the disk group name maps to the latest imported disk group ID. RESOLUTION: The code is modified in case of the tagged disk group import for disk groups that have multiple sets of the clone disks. The tag name is given higher priority than the latest update time of the disk group, during the disk group name to disk group ID mapping. * 3164583 (Tracking ID: 3065072) SYMPTOM: Data loss occurs during the import of a clone disk group, when some of the disks are missing and the import "useclonedev" and "updateid" options are specified. The following error message is displayed: VxVM vxdg ERROR V-5-1-10978 Disk group pdg: import failed: Disk for disk group not found DESCRIPTION: During the clone disk group import if the "updateid" and "useclonedev" options are specified and some disks are unavailable, this causes the permanent data loss. Disk group Id is updated on the available disks during the import operation. The missing disks contain the old disk group Id, hence are not included in the later attempts to import the disk group with the new disk group Id. RESOLUTION: The code is modified such that any partial import of the clone disk group with the "updateid" option will no longer be allowed without the "f" (force) option. If the user forces the partial import of the clone disk group using the "f" option, the missing disks are not included in the later attempts to import the clone disk group with the new disk group Id. * 3164601 (Tracking ID: 2957555) SYMPTOM: The vxconfigd(1M) daemon on the CVM master node hangs in the userland during the vxsnap(1M) restore operation. The following stack trace is displayed: rec_find_rid() position_in_restore_chain() kernel_set_object_vol() kernel_set_object() kernel_dg_commit_kernel_objects_20() kernel_dg_commit() commit() dg_trans_commit() slave_trans_commit() slave_response() fillnextreq() DESCRIPTION: During the snapshot restore operation, when the volume V1 gets restored from the source volume V2, and at the same time if the volume V2 gets restored from V1 or the child of V1 , the vxconfigd(1M) daemon tries to find the position of the volume that gets restored in the snapshot chain. For such instances, finding the position in the restore chain, causes the vxconfigd(1M) daemon to enter in an infinite loop and hangs. RESOLUTION: The code is modified to remove the infinite loop condition when the restore position is found. * 3164613 (Tracking ID: 2814891) SYMPTOM: The vxconfigrestore(1M) utility utility does not work properly if SCSI page 83 inquiry returns more than one FPCH name identifier for a single LUN. The restoration fails with the following error message: /etc/vx/bin/vxconfigrestore[1606]: shift: 4: bad number expr: syntax error expr: syntax error .. .. Installing volume manager disk header for 17 ... VxVM vxdisk ERROR V-5-1-558 Disk 17: Disk not in the configuration 17 disk format has been changed from cdsdisk to . VxVM vxdisk ERROR V-5-1-5433 Device 17: init failed: Device path not valid DESCRIPTION: The vxconfigrestore(1M) utility is used to restore a disk group's configuration information if it is lost or is corrupted. This operation should pick up the same LUNs that were used during the vxconfigbackup(1M) utility to save the configuration. If the SCSI-page-83 inquiry returns more than one FPCH-name identifier for a single LUN, the vxconfigrestore(1M) utility picks up the wrong LUN. So, the recovery may fail or succeed with the incorrect LUNs. RESOLUTION: The code is modified to pick up the correct LUN even when the SCSI-page-83 inquiry returns more than one identifier. * 3164615 (Tracking ID: 3102114) SYMPTOM: System crash during the 'vxsnap restore' operation can cause the vxconfigd(1M) daemon to dump core with the following stack on system start-up: rinfolist_iter() process_log_entry() scan_disk_logs() ... startup() main() DESCRIPTION: To recover from an incomplete restore operation, an entry is made in the internal logs. If the corresponding volume to that entry is not accessible, accessing a non-existent record causes the vxconfigd(1M) daemon to dump core with the SIGSEGV signal. RESOLUTION: The code is modified to ignore such an entry in the internal logs, if the corresponding volume does not exist. * 3164617 (Tracking ID: 2938710) SYMPTOM: The vxassist(1M) command dumps core with the following stack during the relayout operation: relayout_build_unused_volume () relayout_trans () vxvmutil_trans () trans () transaction () do_relayout () main () DESCRIPTION: During the relayout operation, the vxassist(1M) command sends a request to the vxconfigd(1M) daemon to get the object record of the volume. If the request fails, the vxassist(1M) command tries to print the error message using the name of the object from the record retrieved. This causes a NULL pointer de- reference and subsequently dumps core. RESOLUTION: The code is modified to print the error message using the name of the object from a known reference. * 3164619 (Tracking ID: 2866059) SYMPTOM: When disk-resize operation fails, the error messages displayed do not give the exact details of the failure. The following error messages are displayed: 1. "VxVM vxdisk ERROR V-5-1-8643 Device : resize failed: One or more subdisks do not fit in pub reg" 2. "VxVM vxdisk ERROR V-5-1-8643 Device : resize failed: Cannot remove last disk in disk group" DESCRIPTION: When a disk-resize operation fails, both the error messages need to be enhanced to display the exact details of the failure. RESOLUTION: The code is modified to improve the error messages. Error message (1) is modified to: VxVM vxdisk ERROR V-5-1-8643 Device emc_clariion0_338: resize failed: One or more subdisks do not fit in pub region. vxconfigd log : 01/16 02:23:23: VxVM vxconfigd DEBUG V-5-1-0 dasup_resize_check: SD emc_clariion0_338-01 not contained in disk sd: start=0 end=819200, public: offset=0 len=786560 Error message (2) is modified to: VxVM vxdisk ERROR V-5-1-0 Device emc_clariion0_338: resize failed: Cannot remove last disk in disk group. Resizing this device can result in data loss. Use -f option to force resize. * 3164620 (Tracking ID: 2993667) SYMPTOM: VxVM allows setting the Cross-platform Data Sharing (CDS) attribute for a disk group even when a disk is missing, because it experienced I/O errors. The following command succeeds even with an inaccessible disk: vxdg -g set cds=on DESCRIPTION: When the CDS attribute is set for a disk group, VxVM does not fail the operation if some disk is not accessible. If the disk genuinely had an I/O error and fails, VxVM does not allow setting the disk group as CDS, because the state of the failed disk cannot be determined. If a disk had a non-CDS format and fails with all the other disks in the disk group with the CDS format, this allows the disk group to be set as CDS. If the disk returns and the disk group is re-imported, there could be a CDS disk group that has a non-CDS disk. This violates the basic definition of the CDS disk group and results in the data corruption. RESOLUTION: The code is modified such that VxVM fails to set the CDS attribute for a disk group, if it detects a failed disk inaccessible because of an I/O error. Hence, the below operation would fail with an error as follows: # vxdg -g set cds=on Cannot enable CDS because device corresponding to is in-accessible. * 3164626 (Tracking ID: 3067784) SYMPTOM: The grow and shrink operations by the vxresize(1M) utility may dump core in the vfprintf() function.The following stack trace is observed: vfprintf () volumivpfmt () volvpfmt () volpfmt () main () DESCRIPTION: The vfprintf() function dumps core as the format specified to print the file system type is incorrect. The integer/ hexadecimal value is printed as a string, using the %s. RESOLUTION: The code is modified to print the file system type as the hexadecimal value, using the %x. * 3164627 (Tracking ID: 2787908) SYMPTOM: The vxconfigd(1M) daemon dumps core when the slave node joins the CVM cluster. The following stack trace is displayed: client_delete master_delete_client master_leavers role_assume vold_set_new_role kernel_get_cvminfo cluster_check vold_check_signal request_loop main _start DESCRIPTION: When the slave node joins the CVM cluster, the vxconfigd(1M) daemon frees a memory structure that is already freed and dumps core. RESOLUTION: The code is modified to ensure that the client memory structure is not freed twice. * 3164628 (Tracking ID: 2952553) SYMPTOM: The vxsnap(1M) command allows refreshing a snapshot from a different volume other than the source volume. An example is as follows: # vxsnap refresh source= DESCRIPTION: The vxsnap(1M) command allows refreshing a snapshot from a different volume other than the source volume. This can result in an unintended loss of the snapshot. RESOLUTION: The code is modified to print the message requesting the user to use the "-f" option. This prevents any accidental loss of the snapshot. * 3164631 (Tracking ID: 2933688) SYMPTOM: When the 'Data corruption protection' check is activated by DMP, the device- discovery operation aborts, but the I/O to the affected devices continues, this results in the data corruption. The message is displayed as following: Data Corruption Protection Activated - User Corrective Action Needed: To recover, first ensure that the OS device tree is up to date (requires OS specific commands). Then, execute 'vxdisk rm' on the following devices before reinitiating device discovery using 'vxdisk scandisks' DESCRIPTION: When 'Data corruption protection' check is activated by DMP, the device- discovery operation aborts after displaying a message. However, the device- discovery operation does not stop I/Os from being issued on the DMP device on the affected devices, for all those devices whose discovery information changed unexpectedly and are no longer valid. RESOLUTION: The code is modified so that DMP is changed to forcibly fail the I/Os on devices whose discovery information is changed unexpectedly. This prevents any further damage to the data. * 3164633 (Tracking ID: 3022689) SYMPTOM: The vxbrk_rootmir(1M) utility succeeds with an error printed on the command line, but disks that are a part of the break-off DG which are under NMP, now come under DMP as the "/etc/vx/darecs" file is not correctly updated. DESCRIPTION: The vxbrk_rootmir(1M) utility uses a hard-coded path "/dev/rdsk" and expects the DMP node to be available. This is done to get the new name corresponding to the input name. With the EBN name as the input, the vxbrk_rootmir(1M) utility does not find the OS new node and displays the error message. RESOLUTION: The code is modified such that the vxbrk_roomir(1M) utility does not use the hard-coded path to get the new node from the DMP input name. * 3164639 (Tracking ID: 2898324) SYMPTOM: Set of memory-leak issues in the user-land daemon "vradmind" that are reported by the Purify tool. DESCRIPTION: The issue is reported due to the improper/no initialization of the allocated memory. RESOLUTION: The code is modified to ensure that the proper initialization is done for the allocated memory. * 3164643 (Tracking ID: 2815441) SYMPTOM: The file system mount operation fails when the volume is resized and the volume has a link to the volume. The following error messages are displayed: # mount -V vxfs /dev/vx/dsk// UX:vxfs fsck: ERROR: V-3-26248: could not read from block offset devid/blknum . Device containing meta data may be missing in vset or device too big to be read on a 32 bit system. UX:vxfs fsck: ERROR: V-3-20694: cannot initialize aggregate file system check failure, aborting ... UX:vxfs mount: ERROR: V-3-26883: fsck log replay exits with 1 UX:vxfs mount: ERROR: V-3-26881: Cannot be mounted until it has been cleaned by fsck. Please run "fsck -V vxfs -y /dev/vx/dsk//"before mounting DESCRIPTION: The resize operation of the link volumes can be interrupted and restarted by the vxrecover(1M) command . The recover operation is triggered when the disk recovers from the failure or during the cluster reconfigurations. If the resize and the recover operation are run in parallel, and there are mirrors in link- to, the volume-recovery offset does not get updated properly for the linked volume. RESOLUTION: The code is modified to grow the "linked from" volume if we see that the volume sizes for "linked to" and "linked from" volumes are not the same when the vxrecover(1M) command is run. Accordingly, update the volume recovery offset for "linked to" volumes properly. * 3164645 (Tracking ID: 3091916) SYMPTOM: In VCS cluster environment, the syslog overflows with following the Small Computer System Interface (SCSI) I/O error messages: reservation conflict Unhandled error code Result: hostbyte=DID_OK driverbyte=DRIVER_OK CDB: Write(10): 2a 00 00 00 00 90 00 00 08 00 reservation conflict VxVM vxdmp V-5-0-0 [Error] i/o error occurred (errno=0x5) on dmpnode 201/0x60 Buffer I/O error on device VxDMP7, logical block 18 lost page write due to I/O error on VxDMP7 DESCRIPTION: In VCS cluster environment when the private disk group is flushed and deported on one node, some I/Os on the disk are cached as the disk writes are done asynchronously. Importing the disk group immediately ater with PGR keys causes I/O errors on the previous node as the PGR keys are not reserved on that node. RESOLUTION: The code is modified to write the I/Os synchronously on the disk. * 3164759 (Tracking ID: 2635640) SYMPTOM: The "vxdisksetup(1M) -ifB" command fails on the Enclosure Based Naming (EBN) devices when the legacy tree is removed. The following error message is displayed: "idisk: Stat of disk failed(2)" DESCRIPTION: The implementation of the function to get the unsliced path, returns the legacy tree based path if the input parameter does not specify the full device path. This leads to further failures when any direct or indirect use of the function is performed. RESOLUTION: The code is modified such that the function returns the DMP based path when the input parameter does not specify the full device path. * 3164790 (Tracking ID: 2959333) SYMPTOM: For Cross-platform Data Sharing (CDS) disk group, the "vxdg list" command does not list the CDS flag when that disk group is disabled. DESCRIPTION: When the CDS disk group is disabled, the state of the record list may not be stable. Hence, it is not considered if disabled disk group was CDS. As a result, Veritas Volume Manager (VxVM) does not mark any such flag. RESOLUTION: The code is modified to display the CDS flag for disabled CDS disk groups. * 3164874 (Tracking ID: 2986596) SYMPTOM: The disk groups imported with mix of standard and clone Logical Unit Numbers (LUNs) may lead to data corruption. DESCRIPTION: The vxdg(1M) command import operation should not allow mixing of clone and non- clone LUNs since it may result in data corruption if the clone copy is not up- to-date. vxdg(1M) import code was going ahead with clone LUNs when corresponding standard LUNs were unavailable on the same host. RESOLUTION: The code is modified for the vxdg(1M) command import operation, so that it does not pick up the clone disks in above case and prevent mix disk group import. The import fails if partial import is not allowed based on other options specified during the import. * 3164880 (Tracking ID: 3031796) SYMPTOM: When a snapshot is reattached using the "vxsnap reattach" command-line- interface (CLI), the operation fails with the following error message: "VxVM vxplex ERROR V-5-1-6616 Internal error in get object. Rec " DESCRIPTION: When a snapshot is reattached to the volume, the volume manager checks the consistency by locking all the related snapshots. If any related snapshots are not available the operation fails. RESOLUTION: The code is modified to ignore any inaccessible snapshot. This prevents any inconsistency during the operation. * 3164881 (Tracking ID: 2919720) SYMPTOM: The vxconfigd(1M) daemon dumps core in the rec_lock1_5() function. The following stack trace is observed: rec_lock1_5() rec_lock1() rec_lock() client_trans_start() req_vol_trans() request_loop() main() DESCRIPTION: During any configuration changes in VxVM, the vxconfigd(1M) command locks all the objects involved in the operations to avoid any unexpected modification. Some objects which do not belong to the current transactions are not handled properly. This results in a core dump. This case is particularly observed during the snapshot operations of the cross disk group linked-volume snapshots. RESOLUTION: The code is modified to avoid the locking of the records which are not yet a part of the committed VxVM configuration. * 3164883 (Tracking ID: 2933476) SYMPTOM: The vxdisk(1M) command resize operation fails with the following generic error messages that do not state the exact reason for the failure: VxVM vxdisk ERROR V-5-1-8643 Device 3pardata0_3649: resize failed: Operation is not supported. DESCRIPTION: The disk-resize operation fails in in the following cases: 1. When shared disk has simple or nopriv format. 2. When GPT (GUID Partition Table) labeled disk has simple or sliced format. 3. When the Cross-platform Data Sharing (CDS) disk is part of the disk group which has version less than 160 and disk resize is done to greater than 1 TB size. RESOLUTION: The code is modified to enhance disk resize failure messages. * 3164911 (Tracking ID: 1901838) SYMPTOM: After installation of a license key that enables multi-pathing, the state of the controller is shown as DISABLED in the command- line-interface (CLI) output for the vxdmpadm(1M) command. DESCRIPTION: When the multi-pathing license key is installed, the state of the active paths of the Logical Unit Number (LUN) is changed to the ENABLED state. However, the state of the controller is not updated. As a result, the state of the controller is shown as DISABLED in the CLI output for the vxdmpadm(1M) command. RESOLUTION: The code is modified so that the states of the controller and the active LUN paths are updated when the multi-pathing license key is installed. * 3164916 (Tracking ID: 1973983) SYMPTOM: Relocation fails with the following error when the Data Change Object (DCO) plex is in a disabled state: VxVM vxrelocd ERROR V-5-2-600 Failure recovering in disk group DESCRIPTION: When a mirror-plex is added to a volume using the "vxassist snapstart" command, the attached DCO plex can be in DISABLED or DCOSNP state. If the enclosure is disabled while recovering such DCO plexes, the plex can get in to the DETACHED/DCOSNP state. This can result in relocation failures. RESOLUTION: The code is modified to handle the DCO plexes in disabled state during relocation. * 3181315 (Tracking ID: 2898547) SYMPTOM: The 'vradmind' process dumps core on the Veritas Volume Replicator (VVR) secondary site in a Clustered Volume Replicator (CVR) environment. The stack trace would look like: __kernel_vsyscall raise abort fmemopen malloc_consolidate delete delete[] IpmHandle::~IpmHandle IpmHandle::events main DESCRIPTION: When log owner service group is moved across the nodes on the primary site, it induces the deletion of IpmHandle of the old log owner node, as the IpmHandle of the new log owner node gets created. During the destruction of IpmHandle object, a pointer '_cur_rbufp' is not set to NULL, which can lead to freeing up of memory which is already freed. This causes 'vradmind' to dump core. RESOLUTION: The code is modified for the destructor of IpmHandle to set the pointer to NULL after it is deleted. * 3182750 (Tracking ID: 2257733) SYMPTOM: At device discovery, the vxconfigd(1M) daemon allocates memory but does not release it after use, causing a user memory leak. The Resident Memory Size (RSS) of the vxconfigd(1M) daemon thus keeps growing and may reach maxdsiz(5) in the extreme case that causes the vxconfigd(1M) daemon to abort. DESCRIPTION: At some places in the device discovery code path, the buffer is not freed. This results in memory leaks. RESOLUTION: The code is modified to free the buffers. * 3189869 (Tracking ID: 2959733) SYMPTOM: When the device paths are moved across LUNs or enclosures, the vxconfigd(1M) daemon can dump core, or the data corruption can occur due to the internal data structure inconsistencies. The following stack trace is observed: ddl_reconfig_partial () ddl_reconfigure_all () ddl_find_devices_in_system () find_devices_in_system () req_discover_disks () request_loop () main () DESCRIPTION: When the device path configuration is changed after a planned or unplanned disconnection by moving only a subset of the device paths across LUNs or the other storage arrays (enclosures), DMP's internal data structure is inconsistent. This causes the vxconfigd(1M) daemon to dump core. Also, for some instances the data corruption occurs due to the incorrect LUN to the path mappings. RESOLUTION: The vxconfigd(1M) code is modified to detect such situations gracefully and modify the internal data structures accordingly, to avoid a vxconfigd(1M) daemon core dump and the data corruption. * 3238094 (Tracking ID: 3243355) SYMPTOM: The vxres_lvmroot(1M) utility which restores the Logical Volume Manager (LVM) root disk from the VxVM root disk fails with the following error message: VxVM vxres_lvmroot ERROR V-5-2-2493 Extending X MB LV for vg00 DESCRIPTION: When the LVM root disk is restored from the VxVM root disk, the 'vxres_lvmroot' creates the Logical Volumes (LVs) based on the Physical Extent (PEs) of the size that corresponds to the VxVM volume. If the volume size is less than the PE size, the vxres_lvmroot(1M) utility creates LV of the size 0, this fails the entire restoration command. RESOLUTION: The code is modified such that the vxres_lvmroot(1M) utility creates the LVs of at least the PE size, if the corresponding volume size is smaller than that of the PE size. * 3240788 (Tracking ID: 3158323) SYMPTOM: In a VVR environment, with multiple secondaries, if SRL overflows for rlinks at different times, it may result in the vxconfigd(1M) daemon to hang on the primary node. The stack trace observed is as following: vol_commit_iowait_objects() vol_commit_iolock_objects() vol_ktrans_commit() volconfig_ioctl() volsioctl_real() volsioctl() vols_ioctl() DESCRIPTION: When the first rlink tries to go into the DCM log mode, the transaction is timed out waiting for the NIO drain. The transaction is retried but it gets timed out. The Network I/O (NIO) drain does not happen because VVR dropped the acknowledgements while in the transaction mode. This results in the vxconfigd (1M) daemon hang. RESOLUTION: The code is modified to accept the acknowledgement even during the transaction phase. * 3242839 (Tracking ID: 3194358) SYMPTOM: Continuous I/O error messages on OS device and DMP node can be seen in the syslog associated with the EMC Symmetrix not-ready (NR) Logical units. DESCRIPTION: VxVM tries to online the EMC not-ready (NR) logical units. As part of the disk online process, it tries to read the disk label from the logical unit. Because the logical unit is NR the I/O fails. The failure messages are displayed in the syslog file. RESOLUTION: The code is modified to skip the disk online for the EMC NR LUNs. * 3245608 (Tracking ID: 3261485) SYMPTOM: The vxcdsconvert(1M) utility fails with following error messages: VxVM vxcdsconvert ERROR V-5-2-2777 : Unable to initialize the disk as a CDS disk VxVM vxcdsconvert ERROR V-5-2-2780 : Unable to move volume off of the disk VxVM vxcdsconvert ERROR V-5-2-3120 Conversion process aborted DESCRIPTION: As part of the conversion process, the vxcdsconvert(1M) utility moves all the volumes to some other disk, before the disk is initialized with the CDS format. On the VxVM formatted disks apart from the CDS format, the VxVM volume starts immediately in the PUBLIC partition. If LVM or FS was stamped on the disk, even after the data migration to some other disk within the disk group, this signature is not erased. As part of the vxcdsconvert operation, when the disk is destroyed, only the SLICED tags are erased but the partition table still exists. The disk is then recognized to have a file system or LVM on the partition where the PUBLIC region existed earlier. The vxcdsconvert(1M) utility fails because the vxdisksetup which is invoked internally to initialize the disk with the CDS format, prevents the disk initialization for any foreign FS or LVM. RESOLUTION: The code is modified so that the vxcdsconvert(1M) utility forcefully invokes the vxdisksetup(1M) command to erase any foreign format. * 3247983 (Tracking ID: 3248281) SYMPTOM: When the "vxdisk scandisks" or "vxdctl enable" commands are run consecutively, an error is displayed as following: VxVM vxdisk ERROR V-5-1-0 Device discovery failed. DESCRIPTION: The device discovery failure occurs because in some cases the variable that is passed to the OS specific function is not set properly. RESOLUTION: The code is modified to set the correct variable before the variable is passed to the OS specific function. * 3253306 (Tracking ID: 2876256) SYMPTOM: The "vxdisk set mediatype" command fails with the new naming scheme. The following error message is displayed: "VxVM vxdisk ERROR V-5-1-12952 Device not in configuration or associated with DG " For example, the "vxdisk set mediatype" command fails when the naming scheme is set to "new" instead of being set as "vxdisk set mediatype". DESCRIPTION: When the vxdisk(1M) command to set the media type is run on the newly named disk it fails. The case to handle the scenario to get the corresponding 'da name' of the 'new name' is not handled. RESOLUTION: The code is modified so that if the 'new name' is not found, then the corresponding 'da name' in the 'set media type' code path is retrieved. * 3256806 (Tracking ID: 3259926) SYMPTOM: The vxdmpadm(1M) command fails to enable the paths when the '-f' option is provided. The following error message is displayed: "VxVM vxdmpadm ERROR V-5-1-2395 Invalid arguments" DESCRIPTION: When the '-f' option is provided, the "vxdmpadm enable" command displays an error message, and fails to enable the paths that were disabled previously. This occurs because the improper argument value is passed to the respective function. RESOLUTION: The code is modified so that the "vxdmpadm enable" command successfully enables the paths when the '-f' option is provided. Patch ID: PHCO_43295 * 3057916 (Tracking ID: 3056311) SYMPTOM: Following problems can be seen on disks initialized with 5.1SP1 listener and which are being used for older releases like 4.1, 5.0, 5.0.1: 1. Creation of a volume failed on a disk indicating in-sufficient space available. 2. Data corruption seen. CDS backup label signature seen within PUBLIC region data. 3. Disks greater than 1TB in size will appear "online invalid" after on older releases. DESCRIPTION: VxVM listener can be used to initialize Boot disks and Data disks which can be used with older VxVM releases. Eg: 5.1SP1 Listener can be used to initialize disks which can be used with all previous VxVM releases like 5.0.1, 5.0, 4.1 etc. With 5.1SP1 onwards VxVM always uses Fabricated geometry while initializing disk with CDS format. Older releases like 4.1, 5.0, 5.0.1 use Raw geometry. These releases do not honor LABEL geometry. Hence, if a disk was initialized through 5.1SP1 listener, disk would be stamped with Fabricated geometry. When such a disk was used with older VxVM releases like 5.0.1, 5.0, 4.1, there can be a mismatch between the stamped geometry (Fabricated) and in-memory geometry (Raw). If on-disk cylinder size < in-memory cylinder size, we might encounter data corruption issues. To prevent any data corruption issues, we need to initialize disks through listener with older CDS format by using raw geometry. Also, if disk size is >= 1TB, 5.1SP1 VxVM will initialize the disk with CDS EFI format. Older releases like 4.1, 5.0, 5.0.1 etc. do not understand EFI format. RESOLUTION: From releases 5.1SP1 onwards, through HP-UX listener, disk to be used for older releases like 4.1, 5.0, 5.0.1 will be initialized with raw geometry. Also, initialization of disk through HPUX listener whose size is greater than 1TB will fail. * 3175698 (Tracking ID: 3175778) SYMPTOM: Provide support for VxVM 5.1SP1 Ignite-UX integration. DESCRIPTION: The new support is added to the "VxVM listener" binary to work with the raw geometry changes along with the support for VxVM 5.1SP1 Ignite-UX integration. RESOLUTION: The new support is added to the "VxVM listener" binary. what(1) string for the new version of "VxVM listener" is "1.33" Patch ID: PHCO_43065 * 2070079 (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. * 2205574 (Tracking ID: 1291519) SYMPTOM: After two VVR migrate operations, vrstat command does not output any statistics. DESCRIPTION: Migrate operation results in RDS (Replicated Data Set) information getting updated on both primary and secondary side vradmind. After multiple migrate operations, stale handle to older RDS is used by vrstat to retrieve statistics resulting in the failure. RESOLUTION: Necessary code changes have being made to ensure correct and updated RDS handle is used by vrstat to retrieve statistics. * 2427560 (Tracking ID: 2425259) SYMPTOM: vxdg join operation fails throwing error "join failed : Invalid attribute specification". DESCRIPTION: For the disk name containing "/" character e. g. cciss/c0d1, join operation fails to parse the name of disks and hence returns with error. RESOLUTION: Code changes are made to handle special characters in disk name. * 2442751 (Tracking ID: 2104887) SYMPTOM: vxdg import fails with following ERROR message for cloned device import, when original diskgroup is already imported with same DGID. # vxdg -Cfn clonedg -o useclonedev=on -o tag=tag1 import testdg VxVM vxdg ERROR V-5-1-10978 Disk group testdg: import failed: Disk group exists and is imported DESCRIPTION: In case of clone device import, vxdg import without "-o updateid" option fails, if original DG is already imported. The error message returned may be interpreted as diskgroup with same name is imported, while actually the dgid is duplicated and not the dgname. RESOLUTION: vxdg utility is modified to return better error message for cloned DG import. It directs you to get details from system log. Details of conflicting dgid and suggestion to use "-o updateid" are added in the system log. * 2442827 (Tracking ID: 2149922) SYMPTOM: Record the diskgroup import and deport events in the /var/adm/syslog/syslog.log 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. * 2485261 (Tracking ID: 2354046) SYMPTOM: dgcfgrestore man page examples are incorrect. DESCRIPTION: Example 1: Restore the VxVM configuration information for the VxVM disk disk01 on the replacement disk device c0t7d0 that was part of the single-disk disk group onediskdg using the default configuration file /etc/vxvmconf/dg00.conf: ## Restore configuration data # dgcfgrestore -n onediskdg c0t7d0 The last step of this example will not work. If we create disk group with same name then the default configuration file /etc/vxvmconf/.conf is moved to etc/vxvmconf/.conf.old and new configuration is written to default configuration file. The -n option will read configuration from default configuration file and dgcfgrestore will fail. Example 2: The final example restores the VxVM configuration information for the VxVM disk, disk01 for failed disk device c0t2d0, which was part of a single-disk disk group, foodg, to disk, c0t3d0. The default configuration file, /etc/vxvmconf/foodg.conf is used. # Initialize c0t3d0 for use by VxVM /etc/vx/bin/vxdisketup -i c0t3d0 # Create disk group using this disk vxdg init onediskdg disk01=c0t3d0 # Restore configuration data dgcfgrestore -n foodg -o c0t3d0 c0t2d0 In this example to restore configuration of foodg on replacement disk we need to create new disk group with same name i.e. foodg. " -o" option refers to old disk media name. In the last step -o option is used with new disk media name so dgcfgrestore will fail. RESOLUTION: This document defect is addressed by document change. For Example 1, -f option is used to read disk group configuration from /etc/vxvmconf/.conf.old file. For Example 2, new disk group name is changed to foodg and -o option is used with old disk media name. * 2492568 (Tracking ID: 2441937) SYMPTOM: vxconfigrestore(1M) command fails with the following error... "The source line number is 1. awk: Input line 22 | cannot be longer than 3, 000 bytes." DESCRIPTION: In the function where we read the disk attributes from backup, we are getting the disk attributes in the variable "$disk_attr". The value of this variable "$disk_attr" comes out to be a line longer than 3000 bytes. Later this variable "$disk_attr" is used by awk(1) command to parse it and hits the awk(1) limitation of 3000 bytes. RESOLUTION: The code is modified to replace awk(1) command with cut(1) command which does not have this limitation. * 2495590 (Tracking ID: 2492451) SYMPTOM: If the Veritas Volume Manager (VxVM) is not configured, the following messages are observed in syslog file: vxesd[1554]: Event Source daemon started vxesd[1554]: HBA API Library Loaded vxesd[1554]: Registration with DMP failed DESCRIPTION: The presence of "/etc/vx/reconfig.d/state.d/install-db" file indicates that VxVM is not configured. The startup script "/sbin/init.d/vxvm-startup2" does not check the presence of install-db file and starts the vxesd(1M) daemon. RESOLUTION: The code has been modified to check the presence of install-db file and start vxesd(1M) daemon accordingly. * 2513457 (Tracking ID: 2495351) SYMPTOM: VxVMconvert utility was incompatible to migrate data across platforms from native LVM configurations. DESCRIPTION: VxVMconvert used for migration of customer data did not take into consideration varied LVM configuration scenarios that hindered its ability to do successful conversion. For example, HPUX Volume Group with large number of Logical and Physical Volumes requires significant metadata size to be stored on the disk for successful conversion. However VxVMconvert failed to calculate metadata size based on the configuration rather created static and lesser sizes thereby leading to failure in migration of data. RESOLUTION: Enhanced VxVMconvert utility to handle different LVM configuration scenarios to migrate data across platforms. * 2515137 (Tracking ID: 2513101) SYMPTOM: When VxVM is upgraded from 4.1MP4RP2 to 5.1SP1RP1, the data on CDS disk gets corrupted. DESCRIPTION: When CDS disks are initialized with VxVM version 4.1MP4RP2, the number of cylinders are calculated based on the disk raw geometry. If the calculated number of cylinders exceed Solaris VTOC limit (65535), because of unsigned integer overflow, truncated value of number of cylinders gets written in CDS label. After the VxVM is upgraded to 5.1SP1RP1, CDS label gets wrongly written in the public region leading to the data corruption. RESOLUTION: The code changes are made to suitably adjust the number of tracks & heads so that the calculated number of cylinders be within Solaris VTOC limit. * 2560539 (Tracking ID: 2252680) SYMPTOM: When a paused VxVM (Veritas Volume Manager task) is aborted using 'vxtask abort' command, it does not get aborted appropriately. It continues to show up in the output of 'vxtask list' command and the corresponding process does not get killed. DESCRIPTION: As appropriate signal is not sent to the paused VxVM task which is being aborted, it fails to abort and continues to show up in the output of 'vxtask list' command. Also, its corresponding process does not get killed. RESOLUTION: Code changes are done to send an appropriate signal to paused tasks to abort them. * 2567623 (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(). * 2576605 (Tracking ID: 2576602) SYMPTOM: listtag option for vxdg command gives results even when executed with wrong syntax. DESCRIPTION: The correct syntax, as per vxdg help, is "vxdg listtag [diskgroup ...]". However, when executed with the wrong syntax, "vxdg [-g diskgroup] listtag", it still give results. RESOLUTION: Please use the correct syntax as per help for vxdg command. The command has being modified from 6.0 release onwards to display error and usage message when wrong syntax is used. * 2626742 (Tracking ID: 2626741) SYMPTOM: Vxassist when used with "-o ordered " and "mediatype:hdd" during striped volume make operation does not maintain disk order. DESCRIPTION: Vxassist when invoked with "-o ordered" and "mediatype:hdd" options while creating a striped volume, does not maintain the disk order provided by the user. First stripe of the volume should correspond to the first disk provided by the user. RESOLUTION: Rectified code to use the disks as per the user specified disk order. * 2626745 (Tracking ID: 2626199) SYMPTOM: "vxdmpadm list dmpnode" command shows the path-type value as "primary/secondary" for a LUN in an Active-Active array as below when it is suppose to be NULL value. dmpdev = c6t0d3 state = enabled ... array-type = A/A ###path = name state type transport ctlr hwpath aportID aportWWN attr path = c23t0d3 enabled(a) secondary FC c30 2/0/0/2/0/0/0.0x50060e800 5c0bb00 - - - DESCRIPTION: For a LUN under Active-Active array the path-type value is supposed to be NULL. In this specific case other commands like "vxdmpadm getsubpaths dmpnode=<>" were showing correct (NULL) value for path-type. RESOLUTION: The "vxdmpadm list dmpnode" code path failed to initialize the path-type variable and by default set path-type to "primary or secondary" even for Active-Active array LUN's. This is fixed by initializing the path-type variable to NULL. * 2627000 (Tracking ID: 2578336) SYMPTOM: I/O error is encountered while accessing the cdsdisk. DESCRIPTION: This issue is seen only on defective cdsdisks, where s2 partition size in sector 0 label is less than sum of public region offset and public region length. RESOLUTION: A solution has been implemented to rectify defective cdsdisk at the time the cdsdisk is onlined. * 2627004 (Tracking ID: 2413763) SYMPTOM: vxconfigd, the VxVM daemon dumps core with the following stack: ddl_fill_dmp_info ddl_init_dmp_tree ddl_fetch_dmp_tree ddl_find_devices_in_system find_devices_in_system mode_set setup_mode startup main __libc_start_main _start DESCRIPTION: Dynamic Multi Pathing node buffer declared in the Device Discovery Layer was not initialized. Since the node buffer is local to the function, an explicit initialization is required before copying another buffer into it. RESOLUTION: The node buffer is appropriately initialized using memset() to address the coredump. * 2641932 (Tracking ID: 2348199) SYMPTOM: vxconfigd dumps core during Disk Group import with the following function call stack strcmp+0x60 () da_find_diskid+0x300 () dm_get_da+0x250 () ssb_check_disks+0x8c0 () dg_import_start+0x4e50 () dg_reimport+0x6c0 () dg_recover_all+0x710 () mode_set+0x1770 () setup_mode+0x50 () startup+0xca0 () main+0x3ca0 () DESCRIPTION: During Disk Group import, vxconfigd performs certain validations on the disks. During one such validation, it iterates through the list of available disk access records to find a match with a given disk media record. It does a string comparison of the disk IDs in the two records to find a match. Under certain conditions, the disk ID for a disk access record may have a NULL value. vxconfigd dumps core when it passes this to strcmp() function. RESOLUTION: Code was modified to check for disk access records with NULL value and skip them from disk ID comparison. * 2646417 (Tracking ID: 2556781) SYMPTOM: In cluster environment, importing a disk group which is imported on another node will result in wrong error messages like given below: VxVM vxdg ERROR V-5-1-10978 Disk group : import failed: Disk is in use by another host DESCRIPTION: When VxVM is translating a given disk group name to disk group id during the disk group import process, an error return indicating that the disk group is in use by another host may be overwritten by a wrong error. RESOLUTION: The source code has been changed to handle the return value in a correct way. * 2652161 (Tracking ID: 2647975) SYMPTOM: Serial Split Brain (SSB) condition caused Cluster Volume Manager(CVM) Master Takeover to fail. The below vxconfigd debug output was noticed when the issue was noticed: VxVM vxconfigd NOTICE V-5-1-7899 CVM_VOLD_CHANGE command received V-5-1-0 Preempting CM NID 1 VxVM vxconfigd NOTICE V-5-1-9576 Split Brain. da id is 0.5, while dm id is 0.4 for dm cvmdgA-01 VxVM vxconfigd WARNING V-5-1-8060 master: could not delete shared disk groups VxVM vxconfigd ERROR V-5-1-7934 Disk group cvmdgA: Disabled by errors VxVM vxconfigd ERROR V-5-1-7934 Disk group cvmdgB: Disabled by errors ... VxVM vxconfigd ERROR V-5-1-11467 kernel_fail_join() : Reconfiguration interrupted: Reason is transition to role failed (12, 1) VxVM vxconfigd NOTICE V-5-1-7901 CVM_VOLD_STOP command received DESCRIPTION: When Serial Split Brain (SSB) condition is detected by the new CVM master, on Veritas Volume Manager (VxVM) versions 5.0 and 5.1, the default CVM behaviour will cause the new CVM master to leave the cluster and causes cluster-wide downtime. RESOLUTION: Necessary code changes have been done to ensure that when SSB is detected in a diskgroup, CVM will only disable that particular diskgroup and keep the other diskgroups imported during the CVM Master Takeover, the new CVM master will not leave the cluster with the fix applied. * 2677025 (Tracking ID: 2677016) SYMPTOM: Veritas Event Manager(vxesd(1M)) daemon dumps core when main thread tries to close one of its thread (which hold connection with HP Event Manager). The stack trace of main thread will be as follows: _evmmiscFree+0 () from /usr/lib/hpux32/libevm.so EvmConnDestroy+0x150 () from /usr/lib/hpux32/libevm.so volhp_evm_stop+0x30 () register_evm_events+0x60 () DESCRIPTION: When main thread of vxesd encounters an error in processing client requests, it starts closing others threads. But when it starts closing EVM thread, main thread destroys the connection used by EVM thread and if there is a context switch at this point to EVM thread, there is a chance of vxesd dumping core. RESOLUTION: Code changes have been done to ensure that EVM thread destroy its connection rather than main thread doing it. * 2690959 (Tracking ID: 2688308) SYMPTOM: When re-import of a disk group fails during master takeover, it makes all the shared disk groups to be disabled. It also results in the corresponding node (new master) leaving the cluster. DESCRIPTION: In cluster volume manager when master goes down, the upcoming master tries to re-import the disk group. If some error occurs while re-importing the disk group then it disables all the shared disk groups and the new master leaves the cluster. This may result in cluster outage. RESOLUTION: Code changes are made to disable the disk group on which error occurred while re-importing and continue import of the other shared disk groups. * 2695231 (Tracking ID: 2689845) SYMPTOM: Disks are seen in error state. hitachi_usp-vm0_11 auto - - error DESCRIPTION: When data at the end of the first sector of the disk is same as MBR signature, Volume Manager misinterprets the data disk as MBR disk. Accordingly, partitions are determined but format determination fails for these fake partitions and disk goes into error state. RESOLUTION: Code changes are made to check the status field of the disk along with the MBR signature. Valid status fields for MBR disk are 0x00 and 0x80. * 2705101 (Tracking ID: 2216951) SYMPTOM: The vxconfigd daemon core dumps in the chosen_rlist_delete() function and the following stack trace is displayed: chosen_rlist_delete() req_dg_import_disk_names() request_loop() main() DESCRIPTION: The vxconfigd daemon core dumps when it accesses a NULL pointer in the chosen_rlist_delete() function. RESOLUTION: The code is modified to handle the NULL pointer in the chosen_rlist_delete() function * 2706024 (Tracking ID: 2664825) SYMPTOM: The following two issues are seen when a cloned disk group having a mixture of disks which are clones of disks initialized under VxVM version 4.x and 5.x is imported. (i) The following error will be seen without "-o useclonedev=on -o updateid" options on 5.x environment with the import failure. # vxdg -Cf import VxVM vxdg ERROR Disk group : import failed: Disk group has no valid configuration copies (ii) The following warning will be seen with "-o useclonedev=on -o updateid" options on 5.x environment with the import success. # vxdg -Cf -o useclonedev=on -o updateid import VxVM vxdg WARNING Disk : Not found, last known location: ... DESCRIPTION: The vxconfigd, a VxVM daemon, imports a disk group having disks where all the disks should be either cloned or standard(non-clone). If the disk group has a mixture of cloned and standard devices, and user attempts to import the disk group - (i) without "-o useclonedev=on" options, only standard disks are considered for import. The import would fail if none of the standard disks have a valid configuration copy. (ii) with "-o useclonedev=on" option, the import would succeed, but the standard disks go missing because only clone disks are considered for import. A disk which is initialized in the VxVM version earlier to 5.x has no concept of Unique Disk Identifier(UDID) which helps to identify the cloned disk. It could not be flagged as cloned disk even if it is indeed a cloned disk. This results in the issues (i) and (ii). RESOLUTION: The source code is modified to set the appropriate flags so that the disks initialized in VxVM 4.X will be recognized as "cloned", and both of the issues (i) and (ii) will be avoided. * 2706038 (Tracking ID: 2516584) SYMPTOM: There are many random directories not cleaned up in /tmp/, like vx.$RANDOM.$RANDOM.$RANDOM.$$ on system startup. DESCRIPTION: In general the startup scripts should call quit(), in which it call do the cleanup when errors detected. The scripts were calling exit() directly instead of quit() leaving some random-created directories uncleaned. RESOLUTION: These script should be restored to call quit() instead of exit() directly. * 2737373 (Tracking ID: 2556467) SYMPTOM: When dmp_native_support is enabled, ASM (Automatic Storage Management) disks are disconnected from host and host is rebooted, user defined user-group ownership of respective DMP (Dynamic Multipathing) devices is lost and ownership is set to default values. DESCRIPTION: The user-group ownership records of DMP devices in /etc/vx/.vxdmprawdev file are refreshed at the time of boot and only the records of currently available devices are retained. As part of refresh, records of all the disconnected ASM disks are removed from /etc/vx/.vxdmpraw and hence set to default value. RESOLUTION: Made code changes so that the file /etc/vx/.vxdmprawdev will not be refreshed at boot time. * 2747340 (Tracking ID: 2739709) SYMPTOM: While rebuilding disk group, maker file generated from "vxprint - dmvpshrcCx -D -" command does not have the links between volumes and vset. Hence, rebuild of disk group fails. DESCRIPTION: File generated by the "vxprint -dmvpshrcCx -D -" command does not have the link between volumes and vset(volume set) due to which diskgroup rebuilding fails. RESOLUTION: Code changes are done to maintain the link between volumes and vsets. * 2759895 (Tracking ID: 2753954) SYMPTOM: When cable is disconnected from one port of a dual-port FC HBA, only paths going through the port should be marked as SUSPECT. But paths going through other port are also getting marked as SUSPECT. DESCRIPTION: Disconnection of a cable from a HBA port generates a FC event. When the event is generated, paths of all ports of the corresponding HBA are marked as SUSPECT. RESOLUTION: The code changes are done to mark the paths only going through the port on which FC event is generated. * 2763211 (Tracking ID: 2763206) SYMPTOM: vxdisk rm dumps core with following stack trace vfprintf volumivpfmt volpfmt do_rm DESCRIPTION: While copying the disk name of very large length array bound checking is not done which causes buffer overflow. Segmentation fault occurs while accessing corrupted memory, terminating "vxdisk rm" process. RESOLUTION: Code changes are done to do array bound checking to avoid such buffer overflow issues. * 2768492 (Tracking ID: 2277558) SYMPTOM: vxassist outputs an error message while doing snapshot related operations. The message looks like : "VxVM VVR vxassist ERROR V-5-1-10127 getting associations of rvg : Property not found in the list" DESCRIPTION: The error message is being displayed incorrectly. There is an error condition which is getting masked by a previously occurred error which vxassist chose to ignore, and went ahead with the operation. RESOLUTION: Fix has been added to reset previously occurred error which has been ignored, so that the real error is displayed by vxassist. * 2802370 (Tracking ID: 2585239) SYMPTOM: On a setup with tape devices, the VxVM commands like "vxdisk -o alldgs list" run very slow. DESCRIPTION: On a setup with tape devices, vxesd invokes HBA API even for tape devices in /dev/rtape directory, which slows down the system. RESOLUTION: Call HBA API only for /dev/[r]disk or /dev/[r]dsk devices. * 2804911 (Tracking ID: 2637217) SYMPTOM: The storage allocation attributes 'pridiskname' and 'secdiskname' are not documented in the vradmin man page for resizevol/resizesrl. DESCRIPTION: The 'pridiskname' and 'secdiskname' are optional arguments to the vradmin resizevol and vradmin resizesrl commands, which enable users to specify a comma- separated list of disk names for the resize operation on a VVR data volume and SRL, respectively. These arguments were introduced in 5.1SP1, but were not documented in the vradmin man page. RESOLUTION: The vradmin man page has been updated to document the storage allocation attributes 'pridiskname' and 'secdiskname' for the vradmin resizevol and vradmin resizesrl commands. * 2821143 (Tracking ID: 1431223) SYMPTOM: "vradmin syncvol" and "vradmin syncrvg" commands do not work if the remote diskgroup and vset names are specified when synchronizing vsets. DESCRIPTION: When command "vradmin syncvol" or "vradmin syncrvg" for vset is executed, vset is expanded to its component volumes and path is generated for each component volume. But when remote vset names are specified on command line, it fails to expand remote component volumes correctly. Synchronization will fail because of incorrect path for volumes. RESOLUTION: Code changes have been made to ensure remote vset is expanded correctly when specified on command line. * 2821452 (Tracking ID: 2495332) SYMPTOM: vxcdsconvert(1M) fails if private region length is less than 1MB and it is a single sub-disk spanning the entire disk with following error: # vxcdsconvert -g alldisks evac_subdisks_ok=yes VxVM vxprint ERROR V-5-1-924 Record not found VxVM vxprint ERROR V-5-1-924 Record not found VxVM vxcdsconvert ERROR V-5-2-3174 Internal Error VxVM vxcdsconvert ERROR V-5-2-3120 Conversion process aborted DESCRIPTION: If non-cds disk private region length is less than 1MB, vxcdsconvert internally tries to relocate subdisks at the start to create room for the private region of 1MB. To make room for back-up labels, vxcdsconvert tries to relocate subdisks at the end of the disk. Two entries, one for relocation at the start and one at the end are created during the analysis phase. Once the first sub-disk is relocated, next vxprint operation fails as the sub-disk has already been evacuated to another DM(disk media record). RESOLUTION: This problem is fixed by allowing generation of multiple relocation entries for same subdisk. Later if the sub-disk is found to be already evacuated to other DM, relocation is skipped for the subdisk with same name. * 2821515 (Tracking ID: 2617277) SYMPTOM: Man pages missing for the vxautoanalysis and vxautoconvert commands. DESCRIPTION: The man pages for the vxautoanalysis and vxautoconvert commands are missing from the base package. RESOLUTION: Added the man pages for vxautoanalysis(1M) and vxautoconvert(1M) commands. * 2821537 (Tracking ID: 2792748) SYMPTOM: In an HPUX cluster environment, the slave join fails with the following error message in syslog: VxVM vxconfigd ERROR V-5-1-5784 cluster_establish:kernel interrupted vold on overlapping reconfig. DESCRIPTION: During the join, the slave node performs disk group import. As part of the import, the file descriptor pertaining to "Port u" is closed because of a wrong assignment of the return value of open(). Hence, the subsequent write to the same port was returning EBADF. RESOLUTION: Code changes are done to avoid closing the wrong file descriptor * 2821678 (Tracking ID: 2389554) SYMPTOM: The vxdg command of VxVM (Veritas Volume Manager) located at /usr/sbin directory shows incorrect message for ssb (Serial Split Brain) information of a disk group. The ssb information uses "DISK PRIVATE PATH" as an item, but the content is public path of some disk. The ssb information also prints unknown characters to represent the config copy id of a disk if the disk's config copies are all disabled. Moreover, there is some redundant information in the output messages. "DISK PRIVATE PATH" error is like this: $ vxdisk list ... pubpaths: block=/dev/vx/dmp/s4 char=/dev/vx/rdmp/s4 privpaths: block=/dev/vx/dmp/s3 char=/dev/vx/rdmp/s3 ... $ vxsplitlines -v -g mydg ... Pool 0 DEVICE DISK DISK ID DISK PRIVATE PATH /dev/vx/rdmp/s4 Unknown character error message is like this: $ vxdg import ... To import the diskgroup with config copy from the second pool issue the command /usr/sbin/vxdg [-s] -o selectcp= import ... DESCRIPTION: VxVM uses a SSB data structure to maintain ssb information displayed to the user. The SSB data structure contains some members, such as Pool ID, config copy id, etc. After memory allocation for a SSB data structure, this new allocated memory area is not initialized. If all the config copies of some disk are disabled, then the config copy id member has unknwon data. vxdg command will try to print such data, then unknown characters are displayed to the stdout. The SSB data structure has "disk public path" member, but no "disk private path" member. So the output message can only display public path of a disk. RESOLUTION: The ssb structure has been changed to use "disk private path" instead of "disk public path". Moreover, after memory allocation for a ssb structure, newly allocated memory is properly initialized. * 2826129 (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 was made to handle the same process id situation correctly. * 2826607 (Tracking ID: 1675482) SYMPTOM: vxdg list command shows configuration copy in new failed state. # vxdg list dgname config disk 3PARDATA0_75 copy 1 len=48144 state=new failed config-tid=0.1550 pending-tid=0.1551 Error: error=Volume error 0 DESCRIPTION: When a configuration copy is initialized on a new disk in a diskgroup, an IO error on the disk can prevent on-disk update and make configuration copy in- consistent. RESOLUTION: In case of a failed initialization, configuration copy is disabled. If required in future, this disabled copy will be reused for setting up a new configuration copy. If current state of configuration copy is "new-failed", next import of the diskgroup will disable it. * 2827939 (Tracking ID: 2088426) SYMPTOM: Re-onlining of all disks irrespective of whether they belong to the shared dg being destroyed/deported is being done on master and slaves. DESCRIPTION: When a shared dg is destroyed/deported, all disks on the nodes in the cluster are re-onlined asynchronously when another command is fired. This results in wasteful usage of resources and delaying the next command substantially based on how many disks/luns are there on each node. RESOLUTION: Restrict re-onlining of luns/disks to those that belong to the dg that is being destroyed/deported. By doing this resource and delay in the next command is restricted to the number of luns/disks that belong to the dg in question. * 2836910 (Tracking ID: 2818840) SYMPTOM: 1. The file permissions set to ASM devices is not persistent across reboot. 2. User is not able to set desired permissions to ASM devices. 3. The files created with user id "root" and group other than "system" are not persistent. DESCRIPTION: The vxdmpasm sets the permissions of the devices to "660", which is not persistent across reboot as these devices are not kept in /etc/vx/.vxdmpasmdev file. Currently there is no option which enables the User to set the desired permissions. The files created with user id root and group other than "system" are changed back to "root:system" upon reboot. RESOLUTION: Code is modified to keep the device entries in the file /etc/vx/.vxdmpasmdev to make the permissions persistent across reboot. Code is enhanced to provide an option to set the desired permissions and set the desired user id/group. * 2852270 (Tracking ID: 2715129) SYMPTOM: Vxconfigd hangs during Master takeover in a CVM (Clustered Volume Manager) environment. This results in vx command hang. DESCRIPTION: During Master takeover, VxVM (Veritas Volume Manager) kernel signals Vxconfigd with the information of new Master. Vxconfigd then proceeds with a vxconfigd- level handshake with the nodes across the cluster. Before kernel could signal to vxconfigd, vxconfigd handshake mechanism got started, resulting in the hang. RESOLUTION: Code changes are done to ensure that vxconfigd handshake gets started only upon receipt of signal from the kernel. * 2858859 (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. * 2859390 (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. * 2860449 (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. * 2860451 (Tracking ID: 2815517) SYMPTOM: vxdg adddisk succeeds to add a clone disk to non-clone and non-clone disk to clone diskgroup, resulting in mixed diskgroup. DESCRIPTION: vxdg import fails for diskgroup which has mix of clone and non-clone disks. So vxdg adddisk should not allow creation of mixed diskgroup. RESOLUTION: vxdisk adddisk code is modified to return an error for an attempt to add clone disk to non-clone or non-clone disks to clone diskgroup, Thus it prevents addition of disk in diskgroup which leads to mixed diskgroup. * 2882488 (Tracking ID: 2754819) SYMPTOM: Diskgroup rebuild through 'vxmake -d' gets stuck with following stack trace: buildlocks() MakeEverybody() main() DESCRIPTION: During diskgroup rebuild for configurations having multiple objects on a single cache object, an internal list of cache objects gets incorrectly modified to a circular list, which causes infinite looping during its access. RESOLUTION: Code changes are done to correctly populate the cache object list. * 2886083 (Tracking ID: 2257850) SYMPTOM: Memory leak is observed when information about enclosure is accessed by vxdiskadm. DESCRIPTION: The memory allocated locally for a data structure keeping information about the array specific attributes is not freed. RESOLUTION: Code changes are made to avoid such memory leaks. * 2911009 (Tracking ID: 2535716) SYMPTOM: LVM Volume Group (VG) to VxVM Disk Group conversion fails requesting user to reduce the number of configuration records. Following is an example of error messages seen during the conversion: Analysis of found insufficient Private Space for conversion SMALLEST VGRA space = 176 RESERVED space sectors = 78 PRIVATE SPACE/FREE sectors = 98 AVAILABLE sector space = 49 AVAILABLE sector bytes = 50176 RECORDS needed to convert = 399 MAXIMUM records allowable = 392 The smallest disk in the Volume Group () does not have sufficient private space for the conversion to succeed. There is only enough private space for 392 VM Database records and the conversion of Volume Group () would require enough space to allow 399 VxVM Database records. This would roughly translate to needing an additional 896 bytes available in the private space. This can be accomplished by reducing the number of volumes in the () Volume Group, and allowing that for every volume removed, the number of Database records required would be reduced by three. This is only a rough approximation, however. DESCRIPTION: Conversion process works in-place such that VXVM's public region is same as LVM public region, while VXVM creates the private region between the start of the disk and the start of the public region. In case the public region for LVM starts early on the disk and source LVM configuration contains very large number of records such that the space between the start of the disk and the start of the public region is not sufficient to hold the private region, conversion process fails. RESOLUTION: Conversion process now creates private region after the public region using the free PE's available in case enough space is not available between the start of the disk to the start of the public region. With this change, new behavior of vxvmconvert ensures that the conversion process succeeds in case at least one disk in the configuration is able to hold the private region either before or after the public region. Conversion process would now fail only if none of the disks in the source configuration is capable of holding private region anywhere on the disk. * 2911010 (Tracking ID: 2627056) SYMPTOM: vxmake(1M) command when run with a very large DESCRIPTION: Due to a memory leak in vxmake(1M) command, data section limit for the process was reached. As a result further memory allocations failed and vxmake command failed with the above error RESOLUTION: Fixed the memory leak by freeing the memory after it has been used. Patch ID: PHCO_42992 * 2621549 (Tracking ID: 2621465) SYMPTOM: When a failed disk belongs to a site has once again become accessible, it cannot be reattached to the disk group. DESCRIPTION: As the disk has a site tag name set, 'vxdg adddisk' command invoked in 'vxreattach' command needs the option '-f' to add the disk back to the disk group. RESOLUTION: Add the option '-f' to 'vxdg adddisk' command when it is invoked in 'vxreattach' command. * 2626915 (Tracking ID: 2417546) SYMPTOM: Raw devices are lost after OS rebooting and also cause permissions issue due to change in dmpnode permissions from 660 to 600. DESCRIPTION: On reboot, while creating raw devices we generate next available device number. There is counting bug due to which VxVM were ending up creating one less device. Also it was creating permissions issue due to change in dmpnode permissions. RESOLUTION: This issue is addressed by source change wherein correct counters are kept and device permissions are changed appropriately. * 2626920 (Tracking ID: 2061082) SYMPTOM: "vxddladm -c assign names" command does not work if dmp_native_support tunable is enabled. DESCRIPTION: If dmp_native_support tunable is set to "on" then VxVM does not allow change in name of dmpnodes. This holds true even for device with native support not enabled like VxVM labeled or Third Party Devices. So there is no way for selectively changing name of devices for which native support is not enabled. RESOLUTION: This enhancement is addressed by code change to selectively change name for devices with native support not enabled. * 2643651 (Tracking ID: 2643634) SYMPTOM: If standard(non-clone) disks and cloned disks of the same disk group are seen in a host, dg import will fail with the following error message when the standard(non-clone) disks have no enabled configuration copy of the disk group. # vxdg import VxVM vxdg ERROR V-5-1-10978 Disk group : import failed: Disk group has no valid configuration copies DESCRIPTION: When VxVM is importing such a mixed configuration of standard(non-clone) disks and cloned disks, standard(non-clone) disks will be selected as the member of the disk group in 5.0MP3RP5HF1 and 5.1SP1RP2. It will be done while administrators are not aware of the fact that there is a mixed configuration and the standard(non-clone) disks are to be selected for the import. It is hard to figure out from the error message and need time to investigate what is the issue. RESOLUTION: Syslog message enhancements are made in the code that administrators can figure out if such a mixed configuration is seen in a host and also which disks are selected for the import. * 2666175 (Tracking ID: 2666163) SYMPTOM: A small memory leak may be seen in vxconfigd, the VxVM configuration daemon when Serial Split Brain(SSB) error is detected in the import process. DESCRIPTION: The leak may occur when Serial Split Brain(SSB) error is detected in the import process. It is because when the SSB error is returning from a function, a dynamically allocated memory area in the same function would not be freed. The SSB detection is a VxVM feature where VxVM detects if the configuration copy in the disk private region becomes stale unexpectedly. A typical use case of the SSB error is that a disk group is imported to different systems at the same time and configuration copy update in both systems results in an inconsistency in the copies. VxVM cannot identify which configuration copy is most up-to-date in this situation. As a result, VxVM may detect SSB error on the next import and show the details through a CLI message. RESOLUTION: Code changes are made to avoid the memory leak and also a small message fix has been done. * 2695225 (Tracking ID: 2675538) SYMPTOM: Data corruption can be observed on a CDS (Cross-platform Data Sharing) disk, as part of LUN resize operations. The following pattern would be found in the data region of the disk. cyl alt 2 hd sec DESCRIPTION: The CDS disk maintains a SUN VTOC in the zeroth block and a backup label at the end of the disk. The VTOC maintains the disk geometry information like number of cylinders, tracks and sectors per track. The backup label is the duplicate of VTOC and the backup label location is determined from VTOC contents. As part of resize, VTOC is not updated to the new size, which results in the wrong calculation of the backup label location. If the wrongly calculated backup label location falls in the public data region rather than the end of the disk as designed, data corruption occurs. RESOLUTION: Update the VTOC contents appropriately for LUN resize operations to prevent the data corruption. * 2695227 (Tracking ID: 2674465) SYMPTOM: Data corruption is observed when DMP node names are changed by following commands for DMP devices that are controlled by a third party multi-pathing driver (E.g. MPXIO and PowerPath ) # vxddladm [-c] assign names # vxddladm assign names file= # vxddladm set namingscheme= DESCRIPTION: The above said commands when executed would re-assign names to each devices. Accordingly the in-core DMP database should be updated for each device to map the new device name with appropriate device number. Due to a bug in the code, the mapping of names with the device number wasn't done appropriately which resulted in subsequent IOs going to a wrong device thus leading to data corruption. RESOLUTION: DMP routines responsible for mapping the names with right device number is modified to fix this corruption problem. * 2701152 (Tracking ID: 2700486) SYMPTOM: If the VVR Primary and Secondary nodes have the same host-name, and there is a loss of heartbeats between them, vradmind daemon can core-dump if an active stats session already exists on the Primary node. Following stack-trace is observed: pthread_kill() _p_raise() raise.raise() abort() __assert_c99 StatsSession::sessionInitReq() StatsSession::processOpReq() StatsSession::processOpMsgs() RDS::processStatsOpMsg() DBMgr::processStatsOpMsg() process_message() main() DESCRIPTION: On loss of heartbeats between the Primary and Secondary nodes, and a subsequent reconnect, RVG information is sent to the Primary by Secondary node. In this case, if a Stats session already exists on the Primary, a STATS_SESSION_INIT request is sent back to the Secondary. However, the code was using "hostname" (as returned by `uname -a`) to identify the secondary node. Since both the nodes had the same hostname, the resulting STATS_SESSION_INIT request was received at the Primary itself, causing vradmind to core dump. RESOLUTION: Code was modified to use 'virtual host-name' information contained in the RLinks, rather than hostname(1m), to identify the secondary node. In a scenario where both Primary and Secondary have the same host-name, virtual host-names are used to configure VVR. * 2702110 (Tracking ID: 2700792) SYMPTOM: vxconfigd, the VxVM volume configuration daemon may dump a core with the following stack during the Cluster Volume Manager(CVM) startup with "hares -online cvm_clus -sys [node]". dg_import_finish() dg_auto_import_all() master_init() role_assume() vold_set_new_role() kernel_get_cvminfo() cluster_check() vold_check_signal() request_loop() main() DESCRIPTION: During CVM startup, vxconfigd accesses the disk group record's pointer of a pending record while the transaction on the disk group is in progress. At times, vxconfigd incorrectly accesses the stale pointer while processing the current transaction, thus resulting in a core dump. RESOLUTION: Code changes are made to access the appropriate pointer of the disk group record which is active in the current transaction. Also, the disk group record is appropriately initialized to NULL value. * 2703370 (Tracking ID: 2700086) SYMPTOM: In the presence of "Not-Ready" EMC devices on the system, multiple dmp (path disabled/enabled) events messages are seen in the syslog DESCRIPTION: The issue is that vxconfigd enables the BCV devices which are in Not-Ready state for IO as the SCSI inquiry succeeds, but soon finds that they cannot be used for I/O and disables those paths. This activity takes place whenever "vxdctl enable" or "vxdisk scandisks" command is executed. RESOLUTION: Avoid changing the state of the BCV device which is in "Not-Ready" to prevent IO and dmp event messages. * 2703373 (Tracking ID: 2698860) SYMPTOM: Mirroring a large size VxVM volume comprising of THIN luns underneath and with VxFS filesystem atop mounted fails with the following error: Command error # vxassist -b -g $disk_group_name mirror $volume_name VxVM vxplex ERROR V-5-1-14671 Volume is configured on THIN luns and not mounted. Use 'force' option, to bypass smartmove. To take advantage of smartmove for supporting thin luns, retry this operation after mounting the volume. VxVM vxplex ERROR V-5-1-407 Attempting to cleanup after failure ... Truss output error: statvfs("", 0xFFBFEB54) Err#79 EOVERFLOW DESCRIPTION: The statvfs system call is invoked internally during mirroring operation to retrieve statistics information of VxFS file system hosted on the volume. However, since the statvfs system call only supports maximum 4294967295 (4GB-1) blocks, so if the total filesystem blocks are greater than that, EOVERFLOW error occurs. This also results in vxplex terminating with the errors. RESOLUTION: Use the 64 bits version of statvfs i.e., statvfs64 system call to resolve the EOVERFLOW and vxplex errors. * 2711758 (Tracking ID: 2710579) SYMPTOM: Data corruption can be observed on a CDS (Cross-platform Data Sharing) disk, as part of operations like LUN resize, Disk FLUSH, Disk ONLINE etc. The following pattern would be found in the data region of the disk. cyl alt 2 hd sec DESCRIPTION: The CDS disk maintains a SUN VTOC in the zeroth block and a backup label at the end of the disk. The VTOC maintains the disk geometry information like number of cylinders, tracks and sectors per track. The backup label is the duplicate of VTOC and the backup label location is determined from VTOC contents. If the content of SUN VTOC located in the zeroth sector are incorrect, this may result in the wrong calculation of the backup label location. If the wrongly calculated backup label location falls in the public data region rather than the end of the disk as designed, data corruption occurs. RESOLUTION: Suppressed writing the backup label to prevent the data corruption. * 2744219 (Tracking ID: 2729501) SYMPTOM: In Dynamic Multi pathing environment, excluding a path also excludes other set of paths with matching substrings. DESCRIPTION: excluding a path using vxdmpadm exclude vxvm path=<> is excluding all the paths with matching substring. This is due to strncmp() used for comparison. Also the size of h/w path defined in the structure is more than what is actually fetched. RESOLUTION: Correct the size of h/w path in the structure and use strcmp for comparison inplace of strncmp() * 2750454 (Tracking ID: 2423701) SYMPTOM: Upgrade of VxVM caused change in permissions of /etc/vx/vxesd during live upgrade from drwx------ to d---r-x---. DESCRIPTION: '/etc/vx/vxesd' directory gets shipped in VxVM with "drwx------" permissions. However, while starting the vxesd daemon, if this directory is not present, it gets created with "d---r-x---". RESOLUTION: Changes are made so that while starting vxesd daemon '/etc/vx/vxesd' gets created with 'drwx------' permissions. * 2752178 (Tracking ID: 2741240) SYMPTOM: In a VxVM environment, "vxdg join" when executed during heavy IO load fails with the below message. VxVM vxdg ERROR V-5-1-4597 vxdg join [source_dg] [target_dg] failed join failed : Commit aborted, restart transaction join failed : Commit aborted, restart transaction Half of the disks that were part of source_dg will become part of target_dg whereas other half will have no DG details. DESCRIPTION: In a vxdg join transaction, VxVM has implemented it as a two phase transaction. If the transaction fails after the first phase and during the second phase, half of the disks belonging to source_dg will become part of target_dg and the other half of the disks will be in a complex irrecoverable state. Also, in heavy IO situation, any retry limit (i.e.) a limit to retry transactions can be easily exceeded. RESOLUTION: "vxdg join" is now designed as a one phase atomic transaction and the retry limit is eliminated. Patch ID: PHCO_42807 * 2477272 (Tracking ID: 2169726) SYMPTOM: After import operation, the imported diskgroup contains combination of cloned and original disks. For example, after importing the diskgroup which has four disks, two of the disks from imported diskgroup are cloned disks and the other two are original disks. DESCRIPTION: For a particular diskgroup, if some of the original disks are not available at the time of diskgroup import operation and the corresponding cloned disks are present, then the diskgroup imported through vxdg import operation contains combination of cloned and original disks. Example - Diskgroup named dg1 with the disks disk1 and disk2 exists on some machine. Clones of disks named disk1_clone disk2_clone are also available. If disk2 goes offline and the import for dg1 is performed, then the resulting diskgroup will contain disks disk1 and disk2_clone. RESOLUTION: The diskgroup import operation will consider cloned disks only if no original disk is available. If any of the original disks exists at the time of import operation, then the import operation will be attempted using original disks only. * 2507120 (Tracking ID: 2438426) SYMPTOM: The following messages are displayed after vxconfigd is started. pp_claim_device: Could not get device number for /dev/rdsk/emcpower0 pp_claim_device: Could not get device number for /dev/rdsk/emcpower1 DESCRIPTION: Device Discovery Layer(DDL) has incorrectly marked a path under dmp device with EFI flag even though there is no corresponding Extensible Firmware Interface (EFI) device in /dev/[r]dsk/. As a result, Array Support Library (ASL) issues a stat command on non-existent EFI device and displays the above messages. RESOLUTION: Avoided marking EFI flag on Dynamic MultiPathing (DMP) paths which correspond to non-efi devices. * 2508294 (Tracking ID: 2419486) SYMPTOM: Data corruption is observed with single path when naming scheme is changed from enclodure based (EBN) to OS Native (OSN). DESCRIPTION: The Data corruption can occur in the following configuration, when the naming scheme is changed while applications are on-line. 1. The DMP device is configured with single path or the devices are controlled by Third party Multipathing Driver (Ex: MPXIO, MPIO etc.,) 2. The DMP device naming scheme is EBN (enclosure based naming) and persistence=yes 3. The naming scheme is changed to OSN using the following command # vxddladm set namingscheme=osn There is possibility of change in name of the VxVM device (DA record) while the naming scheme is changing. As a result of this the device attribute list is updated with new DMP device names. Due to a bug in the code which updates the attribute list, the VxVM device records are mapped to wrong DMP devices. Example: Following are the device names with EBN naming scheme. MAS-usp0_0 auto:cdsdisk hitachi_usp0_0 prod_SC32 online MAS-usp0_1 auto:cdsdisk hitachi_usp0_4 prod_SC32 online MAS-usp0_2 auto:cdsdisk hitachi_usp0_5 prod_SC32 online MAS-usp0_3 auto:cdsdisk hitachi_usp0_6 prod_SC32 online MAS-usp0_4 auto:cdsdisk hitachi_usp0_7 prod_SC32 online MAS-usp0_5 auto:none - - online invalid MAS-usp0_6 auto:cdsdisk hitachi_usp0_1 prod_SC32 online MAS-usp0_7 auto:cdsdisk hitachi_usp0_2 prod_SC32 online MAS-usp0_8 auto:cdsdisk hitachi_usp0_3 prod_SC32 online MAS-usp0_9 auto:none - - online invalid disk_0 auto:cdsdisk - - online disk_1 auto:none - - online invalid bash-3.00# vxddladm set namingscheme=osn The follwoing is after executing the above command. The MAS-usp0_9 is changed as MAS-usp0_6 and the following devices are changed accordingly. bash-3.00# vxdisk list DEVICE TYPE DISK GROUP STATUS MAS-usp0_0 auto:cdsdisk hitachi_usp0_0 prod_SC32 online MAS-usp0_1 auto:cdsdisk hitachi_usp0_4 prod_SC32 online MAS-usp0_2 auto:cdsdisk hitachi_usp0_5 prod_SC32 online MAS-usp0_3 auto:cdsdisk hitachi_usp0_6 prod_SC32 online MAS-usp0_4 auto:cdsdisk hitachi_usp0_7 prod_SC32 online MAS-usp0_5 auto:none - - online invalid MAS-usp0_6 auto:none - - online invalid MAS-usp0_7 auto:cdsdisk hitachi_usp0_1 prod_SC32 online MAS-usp0_8 auto:cdsdisk hitachi_usp0_2 prod_SC32 online MAS-usp0_9 auto:cdsdisk hitachi_usp0_3 prod_SC32 online c4t20000014C3D27C09d0s2 auto:none - - online invalid c4t20000014C3D26475d0s2 auto:cdsdisk - - online RESOLUTION: Code changes are made to update device attribute list correctly even if name of the VxVM device is changed while the naming scheme is changing. * 2511928 (Tracking ID: 2420386) SYMPTOM: Corrupted data is seen near the end of a sub-disk, on thin-reclaimable disks with either CDS EFI or sliced disk formats. DESCRIPTION: In environments with thin-reclaim disks running with either CDS-EFI disks or sliced disks, misaligned reclaims can be initiated. In some situations, when reclaiming a sub-disk, the reclaim does not take into account the correct public region start offset, which in rare instances can potentially result in reclaiming data before the sub-disk which is being reclaimed. RESOLUTION: The public offset is taken into account when initiating all reclaim operations. * 2515137 (Tracking ID: 2513101) SYMPTOM: When VxVM is upgraded from 4.1MP4RP2 to 5.1SP1RP1, the data on CDS disk gets corrupted. DESCRIPTION: When CDS disks are initialized with VxVM version 4.1MP4RP2, the number of cylinders are calculated based on the disk raw geometry. If the calculated number of cylinders exceed Solaris VTOC limit (65535), because of unsigned integer overflow, truncated value of number of cylinders gets written in CDS label. After the VxVM is upgraded to 5.1SP1RP1, CDS label gets wrongly written in the public region leading to the data corruption. RESOLUTION: The code changes are made to suitably adjust the number of tracks & heads so that the calculated number of cylinders be within Solaris VTOC limit. * 2517819 (Tracking ID: 2530279) SYMPTOM: vxesd consumes 100% CPU, and hang is in following stack: vold_open () es_update_ddlconfig () do_get_ddl_config () start_ipc () main () DESCRIPTION: Due to inappropriate handling of thread control, race condition occurs inside the ESD code path. This race condition leads 100% CPU cycles and reaches to hang state. RESOLUTION: Done the proper way of handling to control thread to avoid the race condition in the code path. * 2525333 (Tracking ID: 2148851) SYMPTOM: "vxdisk resize" operation fails on a disk with VxVM cdsdisk/simple/sliced layout on Solaris/Linux platform with the following message: VxVM vxdisk ERROR V-5-1-8643 Device emc_clariion0_30: resize failed: New geometry makes partition unaligned DESCRIPTION: The new cylinder size selected during "vxdisk resize" operation is unaligned with the partitions that existed prior to the "vxdisk resize" operation. RESOLUTION: The algorithm to select the new geometry has been redesigned such that the new cylinder size is always aligned with the existing as well as new partitions. * 2528144 (Tracking ID: 2528133) SYMPTOM: vxprint -l command gives following error (along with the output), when multiple DGs have same DM_NAME VxVM vxdisk ERROR V-5-1-0 disk100 - Record in multiple disk groups DESCRIPTION: vxprint -l, internally takes one record(in this case DM_NAME) at a time and searches that record in all the DGs. If it finds the record in more than one DG, it marks the flag to DGL_MORE. This DGL_MORE flag checking was causing the error in case of vxprint -l. RESOLUTION: Since, it is a valid operation to create multiple DGs with same DM_NAME. The error checking is not required at all. The code change removes the flag checking logic from the function. * 2531993 (Tracking ID: 2524936) SYMPTOM: Disk group is disabled after rescanning disks with "vxdctl enable" command. The error messages given below are seen in vxconfigd debug log output: VxVM vxconfigd ERROR V-5-1-12223 Error in claiming /dev/: The process file table is full. VxVM vxconfigd ERROR V-5-1-12223 Error in claiming /dev/: The process file table is full. ... VxVM vxconfigd ERROR V-5-1-12223 Error in claiming /dev/: The process file table is full. DESCRIPTION: When attachment of shared memory segment to the process address space fails, proper error handling of such case was missing in vxconfigd code, hence resulting in error in claiming disks and offlining configuration copies which in-turn results in disabling of disk group. RESOLUTION: Code changes are made to handle the failure case while creating shared memory segment. * 2574840 (Tracking ID: 2344186) SYMPTOM: In a master-slave configuration with FMR3/DCO volumes, reboot of a cluster node fails to join back the cluster again with following error messages in the console [..] Jul XX 18:44:09 vienna vxvm:vxconfigd: [ID 702911 daemon.error] V-5-1-11092 cleanup_client: (Volume recovery in progress) 230 Jul XX 18:44:09 vienna vxvm:vxconfigd: [ID 702911 daemon.error] V-5-1-11467 kernel_fail_join() : Reconfiguration interrupted: Reason is retry to add a node failed (13, 0) [..] DESCRIPTION: VxVM volumes with FMR3/DCO have inbuilt DRL mechanism to track the disk block of in-flight IOs in order to recover the data much quicker in case of a node crash. Thus, a joining node awaits the variable, responsible for recovery, to get unset to join the cluster. However, due to a bug in FMR3/DCO code, this variable was set forever, thus leading to node join failure. RESOLUTION: Modified the FMR3/DCO code to appropriately set and unset this recovery variable. * 2676703 (Tracking ID: 2553729) SYMPTOM: The following is observed during 'Upgrade' of VxVM (Veritas Volume Manager): i) 'clone_disk' flag is seen on non-clone disks in STATUS field when 'vxdisk -e list' is executed after uprade to 5.1SP1 from lower versions of VxVM. Eg: DEVICE TYPE DISK GROUP STATUS emc0_0054 auto:cdsdisk emc0_0054 50MP3dg online clone_disk emc0_0055 auto:cdsdisk emc0_0055 50MP3dg online clone_disk ii) Disk groups (dg) whose versions are less than 140 do not get imported after upgrade to VxVM versions 5.0MP3RP5HF1 or 5.1SP1RP2. Eg: # vxdg -C import VxVM vxdg ERROR V-5-1-10978 Disk group : import failed: Disk group version doesn't support feature; see the vxdg upgrade command DESCRIPTION: While uprading VxVM i) After upgrade to 5.1SP1 or higher versions: If a dg which is created on lower versions is deported and imported back on 5.1SP1 after the upgrade, then "clone_disk" flags gets set on non-cloned disks because of the design change in UDID (unique disk identifier) of the disks. ii) After upgrade to 5.0MP3RP5HF1 or 5.1SP1RP2: Import of dg with versions less than 140 fails. RESOLUTION: Code changes are made to ensure that: i) clone_disk flag does not get set for non-clone disks after the upgrade. ii) Disk groups with versions less than 140 get imported after the upgrade. Patch ID: PHCO_42245 * 2163809 (Tracking ID: 2151894) SYMPTOM: Internal testing utility volassert prints a message: Volume TCv1-548914: recover_offset=0, expected 1024 DESCRIPTION: We changed the behavior of recover_offset in other incident by resetting it back to zero after starting a volume. This works okay for normal cases but not for raid5 volumes. RESOLUTION: Recover offset will be set at the end of a volume after grow/init operations. * 2198041 (Tracking ID: 2196918) SYMPTOM: When creating a space-opimized snapshot by specifying cache-object size either in percentage terms of the volume size or an absolute size, the snapshot creation can fail with an error similar to following: "VxVM vxassist ERROR V-5-1-10127 creating volume snap-dvol2-CV01: Volume or log length violates disk group alignment" DESCRIPTION: VxVM expects all virtual storage objects to have size aligned to a value which is set diskgroup-wide. One can get this value with: # vxdg list testdg|grep alignment alignment: 8192 (bytes) When the cachesize is specified in percentage, the value might not align with dg alignment. If not aligned, the creation of the cache-volume could fail with specified error message RESOLUTION: After computing the cache-size from specified percentage value, it is aligned up to the diskgroup alignment value before trying to create the cache-volume. * 2204146 (Tracking ID: 2200670) SYMPTOM: Some disks are left detached and not recovered by vxattachd. DESCRIPTION: If the shared disk group is not imported or node is not part of the cluster when storage connectivity to failed node is restored, the vxattachd daemon does not getting notified about storage connectivity restore and does not trigger a reattach. Even if the disk group is later imported or the node is joined to CVM cluster, the disks are not automatically reattached. RESOLUTION: i) Missing events for a deported diskgroup: The fix handles this by listening to the import event of the diksgroup and triggers the brute-force recovery for that specific diskgroup. ii) parallel recover of volumes from same disk: vxrecover automatically serializes the recovery of objects that are from the same disk to avoid the back and forth head movements. Also provided an option in vxattchd and vxrecover to control the number of parallel recovery that can happen for objects from the same disk. * 2214184 (Tracking ID: 2202710) SYMPTOM: Transactions on Rlink are not allowed during SRL to DCM flush. DESCRIPTION: Present implementation doesn't allow rlink transaction to go through if SRL to DCM flush is in progress. As SRL overflows, VVR start reading from SRL and mark the dirty regions in corresponding DCMs of data volumes, it is called SRL to DCM flush. During SRL to DCM flush transactions on rlink is not allowed. Time to complete SRL flush depend on SRL size, it could range from minutes to many hours. If user initiate any transaction on rlink then it will hang until SRL flush completes. RESOLUTION: Changed the code behavior to allow rlink transaction during SRL flush. Fix stops the SRL flush for transaction to go ahead and restart the flush after transaction completion. * 2232829 (Tracking ID: 2232789) SYMPTOM: With NetApp metro cluster disk arrays, takeover operations (toggling of LUN ownership within NetApp filer) can lead to IO failures on VxVM volumes. Example of an IO error message at VxVM VxVM vxio V-5-0-2 Subdisk disk_36-03 block 24928: Uncorrectable write error DESCRIPTION: During the takeover operation, the array fails the PGR and IO SCSI commands on secondary paths with the following transient error codes - 0x02/0x04/0x0a (NOT READY/LOGICAL UNIT NOT ACCESSIBLE, ASYMMETRIC ACCESS STATE TRANSITION) or 0x02/0x04/0x01 (NOT READY/LOGICAL UNIT IS IN PROCESS OF BECOMING READY) - that are not handled properly within VxVM. RESOLUTION: Included required code logic within the APM so that the SCSI commands with transient errors are retried for the duration of NetApp filer reconfig time (60 secs) before failing the IO's on VxVM volumes. * 2234292 (Tracking ID: 2152830) SYMPTOM: Sometimes the storage admins create multiple copies/clones of the same device. Diskgroup import fails with a non-descriptive error message when multiple copies(clones) of the same device exists and original device(s) are either offline or not available. # vxdg import mydg VxVM vxdg ERROR V-5-1-10978 Disk group mydg: import failed: No valid disk found containing disk group DESCRIPTION: If the original devices are offline or unavailable, vxdg import picks up cloned disks for import. DG import fails by design unless the clones are tagged and tag is specified during DG import. While the import failure is expected, but the error message is non-descriptive and doesn't provide any corrective action to be taken by user. RESOLUTION: Fix has been added to give correct error meesage when duplicate clones exist during import. Also, details of duplicate clones is reported in the syslog. Example: [At CLI level] # vxdg import testdg VxVM vxdg ERROR V-5-1-10978 Disk group testdg: import failed: DG import duplcate clone detected [In syslog] vxvm:vxconfigd: warning V-5-1-0 Disk Group import failed: Duplicate clone disks are detected, please follow the vxdg (1M) man page to import disk group with duplicate clone disks. Duplicate clone disks are: c2t20210002AC00065Bd0s2 : c2t50060E800563D204d1s2 c2t50060E800563D204d0s2 : c2t50060E800563D204d1s2 * 2241149 (Tracking ID: 2240056) SYMPTOM: 'vxdg move/split/join' may fail during high I/O load. DESCRIPTION: During heavy I/O load 'dg move' transcation may fail because of open/close assertion and retry will be done. As the retry limit is set to 30 'dg move' fails if retry hits the limit. RESOLUTION: Change the default transaction retry to unlimit, introduce a new option to 'vxdg move/split/join' to set transcation retry limit as follows: vxdg [-f] [-o verify|override] [-o expand] [-o transretry=retrylimit] move src_diskgroup dst_diskgroup objects ... vxdg [-f] [-o verify|override] [-o expand] [-o transretry=retrylimit] split src_diskgroup dst_diskgroup objects ... vxdg [-f] [-o verify|override] [-o transretry=retrylimit] join src_diskgroup dst_diskgroup * 2247645 (Tracking ID: 2243044) SYMPTOM: Initialization of VxVM cdsdisk layout on a disk with greater than or equal to 1 TB fails on HP-UX/ia-64 platform. DESCRIPTION: During the initialization of VxVM cdsdisk layout on a disk with size greater than or equal to 1 TB on HP-UX/ia-64 platform, we were checking if the disk has an existing HP-UX LVM layout. During this check, the i/o was performed incorrectly using the DMP (Dynamic Multi-Pathing Driver) paths associated with the existing GPT partitions on the disk. RESOLUTION: This issue has been resolved by performing i/o to the whole device path during the initialization of VxVM cdsdisk layout on a disk with size greater than or equal to 1 TB. * 2253269 (Tracking ID: 2263317) SYMPTOM: vxdg(1M) man page does not clearly describe diskgroup import and destroy operations for the case in which original diskgroup is destroyed and cloned disks are present. DESCRIPTION: Diskgroup import with dgid is cosidered as a recovery operation. Therefore, while importing with dgid, even though the original diskgroup is destroyed, both the original as well as cloned disks are considered as available disks. Hence, the original diskgroup is imported in such a scenario. The existing vxdg(1M) man page does not clearly describe this scenario. RESOLUTION: Modified the vxdg(1M) man page to clearly describe the scenario. * 2256728 (Tracking ID: 2248730) SYMPTOM: Command hungs if "vxdg import" called from script with STDERR redirected. DESCRIPTION: If script is having "vxdg import" with STDERR redirected then script does not finish till DG import and recovery is finished. Pipe between script and vxrecover is not closed properly which keeps calling script waiting for vxrecover to complete. RESOLUTION: Closed STDERR in vxrecover and redirected the output to /dev/console. * 2316309 (Tracking ID: 2316297) SYMPTOM: The following error messages are printed on the console every time system boots. VxVM vxdisk ERROR V-5-1-534 Device [DEVICE NAME]: Device is in use DESCRIPTION: During system boot up, while Volume Manager diskgroup imports, vxattachd daemon tries to online the disk. Since the disk may be already online sometimes, an attempt to re-online disk gives the below error message: VxVM vxdisk ERROR V-5-1-534 Device [DEVICE NAME]: Device is in use RESOLUTION: The solution is to check if the disk is already in "online" state. If so, avoid reonline. * 2323999 (Tracking ID: 2323925) SYMPTOM: If the rootdisk is under VxVM control and /etc/vx/reconfig.d/state.d/install-db file exists, the following messages are observed on the console: UX:vxfs fsck: ERROR: V-3-25742: /dev/vx/dsk/rootdg/homevol:sanity check failed: cannot open /dev/vx/dsk/rootdg/homevol: No such device or address UX:vxfs fsck: ERROR: V-3-25742: /dev/vx/dsk/rootdg/optvol:sanity check failed: cannot open /dev/vx/dsk/rootdg/optvol: No such device or address DESCRIPTION: In the vxvm-startup script, there is check for the /etc/vx/reconfig.d/state.d/install-db file. If the install-db file exist on the system, the VxVM assumes that volume manager is not configured and does not start volume configuration daemon "vxconfigd". "install-db" file somehow existed on the system for a VxVM rootable system, this causes the failure. RESOLUTION: If install-db file exists on the system and the system is VxVM rootable, the following warning message is displayed on the console: "This is a VxVM rootable system. Volume configuration daemon could not be started due to the presence of /etc/vx/reconfig.d/state.d/install-db file. Remove the install-db file to proceed" * 2328219 (Tracking ID: 2253552) SYMPTOM: vxconfigd leaks memory while reading the default tunables related to smartmove (a VxVM feature). DESCRIPTION: In Vxconfigd, memory allocated for default tunables related to smartmove feature is not freed causing a memory leak. RESOLUTION: The memory is released after its scope is over. * 2328286 (Tracking ID: 2244880) SYMPTOM: Initialization of VxVM cdsdisk layout on a disk with size greater than or equal to 1 TB fails. DESCRIPTION: During the initialization of VxVM cdsdisk layout on a disk with size greater than or equal to 1 TB, alternative (backup) GPT label is written in the last 33 sectors of the disk. SCSI pass-thru mode was used to write the alternative GPT label. SCSI pass-thru mode could not handle device offsets equal to or greater than 1 TB RESOLUTION: This issue has been resolved by using the posix system calls to write the alternative GPT label during initialization of VxVM cdsdisk layout. * 2337091 (Tracking ID: 2255182) SYMPTOM: If EMC CLARiiON arrays are configured with different failovermode for each host controllers ( e.g. one HBA has failovermode set as 1 while the other as 2 ), then VxVM's vxconfigd demon dumps core. DESCRIPTION: DDL (VxVM's Device Discovery Layer) determines the array type depending on the failovermode setting. DDL expects the same array type to be returned across all the paths going to that array. This fundamental assumption of DDL will be broken with different failovermode settings thus leading to vxconfigd core dump. RESOLUTION: Validation code is added in DDL to detect such configurations and emit appropriate warning messages to the user to take corrective actions and skips the later set of paths that are reporting different array type. * 2349653 (Tracking ID: 2349352) SYMPTOM: Data corruption is observed on DMP(Dynamic Multipathing) device with single path during Storage reconfiguration (LUN addition/removal). DESCRIPTION: Data corruption can occur in the following configuration, when new LUNs are provisioned or removed under VxVM, while applications are on-line. 1. The DMP device naming scheme is EBN (enclosure based naming) and persistence=no 2. The DMP device is configured with single path or the devices are controlled by Third Party Multipathing Driver (Ex: MPXIO, MPIO etc.,) There is a possibility of change in name of the VxVM devices (DA record), when LUNs are removed or added followed by the following commands, since the persistence naming is turned off. (a) vxdctl enable (b) vxdisk scandisks Execution of above commands discovers all the devices and rebuilds the device attribute list with new DMP device names. The VxVM device records are then updated with this new attributes. Due to a bug in the code, the VxVM device records are mapped to wrong DMP devices. Example: Following are the device before adding new LUNs. sun6130_0_18 auto:cdsdisk disk_0 prod_SC32 online nohotuse sun6130_0_19 auto:cdsdisk disk_1 prod_SC32 online nohotuse The following are after adding new LUNs sun6130_0_18 auto - - nolabel sun6130_0_19 auto - - nolabel sun6130_0_20 auto:cdsdisk disk_0 prod_SC32 online nohotuse sun6130_0_21 auto:cdsdisk disk_1 prod_SC32 online nohotuse The name of the VxVM device sun6130_0_18 is changed to sun6130_0_20. RESOLUTION: The code that updates the VxVM device records is rectified. * 2353327 (Tracking ID: 2179259) SYMPTOM: When using disks of size > 2TB and the disk encounters a media error with offset > 2TB while the disk responds to SCSI inquiry, data corruption can occur incase of a write operation DESCRIPTION: The I/O rety logic in DMP assumes that the I/O offset is within 2TB limit and hence when using disks of size > 2TB and the disk encounters a media error with offset > 2TB while the disk responds to SCSI inquiry, the I/O would be issued on a wrong offset within the 2TB range causing data corruption incase of write I/Os. RESOLUTION: The fix for this issue to change the I/O retry mechanism to work for >2TB offsets as well so that no offset truncation happens that could lead to data corruption * 2353328 (Tracking ID: 2194685) SYMPTOM: vxconfigd dumps core in scenario where array side ports are disabled/enabled in loop for some iterations. gdb) where #0 0x081ca70b in ddl_delete_node () #1 0x081cae67 in ddl_check_migration_of_devices () #2 0x081d0512 in ddl_reconfigure_all () #3 0x0819b6d5 in ddl_find_devices_in_system () #4 0x0813c570 in find_devices_in_system () #5 0x0813c7da in mode_set () #6 0x0807f0ca in setup_mode () #7 0x0807fa5d in startup () #8 0x08080da6 in main () DESCRIPTION: Due to disabling the array side ports, the secondary paths get removed. But the primary paths are reusing the devno of the removed secondary paths which is not correctly handled in current migration code. Due to this, the DMP database gets corrupted and subsequent discoveries lead to configd core dump. RESOLUTION: The issue is due to incorrect setting of a DMP flag. The flag settting has been fixed to prevent the DMP database from corruption in the mentioned scenario. * 2353403 (Tracking ID: 2337694) SYMPTOM: "vxdisk -o thin list" displays size as 0 for thin luns of capacity greater than 2 TB. DESCRIPTION: SCSI READ CAPACITY ioctl is invoked to get the disk capacity. SCSI READ CAPACITY returns data in extended data format if a disk capacity is 2 TB or greater. This extended data was parsed incorectly while calculating the disk capacity. RESOLUTION: This issue has been resolved by properly parsing the extended data returned by SCSI READ CAPACITY ioctl for disks of size greater than 2 TB or greater. * 2353404 (Tracking ID: 2334757) SYMPTOM: Vxconfigd consumes a lot of memory when the DMP tunable dmp_probe_idle_lun is set on. "pmap" command on vxconfigd process shows continuous growing heap. DESCRIPTION: DMP path restoration daemon probes idle LUNs(Idle LUNs are VxVM disks on which no I/O requests are scheduled) and generates notify events to vxconfigd. Vxconfigd in turn send the nofification of these events to its clients. For any reasons, if vxconfigd could not deliver these events (because client is busy processing earlier sent event), it keeps these events to itself. Because of this slowness of events consumption by its clients, memory consumption of vxconfigd grows. RESOLUTION: dmp_probe_idle_lun is set to off by default. * 2353421 (Tracking ID: 2334534) SYMPTOM: In CVM (Cluster Volume Manager) environment, a node (SLAVE) join to the cluster is getting stuck and leading to unending join hang unless join operation is stopped on joining node (SLAVE) using command '/opt/VRTS/bin/vxclustadm stopnode'. While CVM join is hung in user-land (also called as vxconfigd level join), on CVM MASTER node, vxconfigd (Volume Manager Configuration daemon) doesn't respond to any VxVM command, which communicates to vxconfigd process. When vxconfigd level CVM join is hung in user-land, "vxdctl -c mode" on joining node (SLAVE) displays an output such as: bash-3.00# vxdctl -c mode mode: enabled: cluster active - SLAVE master: mtvat1000-c1d state: joining reconfig: vxconfigd in join DESCRIPTION: As part of a CVM node join to the cluster, every node in the cluster updates the current CVM membership information (membership information which can be viewed by using command '/opt/VRTS/bin/vxclustadm nidmap') in kernel first and then sends a signal to vxconfigd in user land to use that membership in exchanging configuration records among each others. Since each node receives the signal (SIGIO) from kernel independently, the joining node's (SLAVE) vxconfigd is ahead of the MASTER in its execution. Thus any requests coming from the joining node (SLAVE) is denied by MASTER with the error "VE_CLUSTER_NOJOINERS" i.e. join operation is not currently allowed (error number: 234) since MASTER's vxconfigd has not got the updated membership from the kernel yet. While responding to joining node (SLAVE) with error "VE_CLUSTER_NOJOINERS", if there is any change in current membership (change in CVM node ID) as part of node join then MASTER node is wrongly updating the internal data structure of vxconfigd, which is being used to send response to joining (SLAVE) nodes. Due to wrong update of internal data structure, later when the joining node retries its request, the response from master is sent to a wrong node, which doesn't exist in the cluster, and no response is sent to the joining node. Joining node (SLAVE) never gets the response from MASTER for its request and hence CVM node join is not completed and leading to cluster hang. RESOLUTION: vxconfigd code is modified to handle the above mentioned scenario effectively. vxconfid on MASTER node will process connection request coming from joining node (SLAVE) effectively only when MASTER node gets the updated CVM membership information from kernel. * 2353425 (Tracking ID: 2320917) SYMPTOM: vxconfigd, the VxVM configuration daemon dumps core and loses disk group configuration while invoking the following VxVM reconfiguration steps: 1) Volumes which were created on thin reclaimable disks are deleted. 2) Before the space of the deleted volumes is reclaimed, the disks (whose volume is deleted) are removed from the DG with 'vxdg rmdisk' command using '- k' option. 3) The disks are removed using 'vxedit rm' command. 4) New disks are added to the disk group using 'vxdg addisk' command. The stack trace of the core dump is : [ 0006f40c rec_lock3 + 330 0006ea64 rec_lock2 + c 0006ec48 rec_lock2 + 1f0 0006e27c rec_lock + 28c 00068d78 client_trans_start + 6e8 00134d00 req_vol_trans + 1f8 00127018 request_loop + adc 000f4a7c main + fb0 0003fd40 _start + 108 ] DESCRIPTION: When a volume is deleted from a disk group that uses thin reclaim luns, subdisks are not removed immediately, rather it is marked with a special flag. The reclamation happens at a scheduled time every day. "vxdefault" command can be invoked to list and modify the settings. After the disk is removed from disk group using 'vxdg -k rmdisk' and 'vxedit rm' command, the subdisks records are still in core database and they are pointing to disk media record which has been freed. When the next command is run to add another new disk to the disk group, vxconfigd dumps core when locking the disk media record which has already been freed. The subsequent disk group deport and import commands erase all disk group configuration as it detects an invalid association between the subdisks and the removed disk. RESOLUTION: 1) The following message will be printed when 'vxdg rmdisk' is used to remove disk that has reclaim pending subdisks: VxVM vxdg ERROR V-5-1-0 Disk is used by one or more subdisks which are pending to be reclaimed. Use "vxdisk reclaim " to reclaim space used by these subdisks, and retry "vxdg rmdisk" command. Note: reclamation is irreversible. 2) Add a check when using 'vxedit rm' to remove disk. If the disk is in removed state and has reclaim pending subdisks, following error message will be printed: VxVM vxedit ERROR V-5-1-10127 deleting : Record is associated * 2353427 (Tracking ID: 2337353) SYMPTOM: The "vxdmpadm include" command is including all the excluded devices along with the device given in the command. Example: # vxdmpadm exclude vxvm dmpnodename=emcpower25s2 # vxdmpadm exclude vxvm dmpnodename=emcpower24s2 # more /etc/vx/vxvm.exclude exclude_all 0 paths emcpower24c /dev/rdsk/emcpower24c emcpower25s2 emcpower10c /dev/rdsk/emcpower10c emcpower24s2 # controllers # product # pathgroups # # vxdmpadm include vxvm dmpnodename=emcpower24s2 # more /etc/vx/vxvm.exclude exclude_all 0 paths # controllers # product # pathgroups # DESCRIPTION: When a dmpnode is excluded, an entry is made in /etc/vx/vxvm.exclude file. This entry has to be removed when the dmpnode is included later. Due to a bug in comparison of dmpnode device names, all the excluded devices are included. RESOLUTION: The bug in the code which compares the dmpnode device names is rectified. * 2353464 (Tracking ID: 2322752) SYMPTOM: Duplicate device names are observed for NR (Not Ready) devices, when vxconfigd is restarted (vxconfigd -k). # vxdisk list emc0_0052 auto - - error emc0_0052 auto:cdsdisk - - error emc0_0053 auto - - error emc0_0053 auto:cdsdisk - - error DESCRIPTION: During vxconfigd restart, disk access records are rebuilt in vxconfigd database. As part of this process IOs are issued on all the devices to read the disk private regions. The failure of these IOs on NR devicess resulted in creating duplicate disk access records. RESOLUTION: vxconfigd code is modified not to create dupicate disk access records. * 2353922 (Tracking ID: 2300195) SYMPTOM: Uninitialization of VxVM cdsdisk of size greater than 1 TB fails on HP-UX/ia-64 platform. DESCRIPTION: During the uninitialization of VxVM cdsdisk of size greater than 1 TB on HP- UX/ia-64 platform, DMP (dynamic-multi-pathing) paths corresponding to the GPT partitions on the VxVM cdsdisk were created incorrectly. This resulted in i/o failure while destroying the VxVM cdsdisk. RESOLUTION: This issue has been solved by performing the i/o to the whole device while uninitializing the VxVM cdsdisk. * 2360419 (Tracking ID: 2237089) SYMPTOM: ======= vxrecover failed to recover the data volumes with associated cache volume. DESCRIPTION: =========== vxrecover doesn't wait till the recovery of the cache volumes is complete before triggering the recovery of the data volumes that are created on top of cache volume. Due to this the recovery might fail for the data volumes. RESOLUTION: ========== Code changes are done to serialize the recovery for different volume types. * 2360719 (Tracking ID: 2359814) SYMPTOM: 1. vxconfigbackup(1M) command fails with the following error: ERROR V-5-2-3720 dgid mismatch 2. "-f" option for the vxconfigbackup(1M) is not documented in the man page. DESCRIPTION: 1. In some cases, a *.dginfo file will have two lines starting with "dgid:". It causes vxconfigbackup to fail. The output from the previous awk command returns 2 lines instead of one for the $bkdgid variable and the comparison fails, resulting in "dgid mismatch" error even when the dgids are the same. This happens in the case if the temp dginfo file is not removed during last run of vxconfigbackup, such as the script is interrupted, the temp dginfo file is updated with appending mode, vxconfigbackup.sh: echo "TIMESTAMP" >> $DGINFO_F_TEMP 2>/dev/null Therefore, there may have 2 or more dginfo are added into the dginfo file, it causes the config backup failure with dgid mismatch. 2. "-f" option to force a backup is not documented in the man page of vxconfigbackup(1M). RESOLUTION: 1. The solution is to change append mode to destroy mode. 2. Updated the vxconfigbackup(1M) man page with the "-f" option. * 2377317 (Tracking ID: 2408771) SYMPTOM: VXVM does not show all the discovered devices. Number of devices shown by VXVM is lesser than those by the OS. DESCRIPTION: For every lunpath device discovered, VXVM creates a data structure and is stored in a hash table. Hash value is computed based on unique minor of the lunpath. In case minor number exceeds 831231, we encounter integer overflow and store the data structure for this path at wrong location. When we later traverse this hash list, we limit the accesses based on total number of discovered paths and as the devices with minor numbers greater than 831232 are hashed wrongly, we do not create DA records for such devices. RESOLUTION: Integer overflow problem has been resolved by appropriately typecasting the minor number and hence correct hash value is computed. * 2379034 (Tracking ID: 2379029) SYMPTOM: Changing of enclosure name was not working for all devices in enclosure. All these devices were present in /etc/vx/darecs. # cat /etc/vx/darecs ibm_ds8x000_02eb auto online format=cdsdisk, privoffset=256, pubslice=2, privslice=2 ibm_ds8x000_02ec auto online format=cdsdisk, privoffset=256, pubslice=2, privslice=2 # vxdmpadm setattr enclosure ibm_ds8x000 name=new_ibm_ds8x000 # vxdisk -o alldgs list DEVICE TYPE DISK GROUP STATUS ibm_ds8x000_02eb auto:cdsdisk ibm_ds8x000_02eb mydg online ibm_ds8x000_02ec auto:cdsdisk ibm_ds8x000_02ec mydg online new_ibm_ds8x000_02eb auto - - error new_ibm_ds8x000_02ec auto - - error DESCRIPTION: /etc/vx/darecs only stores foreign devices and nopriv or simple devices, the auto device should NOT be written into this file. A DA record is flushed in the /etc/vx/darecs at the end of transaction, if R_NOSTORE flag is NOT set on a DA record. There was a bug in VM where if we initialize a disk that does not exist(e.g. using vxdisk rm) in da_list, the R_NOSTORE flag is NOT set for the new created DA record. Hence duplicate entries for these devices were created and resulted in these DAs going in error state. RESOLUTION: Source has been modified to add R_NOSTORE flag for auto type DA record created by auto_init() or auto_define(). # vxdmpadm setattr enclosure ibm_ds8x000 name=new_ibm_ds8x000 # vxdisk -o alldgs list new_ibm_ds8x000_02eb auto:cdsdisk ibm_ds8x000_02eb mydg online new_ibm_ds8x000_02ec auto:cdsdisk ibm_ds8x000_02ec mydg online * 2382705 (Tracking ID: 1675599) SYMPTOM: Vxconfigd leaks memory while excluding and including a Third party Driver controlled LUN in a loop. As part of this vxconfigd loses its license information and following error is seen in system log: "License has expired or is not available for operation" DESCRIPTION: In vxconfigd code, memory allocated for various data structures related to device discovery layer is not freed which led to the memory leak. RESOLUTION: The memory is released after its scope is over. * 2382710 (Tracking ID: 2139179) SYMPTOM: DG import can fail with SSB (Serial Split Brain) though the SSB does not exist. DESCRIPTION: An association between DM and DA records is done while importing any DG, if the SSB id of the DM and DA records match. On a system with stale cloned disks, the system is attempting to associate the DM with cloned DA, where the SSB id mismatch is observed and resulted in import failure with SSB mismatch. RESOLUTION: The selection of DA to associate with DM is rectified to resolve the issue. * 2382717 (Tracking ID: 2197254) SYMPTOM: vxassist, the VxVM volume creation utility when creating volume with "logtype=none" doesn't function as expected. DESCRIPTION: While creating volumes on thinrclm disks, Data Change Object(DCO) version 20 log is attached to every volume by default. If the user do not want this default behavior then "logtype=none" option can be specified as a parameter to vxassist command. But with VxVM on HP 11.31 , this option does not work and DCO version 20 log is created by default. The reason for this inconsistency is that when "logtype=none" option is specified, the utility sets the flag to prevent creation of log. However, VxVM wasn't checking whether the flag is set before creating DCO log which led to this issue. RESOLUTION: This is a logical issue which is addressed by code fix. The solution is to check for this corresponding flag of "logtype=none" before creating DCO version 20 by default. * 2383705 (Tracking ID: 2204752) SYMPTOM: The following message is observed after the diskgroup creation: "VxVM ERROR V-5-3-12240: GPT entries checksum mismatch" DESCRIPTION: This message is observed with the disk which was initialized as cds_efi and later on this was initialized as hpdisk. A harmless message "checksum mismatch" is thrown out even when the diskgroup initialization is successful. RESOLUTION: Remove the harmless message "GPT entries checksum mismatch" * 2384473 (Tracking ID: 2064490) SYMPTOM: vxcdsconvert utility fails if disk capacity is greater than or equal to 1 TB DESCRIPTION: VxVM cdsdisk uses GPT layout if the disk capacity is greater than 1 TB and uses VTOC layout if the disk capacity is less 1 TB. Thus, vxcdsconvert utility was not able to convert to the GPT layout if the disk capacity is greater than or equal to 1 TB. RESOLUTION: This issue has been resolved by converting to proper cdsdisk layout depending on the disk capacity * 2384844 (Tracking ID: 2356744) SYMPTOM: When "vxvm-recover" are executed manually, the duplicate instances of the Veritas Volume Manager(VxVM) daemons (vxattachd, vxcached, vxrelocd, vxvvrsecdgd and vxconfigbackupd) are invoked. When user tries to kill any of the daemons manually, the other instances of the daemons are left on this system. DESCRIPTION: The Veritas Volume Manager(VxVM) daemons (vxattachd, vxcached, vxrelocd, vxvvrsecdgd and vxconfigbackupd) do not have : 1. A check for duplicate instance. and 2. Mechanism to clean up the stale processes. Because of this, when user executes the startup script(vxvm-recover), all daemons are invoked again and if user kills any of the daemons manually, the other instances of the daemons are left on this system. RESOLUTION: The VxVM daemons are modified to do the "duplicate instance check" and "stale process cleanup" appropriately. * 2386763 (Tracking ID: 2346470) SYMPTOM: The Dynamic Multi Pathing Administration operations such as "vxdmpadm exclude vxvm dmpnodename=" and "vxdmpadm include vxvm dmpnodename= " triggers memory leaks in the heap segment of VxVM Configuration Daemon (vxconfigd). DESCRIPTION: vxconfigd allocates chunks of memory to store VxVM specific information of the disk being included during "vxdmpadm include vxvm dmpnodename=" operation. The allocated memory is not freed while excluding the same disk from VxVM control. Also when excluding a disk from VxVM control, another chunk of memory is temporarily allocated by vxconfigd to store more details of the device being excluded. However this memory is not freed at the end of exclude operation. RESOLUTION: Memory allocated during include operation of a disk is freed during corresponding exclude operation of the disk. Also temporary memory allocated during exclude operation of a disk is freed at the end of exclude operation. * 2389095 (Tracking ID: 2387993) SYMPTOM: In presence of NR (Not-Ready) devices, vxconfigd (VxVM configuration daemon) goes into disabled mode once restarted. # vxconfigd -k -x syslog # vxdctl mode mode: disabled If vxconfigd is restarted in debug mode at level 9 following message could be seen. # vxconfigd -k -x 9 -x syslog VxVM vxconfigd DEBUG V-5-1-8856 DA_RECOVER() failed, thread 87: Kernel and on-disk configurations don't match DESCRIPTION: When vxconfid is restarted, all the VxVM devices are recovered. As part of recovery the capacity of the device is read, which can fail with EIO. This error is not handled properly. As a result of this the vxconfigd is going to DISABLED state. RESOLUTION: EIO error code from read capacity ioctl is handled specifically. * 2397663 (Tracking ID: 2165394) SYMPTOM: If the cloned copy of a diskgroup and a destroyed diskgroup exists on the system, an import operation imports destroyed diskgroup instread of cloned one. For example, consider a system with diskgroup dg containing disk disk1. Disk disk01 is cloned to disk02. When diskgroup dg containing disk01 is destroyed and diskgroup dg is imported, VXVM should import dg with cloned disk i.e disk02. However, it imports the diskgroup dg with disk01. DESCRIPTION: After destroying a diskgroup, if the cloned copy of the same diskgroup exists on the system, the following disk group import operation wrongly identifies the disks to be import and hence destroyed diskgroup gets imported. RESOLUTION: The diskgroup import code is modified to identify the correct diskgroup when a cloned copy of the destroyed diskgroup exists. * 2405446 (Tracking ID: 2253970) SYMPTOM: Enhancement to customize private region I/O size based on maximum transfer size of underlying disk. DESCRIPTION: There are different types of Array Controllers which support data transfer sizes starting from 256K and beyond. VxVM tunable volmax_specialio controls vxconfigd's configuration I/O as well as Atomic Copy I/O size. When volmax_specialio is tuned to a value greater than 1MB to leverage maximum transfer sizes of underlying disks, import operation is failing for disks which cannot accept more than 256K I/O size. If the tunable is set to 256k then it will be the case where large transfer size of disks is not being leveraged. RESOLUTION: This enhancement leverages large disk transfer sizes as well as supports Array controllers with 256K transfer sizes. * 2408209 (Tracking ID: 2291226) SYMPTOM: Data corruption can be observed on a CDS (Cross-platform Data Sharing) disk, whose capacity is more than 1 TB. The following pattern would be found in the data region of the disk. cyl alt 2 hd sec DESCRIPTION: The CDS disk maintains a SUN vtoc in the zeroth block of the disk. This VTOC maintains the disk geometry information like number of cylinders, tracks and sectors per track. These values are limited by a maximum of 65535 by design of SUN's vtoc, which limits the disk capacity to 1TB. As per SUN's requirement, few backup VTOC labels have to be maintained on the last track of the disk. VxVM 5.0 MP3 RP3 allows to setup CDS disk on a disk with capacity more than 1TB. The data region of the CDS disk would span more than 1TB utilizing all the accessible cylinders of the disk. As mentioned above, the VTOC labels would be written at zeroth block and on the last track considering the disk capacity as 1TB. The backup labels would fall in to the data region of the CDS disk causing the data corruption. RESOLUTION: Suppress writing the backup labels to prevent the data corruption. * 2409212 (Tracking ID: 2316550) SYMPTOM: While doing cold/ignite install to 11.31 + VxVM 5.1, following warning messages are seen on a setup with ALUA array: "VxVM vxconfigd WARNING V-5-1-0 ddl_add_disk_instr: Turning off NMP Alua mode failed for dmpnode 0xffffffff with ret = 13 " DESCRIPTION: The above warning messages are displayed by vxconfigd started at the early boot if fails to turn off the NMP ALUA mode for a given dmp device. These messages are not harmful, as later vxconfigd started in enabled mode will turn off the NMP ALUA mode for all the dmp devices. RESOLUTION: Changes done in vxconfigd to not to print these warning messages in vxconfigd boot mode. * 2411052 (Tracking ID: 2268408) SYMPTOM: 1) On suppressing the underlying path of powerpath controlled device, the disk goes in error state. 2) "vxdmpadm exclude vxvm dmpnodename=" command does not suppress TPD devices. DESCRIPTION: During discovery, H/W path corresponding to the basename is not generated for powerpath controlled devices because basename does not contain the slice portion. Device name with s2 slice is expected while generating H/W name. RESOLUTION: Whole disk name i.e., device name with s2 slice is used to generate H/W path. * 2411053 (Tracking ID: 2410845) SYMPTOM: If a DG(Disk Group) is imported with reservation key, then during DG deport lots of 'reservation conflict' messages will be seen. [DATE TIME] [HOSTNAME] multipathd: VxVM26000: add path (uevent) [DATE TIME] [HOSTNAME] multipathd: VxVM26000: failed to store path info [DATE TIME] [HOSTNAME] multipathd: uevent trigger error [DATE TIME] [HOSTNAME] multipathd: VxVM26001: add path (uevent) [DATE TIME] [HOSTNAME] multipathd: VxVM26001: failed to store path info [DATE TIME] [HOSTNAME] multipathd: uevent trigger error .. [DATE TIME] [HOSTNAME] kernel: sd 2:0:0:2: reservation conflict [DATE TIME] [HOSTNAME] kernel: sd 2:0:0:2: reservation conflict [DATE TIME] [HOSTNAME] kernel: sd 2:0:0:1: reservation conflict [DATE TIME] [HOSTNAME] kernel: sd 2:0:0:2: reservation conflict [DATE TIME] [HOSTNAME] kernel: sd 2:0:0:1: reservation conflict [DATE TIME] [HOSTNAME] kernel: sd 2:0:0:2: reservation conflict DESCRIPTION: When removing a PGR(Persistent Group Reservation) key during DG deport, we need to preempt the key but the preempt operation is failed with reservation conflict error because the passing key for preemption is not correct. RESOLUTION: Code changes are made to set the correct key value for the preemption operation. * 2413908 (Tracking ID: 2413904) SYMPTOM: Performing Dynamic LUN reconfiguration operations (adding and removing LUNs), can cause corruption in DMP database. This in turn may lead to vxconfigd core dump OR system panic. DESCRIPTION: When a LUN is removed from the VM using 'vxdisk rm' and at the same time some new LUN is added and in case the newly added LUN reuses the devno of the removed LUN then this may corrupt the DMP database as this condition is not handled currently. RESOLUTION: Fixed the DMP code to handle the mentioned issue. * 2415566 (Tracking ID: 2369177) SYMPTOM: When using > 2TB disks and the device respons to SCSI inquiry but fails to service I/O, data corruption can occur as the write I/O would be directed at an incorrect offset DESCRIPTION: Currently when the failed I/O is retried, DMP assumes the offset to be a 32 bit value and hence I/O offsets >2TB can get truncated leading to the rety I/O issued at wrong offset value RESOLUTION: Change the offset value to a 64 bit quantity to avoid truncation during I/O retries from DMP. * 2415577 (Tracking ID: 2193429) SYMPTOM: Enclosure attributes like iopolicy, recoveryoption etc do not persist across reboots in case when before vold startup itself DMP driver is already configured before with different array type (e.g. in case of root support) than stored in array.info. DESCRIPTION: When DMP driver is already configured before vold comes up (as happens in root support), then the enclosure attributes do not take effect if the enclosure name in kernel has changed from previous boot cycle. This is because when vold comes up da_attr_list will be NULL. And then it gets events from DMP kernel for data structures already present in kernel. On receiving this information, it tries to write da_attr_list into the array.info, but since da_attr_list is NULL, array.info gets overwritten with no data. And hence later vold could not correlate the enclosure attributes present in dmppolicy.info with enclosures present in array.info, so the persistent attributes could not get applied. RESOLUTION: Do not overwrite array.info of da_attr_list is NULL * 2417205 (Tracking ID: 2407699) SYMPTOM: The vxassist command dumps core if the file "/etc/default/vxassist" contains the line "wantmirror=" DESCRIPTION: vxassist, the Veritas Volume Manager client utility can accept attributes from the system defaults file (/etc/default/vxassist), the user specified alternate defaults file and the command line. vxassist automatically merges all the attributes by pre-defined priority. However, a null pointer checking is missed while merging "wantmirror" attribute which leads to the core dump. RESOLUTION: Within vxassist, while merging attributes, add a check for NULL pointer. * 2421491 (Tracking ID: 2396293) SYMPTOM: On VXVM rooted systems, during machine bootup, vxconfigd core dumps with following assert and machine does not bootup. Assertion failed: (0), file auto_sys.c, line 1024 05/30 01:51:25: VxVM vxconfigd ERROR V-5-1-0 IOT trap - core dumped DESCRIPTION: DMP deletes and regenerates device numbers dynamically on every boot. When we start static vxconfigd in boot mode, since ROOT file system is READ only, new DSF's for DMP nodes are not created. But, DMP configures devices in userland and kernel. So, there is mismatch in device numbers of the DSF's and that in DMP kernel, as there are stale DSF's from previous boot present. This leads vxconfigd to actually send I/O's to wrong device numbers resulting in claiming disk with wrong format. RESOLUTION: Issue is fixed by getting the device numbers from vxconfigd and not doing stat on DMP DSF's. * 2428179 (Tracking ID: 2425722) SYMPTOM: VxVM's subdisk operation - vxsd mv - fails on subdisk sizes greater than or equal to 2TB. Eg: #vxsd -g nbuapp mv disk_1-03 disk_2-03 VxVM vxsd ERROR V-5-1-740 New subdisks have different size than subdisk disk_1- 03, use -o force DESCRIPTION: VxVM code uses 32-bit unsigned integer variable to store the size of subdisks which can only accommodate values less than 2TB. Thus, for larger subdisk sizes integer overflows resulting in the subdisk move operation failure. RESOLUTION: The code has been modified to accommodate larger subdisk sizes. * 2440351 (Tracking ID: 2440349) SYMPTOM: The grow operation on a DCO volume may grow it into any 'site' not honoring the allocation requirements strictly. DESCRIPTION: When a DCO volume is grown, it may not honor the allocation specification strictly to use only a particular site even though they are specified explicitly. RESOLUTION: The Data Change Object of Volume Manager is modified such that it will honor the alloc specification strictly if provided explicitly * 2442850 (Tracking ID: 2317703) SYMPTOM: When the vxesd daemon is invoked by device attach & removal operations in a loop, it leaves open file descriptors with vxconfigd daemon DESCRIPTION: The issue is caused due to multiple vxesd daemon threads trying to establish contact with vxconfigd daemon at the same time and ending up using losing track of the file descriptor through which the communication channel was established RESOLUTION: The fix for this issue is to maintain a single file descriptor that has a thread safe reference counter thereby not having multiple communication channels established between vxesd and vxconfigd by various threads of vxesd. * 2477291 (Tracking ID: 2428631) SYMPTOM: Shared DG import or Node Join fails with Hitachi Tagmastore storage DESCRIPTION: CVM uses different fence key for every DG. The key format is of type 'NPGRSSSS' where N is the node id (A, B, C..) and 'SSSS' is the sequence number. Some arrays have a restriction on total number of unique keys that can be registered (eg Hitachi Tagmastore) and hence causes issues for configs involving large number of DGs, rather the product of #DGs and #nodes in the cluster. RESOLUTION: Having a unique key for each DG is not essential. Hence a tunable is added to control this behavior. # vxdefault list KEYWORD CURRENT-VALUE DEFAULT-VALUE ... same_key_for_alldgs off off ... Default value of the tunable is 'off' to preserve the current behavior. If a configuration hits the storage array limit on total number of unique keys, the tunable value could be changed to 'on'. # vxdefault set same_key_for_alldgs on # vxdefault list KEYWORD CURRENT-VALUE DEFAULT-VALUE ... same_key_for_alldgs on off ... This would make CVM generate same key for all subsequent DG imports/creates. Already imported DGs need to be deported and re-imported for them to take into consideration the changed value of the tunable. * 2480006 (Tracking ID: 2400654) SYMPTOM: "vxdmpadm listenclosure" command hangs because of duplicate enclosure entries in /etc/vx/array.info file. Example: Enclosure "emc_clariion0" has two entries. #cat /etc/vx/array.info DD4VM1S emc_clariion0 0 EMC_CLARiiON DISKS disk 0 Disk DD3VM2S emc_clariion0 0 EMC_CLARiiON DESCRIPTION: When "vxdmpadm listenclosure" command is run, vxconfigd reads its in-core enclosure list which is populated from the /etc/vx/array.info file. Since the enclosure "emc_clariion0" (as mentioned in the example) is also a last entry within the file, the command expects vxconfigd to return the enclosure information at the last index of the enclosure list. However because of duplicate enclosure entries, vxconfigd returns a different enclosure information thereby leading to the hang. RESOLUTION: The code changes are made in vxconfigd to detect duplicate entries in /etc/vx/array.info file and return the appropriate enclosure information as requested by the vxdmpadm command. * 2483476 (Tracking ID: 2491091) SYMPTOM: The vxdisksetup(1M) command fails on the disk which have stale EFI information, with the following error: VxVM vxdisksetup ERROR V-5-2-4686 Disk is currently an EFI formatted disk. Use -f option to force EFI removal. DESCRIPTION: The vxdisksetup(1M) command checks for the EFI headers on the disk, if found then vxdisksetup(1M) command exits with the suggestion to use "-f" option. The check for the EFI headers is not correct to take care of stale EFI headers, so the vxdisksetup(1M) command exits with the error. RESOLUTION: The code is modified to check the valid EFI headers. * 2485230 (Tracking ID: 2481938) SYMPTOM: The vxdisk command displays incorrect pubpath of an EFI partitioned disk on HP 1131 platform. For example, # vxdisk list cXtXdXs2 Device: diskX_p2 devicetag: cXtXdXs2 .. pubpaths: block=/dev/vx/dmp/cXtXdX char=/dev/vx/rdmp/cXtXdX ... DESCRIPTION: The VxVM configuration daemon (vxconfigd) maintains all the disks' information. On HP platform, an EFI disk has EFI_SDI_FLAG flag set. When the vxconfigd sets up an EFI partitioned disk, the EFI_SDI_FLAG is checked firstly and vxconfigd changes the disk access name according to the flag and the disk's original value. However, in some cases vxconfigd still uses the original disk access name not the new disk access name which lead to the incorrect subpath value. RESOLUTION: vxconfigd is modified to use the new disk access name. * 2485278 (Tracking ID: 2386120) SYMPTOM: Error messages printed in the syslog in the event of master takeover failure in some situations are not be enough to find out the root cause of the failure. DESCRIPTION: During master takeover if the new master encounters some errors, the master takeover operation fails. We have messages in the code to log the reasons for the failure. These log messages are not available on the customer setups. These are generally enabled in the internal developmenttesting scenarios. RESOLUTION: Some of the relevant messages have been modified such that they will now be available on the customer setups as well, logging crucial information for root cause analysis of the issue. * 2485288 (Tracking ID: 2431470) SYMPTOM: 1. "vxpfto" command sets PFTO(Powerfail Timeout) value on a wrong VxVM device when it passes DM(Disk Media) name to the "vxdisk set" command with -g option. 2. "vxdisk set" command does not work when DA name is specified either -g option specified or not. Ex.) # vxdisk set [DA name] clone=off VxVM vxdisk ERROR V-5-1-5455 Operation requires a disk group # vxdisk -g [DG name] set [DA name] clone=off VxVM vxdisk ERROR V-5-1-0 Device [Da name] not in configuration or associated with DG [DG name] DESCRIPTION: 1. "vxpfto" command invokes "vxdisk set" command to set the PFTO value. It shall accept both DM and DA names for device specification. However DM and DA names can have conflicts such that even within the same disk group, the same name can refer to different devices - one as a DA name and another as a DM name. "vxpfto" command uses a DM name with -g option when invoking the "vxdisk set" command but it will choose a matching DA name before a DM name. This causes incorrect device to be acted upon. Both DM and DA name can be specified for the "vxdisk set" command with -g option however the DM name are given preference with -g option from the design perspective. 2. "vxdisk set" command shall accept DA name for device specification. Without -g option, the command shall work only when DA name is specified. However it doesn't work because the disk group name is not extracted from the DA record correctly. Hence the first error. With -g option the DA name specified is treated as a matching DM name wrongly, hence the second error. RESOLUTION: Code changes are made to make the "vxdisk set" command working correctly on DA name without -g option and on both DM and DA names with -g option. The given preference is DM name when -g option is specified. It resolves the "vxpfto" command issue as well. * 2492016 (Tracking ID: 2232411) SYMPTOM: Subsequent resize operations of raid5 or layered volumes may fail with "VxVM vxassist ERROR V-5-1-16092 Volume TCv7-13263: There are other recovery activities. Cannot grow volume" DESCRIPTION: If a user tries to grow or shrink a raid5 volume or a layered volume more than once using vxassist command, the command may fail with the above mentioned error message. RESOLUTION: 1. Skip setting recover offset for RAID volumes. 2. For layered volumes, topvol: skip setting recover offset. subvols: handles separately later. (code exists). INSTALLING THE PATCH -------------------- a) VxVM 5.1 SP1 (GA)version 5.1.100.000 or version 5.1.100.001 must be installed before applying these patches. b) VxVM VRTSaslapm version must be 5.1.103.100 or higher. c) Below filesets on system must be B.11.31.1311 or higher: FC-COMMON.FC-SNIA SAS-COMMON.SAS-COMMON-RUN FC-FCD.FC-FCD-RUN FC-FCLP.FC-FCLP-RUN FC-FCOC.FC-FCOC-RUN Please refer to the link for detail info: http://www.symantec.com/business/support/index?page=content&amp;amp;id=TECH200183 NOTE: In a CVM cluster environment, patch can be installed one node at a time. If VCS is installed: Shutdown VCS on the node using the command # /opt/VRTSvcs/bin/hastop -local If Serviceguard SMS (Storage Management Suite) is installed: Stop the node use the below command # cmhaltnode [-f] NOTE: For environments other than VCS and Serviceguard SMS, please refer to Release Note or contact Symantec support. d) In case the patch is not registered, the patch can be registered using the following command: # swreg -l depot patch_directory where patch_directory is the absolute path where the patch resides. e) To install the patch, enter the following command: # swinstall -x autoreboot=true -s patch_directory PHCO_44714, PHKL_44661 where patch_directory is the absolute path where the patch resides. NOTE: After this step the system would be rebooted. f) Please do swverify after installing the patches in order to make sure that the patches are installed correctly using: # swverify PHCO_44714, PHKL_44661 If VCS is installed: Start VCS using the command # /opt/VRTSvcs/bin/hastart If Serviceguard SMS (Storage Management Suite) is installed: Start the node using command # cmrunnode NOTE: For environments other than VCS and Serviceguard SMS, please refer to Release Note or contact Veritas support. REMOVING THE PATCH ------------------ NOTE: In a CVM cluster environment, patch can be removed one node at a time. If VCS is installed: Shutdown VCS on the node using the command # /opt/VRTSvcs/bin/hastop -local If Serviceguard SMS (Storage Management Suite) is installed: Stop the node use the below command # cmhaltnode [-f] NOTE: For environments other than VCS and Serviceguard SMS, please refer to Release Note or contact Symantec support. To remove the patch, enter the following command: # swremove -x autoreboot=true PHCO_44714, PHKL_44661 NOTE: After this step the system would be rebooted. If VCS is installed: Start VCS using the command # /opt/VRTSvcs/bin/hastart If Serviceguard SMS (Storage Management Suite) is installed: Start the node using command # cmrunnode NOTE: For environments other than VCS and Serviceguard SMS, please refer to Release Note or contact Symantec support. SPECIAL INSTRUCTIONS -------------------- NONE OTHERS ------ NONE