vm-aix-5.1SP1RP3P1
Obsolete
The latest patch(es) : sfha-aix-5.1SP1RP4  sfha-aix71-5.1SP1PR1RP4 

 Basic information
Release type: P-patch
Release date: 2012-11-16
OS update support: None
Technote: None
Documentation: None
Popularity: 4572 viewed    downloaded
Download size: 76.23 MB
Checksum: 1440798114

 Applies to one or more of the following products:
Dynamic Multi-Pathing 5.1SP1 On AIX 5.3
Dynamic Multi-Pathing 5.1SP1 On AIX 6.1
Dynamic Multi-Pathing 5.1SP1PR1 On AIX 7.1
Storage Foundation 5.1SP1 On AIX 5.3
Storage Foundation 5.1SP1 On AIX 6.1
Storage Foundation 5.1SP1PR1 On AIX 7.1
Storage Foundation Cluster File System 5.1SP1 On AIX 5.3
Storage Foundation Cluster File System 5.1SP1 On AIX 6.1
Storage Foundation Cluster File System 5.1SP1PR1 On AIX 7.1
Storage Foundation for Oracle RAC 5.1SP1 On AIX 5.3
Storage Foundation for Oracle RAC 5.1SP1 On AIX 6.1
Storage Foundation for Oracle RAC 5.1SP1PR1 On AIX 7.1
Storage Foundation HA 5.1SP1 On AIX 5.3
Storage Foundation HA 5.1SP1 On AIX 6.1
Storage Foundation HA 5.1SP1PR1 On AIX 7.1

 Obsolete patches, incompatibilities, superseded patches, or other requirements:

This patch is obsolete. It is superseded by: Release date
sfha-aix71-5.1SP1PR1RP4 2013-08-21
sfha-aix-5.1SP1RP4 2013-08-21

This patch supersedes the following patches: Release date
vm-aix-5.1SP1RP2P3 (obsolete) 2012-06-13
vm-aix-5.1SP1RP2P2 (obsolete) 2011-10-28
vm-aix-5.1SP1RP2P1 (obsolete) 2011-10-19
vm-aix-5.1SP1RP1P1 (obsolete) 2011-02-24
vm-aix-5.1SP1P2 (obsolete) 2011-01-12
vm-aix71-5.1SP1PR1P1 (obsolete) 2011-01-07
vm-aix-5.1SP1P1 (obsolete) 2010-12-01

This patch requires: Release date
sfha-aix71-5.1SP1PR1RP3 (obsolete) 2012-10-02
sfha-aix-5.1SP1RP3 (obsolete) 2012-10-02

 Fixes the following incidents:
2485252, 2711758, 2847333, 2860208, 2881862, 2883229, 2883606, 2906832, 2908571, 2919718, 2929003, 2933058, 2940448, 2946948, 2957608, 2979692

 Patch ID:
VRTSvxvm-05.01.0113.0100

Readme file
                          * * * READ ME * * *
             * * * Veritas Volume Manager 5.1 SP1 RP3 * * *
                         * * * P-patch 1 * * *
                         Patch Date: 2012-11-15


This document provides the following information:

   * PATCH NAME
   * PACKAGES AFFECTED BY THE PATCH
   * BASE PRODUCT VERSIONS FOR THE PATCH
   * OPERATING SYSTEMS SUPPORTED BY THE PATCH
   * INCIDENTS FIXED BY THE PATCH
   * INSTALLATION PRE-REQUISITES
   * INSTALLING THE PATCH
   * REMOVING THE PATCH


PATCH NAME
----------
Veritas Volume Manager 5.1 SP1 RP3 P-patch 1


PACKAGES AFFECTED BY THE PATCH
------------------------------
VRTSvxvm


BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * Veritas Storage Foundation for Oracle RAC 5.1 SP1
   * Veritas Storage Foundation Cluster File System 5.1 SP1
   * Veritas Storage Foundation 5.1 SP1
   * Veritas Storage Foundation High Availability 5.1 SP1
   * Veritas Dynamic Multi-Pathing 5.1 SP1


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
AIX 5.3 ppc
AIX 6.1 ppc
AIX 7.1 ppc


