Latest additions to the Release Notes for the Veritas Storage Foundation 4.1 to 4.1 MP2 for HP-UX 11i v2 product line and cross references to product documentation

Details:

To locate the most current product patch releases including Maintenance Packs, Rolling Patches, and Hot Fixes visit https://vos.symantec.com/patch/matrix

VOS (Veritas Operation Services) Portal: https://vos.symantec.com

VOS Portal Contains:

- Risk Assessments
- Installation Assessment Services (Installation and Upgrade preparation)
- VOS Searchability (Error Code Lookup, Patches, Documentation, Systems, Reports)
- Detailed Reports (Product and License Usage)
- Notification Signup (VOS Notification Widget)

Documentation

Product documentation, man pages and error messages for this release are available at http://sfdoccentral.symantec.com/index.html

Storage Foundation and High Availability 4.1 Product Family Documentation http://support.veritas.com/docs/307510

Storage Foundation and High Availability 4.1 MP1 Product Family Documentation http://support.veritas.com/docs/307511

Storage Foundation and High Availability 4.1 MP2 Product Family Documentation http://support.veritas.com/docs/307512

Storage Foundation and High Availability 4.1 for HP-UX Manual Pages http://support.veritas.com/docs/307659

Downloads

4.1 Maintenance Pack 2 is Available at http://entsupport.symantec.com/docs/292585

Patches are available on Patch Central https://vias.symantec.com/labs/patch

Tools

VIAS (Veritas Installation Assessment Service) https://vias.symantec.com
Health Check https://vias.symantec.com/labs/vhcs
Error Code Lookup https://vias.symantec.com/labs/vels
VIMS (Veritas Inventory Management Service) https://vias.symantec.com/labs/vims
Veritas Operations Services (VOS) Labs https://vias.symantec.com/labs

System Panic with Veritas File System (VxFS) and Hitachi Dynamic Link Manager (HDLM) 6.1.0-00 for HP-UX 11iv1 and 11iv2 without Logical Volume Manager (LVM) http://entsupport.symantec.com/docs/340090

File System 4.1 MP2 RP4 patches released:

PHKL_39026: s700_800 11.23 VRTS 4.1 MP2RP4 VRTSvxfs Kernel Patch
PHCO_39026: s700_800 11.23 VRTS 4.1 MP2RP4 VRTSvxfs Commands Patch

Volume Manager 4.1 MP2 RP5 patches released:

PHCO_38757: s700_800 11.23 VxVM 4.1 MP2RP5 Command Patch 11
PHKL_38758: s700_800 11.23 VxVM 4.1 MP2RP5 Kernel Patch 10

The above patches are now available from the HP Support web site at http://www.itrc.hp.com

4.1 Maintenance Pack 2 (MP2) is Available

The 4.1 MP2 release is now available at http://entsupport.symantec.com/docs/292585

4.1 MP2 Rolling Patch 1 Requirements

File System 4.1 MP2RP1 - PHKL_37393 has the following dependencies: PHCO_35888, PHCO_35892, PHCO_36522, PHCO_36744, PHKL_31500, PHKL_36745

Volume Manager 4.1 MP2RP1 - PHCO_37391 has the following dependencies: PHCO_36744, PHCO_37390, PHKL_31500, PHKL_36745, PHKL_37392

Cluster Volume Manager (CVM) fail back behavior for non-Active/Active arrays

This describes the fail back behavior for non-Active/Active arrays in a CVM cluster. This behavior applies to A/P, A/PF, APG, A/A-A, and ALUA arrays.

When all of the Primary paths fail or are disabled in a non-Active/Active array in a CVM cluster, the cluster-wide failover is triggered. All hosts in the cluster start using the Secondary path to the array. When the Primary path is enabled, the hosts fail back to the Primary path.

However, suppose that one of the hosts in the cluster is shut down or disabled while the Primary path is disabled. If the Primary path is then enabled, it does not trigger failback. The remaining hosts in the cluster continue to use the Secondary path. When the disabled host is rebooted and rejoins the cluster, all of the hosts in the cluster will continue using the Secondary path. This is expected behavior.

If the disabled host is rebooted and rejoins the cluster before the Primary path is enabled, enabling the path does trigger the failback. In this case, all of the hosts in the cluster will fail back to the Primary path. [e1441769]

