vm-sol11_sparc-6.1.0.100

 Basic information
Release type: Patch
Release date: 2014-05-29
OS update support: None
Technote: None
Documentation: None
Popularity: 4729 viewed    downloaded
Download size: 54.66 MB
Checksum: 1163854338

 Applies to one or more of the following products:
Dynamic Multi-Pathing 6.1 On Solaris 11 SPARC
Storage Foundation 6.1 On Solaris 11 SPARC
Storage Foundation Cluster File System 6.1 On Solaris 11 SPARC
Storage Foundation for Oracle RAC 6.1 On Solaris 11 SPARC
Storage Foundation HA 6.1 On Solaris 11 SPARC
Volume Manager 6.1 On Solaris 11 SPARC

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

 Fixes the following incidents:
3424815, 3440980, 3444900, 3445233, 3445234, 3445249, 3445268, 3445991, 3445992, 3446010, 3446126, 3447306, 3447894, 3449714, 3452709, 3452727, 3452811, 3455455, 3456729, 3458036, 3458799, 3470346, 3498923

 Patch ID:
None.

Readme file
                          * * * READ ME * * *
                * * * Symantec Volume Manager 6.1 * * *
                      * * * Patch 6.1.0.100 * * *
                         Patch Date: 2014-05-22


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
----------
Symantec Volume Manager 6.1 Patch 6.1.0.100


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


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


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


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: 6.1.0.100
* 3424815 (3424704) vxbootsetup command fails with localized strings
* 3440980 (3107699) VxDMP (Veritas Dynamic MultiPathing)  causes system panic 
after a shutdown/reboot.
* 3444900 (3399131) For PowerPath (PP) enclosure, both DA_TPD and DA_COEXIST_TPD flags are set.
* 3445233 (3339195) While running vxdiskadm error is observed
* 3445234 (3358904) System with ALUA enclosures sometimes panics during path fault scenarios
* 3445249 (3344796) shared disk group import fails on LDOM guest with SCSI-3 Persistent Reservation
enabled
* 3445268 (3422504) Paths gets unexpectdely disabled/enabled in LDOM guest
* 3445991 (3421326) DMP keeps on logging 'copyin failure messages' in system log repeatedly
* 3445992 (3421322) LDOM guest experiences intermittent I/O failures
* 3446010 (3421330) vxfentsthdw utility tests fail in LDOM guest for DMP backed virtual devices.
* 3446126 (3338208) writes from fenced out node on Active-Passive (AP/F) shared storage device fail
with unexpected error
* 3447306 (3424798) Veritas Volume Manager (VxVM) mirror attach operations
(e.g., plex attach, vxassist mirror, and third-mirror break-off snapshot
resynchronization) may take longer time under heavy application I/O load.
* 3447894 (3353211) A. After EMC Symmetrix BCV (Business Continuance Volume) device switches to
read-write mode, continuous vxdmp (Veritas Dynamic Multi Pathing) error messages
flood syslog.
B. DMP metanode/path under DMP metanode gets disabled unexpectedly.
* 3449714 (3417185) Rebooting host, after the exclusion of a dmpnode while I/O is in progress on it, leads to vxconfigd core dump.
* 3452709 (3317430) The vxdiskunsetup utility throws error after upgradation from 
5.1SP1RP4.
* 3452727 (3279932) The vxdisksetup and vxdiskunsetup utilities were failing on
disk which is part of a deported disk group (DG), even if "-f" option is specified.
* 3452811 (3445120) Change tunable VOL_MIN_LOWMEM_SZ value to trigger early readback.
* 3455455 (3409612) The value of reclaim_on_delete_start_time cannot be set to
values outside the range: 22:00-03:59
* 3456729 (3428025) System running Symantec Replication Option (VVR) and configured as VVR primary crashes when heavy parallel I/Os load are issued
* 3458036 (3418830) Node boot-up is getting hung while starting vxconfigd
* 3458799 (3197987) vxconfigd dumps core, when 'vxddladm assign names file=<filename>' is executed and the file has one or more invalid values 
for enclosure vendor ID or product ID.
* 3470346 (3377383) The vxconfigd crashes when a disk under Dynamic Multi-pathing
(DMP) reports device failure.
* 3498923 (3087893) EMC TPD emcpower names are changing every reboot with VxVM


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

