This page lists publically-released patches for Veritas Enterprise Products.
For Product GA build, see Veritas Entitlement Management System(VEMS) by clicking the Veritas Support 'Licensing' option.
For information on private patches, contact Veritas Technical Support.
Veritas is making it easier to find all software installers and updates for Veritas products with a completely redesigned experience. NetBackup HotFixes and NetBackup Appliance patches are now also available at the new Veritas Download Center.
Patches for your product can have a variety of names. These names are based on product, component, or package names. For more information on patch naming conventions and the relationship between products, components, and packages, see the SORT online help.
sfha-sles11sp4_x86_64-Patch-6.2.1.100
Sign in if you want to rate this patch.

 Basic information
Release type: Patch
Release date: 2015-09-22
OS update support: SLES11 x86-64 SP 4
Technote: None
Documentation: None
Popularity: 2262 viewed    282 downloaded
Download size: 133.73 MB
Checksum: 2213001648

 Applies to one or more of the following products:
Application HA 6.2 On SLES11 x86-64
Cluster Server 6.2 On SLES11 x86-64
Dynamic Multi-Pathing 6.2 On SLES11 x86-64
File System 6.2 On SLES11 x86-64
Storage Foundation 6.2 On SLES11 x86-64
Storage Foundation Cluster File System 6.2 On SLES11 x86-64
Storage Foundation for Oracle RAC 6.2 On SLES11 x86-64
Storage Foundation HA 6.2 On SLES11 x86-64
Volume Manager 6.2 On SLES11 x86-64

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

This patch requires: Release date
sfha-sles11_x86_64-MR-6.2.1 2015-04-24

 Fixes the following incidents:
3752475, 3753724, 3754492, 3756002, 3759910, 3760226, 3765324, 3765998, 3769992, 3780334, 3793241, 3794264, 3795710, 3798437, 3802857, 3803497, 3804299, 3808134, 3808285, 3816222, 3817120, 3821688, 3821696, 3821699, 3821702, 3823288, 3831477, 3832505, 3833186, 3848011, 3849458

 Patch ID:
VRTSaslapm-6.2.1.200-SLES11
VRTSvxvm-6.2.1.100-SLES11
VRTSamf-6.2.1.100-SLES11
VRTSvxfen-6.2.1.100-SLES11
VRTSllt-6.2.1.100-SLES11
VRTSgab-6.2.1.100-SLES11
VRTSdbac-6.2.1.100-SLES11
VRTSvxfs-6.2.1.100-SLES11
VRTScavf-6.2.1.100-SLES11
VRTSglm-6.2.0.100-SLES11
VRTSgms-6.2.0.100-SLES11
VRTSodm-6.2.0.100-SLES11

 Readme file  [Save As...]
                          * * * READ ME * * *
            * * * Symantec Storage Foundation HA 6.2.1 * * *
                         * * * Patch 100 * * *
                         Patch Date: 2015-08-17


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
   * KNOWN ISSUES


PATCH NAME
----------
Symantec Storage Foundation HA 6.2.1 Patch 100


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
SLES11 x86-64


PACKAGES AFFECTED BY THE PATCH
------------------------------
VRTSamf
VRTSaslapm
VRTScavf
VRTSdbac
VRTSgab
VRTSglm
VRTSgms
VRTSllt
VRTSodm
VRTSvxfen
VRTSvxfs
VRTSvxvm


BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * Symantec Application HA 6.2
   * Symantec Cluster Server 6.2
   * Symantec Dynamic Multi-Pathing 6.2
   * Symantec File System 6.2
   * Symantec Storage Foundation 6.2
   * Symantec Storage Foundation Cluster File System HA 6.2
   * Symantec Storage Foundation for Oracle RAC 6.2
   * Symantec Storage Foundation HA 6.2
   * Symantec Volume Manager 6.2


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: VRTSvxvm-6.2.1.100-SLES11
* 3780334 (3762580) In Linux kernels greater than or equal to RHEL6.6 like RHEL7 and SLES11SP3, the 
vxfen module fails to register the SCSI-3 PR keys to EMC devices when powerpath
exists in coexistence with DMP (Dynamic Multipathing).
* 3795710 (3508122) After one node preempts SCSI-3 reservation for the other node, the I/O from victim 
node does not fail
* 3802857 (3726110) On systems with high number of CPU's, Dynamic Multipathing (DMP) devices may perform considerably slower than OS device 
paths.
* 3803497 (3802750) VxVM (Veritas Volume Manager) volume IO-shipping functionality is not disabled 
even after the user issues the correct command to disable it.
* 3804299 (3804298) Record setting/unsetting of 'lfailed/lmissing' flag in syslog.
* 3808134 (3808135) While installing hotfix(HF) on top of Veritas Volume
Manager(VxVM)6.2.1, symbolic link creation is failed as old links are not
cleaned from installation scripts.
* 3816222 (3816219) VxDMP event source daemon keeps reporting UDEV change event in syslog.
* 3823288 (3823283) While unencapsulating a boot disk in SAN environment(Storage Area Network),
Linux operating system sticks in grub after reboot.
* 3832505 (3832508) VRTSvxvm patch version 6.2.1, 6.1.1.100 and 6.0.5.100 or previous will not work
with SLES11SP4 update.
* 3848011 (3806909) Due to some modification in licensing , for STANDALONE DMP, DMP keyless 
license was not working.
* 3849458 (3776520) Filters are not updated properly in lvm.conf file in VxDMP initrd(initial 
ramdisk) while enabling Dynamic Multipathing (DMP) Native Support.
Patch ID: VRTSaslapm-6.2.1.200-SLES11
* 3833186 (3833182) While VRTSaslapm package installation for SLES11SP4(new suse
update), APM (array policy modules) are not loading properly.
Patch ID: VRTSamf-6.2.1.100-SLES11
* 3794264 (3794203) Veritas Cluster Server (VCS) does not support SuSE Linux Enterprise Server 11 
Service Pack 4 (SLES 11 SP4).
Patch ID: VRTSgab-6.2.1.100-SLES11
* 3794264 (3794203) Veritas Cluster Server (VCS) does not support SuSE Linux Enterprise Server 11 
Service Pack 4 (SLES 11 SP4).
Patch ID: VRTSllt-6.2.1.100-SLES11
* 3794264 (3794203) Veritas Cluster Server (VCS) does not support SuSE Linux Enterprise Server 11 
Service Pack 4 (SLES 11 SP4).
Patch ID: VRTSdbac-6.2.0.100-SLES11
* 3831477 (3834801) 6.2.0 vcsmm module does not load with SLES11SP4 (3.0.101-63-default kernel)
Patch ID: VRTSvxfs-6.2.1.100-SLES11
* 3753724 (3731844) umount -r option fails for vxfs 6.2.
* 3754492 (3761603) Internal assert failure because of invalid extop processing 
at the mount time.
* 3756002 (3764824) Internal cluster file system(CFS) testing hit debug assert
* 3765324 (3736398) NULL pointer dereference panic in lazy unmount.
* 3765998 (3759886) In case of nested mount, force umount of parent leaves 
stale child entry in /etc/mtab even after subsequent umount of child.
* 3769992 (3729158) Deadlock due to incorrect locking order between write advise
and dalloc flusher thread.
* 3793241 (3793240) Vxrestore command dumps core file because of invalid 
japanese strings.
* 3798437 (3812914) On RHEL 6.5 and RHEL 6.4 latest kernel patch, umount(8) system call hangs if an
application watches for inode events using inotify(7) APIs.
* 3808285 (3808284) fsdedupadm status Japanese text includes strange character.
* 3817120 (3804400) VRTS/bin/cp does not return any error when quota hard 
limit is reached and partial write is encountered.
* 3821688 (3821686) VxFS module failed to load on SLES11 SP4.
Patch ID: VRTSglm-6.2.0.100-SLES11
* 3752475 (3758102) In Cluster File System(CFS) on Linux, stack overflow while
creating ODM file.
* 3821699 (3821698) GLM module failed to load on SLES11 SP4.
Patch ID: VRTSgms-6.2.0.100-SLES11
* 3821702 (3821700) GMS module failed to load on SLES11 SP4.
Patch ID: VRTSodm-6.2.0.100-SLES11
* 3821696 (3821693) ODM module failed to load on SLES11 SP4.
Patch ID: VRTScavf-6.2.1.100-SLES11
* 3759910 (3765928) "cfsshare config -p all" doesn't populating smb.conf(samba
configuration file) properly for some global variables.
* 3760226 (3765921) On RHEL7 onwards, pluggable Authentication Modules(PAM)
related error messages for Samba daemon may be observed in system logs after
adding CIFS(common internet file system) share


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