Veritas Cluster Server (VCS) Support

VCS requires that all nodes in the cluster use the same processor architecture and
run the same operating system version. All cluster nodes must be at the same
patch level.

4.1 MP2 Known Issues

VxSS goes into PARTIAL state after getting added to SFMS

Issue Details:

If the customer uses SFMS 5.0 LMH (Legacy Managed Hosts) to manage 4.1 based
systems and if these are secured clusters which have VxSS SG, then the status of
the VxSS service group becomes partial after the cluster nodes are configured as
SFMS clients.

Workaround Steps:

After installing SFMS 5.0 LMH on secured cluster nodes, carry out the following steps:

1. Remove GSS entries from VRTSatlocal.conf file using
/opt/VRTSat/bin/vssregctl -l -D -R 1 -b
"Security\Authentication\Authentication Broker\AtPlugins" -S "gssapi"

2. Change the path entry /opt/VRTSat/bin/pa20_64/vxatd to
/opt/VRTSat/bin/vxatd in main.cf file on all cluster nodes using the
following commands:

a> haconf -makerw
b> hares -modify vxatd PathName /opt/VRTSat/bin/vxatd
c> haconf -dump -makero

3. Start vxatd resource from VCS by using "hares -online vxatd -sys
sysname" command.

4. Configure the system as SFMS LMH.

Daylight Savings Time Change

Information about Daylight Savings Time issues is available at http://support.veritas.com/docs/286461

Addendum to the 4.1 Release Notes for all Veritas Storage Foundation products

Version Number Differences
The version numbers for the VRTSvlic, VRTSvxvm, and VRTSvxfs packages on the HP December 2005 HP-UX 11.23 DVD are higher than those on the 4.1 DVD and this will cause warning messages to be displayed during product installations. Answer "yes/y" instead of the default of "n" when prompted with "Do you want to continue? [y,n,q,?] (n)" during the installation process to work around this issue. For more information, refer to TechNote http://support.veritas.com/docs/282275

Veritas Cluster Server Installation Guide for 4.1 Documentation correction

LLT supports Cluster ID numbers between 0 and 65535

Cluster ID is a unique number that the LLT module uses to identify a cluster.
The LLT module for VCS 4.1 and later supports an integer value between 0 and 65535 for the cluster ID. The LLT configuration file /etc/llttab contains this value.

The Veritas Cluster Server Installation Guide for 4.1 mentions that the cluster ID is an integer between 0 and 255. But LLT actually supports an integer value up to 65535.

Workaround:
Though the installvcs program does not support a cluster id value that is greater than 255, you can manually change the cluster ID value in the /etc/llttab file.
For example, if your /etc/llttab file content is as follows, you can change the line "set-cluster 2" to "set-cluster 50000"

After you edit the /etc/llttab file, you must restart LLT for this change to take effect.

Volume Manager (VxVM) and File System (VxFS) Support for HP Integrity Virtual Machines

Starting with 4.1 VxVM and VxFS are supported to work in an HP-UX 11i v2 and 11i v3 virtual machine in the HP Integrity Virtual Machines environment on all supported HP Integrity Servers.

Addendum to the 4.1 Release Notes for all Veritas Storage Foundation products which require HP-UX OS patches

Patch Bundles

The FEATURE11i patch bundle is available from HP to provide the patches required for this release.

The patches required for Veritas File System are available from HP in a patch bundle called EnableVxFS, rather than EnableVXFS41.

The FEATURE11i and EnableVxFS required patch bundles are available from HP, along with Base-VXVM 4.1 and Base-VXFS 4.1, starting with their 0512 11i v2 Fusion Release.

Optional Patches

The following optional patches are also now available from the HP patch Web site:

PHCO_33509 1.0 VERITAS Volume Manager 4.1 Command Patch 01 SMS Bundle
PHCO_33517 1.0 VERITAS File System Command Cumulative Patch 1 SMS Bundle
PHCO_33522 1.0 VERITAS File System Manpage Cumulative Patch 1 SMS Bundle
PHCO_33691 1.0 VERITAS File System Mgmt Srvc Provider Patch 1 SMS Bundle
PHCO_34038 1.0 VERITAS Volume Manager Provider 4.1 Patch 01 SMS Bundle
PHKL_33510 1.0 VERITAS Volume Manager 4.1 Kernel Patch 01 SMS Bundle
PHKL_33518 1.0 VERITAS File System Kernel Cumulative Patch 1 SMS Bundle
PHKL_33566 1.0 GLM Kernel Cumulative Patch 1 SMS Bundle
PHKL_33586 1.0 ODM Kernel Cumulative Patch 1 SMS Bundle
PHKL_33620 1.0 GMS Kernel Cumulative Patch 1 SMS Bundle
PHNE_33611 1.0.3 LLT Kernel Cumulative Patch 1 SMS Bundle
PHNE_33612 1.0.3 GAB Cumulative Patch 1 SMS Bundle
PHNE_33723 1.0.3 LLT Command Cumulative Patch 1 SMS Bundle
PHCO_34036 1.0 LVM Commands Patch (Co-required for PHKL_33518)

These patches are included with this patch bundle: http://www.hp.com/go/sgsms/patches

These optional patches are recommended for all customers using the 4.1 release of Storage Foundation, Storage Foundation for Oracle, Volume Manager, File System or Volume Replicator.

Do not install Volume Manager patches PHCO_33509, PHKL_33510, and PHCO_34038 on the 4.1 release of Storage Foundation for Oracle RAC or Storage Foundation Cluster File System. All of the other optional patches listed above can be installed.

For Storage Foundation for Oracle RAC, Storage Foundation Cluster File System, or any other product, these Volume Manager patches are now approved and available from the HP Support patch Web site:

PHCO_34811 - VxVM 4.1 Command Cumulative Patch 02
PHKL_34812 - VxVM 4.1 Kernel Cumulative Patch 02
PHCO_35465 - VERITAS VM Provider 4.1 Patch 02

For Storage Foundation for Oracle RAC, Storage Foundation Cluster File System, or any other Storage Foundation product, these File System patches are now approved and available from the HP Support patch Web site:

PHKL_35430
PHCO_35431

Each node must be at the same patch level and cluster nodes running at different patch levels is not a supported configuration. The installation of these patches will perform an automatic reboot of each node. For patch installation instructions, refer to TechNote 282311, found below, in the Related Documents section.

HP has released patch PHKL_34010 to fix a virtual memory management problem and this patch is now recommended for all Storage Foundation 4.1 for Oracle RAC and Storage Foundation Cluster File System 4.1 customers. For more information, refer to TechNote 277395, found below, in the Related Documents section.

For more information on downloading and installing patches from the ITRC HP Web site, see DocId: KBRC00014314 on the HP Support Web site and refer to these TechNotes in the Related Documents section below:

How to install Volume Manager and File System patches when running Storage Foundation for Oracle Real Application Cluster or Storage Foundation Cluster File System - TechNote 282311
Patch installation procedure for Storage Foundation for Oracle - TechNote 283636

Superseded Patches

The 4.1 installation script will exit when a required patch is not installed, even if a superseded patch is installed. The updated fix for this issue is at http://support.veritas.com/docs/292511

Node and Host Name Expansion

As part of the Software Pack (SPK) for HP-UX 11i v2 of May 2005, HP provided an optional Node and Host Name Expansion (NodeHostNameXpnd) product bundle, revision B.11.23.01. This product bundle provides customers with the capability to set node and host names up to 255 bytes. The current limitation is 8 bytes for node names and 64 bytes for host names.
Installation of this product bundle does not automatically activate 255 byte length support for node and host names. The default OS configuration will still be 8 bytes for node names and 64 bytes for host names. A dynamic kernel tunable parameter, expanded_node_host_names, must be enabled via the kctune(1M) command to allow the use of larger names on the system.

However, Veritas Storage Foundation 4.1 products for HP-UX have not been tested with the Host Name Expansion bundle and therefore do not support Node and Host Name Expansion.

Addendum to the 4.1 Release Notes for all Veritas Storage Foundation products containing Veritas Enterprise Administrator (VEA)

The following required Veritas Enterprise Administrator patches were not listed in the 4.1 release user documentation:

      PHCO_33078
      PHCO_33079

However, these patches are included in the product distributions and are installed with other Veritas patches when using the product installer or installation scripts.

Addendum to the Release Notes for Veritas Cluster Server 4.1