Patch ID: 6.1.0.100

* 3424815 (Tracking ID: 3424704)

SYMPTOM:
vxbootsetup command fails while using localized messages with below error:
VxVM vxbootsetup ERROR V-5-2-5651 <garbage value>

DESCRIPTION:
The issue occurs because while comparing the output of 'vxsctl mode' command, it is not converted in English language. The output 
of the command comes in localized form which leads to the failure of vxbootsetup.

RESOLUTION:
Code changes have been made to convert the output of 'vxdctl mode' command in English before comparing.

* 3440980 (Tracking ID: 3107699)

SYMPTOM:
VxDMP causes system panic after a shutdown or reboot and displays
the following stack trace:
mutex_enter() 
volinfo_ioct()
volsioctl_real()
cdev_ioctl()
dmp_signal_vold()
dmp_throttle_paths()
dmp_process_stats()
dmp_daemons_loop()
thread_start()
OR
panicsys()
vpanic_common()
panic+0x1c()
mutex_enter()
cdev_ioctl()
dmp_signal_vold()
dmp_check_path_state()
dmp_restore_callback()
dmp_process_scsireq()
dmp_daemons()
thread_start()

DESCRIPTION:
In a special scenario of system shutdown/reboot, the DMP
(Dynamic MultiPathing) I/O statistic daemon tries to call the ioctl functions
in VXIO module which is being unloaded and this causes system panic.

RESOLUTION:
The code is modified to stop the DMP I/O statistic daemon before
system shutdown/reboot. Also added a code change to avoid to other probe to vxio
devices during shutdown.

* 3444900 (Tracking ID: 3399131)

SYMPTOM:
The following command fails with an error for a path managed by Third Party
Driver (TPD) which co-exists with DMP.
# vxdmpadm -f disable path=<path name> 
VxVM vxdmpadm ERROR V-5-1-11771 Operation not supported

DESCRIPTION:
The Third Party Drivers manage the devices with or without the co-existence of
Dynamic Multi Pathing driver. Disabling the paths managed by a third party
driver which does not co-exist with DMP is not supported. But due to bug in the
code, disabling the paths managed by a third party driver which co-exists with
DMP also fails. The same flags are set for all third party driver devices.

RESOLUTION:
The code has been modified to block this command only for the third party
drivers which cannot co-exist with DMP.

* 3445233 (Tracking ID: 3339195)

SYMPTOM:
While running vxdiskadm following error message is observed.
 "/usr/lib/vxvm/voladm.d/bin/exclude.do: 
syntax error at line 103: `CMD=$' unexpected"

Volume Manager Device Operations
Menu: VolumeManager/Disk/ExcludeDevices

 1      Suppress all paths through a controller from VxVM's view
 2      Suppress a path from VxVM's view
 3      Suppress disks from VxVM's view by specifying a VID:PID combination
 4      Suppress all paths to a disk
 5      Prevent multipathing of all disks on a controller by VxVM
 6      Prevent multipathing of a disk by VxVM
 7      Prevent multipathing of disks by specifying a VID:PID combination
 8      List currently suppressed devices

 ?      Display help about menu
 ??     Display help about the menuing system
 q      Exit from menus

Select an operation to perform: 4

/usr/lib/vxvm/voladm.d/bin/exclude.do: syntax error at line 103: `CMD=$' 
unexpected

DESCRIPTION:
Script fails as legacy backtick option "`CMD`" to store command in a variable is not used.

RESOLUTION:
Code changes are made to use correct syntax by putting required backticks.

* 3445234 (Tracking ID: 3358904)

SYMPTOM:
System panics with following stack:

dmp_alua_get_owner_state()
dmp_alua_get_path_state()
dmp_get_path_state()
dmp_get_enabled_ctlrs()
dmp_info_ioctl()
gendmpioctl()
dmpioctl()
vol_dmp_ktok_ioctl()
dmp_get_enabled_cntrls()
vx_dmp_config_ioctl()
quiescesio_start()
voliod_iohandle()
voliod_loop()
kernel_thread()