Patch ID: VRTSvxvm-6.2.1.100-SLES11

* 3780334 (Tracking ID: 3762580)

SYMPTOM:
Below logs were seen while setting up fencing for the cluster.

VXFEN: vxfen_reg_coord_pt: end ret = -1
vxfen_handle_local_config_done: Could not register with a majority of the
coordination points.

DESCRIPTION:
It is observed that in Linux kernels greater than or equal to RHEL6.6, RHEL7 and 
SLES11SP3, the interface used by DMP to send the SCSI commands to block devices
does not transfer the data to/from the device. Therefore the SCSI-3 PR keys does
not get registered.

RESOLUTION:
Code change is done to use scsi request_queue to send the SCSI commands to the 
underlying block device.
Additional patch is required from EMC to support processing SCSI commands via the 
request_queue mechanism on EMC PowerPath devices. Please contact EMC for 
patch details for a specific kernel version.

* 3795710 (Tracking ID: 3508122)

SYMPTOM:
When running vxfentsthdw during the preempt key operation, it expected the IO to 
fail from the victim node,  but sometimes it doesn't:
Preempt key KeyC using key KeyB on node arcx36507b8k9 .................. Passed 
Test to see if I/O on node arcx36502m9gn terminated .................... Failed

DESCRIPTION:
After node 1 preempts the SCSI-3 reservations for node 2, it is expected that write 
I/Os from victim node 2 will fail. It is observed that sometimes the storage does 
not preempts all the keys of victim node fast enough, but it fails the I/O with 
reservation conflict. In such a case the victim node could not correctly identify 
that it has been preempted and can still do re-registration of keys to perform the 
I/O.

RESOLUTION:
Code changes have been done to correctly identify that SCSI-3 keys of a node has 
been preempted.

* 3802857 (Tracking ID: 3726110)

SYMPTOM:
On systems with high number of CPU's, Dynamic Multipathing (DMP) devices may perform considerably slower than OS device 
paths.

DESCRIPTION:
In high CPU configuration, IO statistics related functionality in DMP takes more
CPU time as DMP statistics are collected on per CPU basis. This stat collection
happens in DMP IO code path hence it reduces the IO performance. Because of
this DMP devices perform slower than OS device paths.

RESOLUTION:
Code changes are made to remove some of the stats collection functionality from
DMP IO code path. Along with this, following tunable need to be turned off. 
1. Turn off idle lun probing. 
#vxdmpadm settune dmp_probe_idle_lun=off
2. Turn off statistic gathering functionality.  
#vxdmpadm iostat stop

Notes: 
1. Please apply this patch if system configuration has large number of CPU and
if DMP is performing considerably slower than OS device paths. For normal
systems this issue is not applicable.

* 3803497 (Tracking ID: 3802750)

SYMPTOM:
Once VxVM (Veritas Volume Manager) volume IO-shipping functionality is turned 
on, it is not disabled even after the user issues the correct command to disable 
it.

DESCRIPTION:
VxVM (Veritas Volume Manager) volume IO-shipping functionality is turned off by 
default. The following two commands can be used to turn it on and off:
	vxdg -g <dgname> set ioship=on
	vxdg -g <dgname> set ioship=off