The 4.1 fixed issues and software enhancements are referenced by Veritas incident number and described briefly below:

267994 Changing a Group from Parallel to Failover Puts Cluster in STALE_ADMIN_WAIT

In a cluster running VCS 3.5, converting a parallel service group to
a failover service group puts all nodes in the STALE_ADMIN_WAIT state.
HAD dies on all nodes and produces a core file when bringing the node
online.

294966 Modify Handling of Vector or Associative Attributes in main.cf

The hacf utility does not handle dynamic modification of vector or
associative attributes that exceed the maximum number of arguments.
When VCS is running, such attribute modifications do not affect the
current status. However, if VCS is brought down and brought up again,
HAD goes into the ADMIN_WAIT state.

Addendum to the Release Notes for Veritas Storage Foundation (tm) 4.1 for Oracle and Storage Foundation (tm) 4.1 for Oracle RAC
Oracle can use RAW files for data files, control files and redo logs. Normally, the SQL 'REUSE" clause is ignored if the associated file is a RAW file. From Oracle 10g onwards, when Oracle Disk Manager (ODM) is enabled, the "REUSE" clause of SQL is mandatory. If ODM is not enabled, the "REUSE" clause is ignored for both Oracle9i and Oracle 10g.
See TechNotehttp://support.veritas.com/docs/283362 for more information

Addendum to the Release Notes for Veritas Storage Foundation 4.1 for Oracle RAC

Oracle 10g Support

The 4.1 MP1 release includes support for Oracle 10g and it includes bugs fixes for 9i customers. To obtain the 4.1 MP1 release, refer to TechNote 278855, found below, in the Related Documents section.
To view the Storage Foundation for Oracle RAC Supportability Matrix, refer to TechNote 280186, found below, in the Related Documents section.

New in Storage Foundation for Oracle/RAC (SFRAC) 4.1 MP1 PP1

Oracle 10g R2 support is added for SFRAC 4.1
Oracle 9.2.0.7 support is added for SFRAC 4.1
Oracle Clusterware can be started and stopped through Veritas Cluster Server

Refer to TechNote 284581, found below in the Related Documents section, for more information

4.1 linkrac9i script for IA64 fails

The linkrac9i script that comes with Veritas Storage Foundation for Oracle RAC 4.1 for HP-UX is used to link Oracle binaries with Veritas libraries. For IA64, the linkrac9i script fails with the error:

ERROR: Oracle binary not linked with Veritas IPC library

That is, even after executing the linkrac9i script, the Oracle binary will still use the Oracle UDP library for inter-process communication.

If you ignore the error and proceed, the consequences are:

Case 1 - CLUSTER_INTERCONNECTS specified in the pfile.
The Oracle IPC traffic will go over the interfaces specified in the pfile. This is likely to be over a private network.

Case 2 - CLUSTER_INTERCONNECTS not specified in the pfile.
The Oracle IPC traffic will go over the public network.

Workaround:

The bug in the linkrac9i script has been fixed in the 4.1 MP1 release. To obtain the 4.1 MP1 release, refer to TechNote 278855, found below, in the Related Documents section.

The workaround below was used before 4.1 MP1 was released.

If the Oracle binaries are on a cluster file system, then perform these steps on only one node. If the Oracle binaries are on a local file system of each cluster node, then perform these steps on each cluster node.

1. Log in as oracle user

2. Stop all the Oracle processes

3. Change directory to ORACLE_HOME/lib:
$ cd ${ORACLE_HOME}/lib

4. Back up the Oracle UDP library:
$ cp libskgxpu.so libskgxpu.so.oracle

5. Copy the VERITAS IPC library to ORACLE_HOME/lib:
$ cp /opt/VRTSvcs/rac/lib/hpux64/libskgxp92.so libskgxpu.so

6. Run the linkrac9i script:
$ /opt/VRTSvcs/rac/bin/linkrac9i

Ensure that the following error does not appear in the script output:
ERROR: Oracle binary not linked with Veritas IPC library.

7. Copy the Oracle UDP library back to the original location:
$ cp libskgxpu.so.oracle libskgxpu.so

After starting Oracle instances, confirm that Oracle uses the Veritas libraries. Examine the Oracle alert file alert_$ORACLE_SID.log in the bdump directory for the following lines:

Oracle instance running with ODM: VERITAS 4.1 ODM Library, Version 1.0
cluster interconnect IPC version: VERITAS IPC 4.1

Note: If Oracle binaries are on a local file system of each cluster node, then examine the Oracle alert file on each cluster node

If you are about to install Oracle, then perform the above steps when linking Oracle to Veritas libraries. See Chapter 4 "Installing Oracle9i Software" in the Veritas Storage Foundation for Oracle RAC Installation and Configuration Guide

LMX could cause Oracle to core dump

A bug in LMX could cause Oracle to core dump and generate the following errors. LMX complains with either EALREADY or ENOENT errors, which in turn causes Oracle to throw errors.

ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-27510: IPC error waiting for a request to complete
ORA-27300: OS system dependent operation:poll: FAILED, errno 244 [Operation failed with status: 244]
ORA-27301: OS failure message: Operation already in progress
ORA-27302: failure occurred at: vcsipc_poll
ORA-27303: additional information: poll: FAILED, errno 244 [Operation already in progress]

Workaround:

LMX triggers these errors if async I/O thread is enabled in LMX/IPC. Therefore, disable the thread using lmx or ipc config

Note: The workaround might cause a degraded performance.

To disable the thread:

1. Shut down Oracle

2. Unconfigure LMX module:

# /sbin/lmxconfig -U

3. Unload LMX module:

# /usr/sbin/kcmodule lmx=unused

4. Set lmx_update_enabled to 0:

# /usr/sbin/kctune lmx_update_enabled=0

5. Reload and restart LMX module:

# /sbin/init.d/lmx start

6. Verify that the "async i/o update thread" is off:

# /opt/VRTSvcs/rac/bin/lmxshow -t

llt_bport: 11

llt_pport: 10

minor_max: 8192

port_max: 4096

buffer_max: 4096

msgbuf_max: 32768

update_enabled: 0 <========= should be "ZERO"

bdel_max: 65535

pdel_max: 512

7. Restart Oracle and LMX

4.1 Fixed Issues

The 4.1 fixed issues and software enhancements are referenced by Veritas incident number and described briefly below:

259566 VCSMM Driver Overwrites User Buffer And References Deallocated Memory

Attempts to shut down Oracle may cause vcsmm to panic each host when Oracle
slaves deregister with the vcsmm module.

310117 Race in lmxdelbuf causes Rare Panic

During buffer copies in the lmx driver, a bug may generate a rare panic
because of access to freed memory.

4.1 MP1 Fixed Issues

To see the fixed issues for the 4.1 MP1 release, refer to TechNote 278855, found below, in the Related Documents section.

Addendum to the Release Notes for Veritas Storage Foundation 4.1

The following incidents are fixed in Veritas Storage Foundation 4.1 for Oracle for HP-UX:

122708
Previously, running the dbed_checkconfig command or displaying database information using the VxDBA utility resulted in an incorrect warning message stating that the database is not running in automatic log archiving mode even when it actually is. This has been fixed.

212189
The error "DBED4267: ERROR: The VxDBA repository does not exist" incorrectly shows up in vxisis.log file. This fix removes that error.

230445
When vxsnapadm printed an alert, dbed_vmchecksnap would fail when it treated the word 'alert' as one of the volume names. This has been fixed.

236259
Executing "dbed_vmchecksnap -o list -f filename" removed the mnttablist file from the repository, which made dbed_vmsnap resync operations fail. This problem has been fixed.

260671
Previously, Storage Checkpoint information stored in the VxDBA repository was not carried over with snapshot volumes to the secondary host. This has been fixed.

On the secondary host, you can list the Storage Checkpoints carried over from the primary database using:

dbed_ckptdisplay -S ORACLE_SID -n

You can mount one of the listed Storage Checkpoints using:

dbed_ckptmount -S ORACLE_SID -c CKPT_NAME -m MOUNT_POINT

The following limitations apply:

- Any mounted Storage Checkpoints must be unmounted before running the following commands:

dbed_vmsnap -S ORACLE_SID -f SNAPPLAN -o reverse_resync_begin

dbed_vmclonedb -o umount,new_sid=new_sid -f SNAPPLAN