DESCRIPTION:
System running with Asymmetric Logical Unit Access (ALUA) LUNs sometimes panics
during path fault scenarios. This happens due to possible NULL pointer
access in some of cases due to bug in the code .

RESOLUTION:
Code changes have been made to fix the bug.

* 3445249 (Tracking ID: 3344796)

SYMPTOM:
shared disk group import fails. I/O failure messages with reservation conflict
seen in system log..

..
..
Tue Oct 22 03:40:54.071: I/O error occurred (errno=0x5) on Dmpnode ams_23000_60 
Tue Oct 22 03:40:54.160: I/O error occurred on Path c3t50060E801025BEE0d12s2 
belonging to Dmpnode ams_23000_61
Tue Oct 22 03:40:54.161: Unmarked as ioerr Path c3t50060E801025BEE0d12s2 belonging 
to Dmpnode ams_23000_61
Tue Oct 22 03:40:54.161: I/O analysis done as DMP_PATH_OKAY on Path 
c3t50060E801025BEE0d12s2 belonging to Dmpnode ams_23000_61
Tue Oct 22 03:40:54.161: I/O retry(1) on Path c3t50060E801025BEE0d12s2 belonging 
to Dmpnode ams_23000_61
Tue Oct 22 03:40:54.461: SCSI error occurred on Path c3t50060E801025BEE0d12s2: 
opcode=0x2a reported reservation conflict (status=0x18, key=0x0, asc=0x0, 
ascq=0x0) 
Tue Oct 22 03:40:54.461: I/O analysis done as DMP_RSV_CONFLICT_ERR on Path 
c3t50060E801025BEE0d12s2 belonging to Dmpnode ams_23000_61
..
..

DESCRIPTION:
From I/O domains DMP metanode is exported to LDOM guest as virtual device. On this virtual device when any SCSI-3 Persistent 
Reservation(PR)command is issued then DMP at I/O domain layer catches it and takes appropriate action. This was not working as expected 
causing missing keys from some of paths at I/O domain layer. Hence I/O routed from unregistered path failing with reservation conflict.

RESOLUTION:
Made code changes to fix the same.

* 3445268 (Tracking ID: 3422504)

SYMPTOM:
path disable/enable messages seen in system log of LDOM guest: 

..
Sat Jan 25 11:20:29.054: Disabled Path c2d2s2 belonging to Dmpnode
hitachi_vsp0_1986 due to path failure
Sat Jan 25 11:20:33.053: SCSI error occurred on Path c2d1s2: opcode=0x5f
reported unit attention (status=0x2, key=0x6, asc=0x2a, ascq=0x4) reservations
released
Sat Jan 25 11:20:33.536: Enabled Path c2d2s2 belonging to Dmpnode 
hitachi_vsp0_1986
..

DESCRIPTION:
In case of LDOMs, DMP(Veritas Dynamic Multipathing) routes SCSI commands using ioctl interface to  underlaying SCSI device. In some specific 
scenario, this interface was making incorrect decision causing path to get disabled. This gets enabled back subsequently.

RESOLUTION:
code changes were done in DMP to fix issue.

* 3445991 (Tracking ID: 3421326)

SYMPTOM:
DMP(Veritas Dynamic Multipathing) keeps on logging 'copyin failure messages' in system log repeatedly 

..
Jan 24 00:53:34 s5120sb0 vxdmp: NOTICE: VxVM vxdmp V-5-3-0 dmp_handler_pgr_out:
uscsi_cdbcopyin failed err = 14
..

DESCRIPTION:
Corresponding log message was kept at default log level. In some cases, it is expected that 'copyin' would fail.

RESOLUTION:
Log level of message has been bumped.

* 3445992 (Tracking ID: 3421322)

SYMPTOM:
1. I/O failure messages with reservation conflict logged in system log of LDOM 
guest..