INCIDENTS FIXED BY THE PATCH
----------------------------
This patch fixes the following Symantec incidents:

Patch ID: 5.1.113.100

* 2485252 (Tracking ID: 2910043)

SYMPTOM:
Frequent swapin/swapout seen due to higher order memory requests

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.

* 2711758 (Tracking ID: 2710579)

SYMPTOM:
Data corruption can be observed on a CDS (Cross-platform Data Sharing) disk, 
as part of operations like LUN resize, Disk FLUSH, Disk ONLINE etc. The
following pattern would be found in the 
data region of the disk.

<DISK-IDENTIFICATION> cyl <number-of-cylinders> alt 2 hd <number-of-tracks> sec 
<number-of-sectors-per-track>

DESCRIPTION:
The CDS disk maintains a SUN VTOC in the zeroth block and a backup label at the 
end of the disk. The VTOC maintains the disk geometry information like number 
of cylinders, tracks and sectors per track. The backup label is the duplicate 
of VTOC and the backup label location is determined from VTOC contents. If the
content of SUN VTOC located in the zeroth sector are incorrect, this may result
in the wrong calculation of the backup label location. If the wrongly 
calculated backup label location falls in the public data region rather than 
the end of the disk as designed, data corruption occurs.

RESOLUTION:
Suppressed writing the backup label to prevent the data corruption.

* 2847333 (Tracking ID: 2834046)

SYMPTOM:
VxVM dynamically reminors all the volumes during DG import if the DG base minor
numbers are not in the correct pool. This behaviour cases NFS client to have to
re-mount all NFS file systems in an environment where CVM is used on the NFS
server side.

DESCRIPTION:
Starting from 5.1, the minor number space is divided into two pools, one for
private disk groups and another for shared disk groups. During DG import, the DG
base minor numbers will be adjusted automatically if not in the correct pool,
and so do the volumes in the disk groups. This behaviour reduces many minor
conflicting cases during DG import. But in NFS environment, it makes all file
handles on the client side stale. Customers had to unmount files systems and
restart applications.

RESOLUTION:
A new tunable, "autoreminor", is introduced. The default value is "on". Most of
the customers don't care about auto-reminoring. They can just leave it as it is.
For a environment that autoreminoring is not desirable, customers can just turn
it off. Another major change is that during DG import, VxVM won't change minor 
numbers as long as there is no minor conflicts. This includes the cases that 
minor numbers are in the wrong pool.

* 2860208 (Tracking ID: 2859470)

SYMPTOM:
The EMC SRDF-R2 disk may go in error state when you create EFI label on the R1 
disk. For example:

R1 site
# vxdisk -eo alldgs list | grep -i srdf
emc0_008c auto:cdsdisk emc0_008c SRDFdg online c1t5006048C5368E580d266 srdf-r1

R2 site
# vxdisk -eo alldgs list | grep -i srdf
emc1_0072 auto - - error c1t5006048C536979A0d65 srdf-r2

DESCRIPTION:
Since R2 disks are in write protected mode, the default open() call (made for 
read-write mode) fails for the R2 disks, and the disk is marked as invalid.

RESOLUTION:
As a fix, DMP was changed to be able to read the EFI label even on a write 
protected SRDF-R2 disk.

* 2881862 (Tracking ID: 2878876)

SYMPTOM:
vxconfigd, VxVM configuration daemon dumps core with the following stack.

vol_cbr_dolog ()
vol_cbr_translog ()
vold_preprocess_request () 
request_loop ()
main     ()

DESCRIPTION:
This core is a result of a race between two threads which are processing the 
requests from the same client. While one thread completed processing a request 
and is in the phase of releasing the memory used, other thread is processing a 
request "DISCONNECT" from the same client. Due to the race condition, the 
second thread attempted to access the memory which is being released and dumped 
core.

RESOLUTION:
The issue is resolved by protecting the common data of the client by a mutex.