- It is only possible to mount a Storage Checkpoint carried over with the snapshot volumes in a two-host configuration if the snapshot volumes were mounted with the dbed_vmclonedb command with the -o mount option without the use of -r relocate_path.

- Storage Checkpoints carried over with the snapshot volumes can be mounted before a clone database is created using dbed_vmclonedb with the -o mount option. After a clone database is created using dbed_vmclonedb with the -o recoverdb option, however, Storage Checkpoints are no longer present.

- After running dbed_vmsnap -o reverse_resync_commit, Storage Checkpoints created on the original database or on the clone database are deleted.

354745
Renaming columns in login.sql sometimes caused scripts to fail or produce incorrect results. This has been fixed. To further prevent this, make the following changes in the user environment to generally avoid loading login.sql:

1. Move login.sql to another directory, for example, to ~oracle/login.sql.

2. Make sure this new directory is included in SQLPATH, for example:

export SQLPATH=~oracle/sql:$SQLPATH

Do not make SQLPATH read-only, so that Storage Foundation for Oracle scripts can unset it at runtime.

4. Avoid starting Storage Foundation for Oracle scripts from the directory where login.sql resides, unless you are sure that login.sql does not contain any settings or commands that change the default output for queries against the data dictionary or increase the startup time for SQL*Plus.

Also avoid using any settings or commands in the glogin.sql file that change the default output for queries against the data dictionary, or that may increase the startup time for SQL*Plus.

355447
A non-root user was able to manage resources in VEA only if that user's primary group was added to the VEA Registry using the vxdbedusr command. Now a non-root user is able to manage resources in VEA if any one of the groups the user belongs to is added to the Registry with vxdbedusr.

376730
In locales that use a comma as a decimal point separator instead of a period, Database Flashsnap failed with the error "ORA-6502:invalid number conversion." This has been fixed.

The following incidents are fixed in Veritas Volume Manager 4.1 for HP-UX:

155733
The VxVM configuration daemon (vxconfigd) dumped core due to failure in memory allocation during device discovery. This condition has been corrected.

229535
The VxVM configuration daemon (vxconfigd) could hang if the /etc/vx/array.info file had become corrupted by the inclusion of incorrect enclosure names. The file is now regenerated if errors are found in it.

275716
A panic occurred if a relayout was attempted on a layered volume that contained a data change object (DCO) on one of its subvolumes. Relayout of layered volumes is now disallowed unless any DCOs are removed from their subvolumes.

301772
The vxplex command could dump core when used to take a snapshot. This condition has been corrected.

330376
Creating a shadow-image pair on an HDS 95XX or 99XX series array could cause VxVM to see the images as two disks with the same disk ID. This condition has been corrected.

330379
Disk group move and join operations could fail if there had previously been a high frequency of write operations to the volumes in the disk groups. This condition has been corrected.

330380
Attempting to stop the DMP restore daemon using the vxdmpadm stop restore command resulted in the command hanging, and the failure of any pending path restoration or failover. This condition has been corrected.

330381
When using DMP to control LUN failover on an EMC Clariion array, invoking a format operation or the vxdctl enable command could cause a trespass on a secondary path and delay I/O operations. This condition has been corrected.

333176
The vxdestroy_lvmroot command did not work correctly. This condition has been corrected.

339253
Conversion of a LVM volume group failed if the Volume Group Descriptor Area (VGDA) had become corrupted. The conversion process now attempts to locate a valid secondary copy of the VGDA.

353355
The addition or removal of an array support library (ASL) followed by the invocation of the vxdctl enable command, or the restart of the VxVM configuration daemon (vxconfigd) could sometimes cause the system to panic if this resulted in DMP devices being migrated from one array category to another. This condition has been corrected.

353568
An attempt by the VxVM configuration daemon (vxconfigd) to perform an I/O operation on a closed device could cause the system to panic. This condition has been corrected.

The following incidents are fixed in Veritas File System 4.1 for HP-UX:

i137091
In previous releases of Veritas File System, bcheckrc would exit into the bootup shell if it encountered iSCSI devices. This issue has been fixed.

i141471
In previous releases, mounting a VxFS File System written on an 8K sector device was not possible. This release provides support for VxFS File Systems on 8k sector devices.