..
..
Tue Oct 22 03:40:54.161: I/O analysis done as DMP_PATH_OKAY on Path 
c3t50060E801025BEE0d12s2 belonging to Dmpnode 3pardata0_940
Tue Oct 22 03:40:54.461: SCSI error occurred on Path c3t50060E801025BEE0d12s2: 
opcode=0x2a reported reservation conflict (status=0x18, key=0x0, asc=0x0, 
ascq=0x0) 
Tue Oct 22 03:40:54.461: I/O analysis done as DMP_RSV_CONFLICT_ERR on Path 
c3t50060E801025BEE0d12s2 belonging to Dmpnode 3pardata0_940 
Tue Oct 22 03:40:54.461: I/O error occurred (errno=0x5) on Dmpnode ams_23000_60 
..

2. faiiling tag is seen against disks in vxdisk list output of LDOM guest

bash-3.2# vxdisk list
..
3pardata0_940 auto:cdsdisk    3pardata0_940  dg1          online failing

DESCRIPTION:
With disk based I/O fencing, multipathing software like Dynamic multipathing 
(DMP) does SCSI-3 Persistent Reservation (SCSI-3 PR) on a virtual storage 
device (vSCSI). Now DMP in I/O domains would catch those commands. While 
processing it might generate multiple SCSI commands and those may get retried 
for retryable errors from end storage device. This retry passes but failure was 
returned to LDOM guest due to code bug.

RESOLUTION:
code changes were done in DMP to fix issue.

* 3446010 (Tracking ID: 3421330)

SYMPTOM:
[root@vcst42b-v9 ~]#vxfentsthdw -n

Veritas vxfentsthdw version 6.1.0 Solaris
..
..

Remove key KeyB on node vcst42b-v9 ..................................... Failed
Removing test keys and temporary files, if any...

DESCRIPTION:
The vxfentsthdw is compliance utility provided to test disks for support of SCSI-3 persistent reservations. It verifies by 
simulating various scenarios that the shared storage device can be used for I/O fencing. Some of scenarios were failing with 
DMP (Veritas Dynamic Multipathing)backed virtual devices due to unhandled cases from DMP in I/O domains.

RESOLUTION:
Code changes were done to fix unhandled cases. ALL SCSI-3 scenarios from vxfentsthdw utility tests PASS for DMP backed virtual 
devices from LDOM guest.

* 3446126 (Tracking ID: 3338208)

SYMPTOM:
writes from fenced out LDOM guest node on Active-Passive (AP/F) shared storage
device fail. I/O failure messages seen in system log..

..
Mon Oct 14 06:03:39.411: I/O retry(6) on Path c0d8s2 belonging to Dmpnode
emc_clariion0_48
Mon Oct 14 06:03:39.951: SCSI error occurred on Path c0d8s2: opcode=0x2a
reported device not ready (status=0x2, key=0x2, asc=0x4, ascq=0x3) LUN not
ready, manual intervention required
Mon Oct 14 06:03:39.951: I/O analysis done as DMP_PATH_FAILURE on Path c0d8s2
belonging to Dmpnode emc_clariion0_48
Mon Oct 14 06:03:40.311: Marked as failing Path c0d1s2 belonging to Dmpnode
emc_clariion0_48
Mon Oct 14 06:03:40.671: Disabled Path c0d8s2 belonging to Dmpnode
emc_clariion0_48 due to path failure
..
..

DESCRIPTION:
write SCSI commands from fenced out host should fail with reservation
conflict from shared device. This error code needs to be propagated to upper
layers for appropriate action.

In DMP ioctl interface, DMP first sends command through available active paths.
If command fails then command was unnecessarily tried on passive paths. 

This causes command to be failed with not ready error code and this error code
getting propagated to upper layer instead of reservation conflict.

RESOLUTION:
Added code changes to not retry IO SCSI commands on passive paths in case of
Active-Passive (AP/F) shared storage device.

* 3447306 (Tracking ID: 3424798)

SYMPTOM:
Veritas Volume Manager (VxVM) mirror attach operations (e.g., plex attach,
vxassist mirror, and third-mirror break-off snapshot resynchronization) may take
longer time under heavy application I/O load. The vxtask list command shows
tasks are in the 'auto-throttled (waiting)' state for a long time.