The command to turn off IO-shipping was not working as intended due to a problem 
with IO-shipping flags not being reset properly.

RESOLUTION:
Code changes have been done to correctly reset IO-ship flags when the user 
issues the CLI command.

* 3804299 (Tracking ID: 3804298)

SYMPTOM:
For CVM (Cluster Volume Manager) environment, record setting/unsetting of 'lfailed/lmissing' flag in syslog.

DESCRIPTION:
For CVM environment, when VxVM (Verita's volume Manager) discovers that a  disk is not accessible from a node of CVM cluster, it marks 
LFAILED(locally failed) flag on the disk. And when VxVM discovers that a disk is not discovered by DMP (Dynamic Multipathing) on a node of 
CVM cluster, it marks LMISSING flag on the disk. Message of setting and unsetting of 'lmissing/lfailed' are not recorded in the syslog.

RESOLUTION:
Code changes are made to record setting/unsetting of 'lfailed/lmissing' flag in syslog.

* 3808134 (Tracking ID: 3808135)

SYMPTOM:
While installing HF on top of VxVM 6.2.1, below error is 
reported.
 
ln: failed to create symbolic link '/etc/rc.d/init.d/vras-vradmind': File exists
ln: failed to create symbolic link '/etc/rc.d/init.d/vxrsyncd': File exists

DESCRIPTION:
During installation of HF, symbolic links are recreated but,
stale links from previously installed VxVM are not deleted, therefore this error
is seen.

RESOLUTION:
Appropriate code changes are done for smooth run of HF
installation on top of VxVM 6.2.1.

* 3816222 (Tracking ID: 3816219)

SYMPTOM:
VxVM(Veritas Dynamic Multi-Pathing) event source daemon(vxesd) keeps reporting 
a lot of messages in syslog as below:
"vxesd: Device sd*(*/*) is changed"

DESCRIPTION:
vxesd registers with the UDEV framework and keeps VxDMP up-to-date with 
device's status. Due to something about the device changed. vxesd keeps 
reporting this kind of event. VxDMP cares about "add" and "remove" UDEV events, 
for  "change" event, vxesd doesn't need to record it in syslog.

RESOLUTION:
The code is modified to stop recording UDEV change event in syslog.

* 3823288 (Tracking ID: 3823283)

SYMPTOM:
After taking reboot, OS sticks in grub. Manual kernel load is required to make
operating system functional.

DESCRIPTION:
During unencapsulation of a boot disk in SAN environment, multiple entries
corresponding to root disk are found in by-id device directory. As a result, a
parse command will fail leading to create an improper menu file in grub. This
menu file defines the device path from where kernel and other modules will be
loaded.

RESOLUTION:
Proper modifications in code base is done to handle the multiple entries for SAN
boot disk.

* 3832505 (Tracking ID: 3832508)

SYMPTOM:
VRTSvxvm patch versions 6.2.1, 6.1.1, 6.0.5.100 or previous ones will not work
with sles11sp4  update.

fslxx8604-v05:/tgupta # rpm -ivh VRTSvxvm-6.2.1.000-SLES11.x86_64.rpm 
Preparing...                ########################################### [100%]
   1:VRTSvxvm               ########################################### [100%]
Installing file /etc/init.d/vxvm-boot
vxvm-boot                 0:off  1:off  2:on   3:on   4:on   5:on   6:off
creating VxVM device nodes under /dev
FATAL: Module vxted is in use.
ERROR: No appropriate modules found. Error in loading module "vxdmp". See
documentation.
error: %post(VRTSvxvm-6.2.1.000-SLES11.x86_64) scriptlet failed, exit status 1
fslxx8604-v05:/tgupta #

DESCRIPTION:
Installation of VRTSvxvm patch version 6.2.1, 6.1.1 and 6.0.5.100 fails on
SLES11SP4 due to change in kernel version.

RESOLUTION:
The VxVM package has been re-compiled with SLES11SP4 build environment.

* 3848011 (Tracking ID: 3806909)

SYMPTOM:
During installation of volume manager installation using CPI in key-less 
mode, following logs were observed.
VxVM vxconfigd DEBUG  V-5-1-5736 No BASIC license
VxVM vxconfigd ERROR  V-5-1-1589 enable failed: License has expired or is 
not available for operation transactions are disabled.

DESCRIPTION:
While using CPI for STANDALONE DMP installation in key less mode, volume 
manager Daemon(vxconfigd) cannot be started due to a modification in a DMP 
NATIVE license string that is used for license verification and this 
verification was failing.

RESOLUTION:
Appropriate code changes are incorporated to resolve the DMP keyless License 
issue to work with STANDALONE DMP.

* 3849458 (Tracking ID: 3776520)

SYMPTOM:
Filters are not updated properly in lvm.conf file in VxDMP initrd while enabling 
DMP Native Support leading to root Logical Volume (LV) mounted on OS 
device upon reboot.

DESCRIPTION:
From LVM version 105, global_filter were introduced as part of lvm.conf file. 
VxDMP updates initird lvm.conf file with the filters required for DMP 
Native Support to function. While updating the lvm.conf, VxDMP checks for the 
filter field to  be updated whereas ideally we should check for 
global_filter field to be updated in the latest LVM version. This leads to 
lvm.conf file not having the proper filters leading to the issue.

RESOLUTION:
Code changes have been made to properly update global_filter field in lvm.conf 
file in VxDMP initrd.

Patch ID: VRTSaslapm-6.2.1.200-SLES11

* 3833186 (Tracking ID: 3833182)

SYMPTOM:
lsmod is not showing the required APM modules loaded.

DESCRIPTION:
For supporting SLES11SP4 update, dmp module is recompiled with latest
SLES11SP4 kernel version. During post install of the package the APM modules
fails to load due to mismatch in dmp and additional APM module kernel
version.

RESOLUTION:
ASLAPM package is recompiled with SLES11SP4 kernel.

Patch ID: VRTSamf-6.2.1.100-SLES11

* 3794264 (Tracking ID: 3794203)

SYMPTOM:
Veritas Cluster Server (VCS) does not support SuSE Linux Enterprise Server 11 
Service Pack 4 (SLES 11 SP4).

DESCRIPTION:
VCS did not support SLES versions released after SLES 11 SP3.

RESOLUTION:
VCS support for SLES 11 SP4 is now introduced.

Patch ID: VRTSgab-6.2.1.100-SLES11

* 3794264 (Tracking ID: 3794203)

SYMPTOM:
Veritas Cluster Server (VCS) does not support SuSE Linux Enterprise Server 11 
Service Pack 4 (SLES 11 SP4).

DESCRIPTION:
VCS did not support SLES versions released after SLES 11 SP3.

RESOLUTION:
VCS support for SLES 11 SP4 is now introduced.

Patch ID: VRTSllt-6.2.1.100-SLES11

* 3794264 (Tracking ID: 3794203)

SYMPTOM:
Veritas Cluster Server (VCS) does not support SuSE Linux Enterprise Server 11 
Service Pack 4 (SLES 11 SP4).

DESCRIPTION:
VCS did not support SLES versions released after SLES 11 SP3.

RESOLUTION:
VCS support for SLES 11 SP4 is now introduced.

Patch ID: VRTSdbac-6.2.0.100-SLES11

* 3831477 (Tracking ID: 3834801)

SYMPTOM:
VRTSdbac patch version does not work with SLES11SP4 (3.0.101-63-default 
kernel) and is unable to load the vcsmm module on SLES11SP4.

DESCRIPTION:
Installation of VRTSdbac patch version 6.2.0 fails on SLES11Sp4 as 
the VCSMM module is not available on SLES11SP4 kernel 3.0.101-63-default. 
The system log file logs the following messages:
Starting VCSMM: 
ERROR: No appropriate modules found.
Error in loading module "vcsmm". See documentation.
Error : VCSMM driver could not be loaded.
Error : VCSMM could not be started.
Error : VCSMM could not be started.

RESOLUTION:
The VRTSdbac package is re-compiled with SLES11SP4 kernel in the build 
environment to mitigate the failure.

Patch ID: VRTSvxfs-6.2.1.100-SLES11

* 3753724 (Tracking ID: 3731844)

SYMPTOM:
umount -r option fails for vxfs 6.2 with error "invalid options"

DESCRIPTION:
Till 6.2 vxfs did not have a umount helper on linux. We added a helper in 6.2,
because of this, each call to linux's umount also gets called to the umount
helper binary. Due to this the -r option, which was only handled by the linux
native umount, is forwarded to the umount.vxfs helper, which exits while
processing the option string becase we don't support readonly remounts.

RESOLUTION:
To solve this, we've changed the umount.vxfs code to not exit on
"-r" option, although we do not support readonly remounts, so if umount -r
actually fails and the os umount attempts a readonly remount, the mount.vxfs
binary will then exit with an error. This solves the problem of linux's default
scripts not working for our fs.

* 3754492 (Tracking ID: 3761603)

SYMPTOM:
Full fsck flag will be set incorrectly at the mount time.

DESCRIPTION:
There might be possibility that extop processing will be deferred 
during umount (i.e. in case of crash or disk failure) and will be kept on 
disk, so that mount can process them. During mount, inode can have multiple 
extop set. Previously if inode has trim and reorg extop set during mount, we 
were incorrectly setting fullfsck. This patch avoids this situation.

RESOLUTION:
Code is modified to avoid such unnecessary setting of fullfsck.

* 3756002 (Tracking ID: 3764824)

SYMPTOM:
Internal cluster file system(CFS) testing hit debug assert

DESCRIPTION:
Internal debug assert is seen when there is a glm recovery while one 
of the secondary  nodes is doing mount, specifically when glm recovery happens 
between attaching a file system and mounting file system.

RESOLUTION:
Code is modified to handle glm reconfiguration issue.

* 3765324 (Tracking ID: 3736398)

SYMPTOM:
Panic in the lazy unmount path during deinit of VxFS-VxVM API.

DESCRIPTION:
The panic is caused when an exiting thread drops the last reference
to a lazy-unmounted VxFS file-system where that fs is the last VxFS mount in the
system. The exiting thread does unmount, which then calls into VxVM to
de-initialize the private FS-VM API(as it is the last VxFS mounted fs). 
The function to be called in VxVM is looked-up via the files under /proc, this
requires an opening of a file but the exit processing has removed the structs
needed by the thread to open a file.

RESOLUTION:
The solution is to cache the de-init function (vx_fsvm_api_deinit)
when the VxFS-VxVM API is initialized, so no function look-up is needed during
an unmount. The cached function pointer can then be called during the last
unmount bypassing the need to open the file by the exiting thread.

* 3765998 (Tracking ID: 3759886)

SYMPTOM:
In case of nested mount, force umount of parent leaves stale child 
entry in /etc/mtab even after subsequent umount of child.

DESCRIPTION:
On rhel6 and sles11, in case of nested mount, if parent mount 
(say /mnt1) was removed/umounted forcefully, then child mounts (like /mnt1/dir) 
also get umounted but the "/etc/mtab" entry was not getting updated accordingly 
for child mount. Previously it was possible to remove such child entries from 
"/etc/mtab" by using os's umount binary. But from shikra on words, we have 
added helper umount binary in "/sbin/umount.vxfs". So now os's umount binary 
will call this helper binary which in turn call vxumount for child umount 
which will fail since path was not present. Hence mtab entry will not get
updated and will show child as mounted.

RESOLUTION:
Code is modified to update mnttab when ENOENT error is returned 
by umount() system call.

* 3769992 (Tracking ID: 3729158)

SYMPTOM:
fuser and other commands hang on vxfs file systems.

DESCRIPTION:
The hang is seen while 2 threads contest for 2 locks -ILOCK and
PLOCK. The writeadvise thread owns the ILOCK but is waiting for the PLOCK.
The dalloc thread owns the PLOCK and is waiting for the ILOCK.

RESOLUTION:
Correct order of locking is PLOCK followed by the ILOCK.

* 3793241 (Tracking ID: 3793240)

SYMPTOM:
Vxrestore command dumps core file because of invalid japanese 
strings.

DESCRIPTION:
Vxrestore command dumps core file because of invalid characters 
such as %, $ etc. are present in the japanese strings.

RESOLUTION:
code is modified to remove the extra characters from the 
Japanese message strings.

* 3798437 (Tracking ID: 3812914)

SYMPTOM:
On RHEL 6.5 and RHEL 6.4 latest kernel patch, umount(8) system call hangs if an
application watches for inode events using inotify(7) APIs.

DESCRIPTION:
On RHEL 6.5 and RHEL 6.4 latest kernel patch, additional OS counters were added in
the super block to track inotify Watches. These new counters were not implemented
in VxFS for RHEL6.5/RHEL6.4 kernel. Hence, while doing umount, the operation hangs
until the counter in the superblock drops to zero, which would never happen since
they are not handled in VxFS.

RESOLUTION:
The code is modified to handle additional counters added in super block of
RHEL6.5/RHEL6.4 latest kernel.

* 3808285 (Tracking ID: 3808284)

SYMPTOM:
fsdedupadm status Japanese text includes strange character.

DESCRIPTION:
The translation of FAILED string in English  is incorrect in Japanese 
and is "I/O" which stands for The failed I / O.So the translation from 
English to Japanese is not correct.

RESOLUTION:
Corrected the translation for "FAILED" string in Japanese.

* 3817120 (Tracking ID: 3804400)

SYMPTOM:
VRTS/bin/cp does not return any error when quota hard limit is 
reached and partial write is encountered.

DESCRIPTION:
When quota hard limit is reached, VRTS/bin/cp may encounter a 
partial write, but it may not return any error to up layer application in 
such situation.

RESOLUTION:
Adjust VRTS/bin/cp to detect the partial write caused by quota 
limit, and return a proper error to up layer application.

* 3821688 (Tracking ID: 3821686)

SYMPTOM:
VxFS module might not get loaded on SLES11 SP4.

DESCRIPTION:
Since SLES11 SP4 is new release therefore VxFS module failed to load
on it.

RESOLUTION:
Added VxFS support for SLES11 SP4.

Patch ID: VRTSglm-6.2.0.100-SLES11

* 3752475 (Tracking ID: 3758102)

SYMPTOM:
In Cluster File System(CFS) on Linux, stack overflow while creating
ODM file.

DESCRIPTION:
In case of CFS, while creating a ODM file, cluster inode needs
initialization, which takes GLM(Group Lock Manager) lock.  While taking GLM
lock, processing within GLM module may lead to the system panic due to stack
overflow in Linux while doing memory allocation.

RESOLUTION:
Modified handoff values.

* 3821699 (Tracking ID: 3821698)

SYMPTOM:
GLM module will not get loaded on SLES11 SP4.

DESCRIPTION:
Since SLES11 SP4 is new release therefore GLM module failed to load
on it.

RESOLUTION:
Added GLM support for SLES11 SP4.

Patch ID: VRTSgms-6.2.0.100-SLES11

* 3821702 (Tracking ID: 3821700)

SYMPTOM:
GMS module will not get loaded on SLES11 SP4.

DESCRIPTION:
Since SLES11 SP4 is new release therefore GMS module failed to load
on it.

RESOLUTION:
Added GMS support for SLES11 SP4.

Patch ID: VRTSodm-6.2.0.100-SLES11

* 3821696 (Tracking ID: 3821693)

SYMPTOM:
ODM module may not get loaded on SLES11 SP4.

DESCRIPTION:
Since SLES11 SP4 is new release therefore ODM module was not
getting loaded on it.

RESOLUTION:
Added ODM support for SLES11 SP4.

Patch ID: VRTScavf-6.2.1.100-SLES11

* 3759910 (Tracking ID: 3765928)

SYMPTOM:
"cfsshare config -p all" doesn't populating smb.conf(samba configuration
file) properly for some global variables.