i147749
Previously, getdents could return with missing entries after a dirblock compression because a full 8k of dirblock entries could not fit into the 8k buffer supplied by getdents. In this situation, getdents would have to obtain the remaining entries from the readdir codepath. However, readdir would not always report all entries and would return EINVAL. This issue has been fixed.

i148486
Previously, when fsck -n pass4 found the first iau summary mismatch, it would continue to loop without advancing iaucp to the
next entry, causing subsequent iau summary comparisons to be incorrect. This issue has been fixed.

i148994
Previously, local mount stress testing of Veritas File System on a PA machine running HP-UX 11.23 would result in hitting f:vx_fbrelse_bp:1c. This issue has been fixed.

i149564
Previously on HP-UX 11.23, noise.replay would exit since fsck could not replay cleanly. This issue has been fixed.

i151122
Previously, files opened for fdd access would cause Oracle Disk Manager threads to hang. This issue has been fixed.

i152189
Previously, Veritas File System would sometimes panic when two threads both attempted to set the ml_flag value. The panic would result in the following error message: panic: unresolved kernel interruption. This issue has been fixed.

i151459
Previously in Cluster File System, the calls GLM_API_UNREGISTER and GAB_API_UNREGISTER were called in the incorrect order. The order has been corrected.

i152909
Previously on HP-UX 11.23, Cluster File System and Cluster Volume Manager would hang due to a memory leak in fdd_sio_free(). This issue has been fixed.

Addendum to the Release Notes for Veritas Volume Replicator (VVR) 4.1

VVR support with HP ServiceGuard is not available in the 4.1 release. The VVR 4.1 documents incorrectly mention that VVR is supported with HP ServiceGuard.

The following incidents are fixed in Veritas Volume Replicator 4.1 for HP-UX:

332121
Functions should be called after holding the spin
      lock. However, due to a bug in the code, a function was
      being called without holding a spin lock. Trying to release
      a lock when it is not being held caused the system to panic.

332118
Trying to resume the replication, caused the system
      to panic because the concerned function was accessing
      a parameter even though its value was set to NULL.


332138
The netd ports (4145 tcp/udp) were not getting closed.
      Trying to restart netd therefore fails, as port 4145
      already seemed to be in use.

332127
Race condition between vol_rv_async_start and
      vol_rv_connect_done resulted in memory corruption
      or panic.

332125
Flow control depends on the vol_rp_increment and
      vol_rp_decrement parameters. The value for these
      parameters has been changed from 1 to 8 because the
      earlier value was not optimal in case of lossy networks
      and affects the performance, adversely. The
      new value gives better performance in case of lossy
      networks but does not cause any regression in case
      of loss-less networks.

332130
Trying to dissociate the volume using the command
      vxvol dis vol_name displayed the following error:
      vxvm:vxvol: ERROR: Rvg (rvg_name) is started.
      This happened even if the RLINKs were dissociated
      or detached.

213213
On HP-UX, all the vxiod threads are started at once
      as opposed to one at a time, on other platforms. Starting
      all voliod threads when only one is required, resulted in
      the Thundering Herd problem causing too many context
      switches and very high CPU usage.

332134
Promoting a Secondary that is in IBC freeze state to a
      Primary, resulted in inconsistency between the data
      volumes on the Primary and Secondary. This occurred due to
      the SRL header initialization during the role change.

332142
Negative error codes returned by functions
      are considered to be errors and are handled
      appropriately. However, in some cases the functions
      returned positive error codes and error handling for
      these was not done.

332144
The vxrecover command failed to recover volumes for
      an RVG having both gen and fsgen volumes.

304173
The t_kunbind function should be called
      only when the TLI state is T_IDLE.
      Not doing so caused the VxVM commands to hang

157975
Trying to restart replication, when there were some
      pending updates on the Primary or if some network
      problems were encountered during restart, caused
      the Primary to Panic as a message from earlier
      connection was accepted and processed.

137839
Executing vxrlink -f att on the Primary caused it
      to panic.

309669
The network messages were not being queued in the
      proper order resulting in messages being sent to
      the Secondary out of order, causing unnecessary
      problems during replication.
      These out of order messages resulted in no memory
      messages on the Secondary because the incoming
      messages buffer would be full with messages of a
      different generation.