DESCRIPTION:
With the AdminIO de-prioritization feature, VxVM administrative I/O's (e.g. plex
attach, vxassist mirror, and third-mirror break-off snapshot resynchronization)
are de-prioritized under heavy application I/O load, but this can lead to very
slow progress of these operations.

RESOLUTION:
The code is modified to disable the AdminIO de-prioritization feature.

* 3447894 (Tracking ID: 3353211)

SYMPTOM:
A. After EMC Symmetrix BCV (Business Continuance Volume) device switches to
read-write mode, continuous vxdmp (Veritas Dynamic Multi Pathing) error messages
flood syslog as shown below:

NOTE VxVM vxdmp V-5-3-1061 dmp_restore_node: The path 18/0x2 has not yet aged - 
299
NOTE VxVM vxdmp 0 dmp_tur_temp_pgr: open failed: error = 6 dev=0x24/0xD0
NOTE VxVM vxdmp V-5-3-1062 dmp_restore_node: Unstable path 18/0x230 will not be 
available for I/O until 300 seconds
NOTE VxVM vxdmp V-5-3-1061 dmp_restore_node: The path 18/0x2 has not yet aged - 
299
NOTE VxVM vxdmp V-5-0-0 [Error] i/o error occurred (errno=0x6) on dmpnode 
36/0xD0
..
..

B. DMP metanode/path under DMP metanode gets disabled unexpectedly.

DESCRIPTION:
A. DMP caches the last discovery NDELAY open for the BCV dmpnode paths. BCV
device switching to read-write mode is an array side operation. Typically in
such cases, the 
system administrators are required to run the following command:

1. vxdisk rm <accessname>

OR 

In case of parallel backup jobs,

1. vxdisk offline <accessname>
2. vxdisk online <accessname>

This causes DMP to close cached open, and during the next discovery, the device
is opened in read-write mode. If the above steps are skipped then it causes the
DMP device to go in state where one of the paths is in read-write mode and the
others remain in NDELAY mode. 

If the above layers request for NORMAL open, then the DMP has the code to close
NDELAY cached open and reopen in NORMAL mode. When the dmpnode is online, this
happens only for one of the paths of dmpnode. 

B. DMP performs error analysis for paths on which I/O has failed. In some cases,
the SCSI probes are sent, failed with the return value/sense codes that are not
handled by DMP. This causes the paths to get disabled.

RESOLUTION:
A. The code is modified for the DMP EMC ASL (Array Support Library) to handle
case A for EMC Symmetrix arrays.
B. The DMP code is modified to handle the SCSI conditions correctly for case B.

* 3449714 (Tracking ID: 3417185)

SYMPTOM:
Rebooting host, after the exclusion of a dmpnode while I/O is in progress on it,
leads to vxconfigd core dump.

DESCRIPTION:
The function which deletes the path after exclusion, does not update the 
corresponding data structures properly. Consequently, rebooting the host, after 
the exclusion of dmpnode while I/O is in progress on it, leads to vxconfigd core 
dump with following stack

ddl_find_devno_in_table ()
ddl_get_disk_policy ()
devintf_add_autoconfig_main ()
devintf_add_autoconfig ()
mode_set ()
req_vold_enable ()
request_loop ()
main ()

RESOLUTION:
Code changes have been made to update the data structure properly.

* 3452709 (Tracking ID: 3317430)

SYMPTOM:
"vxdiskunsetup" utility throws  error during execution. 
Following error message is observed.
"Device unexport failed: Operation is not supported".

DESCRIPTION:
In vxdisksetup vxunexport is called, without checking if the disk is 
exported or the CVM protocol version. When the bits are upgraded 
from 5.1SP1RP4, the CVM protocol version is not updated. Hence the error.

RESOLUTION:
Code changes done so that the vxunexport is called after doing proper checks.

* 3452727 (Tracking ID: 3279932)

SYMPTOM:
The vxdisksetup and vxdiskunsetup utilities were failing on disk which
is part of deported disk group (DG), even if '-f' option is specified.
The vxdisksetup command fails with following error:

VxVM vxedpart ERROR V-5-1-10089 partition modification failed :
Device or resource busy 

The vxdiskunsetup command fails following error:

VxVM vxdisk ERROR ERROR V-5-1-0 Device <Disk name> appears to be 
owned by disk group <Disk group>. Use -f option to force destroy.
VxVM vxdiskunsetup ERROR V-5-2-5052 <Disk name>: Disk destroy failed.

DESCRIPTION:
The vxdisksetup and vxdiskunsetup utilities internally call the
'vxdisk' utility. Due to a defect in vxdisksetup and vxdiskunsetup, the vxdisk
operation used to fail on disk which is part of deported DG, even if '-f'
operation is requested by user.

RESOLUTION:
Code changes are done to the vxdisksetup and vxdiskunsetup
utilities so that when "-f" option is specified the operation succeeds.

* 3452811 (Tracking ID: 3445120)

SYMPTOM:
Default value of tunable 'vol_min_lowmem_sz' is not consistent on all platforms.

DESCRIPTION:
Default value of tunable 'vol_min_lowmem_sz' is not consistent on all platforms.

RESOLUTION:
Set the default value of tunable 'vol_min_lowmem_sz' to 32MB on all platforms.

* 3455455 (Tracking ID: 3409612)

SYMPTOM:
Fails to run "vxtune reclaim_on_delete_start_time <value>" if the specified
value is 
outside the range of 22:00-03:59 (E.g. setting it to 04:00 or 19:30 fails).

DESCRIPTION:
Tunable reclaim_on_delete_start_time can be set to any time value within 00:00
to 23:59. But because of the wrong regular expression to parse time, it cannot
be set to all values in 00:00 - 23:59.

RESOLUTION:
The regular expression has been updated to parse time format correctly.
Now all values in 00:00-23:59 can be set.

* 3456729 (Tracking ID: 3428025)

SYMPTOM:
When heavy parallel I/O load is issued, system running Symantec Replication 
Option (VVR) and configured as VVR primary, panics with the below stack:

schedule 
vol_alloc 
vol_zalloc 
volsio_alloc_kc_types 
vol_subdisk_iogen_base 
volobject_iogen 
vol_rv_iogen 
volobject_iogen 
vol_rv_batch_write_start 
volkcontext_process 
vol_rv_start_next_batch 
vol_rv_batch_write_done 
[...]
vol_rv_batch_write_done 
volkcontext_process 
vol_rv_start_next_batch 
vol_rv_batch_write_done 
volkcontext_process 
vol_rv_start_next_batch 
vol_rv_batch_kio 
volkiostart 
vol_linux_kio_start 
vol_fsvm_strategy

DESCRIPTION:
Heavy parallel I/O load leads to I/O throttling in Symantec Replication Option (VVR). Improper throttle handling leads to kernel stack 
overflow.

RESOLUTION:
Handled I/O throttle correctly which avoids stack overflow and subsequent panic.

* 3458036 (Tracking ID: 3418830)

SYMPTOM:
Node boot-up is getting hung while starting vxconfigd if 
'/etc/VRTSvcs/conf/sysname' file or 
'/etc/vx/vxvm-hostprefix' file is not present. User will see following messages 
on console.

# Starting up VxVM
...
# VxVM general startup...

After these messages, it will hung.

DESCRIPTION:
While generating unique prefix, we were calling scanf instead of 
sscanf for fetching prefix which 
resulted in this hang. So while starting vxconfigd, it was waiting for some user 
input because of scanf which 
resulted in hang while booting up the node.

RESOLUTION:
Code changes are done to address this issue.

* 3458799 (Tracking ID: 3197987)

SYMPTOM:
vxconfigd dumps core, when 'vxddladm assign names file=<filename> is executed and the file has one or more invalid values 
for enclosure vendor ID or product ID.

DESCRIPTION:
When the input file provided to 'vxddladm assign names file=<filename>' has invalid vendor ID or product ID, the vxconfigd 
daemon is unable to find the corresponding enclosure being referred to and makes an invalid memory reference. 

Following stack trace can be seen-