* 2883229 (Tracking ID: 2180382)

SYMPTOM:
System panic happens with the following stack trace during heavy I/O load:

vol_ldata_siofree
voldco_multiupdate_sio_delete
voldco_multiupdate_sio_done
voliod_iohandle
voliod_loop
vol_kernel_thread_init

DESCRIPTION:
VxVM uses ldata pools provided by AIX to allocate memory for I/O structures. 
When a ldata pool is not being used, VxVM marks it for deletion. The marked 
pools will be deleted by separate kernel thread. In race condition where the 
deleted ldata pool is accessed for processing I/O's panic happens.

RESOLUTION:
Code changes are made to hold locks on ldata pools and make sure that it is not
already deleted.

* 2883606 (Tracking ID: 2189812)

SYMPTOM:
While executing 'vxdisk updateudid' on a disk which is in 'online invalid' 
state causes vxconfigd to dump core with following stack:

priv_join()
req_disk_updateudid()
request_loop()
main()

DESCRIPTION:
While updating udid, nullity check was not done for an internal data structure.
This lead vxconfigd to dump core.

RESOLUTION:
Code changes are done to add nullity checks for internal data structure.

* 2906832 (Tracking ID: 2398954)

SYMPTOM:
Machine panics while doing I/O on a VxFS mounted instant snapshot with ODM
smartsync enabled.
The panic has the following stack.
panic: post_hndlr(): Unresolved kernel interruption
cold_vm_hndlr
bubbledown
as_ubcopy
privlbcopy
volkio_to_kio_copy
vol_multistepsio_overlay_data
vol_multistepsio_start
voliod_iohandle
voliod_loop
kthread_daemon_startup

DESCRIPTION:
VxVM uses the fields av_back and av_forw of io buf structure to store its 
private information. VxFS also uses these fields to chain io buffers before 
passing I/O to VxVM. When an I/O is received at VxVM layer it always resets 
these fields. But if ODM smartsync is enabled, VxFS uses a special strategy 
routine to pass on hints to VxVM. Due to a bug in the special strategy routine, 
the fields av_back and av_forw are not reset and could be pointing to a valid 
buffer in VxFS io buffer chain. So VxVM interprets these fields wrongly and 
modifies its contents, it corrupts the next buffer in the chain leading to this 
panic.

RESOLUTION:
The fields av_back and av_forw of io buf structure are reset in the special
strategy routine.

* 2908571 (Tracking ID: 2288163)

SYMPTOM:
Exclusion of OS device path corresponding to a vSCSI lun using "vxdmpadm exclude
vxvm path=<>", excludes all the paths under its parent vSCSI controller.

Consider a vSCSI controller "vscsi1" with 4 paths:

# vxdmpadm getsubpaths ctlr=vscsi1
hdisk52      ENABLED(A)   -          v_ibm_ds8x000_015a v_ibm_ds8x000 vscsi1   -
hdisk53      ENABLED      -          v_ibm_ds8x000_015b v_ibm_ds8x000 vscsi1   -
hdisk16      ENABLED(A)   -          v_ibm_ds8x000_015c v_ibm_ds8x000 vscsi1   -
hdisk54      ENABLED      -          v_ibm_ds8x000_015c v_ibm_ds8x000 vscsi1   -

Exclusion of any of the above paths with following command, excludes all the 
other paths under "vscsi1" controller from vxvm view.

# vxdmpadm exclude vxvm path=hdisk52

After exclusion, following CLI to list subpaths will report "vscsi1" as invalid
controller.

# vxdmpadm getsubpaths ctlr=vscsi1
VxVM vxdmpadm ERROR V-5-1-2267 vscsi1 is not a valid controller name

DESCRIPTION:
VxVM internally uses OS device hardware path information to exclude devices. 
Logic to obtain hardware path information is incorrect for vSCSI devices. Thus 
exclusion of a path resulted in exclusion of all the paths of a controller.

RESOLUTION:
Corrected the logic to obtain hardware path information for vSCSI devices.

* 2919718 (Tracking ID: 2919714)

