* * * READ ME * * * * * * Veritas Volume Manager 6.0.3 * * * * * * Public Hot Fix 1 * * * Patch Date: 2013-09-13 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 6.0.3 Public Hot Fix 1 OPERATING SYSTEMS SUPPORTED BY THE PATCH ---------------------------------------- HP-UX 11i v3 (11.31) PACKAGES AFFECTED BY THE PATCH ------------------------------ VRTSvxvm VRTSvxvm BASE PRODUCT VERSIONS FOR THE PATCH ----------------------------------- * Veritas Storage Foundation for Oracle RAC 6.0.1 * Veritas Storage Foundation Cluster File System 6.0.1 * Veritas Storage Foundation 6.0.1 * Veritas Storage Foundation High Availability 6.0.1 * Veritas Dynamic Multi-Pathing 6.0.1 SUMMARY OF INCIDENTS FIXED BY THE PATCH --------------------------------------- Patch ID: PVCO_04001, PVKL_04002 * 2892702 (2567618) The VRTSexplorer dumps core in vxcheckhbaapi/print_target_map_entry. * 3090670 (3090667) The system panics or hangs while executing the "vxdisk -o thin, fssize list" command as part of Veritas Operations Manager (VOM) Storage Foundation (SF) discovery. * 3140411 (2959325) The vxconfigd(1M) daemon dumps core while performing the disk group move operation. * 3150893 (3119102) Support LDOM Live Migration with fencing enabled * 3156719 (2857044) System crash on voldco_getalloffset when trying to resize filesystem. * 3159096 (3146715) 'Rlinks' do not connect with NAT configurations on Little Endian Architecture. * 3254227 (3182350) VxVM volume creation or size increase hangs * 3254229 (3063378) VM commands are slow when Read Only disks are presented * 3254427 (3182175) "vxdisk -o thin, fssize list" command can report incorrect File System usage data * 3280555 (2959733) Handling device path reconfiguration incase the device paths are moved across LUNs or enclosures to prevent vxconfigd coredump. * 3294641 (3107741) vxrvg snapdestroy fails with "Transaction aborted waiting for io drain" error and vxconfigd hangs for around 45 minutes * 3294642 (3019684) IO hang on master while SRL is about to overflow Patch ID: PVCO_03974, PVKL_03975 * 2853712 (2815517) vxdg adddisk allows mixing of clone & non-clone disks in a DiskGroup. * 2863672 (2834046) NFS migration failed due to device reminoring. * 2892590 (2779580) Secondary node gives configuration error (no Primary RVG) after reboot of master node on Primary site. * 2892682 (2837717) "vxdisk(1M) resize" command fails if 'da name' is specified. * 2892684 (1859018) "link detached from volume" warnings are displayed when a linked-breakoff snapshot is created * 2892698 (2851085) DMP doesn't detect implicit LUN ownership changes for some of the dmpnodes * 2892716 (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. * 2913789 (2876256) vxdisk -f -g set mediatype=ssd command is failing with new namingscheme. * 2940447 (2940446) A full file system check (fsck) hangs on I/O in Veritas Volume Manager (VxVM) when the cache object size is very large. * 2941193 (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. * 2941226 (2915063) During the detachment of a plex of a volume in the Cluster Volume Manager (CVM) environment, the system panics. * 2941234 (2899173) The vxconfigd(1M) daemon hangs after executing the "vradmin stoprep" command. * 2941237 (2919318) The I/O fencing key value of data disk are different and abnormal in a VCS cluster with I/O fencing. * 2941252 (1973983) The vxunreloc(1M) command fails when the Data Change Object (DCO) plex is in DISABLED state. * 2942336 (1765916) VxVM socket files don't have proper write protection * 2944708 (1725593) The 'vxdmpadm listctlr' command has to be enhanced to print the count of device paths seen through the controller. * 2944710 (2744004) vxconfigd is hung on the VVR secondary node during VVR configuration. * 2944714 (2833498) vxconfigd hangs while reclaim operation is in progress on volumes having instant snapshots * 2944717 (2851403) System panic is seen while unloading "vxio" module. This happens whenever VxVM uses SmartMove feature and the "vxportal" module gets reloaded (for e.g. during VxFS package upgrade) * 2944722 (2869594) Master node panics due to corruption if space optimized snapshots are refreshed and 'vxclustadm setmaster' is used to select master. * 2944724 (2892983) vxvol dumps core if new links are added while the operation is in progress. * 2944725 (2910043) Avoid order 8 allocation by vxconfigd in node reconfig. * 2944727 (2919720) The vxconfigd(1M) command dumps core in the rec_lock1_5() function. * 2944729 (2933138) panic in voldco_update_itemq_chunk() due to accessing invalid buffer * 2944736 (2857827) During early boot, recovery of linked volume resize fails due to /usr not mounted. * 2944741 (2866059) The error messages displayed during the resize operation by using the vxdisk (1M) command needs to be enhanced. * 2962257 (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. * 2974870 (2935771) In a Veritas Volume Replicator (VVR) environment, the 'rlinks' disconnect after switching the master node. * 2976946 (2919714) On a thin Logical Unit Number (LUN), the vxevac(1M) command returns 0 without migrating the unmounted-VxFS volumes. * 2978189 (2948172) Executing "vxdisk -o thin, fssize list" command can result in panic. * 2979767 (2798673) System panics in voldco_alloc_layout() while creating volume with instant DCO * 2983679 (2970368) Enhance handling of SRDF-R2 Write-Disabled devices in DMP. * 3004823 (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. * 3004852 (2886333) The vxdg(1M) join operation should not allow mixing of clone and non-clone disks in a disk group. * 3005921 (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. * 3006262 (2715129) Vxconfigd hangs during Master takeover in a CVM (Clustered Volume Manager) environment. * 3011391 (2965910) Volume creation with vxassist using "-o ordered alloc=" dumps core. * 3011444 (2398416) vxassist dumps core while creating volume after adding attribute "wantmirror=ctlr" in default vxassist rulefile * 3020087 (2619600) Live migration of virtual machine having SFHA/SFCFSHA stack with data disks fencing enabled, causes service groups configured on virtual machine to fault. * 3025973 (3002770) While issuing a SCSI inquiry command, NULL pointer dereference in DMP causes system panic. * 3026288 (2962262) Uninstall of dmp fails in presence of other multipathing solutions * 3027482 (2273190) Incorrect setting of UNDISCOVERED flag can lead to database inconsistency DETAILS OF INCIDENTS FIXED BY THE PATCH --------------------------------------- This patch fixes the following Symantec incidents: Patch ID: PVCO_04001, PVKL_04002 * 2892702 (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. * 3090670 (Tracking ID: 3090667) SYMPTOM: The "vxdisk -o thin, fssize list" command can cause system to hang or panic due to a kernel memory corruption. This command is also issued by Veritas Operations Manager (VOM) internally during Storage Foundation (SF) discovery. The following stack trace is observed: panic string: kernel heap corruption detected vol_objioctl vol_object_ioctl voliod_ioctl - frame recycled volsioctl_real DESCRIPTION: Veritas Volume Manager (VxVM) allocates data structures and invokes thin Logical Unit Numbers (LUNs) specific function handlers, to determine the disk space that is actively used by the file system. One of the function handlers wrongly accesses the system memory beyond the allocated data structure, which results in the kernel memory corruption. RESOLUTION: The code is modified so that the problematic function handler accesses only the allocated memory. * 3140411 (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. * 3150893 (Tracking ID: 3119102) SYMPTOM: Live migration of virtual machine having Storage Foundation stack with data disks fencing enabled, causes service groups configured on virtual machine to fault. DESCRIPTION: After live migration of virtual machine having Storage Foundation stack with data disks fencing enabled is done, I/O fails on shared SAN devices with reservation conflict and causes service groups to fault. Live migration causes SCSI initiator change. Hence I/O coming from migrated server to shared SAN storage fails with reservation conflict. RESOLUTION: Code changes are added to check whether the host is fenced off from cluster. If host is not fenced off, then registration key is re-registered for dmpnode through migrated server and restart IO. Admin needs to manually invoke 'vxdmpadm pgrrereg' from guest which was live migrated after live migration. * 3156719 (Tracking ID: 2857044) SYMPTOM: System crashes with following stack when resizing volume with DCO version 30. PID: 43437 TASK: ffff88402a70aae0 CPU: 17 COMMAND: "vxconfigd" #0 [ffff884055a47600] machine_kexec at ffffffff8103284b #1 [ffff884055a47660] crash_kexec at ffffffff810ba972 #2 [ffff884055a47730] oops_end at ffffffff81501860 #3 [ffff884055a47760] no_context at ffffffff81043bfb #4 [ffff884055a477b0] __bad_area_nosemaphore at ffffffff81043e85 #5 [ffff884055a47800] bad_area at ffffffff81043fae #6 [ffff884055a47830] __do_page_fault at ffffffff81044760 #7 [ffff884055a47950] do_page_fault at ffffffff8150383e #8 [ffff884055a47980] page_fault at ffffffff81500bf5 [exception RIP: voldco_getalloffset+38] RIP: ffffffffa0bcc436 RSP: ffff884055a47a38 RFLAGS: 00010046 RAX: 0000000000000001 RBX: ffff883032f9eac0 RCX: 000000000000000f RDX: ffff88205613d940 RSI: ffff8830392230c0 RDI: ffff883fd1f55800 RBP: ffff884055a47a38 R8: 0000000000000000 R9: 0000000000000000 R10: 000000000000000e R11: 000000000000000d R12: ffff882020e80cc0 R13: 0000000000000001 R14: ffff883fd1f55800 R15: ffff883fd1f559e8 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #9 [ffff884055a47a40] voldco_get_map_extents at ffffffffa0bd09ab [vxio] #10 [ffff884055a47a90] voldco_update_extents_info at ffffffffa0bd8494 [vxio] #11 [ffff884055a47ab0] voldco_instant_resize_30 at ffffffffa0bd8758 [vxio] #12 [ffff884055a47ba0] volfmr_instant_resize at ffffffffa0c03855 [vxio] #13 [ffff884055a47bb0] voldco_process_instant_op at ffffffffa0bcae2f [vxio] #14 [ffff884055a47c30] volfmr_process_instant_op at ffffffffa0c03a74 [vxio] #15 [ffff884055a47c40] vol_mv_precommit at ffffffffa0c1ad02 [vxio] #16 [ffff884055a47c90] vol_commit_iolock_objects at ffffffffa0c1244f [vxio] #17 [ffff884055a47cf0] vol_ktrans_commit at ffffffffa0c131ce [vxio] #18 [ffff884055a47d70] volconfig_ioctl at ffffffffa0c8451f [vxio] #19 [ffff884055a47db0] volsioctl_real at ffffffffa0c8c9b8 [vxio] #20 [ffff884055a47e90] vols_ioctl at ffffffffa0040126 [vxspec] #21 [ffff884055a47eb0] vols_compat_ioctl at ffffffffa004034d [vxspec] #22 [ffff884055a47ee0] compat_sys_ioctl at ffffffff811ce0ed #23 [ffff884055a47f80] sysenter_dispatch at ffffffff8104a880 DESCRIPTION: While updating DCO TOC(Table Of Content) entries into in-core TOC, a TOC entry is wrongly freed and zeroed out. As a result, traversing TOC entries leads to NULL pointer dereference and thus, causing the panic. RESOLUTION: Code changes have been made to appropriately update the TOC entries. * 3159096 (Tracking ID: 3146715) SYMPTOM: The 'rinks' do not connect with the Network Address Translation (NAT) configurations on Little Endian Architecture (LEA). DESCRIPTION: On LEAs, the Internet Protocol (IP) address configured with the NAT mechanism is not converted from the host-byte order to the network-byte order. As a result, the address used for the rlink connection mechanism gets distorted and the 'rlinks' fail to connect. RESOLUTION: The code is modified to convert the IP address to the network-byte order before it is used. * 3254227 (Tracking ID: 3182350) SYMPTOM: If there are more than 8192 paths in the system, the vxassist command hangs while creating a new VxVM volume or increasing the existing volume's size. DESCRIPTION: The vxassist command creates a hash table with max 8192 entries. Hence other paths greater than 8192 will get hashed to an overlapping bucket in this hash table. In such case, multiple paths which hash to the same bucket are linked in a chain. In order to find a particular path in a specified bucket, vxassist command needs to traverse the entire linked chain. However vxassist only searches the first element and hangs. RESOLUTION: The code is modifed to traverse the entire linked chain. * 3254229 (Tracking ID: 3063378) SYMPTOM: Some VxVM (Volume Manager) commands run slowly when "read only" devices (e.g. EMC SRDF-WD, BCV-NR) are presented and managed by EMC PowerPath. DESCRIPTION: When performing IO write on a "read only" device, IO fails and retry will be done if IO is on TPD(Third Party Driver) device and path status is okay. Owing to the retry, IO will not return until timeout reaches which gives the perception that VxVM commands run slowly. RESOLUTION: Code changes have been done to return IO immediately with disk media failure if IO fails on any TPD device and path status is okay. * 3254427 (Tracking ID: 3182175) SYMPTOM: "vxdisk -o thin, fssize list" command can report incorrect File System usage data. DESCRIPTION: An integer overflow in the internal calculation can cause this command to report incorrect per disk FS usage. RESOLUTION: Code changes are made so that the command would report the correct File System usage data. * 3280555 (Tracking ID: 2959733) SYMPTOM: When device paths are moved across LUNs or enclosures, vxconfigd daemon can dump core or data corruption can occur due to internal data structure inconsistencies. 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 other storage arrays (enclosures), the DMP's internal data structures get messed up leading to vxconfigd daemon dumping core and in some situations data corruption due to incorrect LUN to path mappings. RESOLUTION: To resolve this issue, the vxconfigd code was modified to detect such situations gracefully and modify the internal data structures accordingly to avoid a vxconfigd coredump and data corruption * 3294641 (Tracking ID: 3107741) SYMPTOM: "vxrvg snapdestroy" command fails with error message "Transaction aborted waiting for io drain", and vxconfigd hang is observed. vxconfigd stack trace is: vol_commit_iowait_objects vol_commit_iolock_objects vol_ktrans_commit volconfig_ioctl volsioctl_real vols_ioctl vols_compat_ioctl compat_sys_ioctl ... DESCRIPTION: The smartmove query of VxFS depends on some reads and writes. If some transaction in VxVM blocks the new read and write, then API is hung waiting for the response. This creates a deadlock-like situation with Smartmove API is waiting for transaction to complete and transaction waiting Smartmove API is hung waiting for transaction, and hence the hang. RESOLUTION: Disallow transactions during the Smartmove API. * 3294642 (Tracking ID: 3019684) SYMPTOM: IO hang is observed when SRL is about to overflow after logowner switch from slave to master. Stack trace looks like: biowait default_physio volrdwr fop_write write syscall_trap32 DESCRIPTION: Delineating the steps, with slave as logowner, overflow the SRL and following it up with DCM resync. Then, switching back logowner to master and trying to overflow SRL again would manifest the IO hang in the master when SRL is about to overflow. This happens because the master has a stale flag set with incorrect value related to last SRL overflow. RESOLUTION: Reset the stale flag and ensure that flag is reset whether the logowner is master or slave. Patch ID: PVCO_03974, PVKL_03975 * 2853712 (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. * 2863672 (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. * 2892590 (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. * 2892682 (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 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. * 2892684 (Tracking ID: 1859018) SYMPTOM: "Link link detached from volume " warnings are displayed when a linked-breakoff snapshot is created. DESCRIPTION: The purpose of these message is to let user and administrators know about the detach of link due to I/O errors. These messages get displayed uneccesarily whenever linked-breakoff snapshot is created. RESOLUTION: Code changes are made to display messages only when link is detached due to I/O errors on volumes involved in link-relationship. * 2892698 (Tracking ID: 2851085) SYMPTOM: DMP doesn't detect implicit LUN ownership changes DESCRIPTION: DMP does ownership monitoring for ALUA arrays to detect implicit LUN ownership changes. This helps DMP to always use Active/Optimized path for sending down I/O. This feature is controlled using dmp_monitor_ownership tune and is enabled by default. In case of partial discovery triggered through event source daemon (vxesd), ALUA information kept in kernel data structure for ownership monitoring was getting wiped. This causes ownership monitoring to not work for these dmpnodes. RESOLUTION: Source has been updated to handle such case. * 2892716 (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. * 2913789 (Tracking ID: 2876256) SYMPTOM: "vxdisk set mediatype" command fails the naming scheme is set to 'new'. The following error message is observed: "VxVM vxdisk ERROR V-5-1-12952 Device not in configuration or associated with DG " DESCRIPTION: When vxdisk(1M) command to set the mediatype is run on the disk 'new naming- scheme', it fails. The case to handle the scenario to get the corresponding 'da name' of the 'new naming-scheme' is not handled. RESOLUTION: If the disk with 'new naming-scheme' is not found then get the corresponding 'da name' in the 'set mediatype' code path. * 2940447 (Tracking ID: 2940446) SYMPTOM: The I/O may hang on a volume with space optimized snapshot if the underlying cache object is of a very large size ( 30 TB ). It can also lead to data corruption in the cache-object. The following stack is observed: pvthread() et_wait() uphyswait() uphysio() vxvm_physio() volrdwr() volwrite() vxio_write() rdevwrite() cdev_rdwr() spec_erdwr() spec_rdwr() vnop_rdwr() vno_rw() rwuio() rdwr() kpwrite() ovlya_addr_sc_flih_main() DESCRIPTION: The cache volume maintains a B+ tree for mapping the offset and its actual location in the cache object. Copy-on-write I/O generated on snapshot volumes needs to determine the offset of the particular I/O in the cache object. Due to the incorrect type-casting, the value calculated for the large offset truncates to the smaller value due to the overflow, leading to data corruption. RESOLUTION: The code is modified to avoid overflow during the offset calculation in the cache object. It is advised to create multiple cache objects of around 10 TB, rather than creating a single cache object of a very large size. * 2941193 (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. * 2941226 (Tracking ID: 2915063) SYMPTOM: During the detachment of a plex of a volume in the Cluster Volume Manager (CVM) environment, the master node panics with the following stack trace: vol_klog_findent() vol_klog_detach() vol_mvcvm_cdetsio_callback() vol_klog_start() voliod_iohandle() voliod_loop() DESCRIPTION: During the plex-detach operation, VxVM searches the plex object to be detached in the kernel. If any transaction is in progress on any disk group in the system, an incorrect plex object may be selected. This results in dereferencing of the invalid addresses and causes the system to panic. RESOLUTION: The code is modified to make sure that the correct plex object is selected. * 2941234 (Tracking ID: 2899173) SYMPTOM: In a Clustered Volume Replicator (CVR) environment, an Storage Replicator Log (SRL) failure may cause the vxconfigd(1M) daemon to hang. This eventually causes the 'vradmin stoprep' command to hang. DESCRIPTION: The 'vradmin stoprep' command hangs because of the vxconfigd(1M) daemon that waits indefinitely during a transaction. The transaction waits for I/O completion on SRL. An error handler is generated to handle the I/O failure on the SRL. But if there is an ongoing transaction, the error is not handled properly. This causes the transaction to hang. RESOLUTION: The code is modified so that when an SRL failure is encountered, the transaction itself handles the I/O error on SRL. * 2941237 (Tracking ID: 2919318) SYMPTOM: In a CVM environment with fencing enabled, wrong fencing keys are registered for opaque disks during node join or dg import operations. DESCRIPTION: During cvm node join and shared dg import code path, when opaque disk registration happens, fencing keys in internal dg records are not in sync with actual keys generated. This was causing wrong fencing keys registered for opaque disks. For rest disks fencing key registration happens correctly. RESOLUTION: Fix is to copy correctly generated key to internal dg record for current dg import/node join scenario and use it for disk registration. * 2941252 (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. * 2942336 (Tracking ID: 1765916) SYMPTOM: VxVM socket files don't have write protection from other users. The following files are writeable by all users: srwxrwxrwx root root /etc/vx/vold_diag/socket srwxrwxrwx root root /etc/vx/vold_inquiry/socket srwxrwxrwx root root /etc/vx/vold_request/socket DESCRIPTION: These sockets are used by the admin/support commands to communicate with the vxconfigd. These sockets are created by vxconfigd during it's start up process. RESOLUTION: Proper write permissions are given to VxVM socket files. Only vold_inquiry/socket file is still writeable by all, because it is used by many VxVM commands like vxprint, which are used by all users. * 2944708 (Tracking ID: 1725593) SYMPTOM: The 'vxdmpadm listctlr' command does not show the count of device paths seen through it DESCRIPTION: The 'vxdmpadm listctlr' currently does not show the number of device paths seen through it. The CLI option has been enhanced to provide this information as an additional column at the end of each line in the CLI's output RESOLUTION: The number of paths under each controller is counted and the value is displayed as the last column in the 'vxdmpadm listctlr' CLI output * 2944710 (Tracking ID: 2744004) SYMPTOM: When VVR is configured, vxconfigd on secondary gets hung. Any vx commands issued during this time does not complete. DESCRIPTION: Vxconfigd is waiting for IOs to drain before allowing a configuration change command to proceed. The IOs never drain completely resulting into the hang. This is because there is a deadlock where pending IOs are unable to start and vxconfigd keeps waiting for their completion. RESOLUTION: Changed the code so that this deadlock does not arise. The IOs can be started properly and complete allowing vxconfigd to function properly. * 2944714 (Tracking ID: 2833498) SYMPTOM: vxconfigd daemon hangs in vol_ktrans_commit() while reclaim operation is in progress on volumes having instant snapshots. Stack trace is given below: vol_ktrans_commit volconfig_ioctl DESCRIPTION: Storage reclaim leads to the generation of special IOs (termed as Reclaim IOs), which can be very large in size(>4G) and unlike application IOs, these are not broken into smaller sized IOs. Reclaim IOs need to be tracked in snapshot maps if the volume has full snapshots configured. The mechanism to track reclaim IO is not capable of handling such large IOs causing hang. RESOLUTION: Code changes are made to use the alternative mechanism in Volume manager to track the reclaim IOs. * 2944717 (Tracking ID: 2851403) SYMPTOM: System panics while unloading 'vxio' module when VxVM SmartMove feature is used and the "vxportal" module gets reloaded (for e.g. during VxFS package upgrade). Stack trace looks like: vxportalclose() vxfs_close_portal() vol_sr_unload() vol_unload() DESCRIPTION: During a smart-move operation like plex attach, VxVM opens the 'vxportal' module to read in-use file system maps information. This file descriptor gets closed only when 'vxio' module is unloaded. If the 'vxportal' module is unloaded and reloaded before 'vxio', the file descriptor with 'vxio' becomes invalid and results in a panic. RESOLUTION: Code changes are made to close the file descriptor for 'vxportal' after reading free/invalid file system map information. This ensures that stale file descriptors don't get used for 'vxportal'. * 2944722 (Tracking ID: 2869594) SYMPTOM: Master node would panic with following stack after a space optimized snapshot is refreshed or deleted and master node is selected using 'vxclustadm setmaster' volilock_rm_from_ils vol_cvol_unilock vol_cvol_bplus_walk vol_cvol_rw_start voliod_iohandle voliod_loop thread_start In addition to this, all space optimized snapshots on the corresponding cache object may be corrupted. DESCRIPTION: In CVM, the master node owns the responsibility of maintaining the cache object indexing structure for providing space optimized functionality. When a space optimized snapshot is refreshed or deleted, the indexing structure would get rebuilt in background after the operation is returned. When the master node is switched using 'vxclustadm setmaster' before index rebuild is complete, both old master and new master nodes would rebuild the index in parallel which results in index corruption. Since the index is corrupted, the data stored on space optimized snapshots should not be trusted. I/Os issued on corrupted index would lead to panic. RESOLUTION: When the master role is switched using 'vxclustadm setmaster', the index rebuild on old master node would be safely aborted. Only new master node would be allowed to rebuild the index. * 2944724 (Tracking ID: 2892983) SYMPTOM: vxvol command dumps core with the following stack trace, if executed parallel to vxsnap addmir command strcmp() do_link_recovery trans_resync_phase1() vxvmutil_trans() trans() common_start_resync() do_noderecover() main() DESCRIPTION: During creation of link between two volumes if vxrecover is triggered, vxvol command may not have information about the newly created links. This leads to NULL pointer dereference and dumps core. RESOLUTION: The code has been modified to check if links information is properly present with vxvol command and fail operation with appropriate error message. * 2944725 (Tracking ID: 2910043) SYMPTOM: When VxVM operations like plex attach, snapshot resync or reattach are performed, frequent swap-in and swap-out activities are observed due to excessive memory allocation by vxiod daemons. DESCRIPTION: In VxVM operations such as plex attach, snapshot resync/reattach issue ATOMIC_COPY IOCTL's. Default I/O size for these operation is 1MB and VxVM allocates this memory from operating system. Memory allocations of such large size can results into swapin/swapout of pages and are not very efficient. In presence of lot of such operations , system may not work very efficiently. RESOLUTION: VxVM has its own I/O memory management module, which allocates pages from operating system and efficiently manage them. Modified ATOMIC_COPY code to make use of VxVM's internal I/O memory pool instead of directly allocating memory from operating system. * 2944727 (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. * 2944729 (Tracking ID: 2933138) SYMPTOM: System panics with stack trace given below: voldco_update_itemq_chunk() voldco_chunk_updatesio_start() voliod_iohandle() voliod_loop() DESCRIPTION: While tracking IOs in snapshot MAPS information is stored in- memory pages. For large sized IOs (such as reclaim IOs), this information can span across multiple pages. Sometimes the pages are not properly referenced in MAP update for IOs of larger size which lead to panic because of invalid page addresses. RESOLUTION: Code is modified to properly reference pages during MAP update for large sized IOs. * 2944736 (Tracking ID: 2857827) SYMPTOM: During early boot, recovery of linked volume resize fails due to "/usr" not mounted. The following error is observed: "Cannot execute /etc/vx/type/static/vxassist: No such file or directory" DESCRIPTION: On HPUX in the early boot cycle, when "/usr" is not mounted and root file system is mounted as read-only, vxrecover(1M) invokes vxassist(1M). As vxassist(1M) is located in "/usr" directory, the vxrecover(1M) command fails. RESOLUTION: Compiled a "static" vxassist binary for the root disk support , especially in the early boot cycle when "/usr" is not mounted and root file system is mounted as read-only. The new "static" vxassist binary is kept at "/etc/vx/type/static/" directory. The vxrecover(1M) command invokes this new static vxassist(1M) binary when "/usr" is not mounted. * 2944741 (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. * 2962257 (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. * 2974870 (Tracking ID: 2935771) SYMPTOM: In a Veritas Volume Replicator (VVR) environment, the 'rlinks' disconnect after switching the master node. DESCRIPTION: Sometimes switching a master node on the primary node can cause the 'rlinks' to disconnect. The "vradmin repstatus" command displays "paused due to network disconnection" as the replication status. VVR uses a connection to check if the secondary node is alive. The secondary node responds to these requests by replying back, indicating that it is alive. On a master node switch, the old master node fails to close this connection with the secondary node. Thus, after the master node switch the old master node as well as the new master node sends the requests to the secondary node. This causes a mismatch of connection numbers on the secondary node, and the secondary node does not reply to the requests of the new master node. Thus, it causes the 'rlinks' to disconnect. RESOLUTION: The code is modified to close the connection of the old master node with the secondary node, so that it does not send the connection requests to the secondary node. * 2976946 (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. * 2978189 (Tracking ID: 2948172) SYMPTOM: Execution of command "vxdisk -o thin, fssize list" can cause hang or panic. Hang stack trace might look like: pse_block_thread pse_sleep_thread .hkey_legacy_gate volsiowait vol_objioctl vol_object_ioctl voliod_ioctl volsioctl_real volsioctl Panic stack trace might look like: voldco_breakup_write_extents volfmr_breakup_extents vol_mv_indirect_write_start volkcontext_process volsiowait vol_objioctl vol_object_ioctl voliod_ioctl volsioctl_real vols_ioctl vols_compat_ioctl compat_sys_ioctl sysenter_dispatch DESCRIPTION: Command "vxdisk -o thin, fssize list" triggers reclaim I/Os to get file system usage from veritas file system on veritas volume manager mounted volumes. We currently do not support reclamation on volumes with space optimized (SO) snapshots. But because of a bug, reclaim IOs continue to execute for volumes with SO Snapshots leading to system panic/hang. RESOLUTION: Code changes are made to not to allow reclamation IOs to proceed on volumes with SO Snapshots. * 2979767 (Tracking ID: 2798673) SYMPTOM: System panic is observed with the stacktrace given below: voldco_alloc_layout voldco_toc_updatesio_done voliod_iohandle voliod_loop DESCRIPTION: DCO (data change object) contains metadata information required to start DCO volume and decode further information from the DCO volume. This information is stored in the 1st block of DCO volume. If this metadata information is incorrect/corrupted, the further processing of volume start resulted into panic due to divide-by-zero error in kernel. RESOLUTION: Code changes are made to verify the correctness of DCO volumes metadata information during startup. If the information read is incorrect, volume start operations fails. * 2983679 (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. * 3004823 (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 * 3004852 (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. * 3005921 (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. * 3006262 (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. * 3011391 (Tracking ID: 2965910) SYMPTOM: vxassist dumps core with following stack: setup_disk_order() volume_alloc_basic_setup() fill_volume() setup_new_volume() make_trans() vxvmutil_trans() trans() transaction() do_make() main() DESCRIPTION: When -o ordered is used, vxassist handles non-disk parameters in a different way. This scenario may result in invalid comparison, leading to a core dump. RESOLUTION: Code changes are made to handle the parameter comparison logic properly. * 3011444 (Tracking ID: 2398416) SYMPTOM: vxassist dumps core with the following stack: merge_attributes() get_attributes() do_make() main() _start() DESCRIPTION: vxassist dumps core while creating volume when attribute 'wantmirror=ctlr' is added to the '/etc/default/vxassist' file. vxassist reads this default file initially and uses the attributes specified to allocate the storage during the volume creation. However, during the merging of attributes specified in the default file, it accesses NULL attribute structure causing the core dump. RESOLUTION: Necessary code changes have been done to check the attribute structure pointer before accessing it. * 3020087 (Tracking ID: 2619600) SYMPTOM: Live migration of virtual machine having SFHA/SFCFSHA stack with data disks fencing enabled, causes service groups configured on virtual machine to fault. DESCRIPTION: After live migration of virtual machine having SFHA/SFCFSHA stack with data disks fencing enabled is done, I/O fails on shared SAN devices with reservation conflict and causes service groups to fault. Live migration causes SCSI initiator change. Hence I/O coming from migrated server to shared SAN storage fails with reservation conflict. RESOLUTION: Code changes are added to check whether the host is fenced off from cluster. If host is not fenced off, then registration key is re-registered for dmpnode through migrated server and restart IO. * 3025973 (Tracking ID: 3002770) SYMPTOM: When a SCSI-inquiry command is executed, any NULL- pointer dereference in Dynamic Multi-Pathing (DMP) causes the system to panic with the following stack trace: dmp_aa_recv_inquiry() dmp_process_scsireq() dmp_daemons_loop() DESCRIPTION: The panic occurs when the SCSI response for the SCSI-inquiry command is handled. In order to determine if the path on which the SCSI-inquiry command issued is read-only, DMP needs to check the error buffer. However, the error buffer is not always prepared. So before making any further checking, DMP should examine if the error buffer is valid before any further checking. Without any error-buffer examination, the system panics with a NULL pointer. RESOLUTION: The code is modified to verify that the error buffer is valid. * 3026288 (Tracking ID: 2962262) SYMPTOM: When DMP Native Stack support is enabled and some devices are being managed by a multipathing solution other than DMP, then uninstalling DMP fails with an error for not being able to turn off DMP Native Stack support. Performing DMP prestop tasks ...................................... Done The following errors were discovered on the systems: CPI ERROR V-9-40-3436 Failed to turn off dmp_native_support tunable on pilotaix216. Refer to Dynamic Multi-Pathing Administrator's guide to determine the reason for the failure and take corrective action. VxVM vxdmpadm ERROR V-5-1-15690 Operation failed for one or more volume groups The CLI 'vxdmpadm settune dmp_native_support=off' also fails with following error. # vxdmpadm settune dmp_native_support=off VxVM vxdmpadm ERROR V-5-1-15690 Operation failed for one or more volume groups DESCRIPTION: With DMP Native Stack support it is expected that devices which are being used by LVM are multipathed by DMP. Co-existence with other multipath solutions in such cases is not supported. Having some other multipath solution results in this error. RESOLUTION: Code changes have been made to not error out while turning off DMP Native Support if device is not being managed by DMP. * 3027482 (Tracking ID: 2273190) SYMPTOM: The device discovery commands 'vxdisk scandisks' or 'vxdctl enable' issued just after license key installation may fail and abort. DESCRIPTION: After addition of license key that enables multi-pathing, the state of paths maintained at user level is incorrect. RESOLUTION: As a fix, whenever multi-pathing license key is installed, the operation updates the state of paths both at user level and kernel level. INSTALLING THE PATCH -------------------- VxVM 6.0.100.000 (GA) must be installed before applying these patches. To install the patch, enter the following command: # swinstall -x autoreboot=true -s Incase the patch is not registered, the patch can be registered using the following command: # swreg -l depot where is the absolute path where the patch resides. d) Please do swverify after installing the patches in order to make sure that the patches are installed correctly using: $ swverify REMOVING THE PATCH ------------------ To remove the patch, enter the following command: # swremove -x autoreboot=true KNOWN ISSUES ------------ * Tracking ID: 2954029 SYMPTOM: When the user tries to remove LUNs from the system using vxdiskadm option 22-2 Dynamic Reconfiguration operation 'Remove Luns', the device removal operation might fail and report the following error message. "ERROR: Please make sure to remove Luns from Array" This is due to the Dynamic Reconfiguration Tool not being able to find devices that are not part of the legacy HP-UX I/O device tree but are seen only in the agile I/O device tree. WORKAROUND: Perform the following steps - Remove the device with no hardware (NO_HW in output of 'ioscan -fNC disk') using rmsf(1M) - Run ioscan(1M) - Run 'vxdisk scandisks'. * Tracking ID: 2977115 SYMPTOM: When device discovery commands (vxdctl enable or vxdisk scandisks) are run during BCV operations, SAN migration and the like, vxconfigd queries the operating system device tree using HP libIO library (io_init, io_search, io_end etc). Occasionally io_search() returns a NULL string. With VxVM 5.0.1 or higher, DDL/DMP thinks that all the devices have disappeared and removes all the arrays and DMP devices (a.k.a. dmpnode's) that are visible to the host. This leads to VxVM I/O errors and file systems getting disabled. In cases where VxVM manages the root disk(s), a system hang would result. In a VCS environment, this could trigger monitor timeouts and a possible service group fault. In a HP Serviceguard/SGeRAC environment integrated with CVM and/or CFS, the VxVM I/O failures would typically lead to a Serviceguard INIT and/or a CRS TOC (if the voting disks sit on VxVM volumes). Please refer to the technote issued on this issue. http://www.symantec.com/business/support/index?page=content&id=TECH200183 WORKAROUND: Running vxconfigd with multithreading disabled will effectively avoid the issue in a standalone VxVM configuration. * Tracking ID: 3037620 SYMPTOM: If VCS engine is stopped for the first time, the SCSI registration keys are removed. But if VCS engine is stopped for the second time, the keys are not removed. WORKAROUND: None SPECIAL INSTRUCTIONS -------------------- NO OTHERS ------ NONE