strncasecmp () from /lib/libc.so.6
ddl_load_namefile ()
req_ddl_set_names ()
request_loop ()
main ()

RESOLUTION:
As a fix the vxconfigd daemon verifies the validity of input vendor ID and
product ID before making a memory reference to the corresponding enclosure in
its internal data structures.

* 3470346 (Tracking ID: 3377383)

SYMPTOM:
vxconfigd crashes when a disk under DMP reports device failure. After this, the 
following error will be seen when a VxVM (Veritas Volume 
Manager)command is excuted:-
"VxVM vxdisk ERROR V-5-1-684 IPC failure: Configuration daemon is not 
accessible"

DESCRIPTION:
If a disk fails and reports certain failure to DMP (Veritas Dynamic 
Multipathing), then vxconfigd crashes because that error is not handled 
properly.

RESOLUTION:
The code is modified to properly handle the device failures reported by a failed 
disk under DMP.

* 3498923 (Tracking ID: 3087893)

SYMPTOM:
EMC PowerPath pseudo device mappings change with each reboot with VxVM 
(Veritas Volume Manager).

DESCRIPTION:
VxVM invokes PowerPath command 'powermt display unmanaged' to discover
 PowerPath unmanaged devices. This command destroys PowerPath devices mappings 
during early boot stage when PowerPath isn't fully up.

RESOLUTION:
EMC fixed the issue by introducing an environment variable MPAPI_EARLY_BOOT to 
powermt command. VxVM startup script set the variable to TRUE before calling 
powermt command. Powermt understands the early boot phase and does things 
differently. The variable is unset by VxVM after device discovery.



INSTALLING THE PATCH
--------------------
NOTE: This patch is qualified by Symantec QA on Oracle Solaris 11.1
and with Support Repository Updates (SRU) 11.1.15.4.0

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 hot-fix vm-sol11_sparc-6.1.0.100-patches.tar.gz to /tmp
2. Untar vm-sol11_sparc-6.1.0.100-patches.tar.gz to /tmp/hf
    # mkdir /tmp/hf
    # cd /tmp/hf
    # gunzip /tmp/vm-sol11_sparc-6.1.0.100-patches.tar.gz
    # tar xf /tmp/vm-sol11_sparc-6.1.0.100-patches.tar
3. Install the hotfix
    # pwd /tmp/hf
    # ./installVRTSvxvm610HF100 [<host1> <host2>...]

If you want to manually apply the patch, please follow the following steps
a. Set the the publisher
    # pkg set-publisher -P -g <patch_file_pathname> Symantec
    For example:
    # pkg set-publisher -P -g /tmp/hf/patches/VRTSvxvm.p5p Symantec
b. Install the package
    # pkg install --accept [<VRTSpkg1> <VRTSpkg2>...]
    For example:
    # pkg install --accept VRTSvxvm
c. Verify the package is installed. The output of the following command should display the version for the package as 6.1.0.x :
    # pkg info [<VRTSpkg1> <VRTSpkg2>...]
    For example:
    # pkg info VRTSvxvm
d. Unset the publisher
    # pkg unset-publisher Symantec

Install the patch manually:
--------------------------
Before-the-upgrade:
  (a) Stop applications using any VxVM volumes.
  (b) Stop I/Os to all the VxVM volumes.
  (c) Umount any filesystems with VxVM volumes.
  (d) In case of multiple boot environments, boot using the BE
      you wish to install the patch on.
For instructions on using install and uninstall options of 'pkg' command please refer 
to the man page of 'pkg' command provided with Solaris 11 release.
Any other special or non-generic installation instructions should be described below as
special instructions.
The following example installs a patch to a standalone machine:
        example# pkg install --accept -g /patch_location/VRTSvxvm.p5p VRTSvxvm
After 'pkg install' please follow mandatory configuration steps mentioned in special 
instructions


REMOVING THE PATCH
------------------
The following example removes a patch from a standalone system:
        example# pkg uninstall VRTSvxvm


SPECIAL INSTRUCTIONS
--------------------
---------------------
After 'pkg install' please follow mandatory configuration steps as follows
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


OTHERS
------
NONE