SYMPTOM:
On a THIN lun, vxevac returns 0 without migrating unmounted VxFS volumes.  The
following error messages are displayed when an unmounted VxFS volumes is 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, VM will not move or copy data on an unmounted VxFS volumes unless
smartmove is bypassed.  The vxevac command fails needs to be enhanced to detect
unmounted VxFS volumes on THIN luns and to support a force option that allows the
user to bypass smartmove.

RESOLUTION:
The vxevac script has be modified to check for unmounted VxFS volumes on THIN luns
prior to performing the migration. If an unmounted VxFS volume is detected the
command fails with a non-zero return code and displays a message notifying the
user to mount the volumes or bypass smartmove by specifying the force option: 

 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.

* 2929003 (Tracking ID: 2928987)

SYMPTOM:
vxconfigd hung is observed when IO failed by OS layer.

DESCRIPTION:
DMP is supposed to do number of IO retries that are defined by user. When it
receives IO failure from OS layer, due to bug it restarts IO without checking IO
retry count, thus IO gets stuck in loop infinitely

RESOLUTION:
Code changes are done in DMP to use the IO retry count defined by user.

* 2933058 (Tracking ID: 2516771)

SYMPTOM:
During device discovery the system may panic with below stack:

KDB(0)> where
pvthread+03B100 STACK:
 abend_trap()
 xmfree1()
 xmfree()
 efsc_fail_open()
 efsc_close()
 devcclose()
 rdevclose()
 gno_close()
 closef()
 fp_close()
 dmp_close_ctlr()
 dmp_do_cleanup()
 dmp_decipher_instructions()
 dmp_process_instruction_buffer()
 dmp_reconfigure_db()
 gendmpioctl()
 vxdmpioctl()
 rdevioctl()
 spec_ioctl()
 vnop_ioctl()
 vno_ioctl()
 common_ioctl()
 svc_instr()
 __ioctl()
 __start()

DESCRIPTION:
The controller device is being closed from DMP while holding a spinlock.
Internally AIX will try to free memory associated with that controller.
Since AIX kernel can be pagedout, holding a spinlock while allocating or freeing
memory will result in a exception.

RESOLUTION:
Release the spinlock before closing the controller device, so that when AIX 
frees the memory associated with the controller there is no spinlock held.

* 2940448 (Tracking ID: 2940446)

SYMPTOM:
I/O can hang on volume with space optimized snapshot if the underlying cache 
object is of very large size. It can also lead to data corruption in cache-
object.

DESCRIPTION:
Cache volume maintains B+ tree for mapping the offset and its actual location 
in cache object. Copy-on-write I/O generated on snapshot volumes needs to 
determine the offset of particular I/O in cache object. Due to incorrect type-
casting the value calculated for large offset truncates to smaller value due to 
overflow, leading to data corruption.

RESOLUTION:
Code changes are done to avoid overflow during offset calculation in cache 
object.

* 2946948 (Tracking ID: 2406096)

SYMPTOM:
vxconfigd, VxVM configuration daemon, dumps core with the following stack:

vol_cbr_oplistfree()
vol_clntaddop()
vol_cbr_translog()
vold_preprocess_request()
request_loop()
main()

DESCRIPTION:
vxsnap utility forks a child process and the parent process exits. The child
process continues the remaining work as a background process. It does not create
a new connection with vxconfigd and continues to use the parent's connection.
Since the parent is dead, vxconfigd cleans up its client structure.
Corresponding to further requests from child process, vxconfigd tries accessing
the client structure that was already freed and hence, dumps core.

RESOLUTION:
The issue is solved by initiating a separate connection with vxconfigd from the
forked child.

* 2957608 (Tracking ID: 2671241)

SYMPTOM:
When the DRL log plex is configured in a volume, vxnotify doesn't report volume 
enabled message.

DESCRIPTION:
When the DRL log plex is configured in a volume, we will make a two
phase start of the volume; The first is to start plexes and make the volume 
state DETACHED, then make the volume state ENABLED in the second phase after 
the log recovery. However when we are notifying the configuration change to the 
interested client, we are only checking the status change from DISABLED to 
ENABLED.