DESCRIPTION:
"cfsshare config -p all" doesn't populating smb.conf properly for
some global variables. Attributes "encryptpasswords" and "smbpasswd file" should
have space in the name.

RESOLUTION:
Code is modified so that correct attribute names are present in samba
configuration file.

* 3760226 (Tracking ID: 3765921)

SYMPTOM:
On RHEL7 onwards, pluggable Authentication Modules(PAM) related error
messages for Samba daemon may be observed in system logs after adding CIFS share
and the CIFS share is may not be accessible from windows client.

DESCRIPTION:
There is a file /etc/pam.d/samba which is not available by default
on RHEL 7 onwards and also "obey pam restrictions" attribute from Samba
configuration file (smb.conf) is set to "yes", where default is "no". This
parameter will control whether or not Samba should obey PAM's account and
session management directives. The default behavior is to use PAM for clear 
text authentication only and to ignore any account or session management. Samba
always ignores PAM for authentication in the case of "encrypt passwords = yes".
If we set "obey pam restrictions" attribute to "no", then there are no PAM
related error messages and also the CIFS share is accessible from windows 
clients.

RESOLUTION:
Set obey pam restrictions = no in
/opt/VRTSvcs/bin/ApplicationNone/smb.conf before doing cfsshare config and
adding share.



