README VERSION : 1.1 README CREATION DATE : 2015-04-20 PATCH-ID : 151232-01 PATCH NAME : VRTSvxvm 6.2.1.000 BASE PACKAGE NAME : VRTSvxvm BASE PACKAGE VERSION : 6.2.0.000 SUPERSEDED PATCHES : NONE REQUIRED PATCHES : NONE INCOMPATIBLE PATCHES : NONE SUPPORTED PADV : sol10_sparc (P-PLATFORM , A-ARCHITECTURE , D-DISTRIBUTION , V-VERSION) PATCH CATEGORY : CORE , CORRUPTION , HANG , MEMORYLEAK , PANIC , PERFORMANCE PATCH CRITICALITY : CRITICAL HAS KERNEL COMPONENT : YES ID : NONE REBOOT REQUIRED : YES REQUIRE APPLICATION DOWNTIME : YES PATCH INSTALLATION INSTRUCTIONS: -------------------------------- Please refer to Install guide for install instructions. PATCH UNINSTALLATION INSTRUCTIONS: ---------------------------------- Please refer to Install guide for uninstall instructions. SPECIAL INSTRUCTIONS: --------------------- NONE SUMMARY OF FIXED ISSUES: ----------------------------------------- PATCH ID:151232-01 3470267 (3414023) If a volume has preexisting snapshots, reattaching a detached plex would resync the extra data. 3656538 (3506450) When migrating from PowerPath to Dynamic Multipathing (DMP), you may observe a system panic or VxVM configuration daemon (vxconfigd) core. 3657352 (3424704) Some VxVM commands fail on using the localized messages. 3661664 (3322760) "vxdisk list" command may list detached disks, if the options are fullshared, partialshared, or local. 3661672 (3442024) The vxdiskadm(1M) option #1(adding disk to disk group and initialization) does not support Extensible Firmware Interface(EFI) disks on Solaris operating system. 3661680 (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. 3661688 (3571434) DMP does not support NetApp cDOT cluster mode array with more than 2 nodes. 3661708 (3594158) The spinlock and unspinlock are referenced to different objects when interleaving with a kernel transaction. 3661712 (3599977) During a replica connection, referencing a port that is already deleted in another thread causes a system panic. 3661723 (3616671) The number of transaction log files is reset to default value 10, even though it is explicitly set to the no_limit value. 3661726 (3621232) The vradmin ibc command cannot be started or executed on Veritas Volume Replicators (VVR) secondary node. 3661731 (3625890) vxdisk resize operation on CDS disks fails with an error message of "Invalid attribute specification" 3661756 (3628860) The vxdisk(1M) command shows disks with status as nolabel in the outputs. 3661780 (3628933) Volumes remain in the DETACHED state, even after nodes with storage join back to the cluster. 3661783 (3631025) The I/O statistics derived using the vxstat utility with "-ft" or "-fi" options along with -i option do not provide the system name and its origin (source or destination). 3661798 (3631989) The vxconfigd(1M) daemon becomes unresponsive on the joiner node. 3661845 (3644687) In a Veritas Volume Replicator (VVR) environment, any node on the Primary cluster may panic during the I/O error handling. 3661847 (3645370) vxevac command fails to evacuate disks with Dirty Region Log(DRL) plexes. 3661849 (3651034) Temporary loss of storage results in application I/O failure. 3661859 (3656539) I/O may hang when SmartIO VxVM block level is configured in only few nodes of cluster, while there are volumes with instant snapshots. 3663698 (3658079) If the size of backup slice of volumes is larger than 64GB, Veritas Volume manager (VxVM) wraps it around it and exports it to LDOM (Logical Domains) guest domain. 3675114 (3671975) The system panics when Veritas Volume manager (VxVM) cachearea is configured in Cluster Volume Manager (CVM). 3680504 (3688156) The output of vxdisk -o local|partialshared list command lists disks in the error state. 3681349 (3651422) "sfcache app" command fails for Sybase application on Solaris. 3683458 (3648719) The server panics while adding or removing LUNs or HBAs. 3683471 (3674614) Restarting the vxconfigd(1M) daemon on the slave (joiner) node during node-join operation may cause the vxconfigd(1M) daemon to become unresponsive on the master and the joiner node. 3683473 (3644291) Some of the disk groups that are composed by 2TB LUNs fail to be auto-imported after a system restart. 3687115 (3669863) "sfcache list" command doesn't show storage devices in the output if "cachearea" is created on stripe-mirror volume. 3702026 (3564260) VVR commands are unresponsive when replication is paused and resumed in a loop. 3709111 (3588012) The vxconfigd(1M) daemon observes memory leak while printing I18N messages. 3724448 (2965910) Volume creation with the vxassist(1M) command dumps core when the non-disk parameters are specified along with the '-o ordered' option. 3726526 (3736156) Solaris 11 update 1 system fails to come up after enabling dmp_native_support and reboot. 3733113 (3672759) The vxconfigd(1M) daemon may core dump when DMP database is corrupted. 3735665 (3727939) Data corruption may occur due to stale device entries in the /dev/vx/[r]dmp directories. 3736633 (3677359) VxDMP (Veritas Dynamic MultiPathing) causes system panic after a shutdown or reboot. 3738576 (3420347) Write errors occur with "vxdg flush" running. 3742578 (3747701) In Cluster Volume Manager (CVM) environment, node-join process fails and node remains in joining state. 3750631 (3749557) System hangs because of high memory usage by vxvm. 3751524 (3719478) ZFS zpool auto LUN expansion is not detected when dmp_native_support is enabled. SUMMARY OF KNOWN ISSUES: ----------------------------------------- 3718348 (3736095) vxassist fails to create volume with maxsize option on fss dg having disk local to one node and exported for fss dg. 3736627 (3558199) VRAS "verifydata" command fails without cleaning up the snapshots created 3757191 (3538594) Root disk encapsulation fails for root volume and swap volume configured on thin LUNs. 3757206 (2858900) The "vxdisk resize" command fails on Solaris 11 during expansion of the LUN from array side. 3757214 (3492350) SmartIO VxVM cache invalidated after relayout operation. 3757219 (3133500) Importing an exported zpool can fail when DMP native support is on 3757294 (2815311) vxmirror to SAN destination failing when 5 partition layout is present: for example, root, swap, home, var, usr. 3757298 (2802698) Performance impact when a large number of disks are reconnected. 3757303 (1834513) Veritas Volume Manager (VxVM) might report false serial split brain under certain scenarios 3757308 (2715119) Upgrading from Symantec Storage Foundation and High Availability Solutions 5.x to 6.2.1 may fail for IBM XIV Series arrays. 3757817 (2064510) Cannot grow Veritas Volume Manager (VxVM) disk using the vxdisk resize command during Dynamic LUN Expansion operation. 3757819 (2831658) Disk group import of BCV LUNs using -o updateid and -ouseclonedev options is not supported if the disk group has mirrored volumes with DCO or has snapshots 3757820 (2757198) After devices that are managed by EMC PowerPath lose access to storage, Veritas Volume Manager commands are delayed. 3757822 (3301991) vxresize does not work with layered volumes that have multiple plexes at the top level. 3757823 (3237696) In a clustered configuration with Oracle ASM and DMP and AP/F array, when all the storage is removed from one node in the cluster, the Oracle DB is unmounted from other nodes of the cluster 3757824 (3272940) The DMP EMC CLARiiON ASL does not recognize mirror view not ready LUNs 3757839 (3289311) When all Primary/Optimized paths between the server and the storage array are disconnected, ASM disk group dismounts and the Oracle database may go down 3757856 (3338075) Running the vxdisk disk set clone=off command on imported clone disk group luns results in a mix of clone and non-clone disks. 3757872 (3110589) The administrator must explicitly enable and disable support for a clone device created from an existing root pool. 3757877 (3591019) Restarting the vxconfigd daemon on the slave node after a disk is removed from all nodes may cause the disk groups to be disabled on the slave node. 3757880 (2562889) Issues if the storage connectivity to data disks is lost on a CVM slave node while vxconfigd was not running on the node. 3757884 (2616422) The vxcdsconvert utility is supported only on the master node. 3757888 (2615680) Issues with the disk state on the CVM slave node when vxconfigd is restarted on all nodes. 3757890 (2788077) Plex synchronization is not completed after resuming synchronization on a new master when the original master lost connectivity. 3757899 (2836798) Dynamic LUN expansion is not supported for EFI disks in simple or sliced format and non-EFI disks greater than 1TB in simple or sliced format. 3757903 (2360780) The vxsnap print command shows incorrect value for percentage dirty 3757919 (3178642) For Solaris 11.1 or later, uninstalling DMP or disabling DMP native support requires steps to enable booting from alternate root pools. 3757925 (3157394) For Solaris 11.1 or later, after enabling DMP native support for ZFS, only the current boot environment is bootable. 3757931 (3221944) Limitation to DMP support for ZFS root in the Oracle VM Server for SPARC guest. 3757939 (3084656) When dmp_native_support is set to on, commands hang for a long time on SAN failures. 3757942 (3628743) System hangs on a boot up after Boot Environment upgrades to Solaris 11 Update 2 and SF 6.2 from Solaris 11 GA. 3757962 (1672417) In an IPv6-only environment RVG, data volumes or SRL names cannot contain a colon. 3757966 (2129601) Cannot relayout data volumes in an RVG from concat to striped-mirror. 3758008 (2360713) vradmin verifydata operation fails when replicating between versions 5.1 and 6.0. 3758015 (2834424) vradmin verifydata may report differences in a cross-endian environment. 3758021 (2808902) vradmin verifydata operation fails if the RVG contains a volume set. 3758026 (3329970) Bunker replay does not occur with volume sets. 3758030 (3270067) During moderate to heavy I/O, the vradmin verifydata command may falsely report differences in data. 3758035 (3347656) While vradmin commands are running, vradmind may temporarily lose heartbeats, 3758040 (2622536) Write I/Os on the primary logowner may take a long time to complete. 3758044 (3642855) After performing a CVM master switch on the secondary node, both rlinks detach. 3758145 (2787766) Server panic after losing connectivity to the voting disk. 3758159 (1933631) Suppressing the primary path of an encapsulated SAN boot disk from Veritas Volume Manager causes the system reboot to fail. 3758163 (2490012) After changing the preferred path from the array side, the secondary path becomes active. 3758167 (2816589) Removing an array node from an IBM Storwize V7000 storage system also removes the controller. 3758176 (2082414) Changes in enclosure attributes are not persistent after an upgrade from release prior to VxVM 5.1SP1. 3758183 (1856723) Failback to primary paths does not occur if the node that initiated the failover leaves the cluster. 3758189 (2425977) Re-enabling connectivity if the disks are in local failed (lfailed) state. 3758209 (2764153) A master node is not capable of doing recovery if it cannot access the disks belonging to any of the plexes of a volume. 3758215 (2787713) CVM fails to start if the first node joining the cluster has no connectivity to the storage. 3758290 (3236772) Transactions on VVR secondary nodes may timeout waiting for I/O drain. 3758291 (1672410) In an IPv6-only environment RVG, data volumes or SRL names cannot contain a colon 3758297 (2071568) While vradmin commands are running, vradmind may temporarily lose heart beats. 3760326 (3134882) Importing a clone disk group fails after splitting pairs. 3761443 (3761441) DMPuses OS device physical path to maintain persistence of path attributes from 6.0 3761482 (3761474) Disk greater than 1TB gos into error state. 3761493 (2706776) 1 TB luns goes in error state with Solaris x86 . 3761498 (3761497) A snapshot volume created on the Secondary, containing a VxFS file system may not mount in read-write mode and performing a read-write mount of the VxFS file systems on the new Primary after a global clustering site failover may fail. 3761511 (145413) vxassist relayout removes the DCM. 3761513 (3343141) The vradmin repstatus command does not show thatthe SmartSync feature is running. 3761528 (2158679) vradmin functionality may not work after a master switch operation. 3761574 (2036644) Bunker replay did not occur when the Application Service Group was configured on some of the systems in the Primary cluster, and ClusterFailoverPolicy is set to "AUTO" 3761575 (2075307) vradmin syncvol command compatibility with IPv6 addresses. 3761580 (2036605) RVGPrimary agent operation to start replication between the original Primary and the bunker fails during failback. 3761582 (1825031) In an IPv6-only environment RVG, data volumes or SRL names cannot contain a colon. KNOWN ISSUES : -------------- * INCIDENT NO:3718348 TRACKING ID:3736095 SYMPTOM: if disk having connectivity to one node and exported for FSS dg. Create volume with maxsize option (command: vxassist -g make maxsize) will fail with following message : VxVM vxassist ERROR V-5-1-18301 No volume can be created within the given constraints WORKAROUND: provide the size instead of "maxsize" at the time of creating volume on FSS dg having disk connectivity on single node. * INCIDENT NO:3736627 TRACKING ID:3558199 SYMPTOM: The "vradmin verifydata" and the "vradmin syncrvg" commands leave behind residues if terminated abnormally. These residues can be snapshot volumes or mount points. WORKAROUND: Remove the snapshot volumes and unmount the mount points manually. * INCIDENT NO:3757191 TRACKING ID:3538594 SYMPTOM: Root disk encapsulation fails if the root disk configuration on a thin LUN includes volumes such as var, usr, or home, in addition to the root volumes and the swap volumes. Root disk encapsulation is not supported in this configuration. WORKAROUND: None. * INCIDENT NO:3757206 TRACKING ID:2858900 SYMPTOM: On Solaris 11, the "vxdisk resize" command may fail with similar error as follows: bash# vxdisk -g testdg resize disk01 length=8g VxVM vxdisk ERROR V-5-1-8643 Device disk01: resize failed:Operation would block WORKAROUND: During the resize operation, run the aformat ada command after you change the size of LUN from array side. * INCIDENT NO:3757214 TRACKING ID:3492350 SYMPTOM: If a relayout operation is done on a volume that has SmartIO VxVM caching enabled, the contents of the cache for the volume may be invalidated. WORKAROUND: This behavior is expected. * INCIDENT NO:3757219 TRACKING ID:3133500 SYMPTOM: On Solaris, when the tunable dmp_native_support is set to on, importing an exported zpool using the command zpool import poolname can fail with following error: Assertion failed: rn->rn_nozpool == B_FALSE, file ../common/libzfs_import.c, line 1084, function zpool_open_func Abort (core dumped) WORKAROUND: Import the zpool using the following command, specifying the DMP device directory: # zpool import -d /dev/vx/dmp poolname * INCIDENT NO:3757294 TRACKING ID:2815311 SYMPTOM: The vxmirror command may fail with following error on a Solaris 10 host, for a thin LUN, if more than one partition excluding root and swap is present. VxVM vxbootsetup WARNING V-5-2-5667 Max volume count 5 exceeded. Example # /etc/vx/bin/vxmirror" -f -g rootdg_17_23_49 rootdisk01 rootdisk02 ! vxassist -g rootdg_17_23_49 mirror swapvol rootdisk02 ! vxassist -g rootdg_17_23_49 mirror rootvol rootdisk02 ! vxassist -g rootdg_17_23_49 mirror usr rootdisk02 ! vxassist -g rootdg_17_23_49 mirror var rootdisk02 ! vxassist -g rootdg_17_23_49 mirror home rootdisk02 ! vxbootsetup -g rootdg_17_23_49 VxVM vxbootsetup WARNING V-5-2-5667 Max volume count 5 exceeded. VxVM vxbootsetup ERROR V-5-2-5678 Skipping volume 'home_dcl' because no free partitions are available on disk 'disk_0'. Either remove the volume or make a partition available VxVM vxbootsetup WARNING V-5-2-5667 Max volume count 5 exceeded. VxVM vxbootsetup ERROR V-5-2-5678 Skipping volume 'usr_dcl' because no free partitions are available on disk 'disk_0'. Either remove the volume or make a partition available VxVM vxbootsetup WARNING V-5-2-5667 Max volume count 5 exceeded. VxVM vxbootsetup ERROR V-5-2-5678 Skipping volume 'var_dcl' because no free partitions are available on disk 'disk_0'. Either remove the volume or make a partition available /usr/lib/vxvm/bin/vxmksdpart: 3pardata0_2492: is not an identifier WORKAROUND: No * INCIDENT NO:3757298 TRACKING ID:2802698 SYMPTOM: If the storage connectivity is lost to part of the storage, the disk group configuration copy is rebalanced to the disks that have connectivity. For example, if the storage for an entire enclosure is removed from a disk group with muliple enclosures.The re-balancing process takes time, during which time the vxconfigd daemon is busy and does not respond to commands. WORKAROUND: No * INCIDENT NO:3757303 TRACKING ID:1834513 SYMPTOM: VxVM might detect and report a false serial split brain when all of the following conditions are met: 1. One or more arrays that provide the shared storage for the cluster are being powered off 2. At the same time when the arrays are being powered off, an operation that requires an internal transaction is initiated (such as VxVM configuration commands) In such a scenario, disk group import will fail with a split brain error and the vxsplitlines output will show 0 or 1 pools. WORKAROUND: To recover from this situation 1 Retrieve the disk media identifier (dm_id) from the configuration copy: # /etc/vx/diag.d/vxprivutil dumpconfig device-path The dm_id is also the serial split brain id (ssbid) 2 Use the dm_id in the following command to recover from the situation: # /etc/vx/diag.d/vxprivutil set device-path ssbid=dm_id * INCIDENT NO:3757308 TRACKING ID:2715119 SYMPTOM: Starting in the Symantec Storage Foundation and High Availability Solutions 5.1 SP1 release, the Array Support Library (ASL) for the IBM XIV enclosures converts the LUN Serial Number from hexadecimal to decimal. Because of this change, the enclosure names differ from releases prior to the 5.1 SP1 releases. When you upgrade Symantec Storage Foundation and High Availability Solutions from a release prior to that release to the current 6.2.1 release, XIV LUNs may go into an error state. Note that the latest RPs on 5.1/5.1SP1 are already modified to use the same logic for enclosure naming. WORKAROUND: After the upgrade, run vxddladm assign names . * INCIDENT NO:3757817 TRACKING ID:2064510 SYMPTOM: The following error message is displayed during the Dynamic LUN Expansion operation of a LUN with the SIMPLE format: VxVM vxdisk ERROR V-5-1-8643 Device : resize failed: Invalid data in request The vxdisk resize command keeps the cylinder size (number of the heads * total number of the sectors per track) constant before and after the resize operation, unless the number of cylinders go beyond 2^16-1 (65535) . Because of the VTOC limitation of storing geometry values only till 2^16 -1, if the number of cylinders increases beyond the limit, vxdisk resize increases the cylinder size. If this happens, the private region will overlap with the public region data and corrupt the user data. As a result of this LUN geometry change, VxVM is unable to complete vxdisk resize on simple format disks. VxVM was not designed to handle such geometry changes during Dynamic LUN Expansion operations on simple disks. WORKAROUND: The VxVM vxdisk resize command behaves differently depending on whether the disk is simple, sliced, or CDS format. The problem shown above only occurs on simple disk configurations. As a result of this difference in behavior, if the geometry changes during a Dynamic LUN Expansion operation at the LUN level, you can convert the disk to a CDS format disk. Use the vxcdsconvert command on the disk. Then you can issue the vxdisk resize command. See http://www.symantec.com/docs/TECH136240 for more information. * INCIDENT NO:3757819 TRACKING ID:2831658 SYMPTOM: VxVM uses guid stored in configuration to uniquely identify all objects. The data change object (DCO) volume stores the guid of mirrors and snapshots. If the disk group is imported with -o updateid and -o useclonedev , it changes the guid of objects in VxVM configuration database and the guids stored in the DCO volume are not updated. The operations involving DCO cannot find objects with the stored guid. This could lead to failure of certain operations involving DCO or could lead to unexpected behavior. WORKAROUND: No * INCIDENT NO:3757820 TRACKING ID:2757198 SYMPTOM: In an enviroment which includes devices that are managed by EMC PowerPath, a storage loss causes Veritas Volume Manager commands to be delayed. In the event of storage loss, VxVM sends SCSI inquiry to each LUN path to check the health of path, which are delayed by the presence of EMC PowerPath. WORKAROUND: None. * INCIDENT NO:3757822 TRACKING ID:3301991 SYMPTOM: If a layered volume has multiple plexes at the top level, vxresize does not work. For example, if you add a mirror to a concat-mirror volume for a third mirror snapshot. The vxresize operation fails with the following message: VxVM vxassist ERROR V-5-1-2528 Volume volname built on layered volumes have multiple plexes VxVM vxresize ERROR V-5-1-4703 Problem running vxassist command for volume volname, in diskgroup dgname WORKAROUND: To resize the volume 1 After adding the mirror to the volume, take a snapshot using the plex. 2 Grow the volume and snapshot volume with vxresize 3 Reattach the snapshot volume to the source volume. * INCIDENT NO:3757823 TRACKING ID:3237696 SYMPTOM: In a clustered configuration with Oracle ASM and DMP and AP/F array, when you remove all the storage from one node in the cluster, I/O is expected to fail on this node. Due to an issue with the Oracle ASM configuration, the Oracle database is unmounted from other nodes of the cluster. This issue is not seen if you delay the I/O failure from DMP. The Oracle database works fine on other node. WORKAROUND: Increase the dmp_lun_retry_timeout tunable value to 300 with following command. # vxdmpadm settune dmp_lun_retry_timeout=300 * INCIDENT NO:3757824 TRACKING ID:3272940 SYMPTOM: On hosts that have EMC CLARiiON mirror view not ready LUNs, if you enable or disable the switch port and then issue the vxdisk scandisks or vxdctl enable command, I/O error messages are written continuously in the syslog. The dynamic multi-pathing (DMP) request for providing information to identify mirror view not ready LUNs through in-band SCSI command is pending with EMC engineering. Not ready LUNs are special kind of LUNs which reject all kinds of I/O requests. Because DMP does not recognize not ready LUNs, Veritas Volume Manager (VxVM) tries to bring them online. As part of the online process, VxVM issues I/Os to read the disk private region. These I/Os fail and generate error messages in syslog. Because of events that are generated as part of the online process, the vxattachd script triggers the vxdisk scandisks command again. This cycle causes continuous I/O error messages. This problem can also cause other commands to run slowly because the VxVM configuration daemon ( vxconfigd ) is busy servicing vxdisk scandisks . WORKAROUND: Stop the vxattachd script and set EMC CLARiiON values, as follows: 1 Disable the vxattachd process. For more information on how to disable vxattachd and what features you lose if vxattachd is disabled, see the vxattachd man page 2 Set the following EMC CLARiiON values: a recoveryoption=fixedretry a retrycount=5 Enter: vxdmpadm setattr enclosure enclosure_name recoveryoption=fixedretry \ retrycount=5 * INCIDENT NO:3757839 TRACKING ID:3289311 SYMPTOM: The Oracle database shows an I/O error on the control file, but there was no I/O error seen on any DMP device. When all Primary/Optimized paths are disconnected, DMP fails over to other available paths but the failover takes time. In the meantime, the application (ASM/Oracle database) times out the I/O. The ASM alert log file displays messages such as the following: Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ckpt_6955.trc: ORA-00221: error on write to control file ORA-00206: error in writing (block 4, # blocks 1) of control file ORA-00202: control file: '+DATA_P6/ORCL/CONTROLFILE/current.261.826783133' ORA-15081: failed to submit an I/O operation to a disk ORA-15081: failed to submit an I/O operation to a disk Wed Oct 09 14:16:07 2013 WARNING: group 2 dismounted: failed to read virtual extent 0 of file 261 Wed Oct 09 14:16:07 2013 USER (ospid: 6955): terminating the instance due to error 221 Wed Oct 09 14:16:07 2013 WARNING: requested mirror side 2 of virtual extent 0 logical extent 1 offset 16384 is not allocated; I/O request failed WARNING: requested mirror side 3 of virtual extent 0 logical extent 2 offset 16384 is not allocated; I/O request failed The above issue may occur when the server is configured as follows: DB: Oracle 12c Volume Manager: ASM Multi-pathing Solutions: DMP OS: Solaris Disk Array : HP EVA in ALUA mode WORKAROUND: The following ways can reduce the probability of this issue, and when you see this issue, you could use Oracle commands to start the database manually. Increase the application time out and make the following changes to reduce the time taken to mark the path as offline: a In the /kernel/drv/fp.conf file, add fp_offline_ticker=15 . a In the /kernel/drv/fcp.conf file, add fcp_offline_delay=10 . * INCIDENT NO:3757856 TRACKING ID:3338075 SYMPTOM: If you do not specify a disk group name, the vxdisk set operation works on the dmname rather than the daname . If a dmname is the same as an existing daname , the vxdisk set operation reflects on the dm name. WORKAROUND: Use the following command syntax to set the attributes: vxdisk -g diskgroup_name set dmname clone=off For example: vxdisk -g dg1 set eva4k6k0_12 clone=off * INCIDENT NO:3757872 TRACKING ID:3110589 SYMPTOM: A non-rpool is a clone of the existing root pool. When native support is enabled, DMP does not touch the clone root pool because the clone may or may not have the VxVM package. WORKAROUND: To add or remove DMP support for a clone boot device, the administrator must boot through the clone and turn on/off dmp_native_support . * INCIDENT NO:3757877 TRACKING ID:3591019 SYMPTOM: The issue occurs if the storage connectivity of a disk is removed from all the nodes of the cluster and the vxconfigd daemon is restarted on the slave node before the disk is detached from the slave. All the disk groups are in the dgdisabled state on the slave node, but show as enabled on the other nodes. If the disk was detached before the vxconfigd daemon is restarted, the issue does not occur. In a Flexible Shared Storage (FSS) environment, removing the storage connectivity on a node that contributes DAS storage to a shared disk group results in global connectivity loss because the storage is not connected elsewhere. WORKAROUND: To prevent this issue: Before restarting the vxconfigd daemon, if a disk in a shared disk group has lost connectivity to all nodes in the cluster, make sure that the disk is in the detached state. If a disk needs to be detached, use the following command: # vxdisk check diskname To resolve the issue after it has occurred: If vxconfigd is restarted before the disks got detached, remove the node from the cluster and rejoin the node to the cluster. * INCIDENT NO:3757880 TRACKING ID:2562889 SYMPTOM: If storage connectivity to data disks is lost on a CVM slave node while vxconfigd was not running on the node, this may result in following issues when vxconfigd comes up on this node: a The shared disk groups on the disconnected storage are marked as dgdisabled on the slave node only. a The shared disk groups are available to rest of the cluster nodes but no transactions, such as VxVM configuration changes, are possible on any shared disk group. a Attempts to deport such shared disk groups will fail. WORKAROUND: remove the slave from the cluster and join it again. This is not regression in Pinnacle. The same behaviour is seen in maxfli also. * INCIDENT NO:3757884 TRACKING ID:2616422 SYMPTOM: The vxcdsconvert utility should not work on slave node. WORKAROUND: The vxcdsconvert utility should be run only from the master node, not from the slave nodes of the cluster. * INCIDENT NO:3757888 TRACKING ID:2615680 SYMPTOM: When a CVM master node and a slave node have lost storage access, and vxconfigd is restarted on all nodes, the disk state on the CVM slave node shows as invalid. WORKAROUND: No * INCIDENT NO:3757890 TRACKING ID:2788077 SYMPTOM: When you run vxrecover -o force , it recovers only one subvolume and it cannot detect that the rest of the volume needs recovery. When you run the vxassist mirror command, you run the vxplex att command serially on each subvolume. If the failure happens before you start the attach operation (need to mark the concerned plex as the attach operation is in progress), vxrecover will not redo the attach operation because it cannot find any record of the attach operation in progress. WORKAROUND: Run the following command on each subvolume to manually recover the complete volume: # usr/lib/vxvm/type/fsgen/vxplex -U fsgen -g diskgroup \ -o force useopt att volume plex * INCIDENT NO:3757899 TRACKING ID:2836798 SYMPTOM: Dynamic LUN expansion is not supported for EFI (Extensible Firmware Interface) disks in simple or sliced format and non-EFI disks greater than 1TB in simple or sliced format. The recommended format is the Cross-platform Data Sharing (CDS) disk format. WORKAROUND: Convert the disk format to CDS using the vxcdsconvert utility. * INCIDENT NO:3757903 TRACKING ID:2360780 SYMPTOM: The vxsnap print command can display the percentage of regions that differ between snapshots, shown as the %dirty. In SF 6.0, if this command is run while the volumes are online and being actively used, the shown %dirty may lag from actual percentage dirty for instant snap data cache object (DCO) volumes. That is,the command output may show less %dirty than actual. WORKAROUND: No * INCIDENT NO:3757919 TRACKING ID:3178642 SYMPTOM: For Solaris 11.1 or later, after you uninstall the VxVM package or after you turn off DMP native support, you may see this issue. After reboot, the root pool containing the active boot environment is migrated to the OS device but alternate root pools continue to show DMP device. The status of the alternate root pools and their DMP devices is shown as "UNAVAIL". pool: crpool state: UNAVAIL status: One or more devices are unavailable in response to persistent errors. There are insufficient replicas for the pool to continue functioning. action: Destroy and re-create the pool from a backup source. Manually marking the device repaired using 'zpool clear' or 'fmadm repaired' may allow some data to be recovered. Run 'zpool status -v' to see device specific details. scan: none requested config: NAME STATE READ WRITE CKSUM crpool UNAVAIL 0 0 0 emc_clariion1_82s0 UNAVAIL 0 0 0 The tunable parameter dmp_native_support only unconfigures DMP for the single root pool containing the active boot environment. If the setup has any alternate root pools, for which DMP native support was enabled, then the alternate root pools continue to show the DMP device. If the alternate root pool is configured in the current boot environment and DMP support is removed, the DMP devices required for ZFS are not found. The DMP devices and the root pools display the state as "UNAVAIL". WORKAROUND: Even though the status of alternate root pool is "UNAVAIL", the system is bootable using the disk containing the alternate root pool. Reboot the system with the disk containing the alternate root pool. The system comes up with the root pool using the DMP device. * INCIDENT NO:3757925 TRACKING ID:3157394 SYMPTOM: After enabling DMP native support for ZFS on Solaris 11.1 or later, only the current boot environment (BE) is bootable. Any alternate BEs in the same root pool are not bootable. This situation occurs because the DMP native support configures the ZFS root pool so that only DMP can import the root pool. If you attempt to boot the system from the alternate BE, the system panics with the following message: NOTICE: zfs_parse_bootfs: error 19 Cannot mount root on rpool/193 fstype zfs panic[cpu0]/thread=10012000: vfs_mountroot: cannot mount root Warning - stack not written to the dumpbuf 000000001000fa00 genunix:main+17c (1, 100dc958, 12d5c00, 124702c, 0, 10828000) %l0-3: 0000000010010000 0000000000000000 00000000100dc800 0000000000000000 %l4-7: 0000000010012000 0000000000000000 000000001038f7c0 000000000104c800 WORKAROUND: To enable booting from another BE, configure the ZFS root pool so that it can be imported without DMP. To configure ZFS root pool to enable booting from all the BEs 1. At the OBP PROM, run the following command to list all the BEs: ok> boot -L 2. Use the following command to boot from the BE for which DMP native support for ZFS is enabled. ok> boot -Z rpool/ROOT/BE_name 3. After booting through new BE, disable the DMP native support using the following command: # vxdmpadm settune dmp_native_support=off The system is now bootable from any BEs in the ZFS root pool. * INCIDENT NO:3757931 TRACKING ID:3221944 SYMPTOM: DMP support for ZFS root is not supported in the Oracle VM Server for SPARC guest. If DMP meta devices are exported to Oracle VM Server for SPARC and used for root pool, then enabling the dmp_native_support tunable fails with the following error: #vxdmpadm settune dmp_native_support=on VxVM vxdmpadm ERROR V-5-1-15690 Operation failed for one or more zpools VxVM vxdmpadm ERROR V-5-1-15686 The following zpool(s) could not be migrated as failed to obtain root pool information - rpool WORKAROUND: Where rpool specifies the root pool name on the Oracle VM Server for SPARC guest: DMP supports non-root ZFS in the Oracle VM Server for SPARC guest. You can use DMP devices for non-root ZFS. * INCIDENT NO:3757939 TRACKING ID:3084656 SYMPTOM: When dmp_native_support is set to on, on SAN failures, commands that do I/O operations to the root file system or I/O to disks that contain the root pool may hang for about 1-5 minutes. The commands include commands like "zpool status", or telnet initiated to connect the system. The hang is seen because the drivers below the DMP layer take more time to report the I/O failure when some of the paths to the disk containing the root pool are disconnected. This situation should not lead to any root pool data corruption. WORKAROUND: This hang cannot be avoided but the hang time can be reduced by tuning the following parameters To tune the parameters 1. In the /kernel/drv/fp.conf file, set fp_offline_ticker=15 2. In the /kernel/drv/fcp.conf file, set fcp_offline_dely=10 3. Reboot the sytem to apply the changes. These steps reduce the hang time to a maximum of 1 minute. * INCIDENT NO:3757942 TRACKING ID:3628743 SYMPTOM: The issue results from some kind of OS race condition causing a deadlock during the system boot after upgrade. This hang sometimes gets resolved after many hours. This is still being investigated further with Oracle support engagement for solution. WORKAROUND: The issue can be avoided if you perform the following steps to upgrade to Solaris 11 Update 2 in a specified order: 1 Upgrade system to Solaris 11 update 1. 2 Upgrade SF to 6.2 3 Upgrade system to Solaris 11 update 2. * INCIDENT NO:3757962 TRACKING ID:1672417 SYMPTOM: After upgrading VVR to an IPv6-only environment in release 6.0 or later, vradmin commands may not work when a colon is specified in the RVG, data volume(s) and/or SRL name. It is also possible that after upgrading VVR to an IPv6-only environment, vradmin createpri may dump core when provided with RVG, volume and/or SRL names containing a colon in it. WORKAROUND: Make sure that colons are not specified in the volume, SRL, and RVG names in the VVR configuration. * INCIDENT NO:3757966 TRACKING ID:2129601 SYMPTOM: This issue occurs when you try a relayout operation on a data volume which is associated to an RVG, and the target layout is a striped-mirror. WORKAROUND: To relayout a data volume in an RVG from concat to striped-mirror 1 Pause or stop the applications. 2 Wait for the RLINKs to be up to date. Enter the following: # vxrlink -g diskgroup status rlink 3 Stop the affected RVG. Enter the following: # vxrvg -g diskgroup stop rvg 4 Disassociate the volumes from the RVG. Enter the following: # vxvol -g diskgroup dis vol 5 Relayout the volumes to striped-mirror. Enter the following: # vxassist -g diskgroup relayout vol layout=stripe-mirror 6 Associate the data volumes to the RVG. Enter the following: # vxvol -g diskgroup assoc rvg vol 7 Start the RVG. Enter the following: # vxrvg -g diskgroup start rvg 8 Resume or start the applications. * INCIDENT NO:3758008 TRACKING ID:2360713 SYMPTOM: When replicating in a cross-version VVR environment consisting of hosts running Storage Foundation 5.1 and hosts running Storage Foundation 6.0, the vradmin verifydata command fails with the following error: VxVM VVR vxrsync ERROR V-5-52-2222 [from host]: VxVM in.vxrsyncd ERROR V-5-36-2125 Server volume access error during [assign volids] volume path: [/dev/vx/dsk/dg/snapshot_volume] reason: [this could be because a target volume is disabled or an rlink associated with a target volume is not detached during sync operation]. WORKAROUND: There are two ways to get out of this issue. 1. Upgrade the hosts running Storage Foundation 5.1 to Storage Foundation 5.1SP1 or later and re-run the vradmin verifydata command. 2. Follow the offline verification procedure in the "Verifying the data on the Secondary" section of the Symantec Storage Foundation and High Availability Solutions Replication Administrator's Guide. This process requires ensuring that the secondary is up-to-date, pausing replication, and running the vradmin syncrvg command with the -verify option. * INCIDENT NO:3758015 TRACKING ID:2834424 SYMPTOM: When replicating between two nodes in a cross-platform environment, and performing an autosync or replication, the vradmin verifydata command may report differences. This is due to different endianness between the platforms. However, the file system on the secondary node will be consistent and up to date. WORKAROUND: No * INCIDENT NO:3758021 TRACKING ID:2808902 SYMPTOM: In a VVR environment, the vradmin verifydata command fails with the following error if the replicated volume group (RVG) contains any volume set: Message from Primary: VxVM VVR vxrsync ERROR V-5-52-2009 Could not open device /dev/vx/dsk/vvrdg/ due to: stat of raw character volume path failed WORKAROUND: No * INCIDENT NO:3758026 TRACKING ID:3329970 SYMPTOM: There are issues with bunker replication using Volume Replicator (VVR) with volume sets. Do not upgrade to Symantec Storage Foundation HA 6.2.1 if you have configured or plan to configure bunker replication using VVR with volume sets. WORKAROUND: Contact Symantec Technical Support for a patch that enables you to use this configuration. * INCIDENT NO:3758030 TRACKING ID:3270067 SYMPTOM: While an application is online at the Volume Replicator primary site, the vradmin verifydata command may fail. The command output shows the differences between the source data volume and the target data volume. WORKAROUND: The reason for this error is that the cache object that is used for the verification might be under allocated. You might need to allocate more space for the shared cache object. For guidelines on shared cache object allocation, see the section "Creating a shared cache object" in the Symantec Storage Foundation Administrator's Guide. * INCIDENT NO:3758035 TRACKING ID:3347656 SYMPTOM: This issue may occasionally occur when you use vradmin commands to administer Volume Replicator (VVR). While the vradmin commands run, vradmind may temporarily lose heartbeats, and the commands terminate with the following error message: VxVM VVR vradmin ERROR V-5-52-803 Lost connection to host host; terminating command execution. WORKAROUND: To resolve this issue: 1.Depending on the application I/O workload and the network environment, uncomment and increase the value of the IPM_HEARTBEAT_TIMEOUT variable in the /etc/vx/vras/vras_env on all the hosts of the replicated data set (RDS) to a higher value. The following example increases the timeout value to 120 seconds: export IPM_HEARTBEAT_TIMEOUT IPM_HEARTBEAT_TIMEOUT=120 2.Restart vradmind on all the hosts of the RDS to put the new IPM_HEARTBEAT_TIMEOUT value into affect. Enter the following on all the hosts of the RDS: # /etc/init.d/vras-vradmind.sh stop # /etc/init.d/vras-vradmind.sh start * INCIDENT NO:3758040 TRACKING ID:2622536 SYMPTOM: Under a heavy I/O load, write I/Os on the Volume Replicator (VVR) primary logowner take a long time to complete. WORKAROUND: There is no way to solve this issue. * INCIDENT NO:3758044 TRACKING ID:3642855 SYMPTOM: If the VVR logowner (master) node on the secondary site goes down during initial synchronization, then during the RVG recovery (initiated on any secondary side node as a result of node crash), the replication links detach with the following error: WARNING: VxVM VVR vxio V-5-0-187 Incorrect magic number or unexpected upid (1) rvg rvg1 WARNING: VxVM VVR vxio V-5-0-287 rvg rvg1, SRL srl1: Inconsistent log - detaching all rlinks. WORKAROUND: Restart replication using the autosync operation. * INCIDENT NO:3758145 TRACKING ID:2787766 SYMPTOM: This issue occurs on A/P arrays. If the voting disk loses connectivty to the primary paths, DMP takes some time to analyze the error and fail over the paths. During this time, the cssd reports a timeout and panics. When using Oracle ASM over DMP devices, set the disktimeout parameter to an appropriate value. This parameter indicates the maximum time allowed for a voting file I/O to complete. If this time is exceeded, the voting disk is marked as offline. The default of disktimeout is 200. If the value of the tunable is less that this value, reset the value to the default value. WORKAROUND: To set the disktimeout to 200: $CRS_HOME/bin/crsctl set css disktimeout 200 [-force] test * INCIDENT NO:3758159 TRACKING ID:1933631 SYMPTOM: If you suppress the primary path of an array from VxVM control and then reboot the system, the system boot fails. If you have an encapsulated SAN boot device with multiple primary paths, the issue occurs when you suppress the first primary path. When you configure a SAN boot device, the primary path is set as a boot device. In general, the first path of the SAN boot device corresponds to the first configured path during SAN boot. Even if another primary path is configured as a boot device, suppressing the first device from VxVM causes the boot to fail. WORKAROUND: When the boot device is suppressed from VxVM, change the OS boot device sequencing accordingly. For Solaris SPARC system, use the eeprom boot-device command to set the boot device sequencing. * INCIDENT NO:3758163 TRACKING ID:2490012 SYMPTOM: For EVA arrays, DMP requires that the prefer bit is static. If the prefer bit is not static, issues like the following may occur. After changing the prefer path of LUN from the array side, and performing a disk discovery ( vxdisk scandisks ) from the host, the secondary path becomes active for the LUN. WORKAROUND: To work around this issue 1 Set the pref bit for the LUN. 2 Perform disk discovery again: # vxdisk scandisks. * INCIDENT NO:3758167 TRACKING ID:2816589 SYMPTOM: When using an IBM Storwize V7000 storage system, after removing one array node, the corresponding controller is also removed. WORKAROUND: The following procedure resolves this issue. To resolve this issue 1. Set the iotimeout tunable to 600: # vxdmpadm setattr enclosure encl1 recoveryoption=throttle \ iotimeout=600 2. After you re-add the SAN VC node, run the vxdctl enable command for Dynamic Multi-Pathing (DMP) to detect the added paths: # vxdctl enable. * INCIDENT NO:3758176 TRACKING ID:2082414 SYMPTOM: The Veritas Volume Manager (VxVM) 6.2.1 includes several array names that differ from the array names in releases 5.1SP1 or prior. Therefore, if you upgrade to VxVM 6.2.1 from a release 5.1SP1 or earlier, changes in the enclosure attributes may not remain persistent. Any enclosure attribute set for these arrays may be reset to the default value after an upgrade to VxVM 6.2.1. WORKAROUND: Manually reconfigure the enclosure attributes to resolve the issue. Table 1-26 shows the Hitachi arrays that have new array names. Table 1-26 Hitachi arrays with new array names Previous name New name TagmaStore-USP Hitachi_USP TagmaStore-NSC Hitachi_NSC TagmaStoreUSPV Hitachi_USP-V TagmaStoreUSPVM Hitachi_USP-VM Hitachi AMS2300 Series arrays New array names are based on the Model Number 8x. For example, AMS_100, AMS_2100, AMS_2300, AMS_2500, etc. In addition, the Array Support Library (ASL) for the enclosures XIV and 3PAR now converts the cabinet serial number that is reported from Hex to Decimal, to correspond with the value shown on the GUI. Because the cabinet serial number has changed, any enclosure attribute set for these arrays may be reset to the default value after an upgrade to VxVM 6.2.1. Manually reconfigure the enclosure attributes to resolve the issue. The cabinet serial numbers are changed for the following enclosures: a IBM XIV Series arrays a 3PAR arrays * INCIDENT NO:3758183 TRACKING ID:1856723 SYMPTOM: When CVM is configured on non-A/A storage, if a node loses access to the storage through all the primary paths, then all the nodes in the cluster switches to the secondary paths. If the node which raised the protocol leaves the cluster and if all the rest of the nodes in the cluster are seeing the primary paths as healthy, then failback to primary paths never happens. WORKAROUND: No * INCIDENT NO:3758189 TRACKING ID:2425977 SYMPTOM: In a Cluster Volume Manager (CVM) cluster, you can disable connectivity to the disks at the controller or enclosure level with the vxdmpadm disable command. In this case, CVM may place the disks into the lfailed state. When you restore connectivity with the vxdmpadm enable command, CVM may not automatically clear the lfailed state. After enabling the controller or enclosure, you must run disk discovery to clear the locally failed state. WORKAROUND: To run disk discovery a Run the following command: # vxdisk scandisks. * INCIDENT NO:3758209 TRACKING ID:2764153 SYMPTOM: A master node with missing disks is not capable of doing recovery, as it does not have access to the disks belonging to any of the plexes of a volume. WORKAROUND: If other nodes have access to the storage, they can do the recovery. Switch the master role to some other node with better storage connectivity. * INCIDENT NO:3758215 TRACKING ID:2787713 SYMPTOM: If the first node joining the cluster has no connectivity to disks, the import of shared disk groups fails. Other nodes that join the cluster later assume that the auto- import of disk groups is already done as part of the existing cluster processing. WORKAROUND: Perform a master switch to the node that has connectivity to the disks. Then import the disk groups manually. * INCIDENT NO:3758290 TRACKING ID:3236772 SYMPTOM: If the VVR secondary node receives updates out of order from the Primary, and a transaction starts on the secondary site, then the transaction may timeout waiting for I/O drain. This issue may occur in situations where the gaps created by out of order updates are not filled within the transaction timeout period. WORKAROUND: Pause replication and make configuration changes. * INCIDENT NO:3758291 TRACKING ID:1672410 SYMPTOM: After upgrading VVR to an IPv6-only environment in release 6.0 or later, vradmin commands may not work when a colon is specified in the RVG, data volume(s) and/or SRL name. It is also possible that after upgrading VVR to an IPv6-only environment, vradmin createpri may dump core when provided with RVG, volume and/or SRL names containing a colon in it. WORKAROUND: Make sure that colons are not specified in the volume, SRL, and RVG names in the VVR configuration. * INCIDENT NO:3758297 TRACKING ID:2071568 SYMPTOM: This issue may occasionally occur when you use vradmin commands to administer VVR. While the vradmin commands run, vradmind may temporarily lose heartbeats, and the commands terminate with the following error message: VxVM VVR vradmin ERROR V-5-52-803 Lost connection to host host; terminating command execution. WORKAROUND: To resolve this issue 1 Depending on the application I/O workload and network environment, uncomment and increase the value of the IPM_HEARTBEAT_TIMEOUT variable in the /etc/vx/vras/vras_env on all the hosts of the RDS to a higher value. The following example increases the timeout value to 120 seconds. export IPM_HEARTBEAT_TIMEOUT IPM_HEARTBEAT_TIMEOUT=120 2 Restart vradmind on all the hosts of the RDS to put the new IPM_HEARTBEAT_TIMEOUT value into affect. Enter the following on all the hosts of the RDS: # /etc/init.d/vras-vradmind.sh stop # /etc/init.d/vras-vradmind.sh start * INCIDENT NO:3760326 TRACKING ID:3134882 SYMPTOM: When you import a clone disk group with the -o updateid option, the GUIDs of all the objects are assigned new values. However, these values are not updated on the maps in the data change object (DCO). When you initiate a volume recovery, it fails on the volumes having instant DCO (version >= 20) because it does not find the objects corresponding to the GUIDs. In this situation, the DCO is considered corrupt and the volume remains inaccessible. WORKAROUND: You mainly need the -o updateid option when you import the clone disk group on the same host as the primary disk group. You can avoid using the option by doing one of the following: a Import the clone disk group on a different host. a Deport the primary disk group before you import the clone disk group. If the import of the clone disk group with -o updateid option or the recovery of volume thereafter fails with a message about the DCO being corrupted, this error occurs because the GUIDs are not being updated on the DCO implicitly. If the * INCIDENT NO:3761443 TRACKING ID:3761441 SYMPTOM: From release 6.0, DMP uses OS device physical path instead of logical name to maintain persistence of path attributes. Hence after upgrading to DMP 6.0 or later releases, path attributes are reset to the default values. You must reconfigure any path-level attributes that were defined in the /etc/vx/dmppolicy.info file. WORKAROUND: To configure path-level attributes 1 Remove the path entries from the /etc/vx/dmppolicy.info file. 2 Reset the path attributes. * INCIDENT NO:3761482 TRACKING ID:3761474 SYMPTOM: If a path of a device having multiple paths is labelled with EFI format using OS command like "format", device is shown in error state in "vxdisk list" output. WORKAROUND: This is SUN OS issue. None. * INCIDENT NO:3761493 TRACKING ID:2706776 SYMPTOM: If you label a disk device as EFI using format on a subset of the paths or on the DMP device, Solaris will not be able to propagate the label to all the other paths of the LUN. This will lead the device to appear in the error state under 'vxdisk list'. WORKAROUND: None. * INCIDENT NO:3761498 TRACKING ID:3761497 SYMPTOM: Issue 1: When the vradmin ibc command is used to take a snapshot of a replicated data volume containing a VxFS file system on the Secondary, mounting the snapshot volume in read-write mode may fail with the following error: UX:vxfs mount: ERROR: V-3-21268: /dev/vx/dsk/dg/snapshot_volume is corrupted. needs checking This happens because the file system may not be quiesced before running the vradmin ibc command and therefore, the snapshot volume containing the file system may not be fully consistent. Issue 2: After a global clustering site failover, mounting a replicated data volume containing a VxFS file system on the new Primary site in read-write mode may fail with the following error: UX:vxfs mount: ERROR: V-3-21268: /dev/vx/dsk/dg/data_volume is corrupted. needs checking This usually happens because the file system was not quiesced on the original Primary site prior to the global clustering site failover and therefore, the file systems on the new Primary site may not be fully consistent. WORKAROUND: The following ways to resolve these issues. For issue 1, run the fsck command on the snapshot volume on the Secondary, to restore the consistency of the file system residing on the snapshot. For example: # fsck -t vxfs /dev/vx/dsk/dg/snapshot_volume For issue 2, run the fsck command on the replicated data volumes on the new Primary site, to restore the consistency of the file system residing on the data volume. For example: # fsck -t vxfs /dev/vx/dsk/dg/data_volume * INCIDENT NO:3761511 TRACKING ID:145413 SYMPTOM: If you perform a relayout that adds a column to a striped volume that has a DCM, the DCM is removed. There is no message indicating that this has happened. WORKAROUND: To replace the DCM, enter the following: #vxassist -g diskgroup addlog vol logtype=dcm * INCIDENT NO:3761513 TRACKING ID:3343141 SYMPTOM: In a Volume Replicator (VVR) environment, after you start the initial synchronization with the vradmin -a startrep command with file system mounted on the primary data volumes, the vradmin repstatus command does not show that the SmartSync feature is running. This is an only issue with the output of the vradmin repstatus command. WORKAROUND: To confirm that SmartSync is running, enter: #vxrlink status rlink * INCIDENT NO:3761528 TRACKING ID:2158679 SYMPTOM: In certain situations, if you switch the master role, vradmin functionality may not work. The following message displays: VxVM VVR vxrlink ERROR V-5-1-15861 Command is not supported for command shipping. Operation must be executed on master WORKAROUND: To restore vradmin functionality after a master switch operation 1 Restart vradmind on all cluster nodes. Enter the following: # /etc/init.d/vras-vradmind.sh stop # /etc/init.d/vras-vradmind.sh start 2 Re-enter the command that failed. * INCIDENT NO:3761574 TRACKING ID:2036644 SYMPTOM: The time that it takes for a global cluster to fail over an application service group can sometimes be smaller than the time that it takes for VVR to detect the configuration change associated with the primary fault. This can occur in a bunkered, globally clustered configuration when the value of the ClusterFailoverPolicy attribute is Auto and the AppGroup is configured on a subset of nodes of the primary cluster. This causes the RVGPrimary online at the failover site to fail. The following messages appear in the VCS engine log: RVGPrimary:RVGPrimary:online:Diskgroup bunkerdgname could not be imported on bunker host hostname. Operation failed with error 256 and message VxVM VVR vradmin ERROR V-5-52-901 NETWORK ERROR: Remote server unreachable... Timestamp VCS ERROR V-16-2-13066 (hostname) Agent is calling clean for resource(RVGPrimary) because the resource is not up even after online completed. WORKAROUND: To resolve this issue a When the configuration includes a bunker node, set the value of the OnlineRetryLimit attribute of the RVGPrimary resource to a non-zero value. * INCIDENT NO:3761575 TRACKING ID:2075307 SYMPTOM: The vradmin syncvol command does not work with the compressed form of IPv6 addresses if the target disk group and volume names are not specified. WORKAROUND: In IPv6 environments, if you run the vradmin syncvol command and identify the target host using the compressed form of the IPv6 address, then you also need to specify the target disk group and volume names. * INCIDENT NO:3761580 TRACKING ID:2036605 SYMPTOM: The RVGPrimary agent initiated operation to start replication between the original Primary and the bunker fails during failback a when migrating back to the original Primary after disaster recovery a with the error message: VxVM VVR vxrlink ERROR V-5-1-5282 Error getting information from remote host. Internal Error. The issue applies to global clustering with a bunker configuration, where the bunker replication is configured using storage protocol. It occurs when the Primary comes back even before the bunker disk group is imported on the bunker host to initialize the bunker replay by the RVGPrimary agent in the Secondary cluster. WORKAROUND: To resolve this issue 1 Before failback, make sure that bunker replay is either completed or aborted. 2 After failback, deport and import the bunker disk group on the original Primary. 3 Try the start replication operation from outside of VCS control. * INCIDENT NO:3761582 TRACKING ID:1825031 SYMPTOM: Issue: After upgrading VVR to an IPv6-only environment in release 6.0 or later, vradmin commands may not work when a colon is specified in the RVG, data volume(s) and/or SRL name. It is also possible that after upgrading VVR to an IPv6-only environment, vradmin createpri may dump core when provided with RVG, volume and/or SRL names containing a colon in it. WORKAROUND: Make sure that colons are not specified in the volume, SRL, and RVG names in the VVR configuration FIXED INCIDENTS: ---------------- PATCH ID:151232-01 * INCIDENT NO:3470267 TRACKING ID:3414023 SYMPTOM: When a plex of a volume that was detached due to an I/O error gets reattached, VxVM resyncs some additional data. DESCRIPTION: VxVM uses a common map to track changes in the I/O path and updates other tracking maps during the transaction to minimize the tracking overhead. When a volume has a preexisting snapshot, the I/O tracking happens on the common map. And, when a plex gets detached to an I/O error, the tracking in common map continues. Later, when the detach transaction is carried out, the common map contents are updated to all the tracking maps including the detach map. Thus, the detach map contains regions that were tracked before the detach process is initiated. Thus, additional resync happens when the plex gets reattached. RESOLUTION: The code is modified such that when a plex gets detached due to an I/O error, the tracking happens directly to detach map instead of going through a common map. Later, when the detach transaction happens, the detach map would not be updated with contents of a common map. And after the detach transaction is complete, the direct tracking of detach map is stopped and it happens only through a common map. * INCIDENT NO:3656538 TRACKING ID:3506450 SYMPTOM: When migrating from PowerPath to Dynamic Multipathing (DMP), you may observe a system panic or VxVM configuration daemon (vxconfigd) core. DESCRIPTION: You may observe system panic or vxconfigd core when there are stale entries in Third Party Driver (TPD) subpaths of a metanode for a dmpnode, which is migrated from PowerPath to DMP. The system panics when the condition for checking stale entries before migration is not present and subsequently some instructions are not getting executed. RESOLUTION: The code is modified to resolve the issue that caused system panic. * INCIDENT NO:3657352 TRACKING ID:3424704 SYMPTOM: On using the localized messages, some VxVM commands such as vxbootsetup(1M) fail with an error message similar to the following: VxVM vxbootsetup ERROR V-5-2-5651 <garbage value> DESCRIPTION: The issue occurs when output of the vxdctl mode command appears in the localized format. When the output is not translated into the English language, a mismatch of messages is observed in the output. RESOLUTION: The code is modified to convert the output of the vxdctl mode command into English language before comparing it with the expected output. * INCIDENT NO:3661664 TRACKING ID:3322760 SYMPTOM: "vxdisk list" command may list detached disks, if the options are fullshared, partialshared, or local. DESCRIPTION: Different options of the vxdisk list command are available to display disks in cluster storage. When the vxdisk list command is used to display fully shared, partially shared, or local disks, the output shows detached DAS disk information also. However, only the vxdisk list command with the alldisks option should show the detached or removed disks. RESOLUTION: The code is modified to add extra conditions for not displaying detached or removed disks. * INCIDENT NO:3661672 TRACKING ID:3442024 SYMPTOM: The adddisk <disk_name> command fails to add the Compressed Diagonal Storage(CDS) EFI disk to the CDS disk group. The failure occurs with the following message: Creating a new disk group named <disk group> containing the disk device <disk name> with the name <disk group>. VxVM ERROR V-5-2-121 Creating disk group <disk group> with disk device <disk name> failed. VxVM vxdg ERROR V-5-1-6478 Device <disk name> cannot be added to a CDS disk Group DESCRIPTION: The vxdiskadm(1M) option #1(adding disk to disk group and initialization) does not provide the CDS format option for an EFI labeled disk, which causes the EFI labeled disk to be formatted as sliced. Subsequently, the adddisk operation fails because a disk with sliced format cannot be added to a CDS disk group. RESOLUTION: The vxdiskadm utility code is modified to allow an EFI labeled disk to be added to an existing CDS disk group, and it can be initialized with CDS format. * INCIDENT NO:3661680 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. * INCIDENT NO:3661688 TRACKING ID:3571434 SYMPTOM: DMP does not support NetApp cDOT cluster mode array with more than 2 nodes. DESCRIPTION: Sometimes array controllers giveback or takeover operation I/Os are sent on un-optimized array controllers. RESOLUTION: The code is modified to support NetApp cDOT cluster mode array with more than 2 nodes. * INCIDENT NO:3661708 TRACKING ID:3594158 SYMPTOM: The system panics on a VVR secondary node with the following stack trace: .simple_lock() soereceive() soreceive() .kernel_add_gate_cstack() kmsg_sys_rcv() nmcom_get_next_mblk() nmcom_get_next_msg() nmcom_wait_msg_tcp() nmcom_server_proc_tcp() nmcom_server_proc_enter() vxvm_start_thread_enter() DESCRIPTION: You may issue a spinlock or unspinlock to the replica to check whether to use a checksum in the received packet. During the lock or unlock operation, if there is a transaction that is being processed with the replica, which rebuilds the replica object in the kernel, then there is a possibility that the replica referenced in spinlock is different than the one which the replica has referenced in unspinlock (especially when the replica is referenced through several pointers). As a result, the system panics. RESOLUTION: The code is modified to set the flag in the port attribute to indicate whether to use the checksum during a port creation. Hence, for each packet that is received, you only need to check the flag in the port attribute rather than referencing it to the replica object. As part of the change, the spinlock or unspinlock statements are also removed. * INCIDENT NO:3661712 TRACKING ID:3599977 SYMPTOM: During a replica connection, referencing a port that is already deleted in another thread causes a system panic with a similar stack trace as below: .simple_lock() soereceive() soreceive() .kernel_add_gate_cstack() kmsg_sys_rcv() nmcom_get_next_mblk() nmcom_get_next_msg() nmcom_wait_msg_tcp() nmcom_server_proc_tcp() nmcom_server_proc_enter() vxvm_start_thread_enter() DESCRIPTION: During a replica connection, a port is created before increasing the count. This is to protect the port from getting deleted. However, another thread deletes the port before the count is increased and after the port is created. While the replica connection thread proceeds, it refers to the port that is already deleted, which causes a NULL pointer reference and a system panic. RESOLUTION: The code is modified to prevent asynchronous access to the count that is associated with the port by means of locks. * INCIDENT NO:3661723 TRACKING ID:3616671 SYMPTOM: When you use the vxtranslog -n no_limit(1M) command to set the number of transaction log files to no_limit value, it is wrongly reset to the default value, 10. Hence, maximum 10 transaction log files are generated and later, the same files are overwritten instead of creating more files beyond the default number. DESCRIPTION: When number of transaction log files is set to the no_limit value. Internally, a specific numeric value is assigned for the special handling of this case. But later, this value is not handled correctly and is considered as an invalid value. So it is wrongly reset to a default value and only default number of transaction log files are generated and overwritten. RESOLUTION: Code changes are done to handle the 'no_limit' case correctly. * INCIDENT NO:3661726 TRACKING ID:3621232 SYMPTOM: When the vradmin ibc command is executed to initiate the In-band Control (IBC) procedure, the vradmind (VVR daemon) on VVR secondary node goes into the disconnected state. Due to which, the following IBC procedure or vradmin ibc commands cannot be started or executed on VVRs secondary node and a message similar to the following appears on VVRs primary node: VxVM VVR vradmin ERROR V-5-52-532 Secondary is undergoing a state transition. Please re-try the command after some time. VxVM VVR vradmin ERROR V-5-52-802 Cannot start command execution on Secondary. DESCRIPTION: When IBC procedure runs into the commands finish state, the vradmin on VVR secondary node goes into a disconnected state, which the vradmind on primary node fails to realize. In such a scenario, the vradmind on primary refrains from sending a handshake request to the secondary node which can change the primary nodes state from disconnected to running. As a result, the vradmind in the primary node continues to be in the disconnected state and the vradmin ibc command fails to run on the VVR secondary node despite of being in the running state on the VVR primary node. RESOLUTION: The code is modified to make sure the vradmind on VVR primary node is notified while it goes into the disconnected state on VVR secondary node. As a result, it can send out a handshake request to take the secondary node out of the disconnected state. * INCIDENT NO:3661731 TRACKING ID:3625890 SYMPTOM: After running the vxdisk resize command, the following message is displayed: "VxVM vxdisk ERROR V-5-1-8643 Device resize failed: Invalid attribute specification" DESCRIPTION: Two reserved cylinders for special usage for CDS (Cross-platform Data Sharing) VTOC(Volume Table of Contents) disks. In case of expanding a disk with particular disk size on storage side, VxVM(Veritas Volume Manager) may calculate the cylinder number as 2, which causes the vxdisk resize fails with the error message of "Invalid attribute specification". RESOLUTION: The code is modified to avoid the failure of resizing a CDS VTOC disk. * INCIDENT NO:3661756 TRACKING ID:3628860 SYMPTOM: The vxdisk(1M) command shows disks with the nolabel status in the output. DESCRIPTION: As per the design, the "vxdisk(1M) -o local list" should not list the disks for which connectivity information is not populated. Thus, the disks with nolabel status should not be displayed in vxdisk(1M) commands output. RESOLUTION: The code is modified to restrict the vxdisk(1M) command from listing disks having the nolabel status. * INCIDENT NO:3661780 TRACKING ID:3628933 SYMPTOM: The storage for a volume and its corresponding DCO volume can be configured from a subset of nodes in FSS (Flexible Share Storage) cluster. If this subset of nodes goes down and become accessible again, the recovery of the volume may fail and the volume may remain in the DETACHED state. Console log shows the following error message: VxVM vxplex ERROR V-5-1-10128 DCO experienced IO errors during the operation. Re-run the operation after ensuring that DCO is accessible. DESCRIPTION: When the nodes which contribute storage for a volume and its corresponding DCO go down, a new node becomes master (master takeover). With inaccessible DCO, the new master may fail to read the DCO and could have invalid in-memory contents for the DCO. Due to an issue in the code, the in-memory content was treated as valid and wasn't refreshed even when the nodes which contribute to the storage of DCO come up. So recovery of such volume would fail to report DCO to be invalid or inaccessible. RESOLUTION: The code is modified to ensure that the failure of reading from dcl volume invalidates the associated DCO metadata in memory. * INCIDENT NO:3661783 TRACKING ID:3631025 SYMPTOM: The output of "vxstat -i" utility with "-ft" or "-fi" options does not mention the system name and its origin (source or destination) DESCRIPTION: The I/O statistics must contain the following details when the below options are selected in the vxstat utility: * -i: System name * -ft and -i: dst as an identifier to indicate that the output is shown for the target system. * -fi and i: src" as an identifier to indicate that the output is shown for the source system. RESOLUTION: The code is modified to print the node name and the src/dst(source/destination) identifiers. The vxstat output will be printed as: -fi option with -i option: vxstat -g stripedg -T -X -fi -i5 SRC OPERATIONS BLOCKS AVG TIME(ms) TYP NAME READ WRITE READ WRITE READ WRITE vmdellr710-1(src) Wed 21 May 2014 07:33:00 AM PDT -ft option with -i option : vxstat -g stripedg -T -X -ft -i5 TGT OPERATIONS BLOCKS AVG TIME(ms) TYP NAME READ WRITE READ WRITE READ WRITE vmdellr710-1(dst) Wed 21 May 2014 07:30:10 AM PDT * INCIDENT NO:3661798 TRACKING ID:3631989 SYMPTOM: The vxconfigd(1M) daemon hangs on the joiner node. DESCRIPTION: At the end of a node join, the joiner node sends its local disks to the master node after the master node starts importing disk group (dg). The master node imports the dg acquiring the disk record lock. When the master node gets restarted, it starts processing its own leave event. During processing of leave event, the master node starts cleaning up the remote disks and again tries to acquire the same disk record lock which it already has taken while importing the dg. As a result, the vxconfigd(1M) daemon becomes unresponsive. RESOLUTION: The code is modified to maintain the id of the owner thread. And, to enable VxVM to check the thread id, which restricts the same thread from acquiring the lock again. * INCIDENT NO:3661845 TRACKING ID:3644687 SYMPTOM: The system panics with the below stack trace: vol_mv_indirectsio_add vol_mv_indirect_write_start voliod_iohandle DESCRIPTION: When I/O error occurs due to disk/HBA/SAN failure with VVR configuration, VVR retries the same intermediate staged I/O when it handles the error. Staged I/O infrastructure in Veritas Volume manager (VxVM) does not handle the retry of the same intermediate staged I/O, and caused the panic. RESOLUTION: The code has been written to handle the retry of intermediate staged I/O. * INCIDENT NO:3661847 TRACKING ID:3645370 SYMPTOM: After running the vxevac command, if the user tries to rollback or commit the evacuation for a disk containing DRL plex, the action fails with the following errors: /etc/vx/bin/vxevac -g testdg commit testdg02 testdg03 VxVM vxsd ERROR V-5-1-10127 deleting plex %1: Record is associated VxVM vxassist ERROR V-5-1-324 fsgen/vxsd killed by signal 11, core dumped VxVM vxassist ERROR V-5-1-12178 Could not commit subdisk testdg02-01 in volume testvol VxVM vxevac ERROR V-5-2-3537 Aborting disk evacuation /etc/vx/bin/vxevac -g testdg rollback testdg02 testdg03 VxVM vxsd ERROR V-5-1-10127 deleting plex %1: Record is associated VxVM vxassist ERROR V-5-1-324 fsgen/vxsd killed by signal 11, core dumped VxVM vxassist ERROR V-5-1-12178 Could not rollback subdisk testdg02-01 in volume testvol VxVM vxevac ERROR V-5-2-3537 Aborting disk evacuation DESCRIPTION: When the user uses the vxevac command, new plexes are created on the target disks. Later, during the commit or roll back operation, VxVM deletes the plexes on the source or the target disks. For deleting a plex, VxVM should delete its sub disks first, otherwise the plex deletion fails with the following error message: VxVM vxsd ERROR V-5-1-10127 deleting plex %1: Record is associated The error is displayed because the code does not handle the deletion of subdisks of plexes marked for DRL (dirty region logging) correctly. RESOLUTION: The code is modified to handle evacuation of disks with DRL plexes correctly. . * INCIDENT NO:3661849 TRACKING ID:3651034 SYMPTOM: The application I/O fails when there is a temporary loss of storage and thehealthy paths are unavailable for I/O. DESCRIPTION: DMP has dmp_lun_retry_timeout tunable that can be used to sustain the total loss of storage for the specified amount of time. Transient SAN failures can also be recovered quickly. The default value for this tunable is 0 second. When dmp_lun_retry_timeout is set to its default value and all paths to storage are lost, it results to application I/O failure instead of recovering from failure automatically. RESOLUTION: The code is modified such that default value of dmp_lun_retry_timeout tunable parameter is changed from 0 to 30 seconds. This makes system more resilient to transient SAN failures. If SAN recovers within 30 seconds, applications will not be impacted and the I/O processing continues. * INCIDENT NO:3661859 TRACKING ID:3656539 SYMPTOM: I/O hang observed when SmartIO VxVM block level is configured in few nodes of cluster, while there are volumes with instant snapshots. DESCRIPTION: With VxVM cachearea configured on nodes of clusters, to maintain the consistency of data in other nodes cache, VxVM initiated cache coherency protocol. With instant snapshot configured on volumes, this protocol can lead to hang in certain situations due to incorrect locking order. RESOLUTION: The code is modified to acquire locks in correct order while cache coherency protocol is running. * INCIDENT NO:3663698 TRACKING ID:3658079 SYMPTOM: If the size of backup slice of volumes is larger than 64GB, VxVMwraps it around it and exports it to LDOM guest domain. DESCRIPTION: The data type of variables declared to store volume's sector/track and tracks/cylinder are not sufficient to handle the value when the volume size goes beyond 64GB. Due to this the size of the cylinder gets wrapped around to 2048 sectors. RESOLUTION: The code has been changed to support volumes up to size 1.4TB. * INCIDENT NO:3675114 TRACKING ID:3671975 SYMPTOM: When VxVM cachearea is configured with CVM, the system panics with the following stack trace: vol_cache_lockbuild_start() voliod_iohandle() voliod_loop() DESCRIPTION: When VxVM read caching is enabled for shared volume, the online operation of VxVM warm cachearea triggers the IO interlock protocol for ensuring cache coherency across multiple nodes in CVM. This protocol leads to panic due to accessing NULL pointer. RESOLUTION: The code has been changed to avoid NULL pointer reference in the IO interlock protocol. * INCIDENT NO:3680504 TRACKING ID:3688156 SYMPTOM: The output of vxdisk -o local|partialshared list command lists disks in the error state. DESCRIPTION: The issue is observed because the command for some reason was incorrectly reporting the disks that were in error state. RESOLUTION: The code is modified to restrict error devices to be listed in output of the vxdisk -o local|partialshared list command. * INCIDENT NO:3681349 TRACKING ID:3651422 SYMPTOM: The sfcache app command gives syntax error when it runs for Sybase application on Solaris with the following message: "/opt/VRTS/bin/sfcache: source: not found sed: illegal option -- i" DESCRIPTION: The sfcache app command uses "source" and "sed -i" during execution but "source" command and "sed -i" support are not present in default installation on Solaris. RESOLUTION: The code is modified to replace the source and the sed -i commands with commands available by default on Solaris. * INCIDENT NO:3683458 TRACKING ID:3648719 SYMPTOM: The server panics with a following stack trace while adding or removing LUNs or HBAs: dmp_decode_add_path() dmp_decipher_instructions() dmp_process_instruction_buffer() dmp_reconfigure_db() gendmpioctl() vxdmpioctl() DESCRIPTION: While deleting a dmpnode, Dynamic Multi-Pathing (DMP) releases the memory associated with the dmpnode structure. In case the dmpnode doesn't get deleted for some reason, and if any other tasks access the freed memory of this dmpnode, then the server panics. RESOLUTION: The code is modified to avoid the tasks from accessing the memory that is freed by the dmpnode, which is deleted. The change also fixed the memory leak issue in the buffer allocation code path. * INCIDENT NO:3683471 TRACKING ID:3674614 SYMPTOM: Restarting the vxconfigd(1M) daemon on the slave (joiner) node during node-join operation may cause the vxconfigd(1M) daemon to become unresponsive on the master and the joiner node. DESCRIPTION: 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. Since the rejoin flag is wrongly set, the import operation of the disk groups on the slave node fails, and the join process is not terminated smoothly. As a result, the vxconfigd(1M) daemon becomes unresponsive 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. * INCIDENT NO:3683473 TRACKING ID:3644291 SYMPTOM: Some of the disk groups that are composed by 2TB LUNs fail to be auto-imported after a system restart. DESCRIPTION: During an early boot stage, sometimes system calls the efi_alloc_and_read() function that fails due to operating system issues. As a result, the disks cannot be brought online and the disk groups cannot be auto-imported. RESOLUTION: The code is modified to remove the efi_alloc_and_read()function. * INCIDENT NO:3687115 TRACKING ID:3669863 SYMPTOM: The sfcache list command doesn't show storage devices in the output if cachearea is created on stripe-mirror volume. sfcache list NAME TYPE SIZE ASSOC-TYPE STATE DEVICE sfcachearea_1 VxVM 19.93g AUTO ONLINE sfcachearea_1-L01,sfcachearea_1-L02 DESCRIPTION: The sfcache list command cannot find the disk involved for SmartIO cachearea when underlying volume has layered volume configuration. It displays internal VxVM objects (sub-volumes) instead of disk names. RESOLUTION: The code is modified to find out the disks of the volume for any layout. * INCIDENT NO:3702026 TRACKING ID:3564260 SYMPTOM: VVR commands are unresponsive when replication is paused and resumed in a loop. DESCRIPTION: While Veritas Volume Replicator (VVR) is in the process of sending updates then pausing a replication is deferred until acknowledgements of updates are received or until an error occurs. For some reason, if the acknowledgements get delayed or the delivery fails, the pause operation continues to get deferred resulting in unresponsiveness. RESOLUTION: The code is modified to resolve the issue that caused unresponsiveness. * INCIDENT NO:3709111 TRACKING ID:3588012 SYMPTOM: The vxconfigd(1M) daemon observes memory leak while printing I18N messages. DESCRIPTION: The vxconfigd(1M) daemon internally calls the strdup() function while printing the I18N messages. However, the daemon does not free the memory, which the function allocates. RESOLUTION: The code is modified to restrict the vxconfigd(1M) daemon from calling the strdup() function while it prints I18N messages. * INCIDENT NO:3724448 TRACKING ID:2965910 SYMPTOM: Volume creation with the vxassist(1M) command dumps core when the non-disk parameters like enclosures are specified along with the "-o ordered" option. The failure occurs with the following stack trace: 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 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 media type. 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 result in segfault. RESOLUTION: The code is modified to remove the filtering of the disk classes while setting up the disk order. To use media type for the ordered allocation, refer to the * INCIDENT NO:3726526 TRACKING ID:3736156 SYMPTOM: Solaris 11 update 1 system fails to come up after enabling dmp_native_support and reboot. DESCRIPTION: Veritas Dynamic Multi-pathing (DMP) doesnt handle EFI labeled non scsi disks correctly. Hence, during starting up, the vxconfigd process generates instructions to mark EFI labeled non scsi disks as failed. If failed disk happens to be the boot disk controlled by Veritas Dynamic Multi-pathing (DMP), the system is stuck during starting up. RESOLUTION: The Veritas Dynamic Multi-pathing (DMP) code is modified to correctly handle EFI labeled non scsi disks. * INCIDENT NO:3733113 TRACKING ID:3672759 SYMPTOM: When a DMP database is corrupted, the vxconfigd(1M) daemon may core dump with the following stack trace: database is corrupted. ddl_change_dmpnode_state () ddl_data_corruption_msgs () ddl_reconfigure_all () ddl_find_devices_in_system () find_devices_in_system () req_change_state () request_loop () main () DESCRIPTION: The issue is observed because the corrupted DMP database is not properly destroyed. RESOLUTION: The code is modified to remove the corrupted DMP database. * INCIDENT NO:3735665 TRACKING ID:3727939 SYMPTOM: Data corruption or VTOC label corruption may occur due to stale device entries present in the /dev/vx/[r]dmp directories. DESCRIPTION: The /dev/vx/[r]dmp directories, where the DMP device entries are created, are mounted as tmpfs (swap) during a boot cycle. These directories can be unmounted while the vxconfigd(1M) daemon is running and the DMP devices are in use. The DMP device entries are recreated on the disk instead of swap device in such situations. These are re-mounted on tmpfs during the next boot cycle thus the device entries created on disk become stale eventually. In such scenarios, the subsequent unmount of these directories results in reading those stale entries. Thus, data corruption or VTOC label corruption occurs. RESOLUTION: The code is modified to clear the stale entries in the /dev/vx/[r]dmp directories before starting the vxconfigd(1M) daemon. * INCIDENT NO:3736633 TRACKING ID:3677359 SYMPTOM: VxDMP causes system panic after a shutdown or reboot with the following stack trace: mutex_enter() volinfo_ioct() volsioctl_real() cdev_ioctl() dmp_signal_vold() dmp_throttle_paths() dmp_process_stats() dmp_daemons_loop() thread_start() OR panicsys() vpanic_common() panic+0x1c() mutex_enter() cdev_ioctl() dmp_signal_vold() dmp_check_path_state() dmp_restore_callback() dmp_process_scsireq() dmp_daemons() thread_start() DESCRIPTION: In a special scenario of system shutdown or reboot, the DMP (Dynamic MultiPathing) I/O statistic daemon tries to call the ioctl functions in VXIO module which is being unloaded. As a result, the system panics. RESOLUTION: The code is modified to stop the DMP I/O statistic daemon before system shutdown or reboot. Also, the code is modified to avoid other probes to vxio devices during shutdown. * INCIDENT NO:3738576 TRACKING ID:3420347 SYMPTOM: When a user runs the vxdg flush command and writes on a volume for the first time, the following message is displayed in the system log: WARNING: VxVM vxio V-5-0-1266 Volume vol1 block 432: Uncorrectable write error DESCRIPTION: Running "vxdg flush" command as well as writing on a volume for the first time requires a special logging operation in the kernel. Due to incorrect handling in the code, the logging, as a part of the volume write, cannot complete while "vxdg flush" is running. Hence, the volume write operation fails and the above message is displayed. RESOLUTION: The code is modified to interlock "vxdg flush" and first write handling operation on volumes to avoid this issue. * INCIDENT NO:3742578 TRACKING ID:3747701 SYMPTOM: The node-join process fails and nodes remain in the Joining state in Cluster Volume Manager environment. DESCRIPTION: In overlapping reconfiguration scenarios, the reconfiguration thread tries to signal vxconfigd. As vxconfigd is busy with handling its user-level reconfiguration, vxconfigd misses that signal. As a result, the deadlock occurs. RESOLUTION: The code is modified to fix the issue. * INCIDENT NO:3750631 TRACKING ID:3749557 SYMPTOM: System hangs and becomes unresponsive because of heavy memory consumption by vxvm. DESCRIPTION: In the Dirty Region Logging(DRL) update code path an erroneous condition was present that lead to an infinite loop which keeps on consuming memory. This leads to consumption of large amounts of memory making the system unresponsive. RESOLUTION: Code has been fixed, to avoid the infinite loop, hence preventing the hang which was caused by high memory usage. * INCIDENT NO:3751524 TRACKING ID:3719478 SYMPTOM: After LUN expands, ZFS zpool size does not expand automatically when dmp_native_support is enabled. DESCRIPTION: Solaris ZFS checks the Nblocks property of the LUN to determine if the zpool size needs to be extended accordingly. When zpool is deployed on Dynamic Multi-pathing (DMP), DMP will return the size of the first path as the Nblocks property to ZFS. If the path is not active and enable, the size will be stale. In such case, ZFS gets the stale size and doesnt expand the zpool. RESOLUTION: The code is modified to return the refreshed size of the active and enabled path. INCIDENTS FROM OLD PATCHES: --------------------------- NONE