RESOLUTION:
With fix, notification is generated on state change of volume from any state 
to 'ENABLED' (and any state to 'DISABLED').

* 2979692 (Tracking ID: 2575051)

SYMPTOM:
In a CVM environment, Master switch or master takeover operations results in
panic with below stack.		

volobject_iogen 
vol_cvol_volobject_iogen 
vol_cvol_recover3_start
voliod_iohandle 
voliod_loop 
kernel_thread

DESCRIPTION:
Panic happens while accessing  fields of stale cache object. The cache recovery
process gets initiated by master takeover or master switch operation. In the
recovery process VxVM do not take I/O count on cache objects. In meanwhile, same
cache object can go through transaction while recovery is still in progress.
Therefore cache object gets changed as part of transaction and in recovery code
path VxVM try to access stale cache object resulting in panic.

RESOLUTION:
This issue is addressed by code changes in cache recovery code path.


INSTALLING THE PATCH
--------------------
If the currently installed VRTSvxvm is below 5.1.113.0 level,
upgrade VRTSvxvm to 5.1.113.0 level before installing this patch.

AIX maintenance levels and APARs can be downloaded from the IBM web site:

 http://techsupport.services.ibm.com

1. Since the patch process will configure the new kernel extensions,
        a) Stop I/Os to all the VxVM volumes.
        b) ensure that no VxVM volumes are in use or open or mounted before starting the installation procedure.
        c) Stop applications using any VxVM volumes.

2. Check whether root support or DMP native support is enabled. If it is enabled, it will be retained after patch upgrade.

# vxdmpadm gettune dmp_native_support


If the current value is "on", DMP native support is enabled on this machine.

# vxdmpadm native list vgname=rootvg

If the output is some list of hdisks, root support is enabled on this machine

3.
a. Before applying this VxVM 5.1 SP1RP3P1 patch, stop the VEA Server's vxsvc process:
     # /opt/VRTSob/bin/vxsvcctrl stop

b. To apply this patch, use following command:
      # installp -ag -d ./VRTSvxvm.bff VRTSvxvm

c. To apply and commit this patch, use following command:
     # installp -acg -d ./VRTSvxvm.bff VRTSvxvm
NOTE: Please refer installp(1M) man page for clear understanding on APPLY & COMMIT state of the package/patch.
d. Reboot the system to complete the patch  upgrade.
     # reboot

e. Confirm that the point patch is installed:
# lslpp -hac VRTSvxvm | tail -1
/etc/objrepos:VRTSvxvm:5.1.113.100::APPLY:COMPLETE:07/11/12:10;56;11
f. If root support or dmp native support is enabled in step 2, verify whether it is retained after completing the patch upgrade
# vxdmpadm gettune dmp_native_support
# vxdmpadm native list vgname=rootvg


REMOVING THE PATCH
------------------
1. Check whether root support or DMP native support is enabled or not:

      # vxdmpadm gettune dmp_native_support

If the current value is "on", DMP native support is enabled on this machine.

      # vxdmpadm native list vgname=rootvg

If the output is some list of hdisks, root support is enabled on this machine

If disabled: goto step 3.
If enabled: goto step 2.

2. If root support or DMP native support is enabled:

        a. It is essential to disable DMP native support.
        Run the following command to disable DMP native support as well as root support
              # vxdmpadm settune dmp_native_support=off

        b. If only root support is enabled, run the following command to disable root suppor
              # vxdmpadm native disable vgname=rootvg

        c. Reboot the system
              # reboot

3.
   a. Before backing out patch, stop the VEA server's vxsvc process:
              # /opt/VRTSob/bin/vxsvcctrl stop

    b. To reject the patch if it is in "APPLIED" state, use the following command and re-enable DMP support
              # installp -r VRTSvxvm 5.1.113.100

    c.   # reboot


SPECIAL INSTRUCTIONS
--------------------
NONE


OTHERS
------
NONE