310173
The VxVM configuration daemon (vxconfigd) could
      go into a cyclic loop if the free_updateq contained
      updates having non-zero update reference count.

310171
Due to a deadlock while calling the untimeout function,
      nmcom_sender thread did not exit causing all further
      VxVM commands to hang.

Addendum to the Release Notes for Veritas Storage Foundation Cluster File System 4.1

Veritas Storage Foundation Cluster File System 4.1 Administration and Installation Guide step 3 in the "Adding a Node" section on page 49 is incorrect.

It should read as follows:

3. If there are any dependencies, take them offline on all the nodes:

# hagrp -offline cvm -sys system01
# hagrp -offline cvm -sys system02

CSSD agent mandatory for SF Oracle RAC installations

You must configure the CSSD agent after installing Oracle Clusterware. The CSSD agent starts, stops, and monitors Oracle Clusterware. It ensures that the OCR, the voting disk, and the private IP address resources required by Oracle Clusterware are online before Oracle Clusterware starts. Using the CSSD agent with SF Oracle RAC installations thus ensures adequate handling of inter-dependencies and prevents premature startup of Oracle Clusterware.

During system startup, the Oracle Clusterware init scripts invoke the clsinfo script provided by Veritas software. The clsinfo script ensures that the OCR, the voting disk, and the private IP address resources are online before the cssd resource comes online. After the underlying resources come online, the CSSD agent starts Oracle Clusterware.

During system shutdown, the agent stops Oracle Clusterware before the OCR and voting disk resources are taken offline. This ensures that Oracle Clusterware does not panic the nodes in the cluster due to unavailability of the required resources.

Products Applied:
Cluster Server for UNIX 4.1 (HP-UX), 4.1 MP2 (HP-UX)
File System for UNIX/Linux 4.1 (HP-UX), 4.1 MP2 (HP-UX)
Storage Foundation Cluster File System 4.1 (HP-UX), 4.1 MP2 (HP-UX)
Storage Foundation for Oracle 4.1 (HP-UX), 4.1 MP2 (HP-UX)
Storage Foundation for Oracle Real Application Clusters 4.1 (HP-UX), 4.1 MP1 (HP-UX), 4.1 MP1 (HP-UX)x 4.1MP1u, 4.1 MP2 (HP-UX)
Storage Foundation for UNIX/Linux 4.1 (HP-UX), 4.1 MP2 (HP-UX)
Volume Manager for UNIX/Linux 4.1 (HP-UX), 4.1 MP2 (HP-UX)
Volume Replicator 4.1 (HP-UX), 4.1 MP2 (HP-UX)

Last Updated: January 12 2010 09:55 PM GMT
Expires on: 01-11-2011

Subscribe to receive critical updates about this document

Subjects:
Cluster Server for UNIX
   Application: Informational
   Publishing Status: Documentation, Manuals
File System for UNIX/Linux
   Application: Informational
   Publishing Status: Documentation, Manuals
HP-UX
   Application: Informational
Storage Foundation Cluster File System
   Application: Information
   Publishing Status: Documentation, Manuals
Storage Foundation for Oracle
   Application: Informational
   Publishing Status: Documentation, Manuals
Storage Foundation for Oracle Real Application Clusters
   Application: Informational
   Publishing Status: Documentation, Manuals
Storage Foundation for UNIX/Linux
   Application: Informational
   Publishing Status: Documentation, Manuals
Volume Manager for UNIX/Linux
   Application: Informational
   Publishing Status: Documentation, Manuals
Volume Replicator
   Application: Informational
   Publishing Status: Documentation, Manuals

Languages:
English (US)

Operating Systems:
HP-UX

11i v2 (IA64), 11i v2 (PA-RISC)

Symantec World Headquarters:
20330 Stevens Creek Blvd. Cupertino, CA 95014
World Wide Web: http://www.symantec.com,
Tech Support Web: http://entsupport.symantec.com,
E-Mail Support: http://seer.entsupport.symantec.com/email_forms,
FTP: ftp://ftp.entsupport.symantec.com or http://ftp.entsupport.symantec.com

THE INFORMATION PROVIDED IN THE SYMANTEC SOFTWARE KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. SYMANTEC SOFTWARE DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SYMANTEC SOFTWARE OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES,EVEN IF SYMANTEC SOFTWARE OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.