* * * READ ME * * *
                * * * Veritas Volume Manager 7.4.1 * * *
                         * * * Patch 2600 * * *
                         Patch Date: 2020-08-11


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 7.4.1 Patch 2600


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
Solaris 11 SPARC


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


BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * InfoScale Enterprise 7.4.1
   * InfoScale Foundation 7.4.1
   * InfoScale Storage 7.4.1


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: 7.4.1.2600
* 3968739 (3968334) Solaris 11.4: Appropriate library VRTS_vxvm_link.so is not copied on the system after OS upgrade.
* 3984165 (3982817) Appropriate modules are not loaded on the system during fresh installation of InfoScale on Solaris 11.4 system
* 4005540 (3970627) vxstat command shows incorrect data for IO Operations.
* 4006949 (4006539) zpool corruption occurs when DMP(Dynamic Multipathing) Native Support is enabled on two servers at the same time.
* 4008748 (3989185) In a Veritas Volume Manager(VVR) environment vxrecover command can hang.
* 4010517 (3998475) Unmapped PHYS read I/O split across stripes gives incorrect data leading to data corruption.
* 4010520 (4003805) Panic encountered when using Oracle with mirrored volumes and DCOs on IS 7.4.1/Sol11.4


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

Patch ID: 7.4.1.2600

* 3968739 (Tracking ID: 3968334)

SYMPTOM:
If the OS of the system is upgraded from 11.3 to 11.4 then on reboot newer library were not copied pertaining to Solaris 11.4.

DESCRIPTION:
In Solaris 11.4 the concept of dual VRTS_vxvm_link.so library support for Solaris was included. In Solaris 11 the work of postinstall script is done by vxvm-configure script. The script runs only once and then it skips because of the .vxvm-configured file being present. If the OS of the system is upgraded from 11.3 to 11.4 then on reboot newer library should be copied pertaining to Solaris 11.4. But since the check for the file is there, copying of the library is skipped on boot.

RESOLUTION:
Changes have been done to verify the cksum of the library and then decide where new module replacing is required or not even if the .vxvm-configured file is present.

* 3984165 (Tracking ID: 3982817)

SYMPTOM:
Appropriate modules are not loaded on the system during fresh installation of InfoScale on Solaris 11.4 system

DESCRIPTION:
During fresh installation of InfoScale Enterprise software on Solaris 11.4 system both the base release as well as the patch are installed with one command. The base release does not have support for Solaris 11.4 and hence as part of installing base release an entry for older modules is registered with Operating system. Because of this older entry the load of newer modules to support Solaris 11.4 which are part of the patch cannot succeed. This leads to error during installation which can be only resolved post reboot.

RESOLUTION:
Changes have been done to verify if the modules present in the current patch are newer and accordingly remove the stale entry of older modules from Operating System.

* 4005540 (Tracking ID: 3970627)

SYMPTOM:
vxstat command shows incorrect data for IO Operations.

DESCRIPTION:
vxstat command shows accumulated data for IO Operations for underlying disks. The IO operations for disk 1 would be added to disk 2 and then displayed. Similar thing would happen for disk2/disk3 and so on. The issue occurs because the memory allocated to store these values are not reset to 0 for different disks leading to garbage/incorrect values being displayed as part of the command output.

RESOLUTION:
Appropriate changes have been incorporated to reset the memory to 0 while calculating stats for each of the disks.

* 4006949 (Tracking ID: 4006539)

SYMPTOM:
zpool corruption occurs when DMP Native Support is enabled on two servers at the same time.

DESCRIPTION:
When DMP Native Support is enabled then all the zpools present on the system are migrated to DMP devices. During migration even exported zpools are imported on top of DMP devices. If the same operation is carried out on 2 servers having shared storage then zpools would be imported on top of DMP devices on both the servers approximately at the same time which leads to zpool corruption.

RESOLUTION:
Changes have been done to not import exported zpools on top of DMP devices and let the customer decide which zpools to import on which server.

* 4008748 (Tracking ID: 3989185)

SYMPTOM:
In a Veritas Volume Manager(VVR) environment vxrecover command can hang.

