* * * READ ME * * *
* * * Veritas Volume Manager 5.1 SP1 RP1 * * *
* * * P-patch 1 * * *
Patch Date: 2011-02-28
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 RP1 P-patch 1
PACKAGES AFFECTED BY THE PATCH
------------------------------
VRTSvxvm
BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
* Veritas Volume Manager 5.1 SP1 RP1
OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
Solaris 9 SPARC
Solaris 10 SPARC
INCIDENTS FIXED BY THE PATCH
----------------------------
This patch fixes the following Symantec incidents:
* 2256685 (Tracking ID: 2080730)
SYMPTOM:
On Linux, exclusion of devices using the "vxdmpadm exclude" CLI is not
persistent across reboots.
DESCRIPTION:
On Linux, names of OS devices (/dev/sd*) are not persistent. The
"vxdmpadm exclude" CLI uses the OS device names to keep track of
devices to be excluded by VxVM/DMP. As a result, on reboot, if the OS
device names change, then the devices which are intended to be excluded
will be included again.
RESOLUTION:
The resolution is to use persistent physical path names to keep track of the
devices that have been excluded.
* 2256686 (Tracking ID: 2152830)
SYMPTOM:
Sometimes the storage admins create multiple copies/clones of the same device.
Diskgroup import fails with a non-descriptive error message when multiple
copies(clones) of the same device exists and original device(s) are either
offline or not available.
# vxdg import mydg
VxVM vxdg ERROR V-5-1-10978 Disk group mydg: import failed:
No valid disk found containing disk group
DESCRIPTION:
If the original devices are offline or unavailable, vxdg import picks
up cloned disks for import. DG import fails by design unless the clones
are tagged and tag is specified during DG import. While the import
failure is expected, but the error message is non-descriptive and
doesn't provide any corrective action to be taken by user.
RESOLUTION:
Fix has been added to give correct error meesage when duplicate clones
exist during import. Also, details of duplicate clones is reported in
the syslog.
Example:
[At CLI level]
# vxdg import testdg
VxVM vxdg ERROR V-5-1-10978 Disk group testdg: import failed:
DG import duplcate clone detected
[In syslog]
vxvm:vxconfigd: warning V-5-1-0 Disk Group import failed: Duplicate clone disks are
detected, please follow the vxdg (1M) man page to import disk group with
duplicate clone disks. Duplicate clone disks are: c2t20210002AC00065Bd0s2 :
c2t50060E800563D204d1s2 c2t50060E800563D204d0s2 : c2t50060E800563D204d1s2
* 2256688 (Tracking ID: 2202710)
SYMPTOM:
Transactions on Rlink are not allowed during SRL to DCM flush.
DESCRIPTION:
Present implementation doesn.t allow rlink transaction to go through if SRL
to DCM flush is in progress. As SRL overflows, VVR start reading from SRL and
mark the dirty regions in corresponding DCMs of data volumes, it is called SRL
to DCM flush. During SRL to DCM flush transactions on rlink is not allowed. Time
to complete SRL flush depend on SRL size, it could range from minutes to many
hours. If user initiate any transaction on rlink then it will hang until SRL
flush completes.
RESOLUTION:
Changed the code behavior to allow rlink transaction during SRL flush. Fix stops
the SRL flush for transaction to go ahead and restart the flush after
transaction completion.
* 2256689 (Tracking ID: 2233889)
SYMPTOM:
The volume recovery happens in a serial fashion when any of the volumes has a
log volume attached to it.
DESCRIPTION:
When recovery is initiated on a disk group, vxrecover creates lists of each type
of volumes such as cache volume, data volume, log volume etc. The log volumes
are recovered in a serial fashion by design. Due to a bug the data volumes are
added to the log volume list if there exists a log volume. Hence even the data
volumes were recovered in a serial fashion if any of the volumes has a log
volume attached.
RESOLUTION:
The code was fixed such that the data volume list, cache volume list and the log
volume list are maintained separately and the data volumes are not added to the
log volumes list. The recovery for the volumes in each list is done in parallel.
* 2256690 (Tracking ID: 2226304)
SYMPTOM:
In Solaris 9 platform, newfs(1M)/mkfs_ufs(1M) cannot create ufs file system on
>1 Tera byte(TB) VxVM volume and it displays the following error:
# newfs /dev/vx/rdsk/<diskgroup name>/<volume>
newfs: construct a new file system /dev/vx/rdsk/<diskgroup name>/<volume>:
(y/n)? y
Can not determine partition size: Inappropriate ioctl for device
# prtvtoc /dev/vx/rdsk/<diskgroup name>/<volume>
prtvtoc: /dev/vx/rdsk/<diskgroup name>/<volume>: Unknown problem reading VTOC
DESCRIPTION:
newfs(1M)/mkfs_ufs(1M) invokes DKIOCGETEFI ioctl. During the enhancement of EFI
support on Solaris 10 on 5.0MP3RP3 or later, DKIOCGETEFI ioctl functionality
was not implemented on Solaris 9 because of the following limitations:
1. EFI feature has not been introduced from Solaris 9 FCS and has been
introduced from Solaris 9 U3(4/03) which includes 114127-03(libefi) and 114129-
02(libuuid and efi/uuid headers).
2. During the enhancement of EFI support on Solaris 10, for solaris 9,
DKIOCGVTOC ioctl was only supported on a volume <= 1TB since the VTOC
specification was defined for only <= 1 TB LUN/volume. If the size of the
volume is > 1 TB DKIOCGVTOC ioctl would return an inaccurate vtoc structure due
to value overflow.
RESOLUTION:
The resolution is to enhance the VxVM code to handle DKIOCGETEFI ioctl
correctly on VxVM volume on Solaris 9 platform. When newfs(1M)/mkfs_ufs(1M)
invokes DKIOCGETEFI ioctl on a VxVM volume device, VxVM shall return the
relevant EFI label information so that the UFS utilities can determine the
volume size correctly.
* 2256691 (Tracking ID: 2197254)
SYMPTOM:
vxassist, the VxVM volume creation utility when creating volume with
"logtype=none" doesn't function as expected.
DESCRIPTION:
While creating volumes on thinrclm disks, Data Change Object(DCO) version 20 log
is attached to every volume by default. If the user do not want this default
behavior then "logtype=none" option can be specified as a parameter to vxassist
command. But with VxVM on HP 11.31 , this option does not work and DCO version
20 log is created by default. The reason for this inconsistency is that when
"logtype=none" option is specified, the utility sets the flag to prevent
creation of log. However, VxVM wasn't checking whether the flag is set before
creating DCO log which led to this issue.
RESOLUTION:
This is a logical issue which is addressed by code fix. The solution is to check
for this corresponding flag of "logtype=none" before creating DCO version 20 by
default
* 2256692 (Tracking ID: 2240056)
SYMPTOM:
'vxdg move/split/join' may fail during high I/O load.
DESCRIPTION:
During heavy I/O load 'dg move' transaction may fail because of open/close
assertion and retry will be done. As the retry limit is set to 30 'dg move'
fails if retry hits the limit.
RESOLUTION:
Change the default transaction retry to unlimit, introduce a new option
to 'vxdg move/split/join' to set transaction retry limit as follows:
vxdg [-f] [-o verify|override] [-o expand] [-o transretry=retrylimit] move
src_diskgroup dst_diskgroup objects ...
vxdg [-f] [-o verify|override] [-o expand] [-o transretry=retrylimit] split
src_diskgroup dst_diskgroup objects ...
vxdg [-f] [-o verify|override] [-o transretry=retrylimit] join src_diskgroup
dst_diskgroup
* 2256722 (Tracking ID: 2215256)
SYMPTOM:
Volume Manager is unable to recognize the devices connected through F5100 HBA
DESCRIPTION:
During device discovery volume manager does not scan the luns that are connected
through SAS HBA (F5100 is a new SAS HBA). So the commands like 'vxdisk list'
does not even show the luns that are connected through F5100 HBA
RESOLUTION:
Modified the device discovery code in volume manager to include the paths/luns
that are connected through SAS HBA
* 2257684 (Tracking ID: 2245121)
SYMPTOM:
Rlinks do not connect for NAT (Network Address Translations) configurations.
DESCRIPTION:
When VVR (Veritas Volume Replicator) is replicating over a Network Address
Translation (NAT) based firewall, rlinks fail to connect resulting in
replication failure.
Rlinks do not connect as there is a failure during exchange of VVR heartbeats.
For NAT based firewalls, conversion of mapped IPV6 (Internet Protocol Version
6) address to IPV4 (Internet Protocol Version 4) address is not handled which
caused VVR heartbeat exchange with incorrect IP address leading to VVR
heartbeat failure.
RESOLUTION:
Code fixes have been made to appropriately handle the exchange of VVR
heartbeats under NAT based firewall.
* 2268733 (Tracking ID: 2248730)
SYMPTOM:
Command hungs if "vxdg import" called from script with STDERR
redirected.
DESCRIPTION:
If script is having "vxdg import" with STDERR redirected then
script does not finish till DG import and recovery is finished. Pipe between
script and vxrecover is not closed properly which keeps calling script waiting
for vxrecover to complete.
RESOLUTION:
Closed STDERR in vxrecover and redirected the output to
/dev/console.
* 2276324 (Tracking ID: 2270880)
SYMPTOM:
On Solaris 10 (SPARC only), if the size of EFI(Extensible Firmware Interface)
labeled disk is greater than 2TB, the disk capacity will be truncated to 2TB
when it is initialized with CDS(Cross-platform Data Sharing) under VxVM(Veritas
Volume Manager).
For example, the sizes shown as the sector count by prtvtoc(1M) and public
region size by vxdisk(1M) will be truncated to the sizes approximate 2TB.
# prtvtoc /dev/rdsk/c0t500601604BA07D17d13
<snip>
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
2 15 00 48 4294967215 4294967262
# vxdisk list c0t500601604BA07D17d13 | grep public
public: slice=2 offset=65744 len=4294901456 disk_offset=48
DESCRIPTION:
From VxVM 5.1 SP1 and onwards, the CDS format is enhanced to support for disks
of greater than 1TB. VxVM will use EFI layout to support CDS functionality for
disks of greater than 1TB, however on Solaris 10 (SPARC only), a problem is seen
that the disk capacity will be truncated to 2TB if the size of EFI labeled disk
is greater than 2TB.
This is because the library /usr/lib/libvxscsi.so in Solaris 10 (SPARC only)
package does not contain the required enhancement on Solaris 10 to support CDS
format for disks greater than 2TB.
RESOLUTION:
The VxVM package for Solaris has been changed to contain all the libvxscsi.so
binaries which is built for Solaris platforms(versions) respectively, for
example libvxscsi.so.SunOS_5.9 and libvxscsi.so.SunOS_5.10.
From this fix and onwards, the appropriate platform's built of the binary will
be installed as /usr/lib/libvxscsi.so during the installation of the VxVM package.
INSTALLING THE PATCH
--------------------
For Solaris 9, and 10 releases, refer to the man pages for instructions on
using 'patchadd' and 'patchrm' scripts provided with Solaris.
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# patchadd 122058-xx
REMOVING THE PATCH
------------------
The following example removes a patch from a standalone system:
example# patchrm 122058-xx
For additional examples please see the appropriate man pages.
SPECIAL INSTRUCTIONS
--------------------
You need to use the shutdown command to reboot the system after patch
installation or de-installation:
shutdown -g0 -y -i6
A Solaris 10 issue prevents this patch from complete installation.
Before installing this VM patch, install the Solaris patch
119254-70 (or a later revision). This Solaris patch fixes packaging,
installation and patch utilities. [Sun Bug ID 6337009]
Download Solaris 10 patch 119254-70 (or later) from Sun at
http://sunsolve.sun.com