INSTALLING THE PATCH
--------------------
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 sfha-sles11sp4_x86_64-6.2.1.100-patches.tar.gz to /tmp
2. Untar sfha-sles11sp4_x86_64-6.2.1.100-patches.tar.gz to /tmp/hf
    # mkdir /tmp/hf
    # cd /tmp/hf
    # gunzip /tmp/sfha-sles11sp4_x86_64-6.2.1.100-patches.tar.gz
    # tar xf /tmp/sfha-sles11sp4_x86_64-6.2.1.100-patches.tar
3. Install the hotfix
    # pwd /tmp/hf
    # ./installSFHA621P1 [<host1> <host2>...]

You can also install this patch together with 6.2 GA release and 6.2.1 Patch release 
using Install Bundles
1. Download Storage Foundation and High Availability Solutions 6.2
2. Extract the tar ball into the /tmp/sfha6.2/ directory
3. Download SFHA Solutions 6.2.1 from https://sort.veritas.com/patches
4. Extract it to the /tmp/sfha6.2.1 directory
5. Change to the /tmp/sfha6.2.1 directory by entering:
    # cd /tmp/sfha6.2.1
6. Invoke the installmr script with -base_path and -patch_path option where the -base_path 
should point to the 62 image directory, while -patch_path to the 6.2.1.100 directory.   
    # ./installmr -base_path [<62 path>] -patch_path [<patch path>] [<host1> <host2>...]


Install the patch manually:
--------------------------
o Before-the-upgrade :-
 (a) Stop I/Os to all the VxVM volumes.
 (b) Umount any filesystems with VxVM volumes.
 (c) Stop applications using any VxVM volumes.
o Select the appropriate RPMs for your system, and upgrade to the new patch.
 # rpm -Uhv VRTSvxvm-6.2.1.100-GA_SLES11.x86_64.rpm


REMOVING THE PATCH
------------------
rpm -e rpm-name


KNOWN ISSUES
------------
* Tracking ID: 3817229

SYMPTOM: When fsfreeze is used together with vxdump, the fsfreeze command
timeout and vxdump command failed.

WORKAROUND: Don't use fsfreeze and vxdump command together.



SPECIAL INSTRUCTIONS
--------------------
For Incident 3705579, An additional patch is required from EMC to support processing SCSI commands via the request_queue mechanism on EMC PowerPath devices. Please contact EMC for patch details for a specific kernel version,
and refer to EMC incident id OPT 472862.


OTHERS
------
NONE



Read and accept Terms of Service