DESCRIPTION:
When vxrecover is triggered after storage failure it is possible that the vxrecover operation may hang.
This is because vxrecover does the RVG recovery. As part of this recovery dummy updates are written on SRL.
Due to a bug in the code these updated were written incorrectly on the SRL which led the flush operation from SRL to data volume hang.

RESOLUTION:
Code changes are done appropriately so that the dummy updates are written  correctly to the SRL.

* 4010517 (Tracking ID: 3998475)

SYMPTOM:
Data corruption is observed and service groups went into partial state.

DESCRIPTION:
In VxVM, fsck log replay initiated read of 64 blocks, that was getting split across 2 stripes of the stripe-mirror volume. 
So, we had 2 read I/Os of 48 blocks (first split I/O) and 16 blocks (second split I/O).
Since the volume was in RWBK mode, this read I/O was stabilized. Upon completion of the read I/O at subvolume level, this I/O was unstabilized and the contents 
of the stable I/O (stablekio) were copied to the original I/O (origkio). It was observed that the data was always correct till the subvolume level but at the 
top level plex and volume level, it was incorrect (printed checksum in vxtrace output for this).

The reason for this was during unstabilization, we do volkio_to_kio_copy() which copies the contents from stable kio to orig kio (since it is a read).
As the orig kio was an unmapped PHYS I/O, in Solaris 11.4, the contents will be copied out using bp_copyout() from volkiomem_kunmap(). The volkiomem_seek() and 
volkiomem_next_segment() allocates pagesize (8K) kernel buffer (zero'ed out) where the contents will be copied to.
When the first split I/O completes unstabilization before the second split I/O, this issue was not seen. However, if the second split 
I/O completed before the first splt I/O then this issue was seen. 

Here, in the last iteration of the volkio_to_kio_copy(), the data copied was less than the allocated region size. We allocate 8K region size whereas the data 
copied from stablekio was less than 8K. Later, during kunmap(), we do a bp_copyout() of alloocated size i.e. 8K. This caused copyout of extra regions that were 
zero'ed out. Hence the data corruption.

RESOLUTION:
Now we do a bp_copyout() of the right length i.e. of the copied size instead of the allocated region size.

* 4010520 (Tracking ID: 4003805)

SYMPTOM:
Panic encountered when Oracle UFS directly uses mirrored volumes with DCOs on IS 7.4.1/Sol11.4. System panic with below stack:
unix:ktl0+7c ()
vxio:voliomem_range_iter+c ()
vxio:volkio_to_iomem_copy+114 ()
vxio:volsio_stabilize+f0 ()
vxio:vol_mv_write_start+9cc ()
Or
bcopy_more+0x1284()
volkio_to_iomem_copy+0x178()
volsio_stabilize+0xf0()
vol_mv_write_start+0xa98()
volkcontext_process+0x124()
volkiostart+0x1144()
vxiostrategy+0xd4()
spec_cb_strategy+0x7c()

DESCRIPTION:
When B_MVECTOR is set on a buffer, that means this is a unmapped buffer. Volume Manager missed this flag and directly access this buffer, hence the panic.

RESOLUTION:
Code changes have been done to use bp_mapin() to properly set b_addr if B_MVECTOR is set.



INSTALLING THE PATCH
--------------------
Run the Installer script to automatically install the patch:
-----------------------------------------------------------
Please be noted that the installation of this P-Patch will cause downtime.

To install the patch perform the following steps on at least one node in the cluster:
1. Copy the patch vm-sol11_sparc-Patch-7.4.1.2600.tar.gz to /tmp
2. Untar vm-sol11_sparc-Patch-7.4.1.2600.tar.gz to /tmp/hf
    # mkdir /tmp/hf
    # cd /tmp/hf
    # gunzip /tmp/vm-sol11_sparc-Patch-7.4.1.2600.tar.gz
    # tar xf /tmp/vm-sol11_sparc-Patch-7.4.1.2600.tar
3. Install the hotfix(Please be noted that the installation of this P-Patch will cause downtime.)
    # pwd /tmp/hf
    # ./installVRTSvxvm741P2600 [<host1> <host2>...]

You can also install this patch together with 7.4.1 base release using Install Bundles
1. Download this patch and extract it to a directory
2. Change to the Veritas InfoScale 7.4.1 directory and invoke the installer script
   with -patch_path option where -patch_path should point to the patch directory
    # ./installer -patch_path [<path to this patch>] [<host1> <host2>...]

Install the patch manually:
--------------------------
Run the Installer script to automatically install the patch:
-----------------------------------------------------------

To install the patch perform the following steps on at least one node in the cluster:

1. Copy the patch vm-sol11_sparc-Patch-7.4.1.2600.tar.gz to /tmp
2. Untar vm-sol11_sparc-Patch-7.4.1.2600.tar.gz to /tmp/hf
    # mkdir /tmp/hf
    # cd /tmp/hf
    # gunzip /tmp/vm-sol11_sparc-Patch-7.4.1.2600.tar.gz
    # tar xf /tmp/vm-sol11_sparc-Patch-7.4.1.2600.tar
3. Install the hotfix(Please be noted that the installation of this P-Patch will cause downtime.)
    # pwd /tmp/hf
    # ./installVRTSvxvm741P2600 [<host1>   <host2>  ...]

This patch can be installed in connection with the InfoScale 7.4.1 maintenance release using the Install Bundles installer feature:

1. Download this patch and extract it to a directory of your choosing
2. Change to the directory hosting the Veritas InfoScale 7.4.1 base product software and invoke the installer script
   with -patch_path option where -patch_path should point to the patch directory you created in step 1.

    # ./installer -patch_path [<host1 <host2>  ...]


Install the patch manually:
--------------------------
o Before-applying-the-patch:-
  (a) Stop applications that access VxVM volumes.
  (b) Stop I/Os to all the VxVM volumes.
  (c) Umount any filesystems residing on VxVM volumes.
  (d) In case of multiple boot environments, boot using the BE (Boot-Environment) you wish to install the patch on.

For Solaris 11, refer to the man pages for specific instructions on using the 'pkg' command to install the patch provided.

Any other special or non-generic installation instructions should be described below as special instructions.

The following example installs the updated VRTSvxvm patch on a single-standalone machine:

        Example# pkg install --accept -g /patch_location/VRTSvxvm.p5p VRTSvxvm

After 'pkg install' please follow mandatory configuration steps mentioned in special instructions.

Please follow the special instructions mentioned below after installing the patch.


REMOVING THE PATCH
------------------
For Solaris 11.1 or later, if DMP native support is enabled, DMP controls the ZFS root pool. Turn off native support before removing the patch.

***  If DMP native support is enabled:
                 a.It is essential to disable DMP native support.

                        Run the following command to disable DMP native support

                        # vxdmpadm settune dmp_native_support=off

                  b.Reboot the system
                         # reboot

NOTE: If you do not disable native support prior to removing the VxVM patch, the system cannot be restarted after you remove DMP.
Please ensure you have access to the base 7.4.1 Veritas software prior to removing the updated VRTSvxvm package.

NOTE: Uninstalling the patch will remove the entire package.

The following example removes a patch from a standalone system:

The VRTSvxvm package cannot be removed unless you also remove the VRTSaslapm package.Therefore the pkg uninstall command will fail as follows:

# pkg uninstall VRTSvxvm
Creating Plan (Solver setup): -
pkg uninstall: Unable to remove 'VRTSvxvm@7.4.1.2600' due to the following packages that depend on it:
  VRTSaslapm@7.4.1.0


You will also need to uninstall the VRTSaslapm package.

# pkg uninstall VRTSvxvm VRTSaslapm

NOTE: You will need access to the base software of the VRTSvxvm package (original source media) to reinstall the uninstalled packages.


SPECIAL INSTRUCTIONS
--------------------
1) Delete '.vxvm-configured'
  # rm  /etc/vx/reconfig.d/state.d/.vxvm-configured
2) Refresh vxvm-configure
    # svcadm refresh vxvm-configure
3) Delete  'install-db'
    # rm /etc/vx/reconfig.d/state.d/install-db
4) Reboot the system using shutdown command.
You need to use the shutdown command to reboot the system after patch installation or de-installation:
    shutdown -g0 -y -i6
If you wish to use DMP native support  tunable then enable it.
#vxdmpadm settune dmp_native_support=on


OTHERS
------
NONE