Document ID: 281987
http://support.veritas.com/docs/281987
E-Mail this document to a colleague
http://support.veritas.com/docs/281987
E-Mail this document to a colleague
Late Breaking News (LBN) - Latest additions to the Release Notes for Veritas Storage Foundation and High Availability 5.0, 5.0 Maintenance Pack 1 (MP1), and Maintenance Pack 3 (MP3) for Solaris (SPARC)
Details:
To locate the most current product patch releases including Maintenance Packs, Rolling Patches, and Hot Fixes visit https://vos.symantec.com/patch/matrix
Documentation
5.0 MP3 Documentation List http://entsupport.symantec.com/docs/307509
5.0 MP1 Documentation List http://entsupport.symantec.com/docs/307438
5.0 Documentation List http://support.veritas.com/docs/307436
Product documentation, man pages and error messages for the 5.0 and 5.0 MP3 releases are available at http://sfdoccentral.symantec.com/index.html
Downloads
5.0 Maintenance Pack 3 for Solaris is available at https://fileconnect.symantec.com
5.0 Maintenance Pack 3 Rolling Patch 1 for Solaris Sparc is available at http://entsupport.symantec.com/docs/316671
The latest patches are available on Patch Central https://vias.symantec.com/labs/patch
Tools
VOS (Veritas Operation Services) Portal: https://vos.symantec.com
VOS Portal Contains:
Forums
Discuss support issues and find solutions in the Support Forums:
Storage Management Forums http://www.symantec.com/connect/storage-management/forums
Clustering and Replication Forums http://www.symantec.com/connect/clustering-and-replication/forums
Support of ZFS Root Devices
The 5.0 version of Storage Foundation is supported on servers with ZFS root devices, however care must be taken to ensure that devices managed by ZFS are excluded from being managed by Storage Foundation. ZFS root disk encapsulation is not supported by this version of storage foundation. Running ZFS on top of DMP or Veritas Volume Manager is not supported in this release. The 5.1 version of Storage Foundation includes functionality to detect and protect ZFS devices and is recommended when ZFS will be used on devices not specifically used for root functionality.
Multiple product versions per server: Licensees of Storage Foundation/High Availability (SFHA) products may run different versions of (SFHA) products on different virtual machines in the same physical server/CPU, provided that the versions of the SFHA products are still supported by Symantec Corporation.
SF Basic Virtual Machine Entitlements: Licensees of Storage Foundation Basic products may use a maximum of 4 volumes and 4 file systems per virtual machine. Storage Foundation Basic can only be used on a server that has a maximum of 2 CPU's.
Addition to all Release Notes:
For all Veritas Storage Foundation 5.0 Release Notes
On a Solaris system with root disk encapsulated and mirrored, if a third party driver (TPD) driver like mpxio is
doing the multipathing, the following steps are required to boot from the mirrored boot disk (Example below):
A. Procedure to boot from the mirrored boot disk when system is still running:
1. Locate the mirror disk device
# vxprint -g bootdg
dm rootdisk c8t20000011C637214Fd0s2 - 143278080 - - - -
dm rootmir c8t20000011C637232Cd0s2 - 143278080 - - - -
2. Determine the TPD mirror path
# ls -l /dev/dsk/c8t20000011C637232Cd0s0
lrwxrwxrwx 1 root other 47 Oct 21 09:33 /dev/dsk/c8t20000011C637232Cd0s2 ->
../../devices/scsi_vhci/ssd@g20000011c637232c:a
3. Set the 'dmp_tpd_root_device' tunable in the vxdmp.conf to
the mirror device path:
# vi /kernel/drv/vxdmp.conf
#
# comment out 'dmp_tpd_root_device' for boot device:
#
# dmp_tpd_root_device="/scsi_vhci/ssd@g2000000087146f57:a";
#
# set 'dmp_tpd_root_device' to mirror device:
dmp_tpd_root_device="/scsi_vhci//ssd@g20000011c637232c:a";
4. Boot from mirror device
NOTE: It is recommended to set the 'dmp_tpd_root_device' tunable
settings in the vxdmp.conf file after the mirror operation completes.
The 'dmp_tpd_root_device' tunable setting can be commented/uncommented
as needed.
B. Procedure to boot from the mirrored boot disk when system is not running:
1. boot system to single user mode from cdrom:
# boot cdrom -s
or from network:
# boot net -s
2. mount the mirror device
# mount /dev/dsk/c8t20000011C637232Cd0s0 /a
3. Determine the TPD mirror path
# ls -l /mnt/dev/dsk/c8t20000011C637232Cd0s0
lrwxrwxrwx 1 root other 47 Oct 21 09:33 /mnt/dev/dsk/c8t20000011C637232Cd0s2
-> ../../devices/scsi_vhci/ssd@g20000011c637232c:a
4. Set the 'dmp_tpd_root_device' tunable in the vxdmp.conf to
the mirror device path:
# ksh
# export TERM=vt100
# vi /mnt/kernel/drv/vxdmp.conf
#
# comment out 'dmp_tpd_root_device' for boot device:
#
# dmp_tpd_root_device="/scsi_vhci/ssd@g2000000087146f57:a";
#
# set 'dmp_tpd_root_device' to mirror device:
dmp_tpd_root_device="/scsi_vhci//ssd@g20000011c637232c:a";
5. boot the mirror
# umount /a
# shutdown -g0 -i0 -y
ok> boot <mirror_devalias>
For all Veritas Cluster Server (VCS) Release Notes
VCS requires that all nodes in the cluster use the same processor architecture and
run the same operating system.
All nodes in the cluster must run the same VCS version. Each node in the cluster
may run a different version of the operating system, as long as the operating
system is supported by the VCS version in the cluster.
Daylight Saving Time Issues
For information about Daylight Saving Time issues, refer to this technote: http://support.veritas.com/docs/286461
NetApp Solaris sparc 5.0 MP3 SSI mode support with qLogic HBA
Under heavy load, it has been observed that i/o response time may exceed
137 seconds.
To workaround that issue, you need to set 2 tunable parameters.
Example:
1. dmpnetapp reconf_time.
To change the apm reconf time use "vxdmpadm cfgapm dmpnetapp reconf_time=0"
to check the reconf time, you will see a message in the messages file:
Apr 3 10:52:25 s445sb1 dmpnetapp: [ID 998758 kern.notice] NOTICE: dmpnetapp_da_configure_apm setting netapp_filer_reconf_time to 0
Other option is to use adb :
# adb -kw
physmem fb360
netapp_filer_reconf_time/D
netapp_filer_reconf_time:
netapp_filer_reconf_time: 0
$q
***Special Note: The setting for this tunable is not persistent across reboot.
Please reset this tunable after the system is rebooted.
2. dmp restore daemon interval time.
To set the dmp restore deamon interval time to 60 seconds instead of the default
of 300 seconds.
# vxdmpadm stop restored
# vxdmpadm start restored interval=60
To check to make sure that the interval is correctly set:
# vxdmpadm stat restored
The number of daemons running : 1
The interval of daemon: 60
The policy of daemon: check_disabled
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.
Recommendations on use of Space-Optimized (SO) snapshots in Storage Foundation for
Oracle RAC 5.0
If you use Volume Manager mirroring, Space-Optimized (SO) snapshots are recommended for Oracle data volumes.
Keep the Fast Mirror Resync regionsize equal to the database block size to reduce the copy-on-write
(COW) overhead.
Reducing the regionsize increases the amount of Cache Object allocations leading to performance overheads.
Do not create Oracle redo log volumes on a space-optimized snapshot.
Use "third-mirror break-off" snapshots for cloning the Oracle redo log volumes.
Permission issues while applying Oracle Bundled Patches
While applying an Oracle bundled patch to Oracle Clusterware (CRS),
at the step when you execute prepatch.sh script with oracle user,
the following error is displayed.
chmod: can't change <ORA_CRS_HOME>/css/admin/init.cssd: Not owner
Workaround:
The solution is to change the owner of init.cssd file as oracle user
before applying Oracle bundled patches to Oracle Clusterware.
$ chown <oracle user>:<oracle group> <ORA_CRS_HOME>/css/admin/init.cssd
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]
VEA service takes a long time to start
VEA service takes a long time to start if the configuration contains large number of LUNs (1403191)
In configurations with large numbers of LUNS which need to be discovered, the VEA service may take a long time to start. The long start-up time may cause the boot time to be longer than is allowed.
Workaround:
The solution is to start the VEA service in the background, so that the boot continues while the LUNs are discovered.
To start the VEA service in the background:
1. Edit the VEA start-up script.
For Storage Foundation 5.x, use the following command:
# edit shell script /opt/VRTSobc/pal33/bin/vxpalctrl
2. In the start_agent() function, add the following line:
exit 0
Before the lines:
max=10
count=0
Support for Branded Zones
Support for Branded Zones is now documented at http://entsupport.symantec.com/docs/315575
and the required patch is available at http://entsupport.symantec.com/docs/309206
Veritas Cluster Server Agent Support Matrix
The Veritas Cluster Server Agents Support Matrix is available at http://www.symantec.com/business/products/agents_options.jsp?pcid=psc_disaster_recov&pvid=20_1
Oracle 11gR1 RAC Support
Oracle 11gR1 RAC (11.1.0.7) is now supported with the 5.0 Maintenance Pack 3 (5.0MP3) version of Storage Foundation For Oracle RAC for Solaris 9 and Solaris 10.
SF Oracle RAC 5.0 MP1 requires the point patch 5.0MP1+e1221809a for Oracle RAC 11g Release 1. The patch is available for download at http://entsupport.symantec.com/docs/303872
Version 5.0 Maintenance Pack 3 (MP3) Rolling Patch 2 (RP2):
Errata for the Veritas Storage Foundation 5.0 MP3 RP2 Read This First document
In the upgrade procedures, the list of patches with the patchadd command for Storage
Foundation on Solaris 8, 9, and 10 SPARC contains some incorrect patch numbers.
Use the corrected procedure below.
On pages 63, 70, 86, and 99, the patchadd command should be as follows:
* For Storage Foundation on Solaris 8 SPARC:
# patchadd -M patch_dir 122058-12 123200-05 123722-02 \
123823-05 139354-01 139356-02 139737-01 139739-01 \
139741-02 139742-02 139743-01 139744-01 140657-01 \
140661-01 141279-01 141745-01
* For Storage Foundation on Solaris 9 SPARC:
# patchadd -M patch_dir 122058-12 123201-05 123722-02\
123823-05 139354-01 139357-02 139737-01 139739-01\
139741-02 139742-02 139743-01 139744-01 140657-01\
140661-01 141279-01 141745-01
* For Storage Foundation on Solaris 10 SPARC:
# patchadd -M patch_dir 122058-12 123202-05 123722-02 \
123823-05 139354-01 139358-02 139359-02 139737-01 \
139739-01 139741-02 139742-02 139743-01 139744-01 \
140657-01 140661-01 141279-01 141745-01
In addition - the patch number included in the installation media is incorrectly numbered in ALL occurrences.
Patch number 139362-01 should be changed to 139362-02 on pages 51, 56, 65, 70, 79, 80, 87, 95, 96, 100, 110.
Patch number 139367-01 should be changed to 139367-02 on pages 52, 70, 79, 80, 87, 95, 96, 100, 110.
Version 5.0 Maintenance Pack 3 (MP3) Rolling Patch 1 (RP1):
Veritas Storage Foundation and High Availability Solutions 5.0 Maintenance Pack 3 Rolling Patch 1 is now available
Veritas Storage Foundation (tm) and High Availability Solutions 5.0 Maintenance Pack 3 Rolling Patch 1 Read This First - Solaris
http://entsupport.symantec.com/docs/316673
Veritas Storage Foundation (tm) and High Availability Solutions 5.0 Maintenance Pack 3 Rolling Patch 1 - Solaris Sparc
http://entsupport.symantec.com/docs/316671
For all products that use Veritas Volume Manager, the vxdiskadm utility fails to replace a failed or removed non-root disk (1434779)
The vxdiskadm utility fails to replace a failed or removed disk using the options:
4 Remove a disk for replacement
5 Replace a failed or removed disk
This issue is specific to the replacement of a non-root disk.
An error message displays similar to the following example:
VxVM ERROR V-5-2-281
Replacement of disk rootdg02 in group rootdg with device c1t1d0
VxVM vxdg ERROR V-5-1-559 Disk rootdg02: Name is already used
Replace a different disk? [y,n,q,?] (default: n)
Workaround:
Replace the disk using the following command:
# vxdg -g $repldgname -k adddisk $repldmname=$repldaname
For example:
vxdg -g rootdg -k adddisk rootdg02=c1t1d0
This issue is seen in the following releases:
5.0 MP3 RP1
The issue will be fixed in the following releases:
5.0 MP3 RP2
Storage Foundation Cluster File System and Storage Foundation for Oracle Real Application Clusters Kernel memory leak
A Kernel memory leak occurs after upgrading to Veritas Volume Manager 5.0 MP3 RP1 for Solaris in a Cluster environment:
http://entsupport.symantec.com/docs/317647
Additions to the Veritas Storage Foundation and High Availability Solutions Read This First for 5.0 MP3 RP1 document:
Software Limitations section
Veritas Cluster Server (VCS) known issue:
Ignore certain warning messages on nodes that run VCS on Solaris 10 update 6 with a ZFS root file system
You can safely ignore the following warning messages on systems that run VCS on Solaris10 update 6 that have the ZFS root file system [1466460]:
"unix: [ID 338433 kern.notice] vn_rdwr failed with error 0x15"
"unix: [ID 689466 kern.notice] kobj_load_module: read header failed"
Storage Foundation for Oracle RAC known issue:
Joining a new node to the cluster may fail [1390591]
If you have a RAC cluster that has fencing enabled and a Sun StorageTek 2540 machine configured in A/PF mode, joining a new node to the cluster may fail if the cluster has a failover in progress.
Workaround
There is no known workaround at this time, check back for the latest status.
Version 5.0 Maintenance Pack 3 (MP3):
5.0 Maintenance Pack 3 for Solaris is available at https://fileconnect.symantec.com
The Veritas Volume Manager 5.0 Maintenance Pack 3 SmartMove Hot Fix 1 for Solaris (SPARC) is available at http://entsupport.symantec.com/docs/311468
The Veritas Cluster Server 5.0 Maintenance Pack 3 Hotfix 1 for Solaris (SPARC) is available at:
http://entsupport.symantec.com/docs/311938
This Hotfix fixes the below issues:
VRTSvcs
1404384: HAD crashing when switching over a global group when PreSwitch is TRUE.
1397692: VCS engine clients hang in connect() if the target system is down
1414219 HostMonitor objects:
HostMonitor objects are internal-use only. While these objects appear in the UI for the 5.0 MP3 release, in later releases these objects are not displayed.
The Storage Foundation Simple Admin 1.0 for Solaris is available at http://entsupport.symantec.com/docs/303625
Incorrect Oracle bug id in the 5.0MP3 Release Notes for Solaris
In the section "Support for new database", the Oracle bug id is incorrect. The correct text is as follows:
For 11g on Solaris:
If you are using ODM and and plan to use the init_ora "memory_target", you
must apply the patch for Oracle bug 6647246.
NetApp Solaris Sparc 5.0 MP3 SSI mode support with qLogic HBA
Under heavy load, it has been observed that i/o response time may exceed 137 seconds.
To workaround that issue, you need to set 2 tunables parameters.
1. dmpnetapp reconf_time.
To change the apm reconf time use "vxdmpadm cfgapm dmpnetapp reconf_time=0"
to check the reconf time, you will see a message in the messages file:
Apr 3 10:52:25 s445sb1 dmpnetapp: [ID 998758 kern.notice] NOTICE: dmpnetapp_da_configure_apm setting netapp_filer_reconf_time to 0
Other option is to use adb :
# adb -kw
physmem fb360
netapp_filer_reconf_time/D
netapp_filer_reconf_time:
netapp_filer_reconf_time: 0
$q
***Special Note: The setting for this tunable is not persistent across reboot.
Please reset this tunable after the system is rebooted.
2. dmp restore daemon interval time.
To set the dmp restore deamon interval time to 60 seconds instead of the default
of 300 seconds.
vxdmpadm stop restored
vxdmpadm start restored interval=60
To check to make sure that the interval is correctly set:
vxdmpadm stat restored
s445sb1:~ # vxdmpadm stat restored
The number of daemons running : 1
The interval of daemon: 60
The policy of daemon: check_disabled
ODM support for Storage Foundation 5.0 MP3
The Veritas extension for ODM is now supported for Storage Foundation Standard 5.0MP3 and Storage Foundation Enterprise 5.0MP3.
In order to use this functionality, you must install a hotfix for the Veritas licensing package at http://support.veritas.com/docs/316720
You may also need to manually install the support packages. See Installing ODM for details.
Using ODM with Storage Foundation or Storage Foundation Cluster File System - http://support.veritas.com/docs/316757
Veritas Storage Foundation and High Availability Solutions 5.0 Maintenance Pack 3 is now supported on Solaris 10 Update 6.
The following are Known Issues on this Update Release:
1) Root disk encapsulation is not supported for ZFS boot disks.
2) The following warning messages can be safely ignored on systems running VCS on a system with ZFS root file system:
"unix: [ID 338433 kern.notice] vn_rdwr failed with error 0x15"
"unix: [ID 689466 kern.notice] kobj_load_module: read header failed"
This issue will be addressed in future release under Etrack incident: 1466460
3) Veritas Volume Manager does not update boot-archive on SPARC Solaris 10 Update 6 and up [1471606]
The SPARC version of Solaris 10 Update 6 adds use of boot-archive. VxVM does not update the boot-archive after installation. Usually this limitation causes no issues; however, there could be an issue if an unclean shutdown occurs prior to the next clean shutdown.
Workaround:
After installation has completed, run the following command:
/sbin/bootadm update-archive
Additions to Veritas Cluster Server 5.0 MP3 Release Notes:
Starting with 5.0MP3, Symantec has added the feature of one-way link detection in LLT (Etrack Incident# 1031514)
Prior to this, (i.e. until 5.0MP1), LLT used broadcast heartbeats by default. Beginning with 5.0MP3, instead of using broadcast heartbeats, LLT uses unicast heartbeats.
LLT considers a link to be in trouble for a peer node when it finds that the link has not been up for that node for 2 seconds (peertrouble 200). On lo-pri links, LLT sends heartbeats just once every second; on hi-pri links, it is twice every second. With the above described change in LLT, it is possible that for lo-pri links, the troubled condition is hit more often. And hence the corresponding LLT messages will be printed more often in the system log. While this message is only informational, frequent appearance in the system logs may alarm the customer.
Therefore, it is recommended that the LLT peertrouble tunable should be increased to 400, so that link inactivity for up to 4 seconds is ignored by LLT before printing out the message in the system log.
As noted before, the trouble message is only informational and changing the trouble time to 4 seconds from 2 seconds is harmless.
If the following messages are seen frequently for an LLT lo-pri link, then change the LLT tunable named peertrouble to 400. Its default value is 200.
LLT INFO V-14-1-10205 link 2 (eri0) node 1 in trouble LLT INFO V-14-1-10024 link 2 (eri0) node 1 active
The peertrouble tunable can be changed with the following command on all the nodes in the cluster:
lltconfig -T peertrouble:400
It is recommended that the following line be added to /etc/llttab on all the nodes in the cluster in order to ensure that this value is used across server reboots. On each node, the change will take effect only after restarting LLT.
set-timer peertrouble:400
Example:
# lltconfig -T query
Current LLT timer values (.01 sec units):
. . .
peertrouble = 200 <--------- before
peerinact = 1600
. . .
# lltconfig -T peertrouble:400 <--- cmd
Use the following command to ensure that the values are indeed changed:
# lltconfig -T query
Current LLT timer values (.01 sec units):
. . .
peertrouble = 400 <--------- after
peerinact = 1600
. . .
Veritas Cluster Server Bundled Agents Reference Guide, Apache agent, non-global zone support
The Apache agent supports non-global zones through the use of the ContainerName attribute. The ContainerName attribute's description is: Non-global zone support for Solaris 10 and later. Defines the name of the non-global zone. Its type-dimension is string-scalar, and an example is "zone1".
Do not change the ContainerType attribute, it is for internal use only. [1249495]
Veritas Cluster Server Zone Agent in the local and branded zone environment
Monitor script fails to work correctly in the Secured Cluster for the 12th month of the year (December).
The workaround is to run VCS in non-secure mode.
Additions to Veritas Storage Foundation 5.0 MP3 Release Notes:
Veritas File System has increased the default value for the tunable max_seqio_extent_size
Veritas File System (VxFS) 5.0 MP3 has an increased default value for the max_seqio_extent_size tunable for better performance in modern file systems.
The max_seqio_extent_size tunable value is the maximum size of an individual extent. Prior to the VxFS 5.0 MP3 release, the default value for this tunable was 2048 blocks. Database tests showed that this default value was outdated and resulted in slower than expected throughput on modern larger file systems. To improve performance and reduce fragmentation, the default value of max_seqio_extent_size was changed to 1 gigabyte in VxFS 5.0 MP3. VxFS allocates extents in a way that allows VxFS to use only the necessary percentage of the 1 gigabyte extent size, avoiding over allocation.
The minimum value allowed for the max_seqio_extent_size tunable is 2048 blocks--the default value prior to the VxFS 5.0 MP3 release.
Known Issue:
Processes that relied on extents being allocated in smaller chunks could result in unneeded extent space being given to other processes. This could lead to file systems getting full.
Workaround:
Change the max_seqio_extent_size tunable back to the pre-5.0MP3 value of 2048.
Disk Group Failure Policy: requestleave
As of 5.0 MP3, Veritas Volume Manager (VxVM) supports 'requestleave' as a valid disk group failure policy. This new disk group failure policy is not currently documented in the 5.0MP3 Veritas Volume Manager Administrator's Guide. The Administrator's Guide will be updated with this information in the next major release.
When the disk group failure policy is set to 'requestleave', the master node gracefully leaves the cluster if the master node loses access to all log/config copies of the diskgroup. If the master node loses access to the log/config copies of a shared diskgroup, Cluster Volume Manager (CVM) signals the CVM Cluster Veritas Cluster Server agent. Veritas Cluster Server (VCS) attempts to take offline the CVM group on the master node. When the CVM group is taken offline, the dependent services groups are also taken offline. If the dependent applications managed by VCS cannot be taken offline for some reason, the master node may not be able to leave the cluster gracefully.
Use the 'requestleave' disk group failure policy together with the 'local' detach policy. Use this combination of disk detach policy and disk group failure policy when the availability of the configuration change records is more important than the availability of nodes. In other words, if you prefer to let a node leave the cluster rather than risk having the disk group be disabled cluster-wide, because of a loss of access to all copies of the disk configuration.
Set the requestleave disk group failure policy as follows:
# vxdg -g mydg set dgfailpolicy=requestleave
Refer to the 5.0MP3 Veritas Volume Manager Administrator's Guide for more information about the disk group failure policy and the disk detach policy.
Upgrade to 5.0MP3 fails if Storage Foundation Manager is installed (Etrack incident #1423124)
Upgrading the Storage Foundation products to 5.0MP3 may fail if Storage Foundation
Manager is installed. The product installer exits with a message indicating that a patch
is missing in the media.
Workaround:
Start the product installer with the following option:
# ./installmp -mpok
If the umask is 0077, the installation or upgrade can fail
Check the umask setting:
# umask
0077
Change umask to 0022:
# umask 0022
# umask
0022
The Local detach policy support documented in the Storage Foundation Release Notes is not correct
The 5.0 MP3 Storage foundation Release Notes included a section titled: "Local detach policy now supported with Veritas Cluster Server clusters and with Dynamic Multipathing Active/Passive arrays." This section is not correct and should be ignored. The restrictions in using the local detach policy still apply for the 5.0MP3 release.
Fire Drill with VVR not supported in SF Oracle RAC environments
SF Oracle RAC now supports Veritas Cluster Server (VCS) Fire Drill. Fire Drill enables organizations to validate the ability of business-critical applications in resuming operations at hot standby data centers following critical outages and disasters. Fire Drill automates creation of point-in-time snapshots and testing of the applications that use the replicated data in the event of a site-to-site application failover, often referred to as a High Availability Disaster Recovery (HA/DR) failover.
Note: All operations are managed within the VCS HA/DR framework through hardware replication technologies that use VCS agents. Replication using VVR is not supported for Fire Drill in an SF Oracle RAC environment. This note corrects a related documentation errata in the Veritas Storage Foundation for Oracle RAC Release Notes, which implies support for VVR.
The Fire Drill setup wizard allows automated configuration of a Fire Drill. The resultant Fire Drill configuration is also fully customizable. The Fire Drill wizard is invoked from the disaster recovery site using hardware replication by executing the script shipped with the hardware replication agents.
Veritas Volume Manager may not restart correctly after patch removal (Etrack 1416930; Sun Bugid 6747492)
On a Solaris 10 system, removing a patch for Veritas Volume Manager
(VxVM) could prevent VxVM from starting correctly after a system reboot.
This issue may occur when you remove any 5.0 Maintenance Pack 1 Rolling Patch or the 5.0 Maintenance Pack 3 patch. The system boots into the maintenance mode of Service Management Facility (SMF).
Workaround:
To recover from the situation, start the Volume Manager processes by using the following commands:
# rm /VRTS5.0-UPGRADE/.start_runed
# svcadm enable vxvm-sysboot
# svcadm enable vxvm-startup1
# svcadm enable vxvm-startup2
# svcadm enable vxvm-reconfig
# svcadm enable vxvm-recover
# svcadm enable vxvm-startvc
Check that the VxVM SMF services are enabled:
# svcs -x
Veritas Volume Manager 5.0 MP3 fixed issues section
The following additional incidents are fixed in 5.0MP3 but were not listed in the Veritas Volume Manager
5.0 MP3 fixed issues section or in the Volume Manager patch README.122058-11:
(e1095411) Need to be able to disable boot disk's last path for DR
(e1095411) Sun Bugid 6277129 UNABLE TO SUPPRESS BOOT DISK FROM VXVM 4.0 control
(e803949) Opteron_x86 - removeable device not being ignored
(e803949) Sun Bugid 6534693 "vxdisk list" lists FDD
Volume Manager 5.0 MP1 Rolling Patch 5
Volume Manager 5.0 MP1 Rolling Patch 5 for Solaris is now available at http://entsupport.symantec.com/docs/306441
File System 5.0 MP1 Rolling Patch 4
File System 5.0 MP1 Rolling Patch 4 for Solaris is now available at http://entsupport.symantec.com/docs/305740
Version 5.0 Maintenance Pack 1 (MP1):
5.0 Maintenance Pack 1 is Available
Veritas Storage Foundation (tm) and High Availability Solutions 5.0 Maintenance Pack 1 (Solaris) is available at:
http://support.veritas.com/docs/288505
Storage Foundation for Oracle RAC support for Oracle 11GR1 RAC
Oracle 11gR1 RAC (11.1.0.6) is now supported with the 5.0 Maintenance Pack 1 (5.0MP1) version of Storage Foundation For Oracle RAC for Solaris 9 and Solaris 10.
An additional patch needs to be installed and the patch is available for download at:
http://entsupport.symantec.com/docs/303872
Please note that DBED checkpoint, DBED flashsnap, Deep Mapping are not supported with Oracle 11gR1 RAC with 5.0MP1 version of Storage Foundation for Oracle RAC for Solaris.
The complete support matrix for Storage Foundation For Oracle RAC is available at:
http://entsupport.symantec.com/docs/280186
VIAS (Formerly known as Prep Utility)
The Veritas Installation Assessment Service ( VIAS , a.k.a Prep Utility ) is a new tool for Storage Foundation users that simplifies and automates the installation and upgrade process to Storage Foundation 5.0 and above. This utility is for anyone preparing for an Storage Foundation-related installation or upgrade.
More information is available at:
https://vias.symantec.com/main.php (VIAS Website)
http://seer.entsupport.symantec.com/docs/308158.htm (Informational Technote)
Note: Please read all relevant README files before downloading.
Addition to the Veritas Storage Foundation Cluster File System (SFCFS) 5.0 MP1 Release Notes:
Support statement for the new feature for the Solaris 10 operating environment in a non-global zone is missing in the SFCFS 5.0 Release Notes:
Solaris 10 operating environment non-global zone support
As of the 5.0 MP1 release, VRTSvxfs and VRTSodm now support clustered file systems mounted within Solaris 10 operating environment non-global zones. This includes lofs and direct mounts.
Additions to Veritas Storage Foundation 5.0 MP1 Release Notes:
Replication may stop responding after upgrading to Volume Replicator 5.0 or 5.0 MP1 if the disk group version is not upgraded at the same time http://support.veritas.com/docs/308183
VRAdvisor wizard fails to detect that Veritas Volume Manager is installed
Releases affected:
SF 5.0 and 5.0MP1 on Solaris
This issue will be fixed in 5.0MP3 (incident 1030193).
Problem:
The VRAdvisor wizard, which is part of the VRTSvradv package, is used to collect data on the host on which VRAdvisor is installed. If you have Veritas Volume Manager (VxVM) installed, the VRAdvisor wizard supports collecting data for a specified VxVM disk group. For Storage Foundation 5.0 and 5.0MP1, the VRAdvisor wizard fails to detect that Veritas Volume Manager is installed. The VRAdvisor wizard reports the following message on the "Data Collection" page:
Note: VxVM is not installed. "iostat" process will be used to collect the data samples.
Workaround:
Modify the description in the pkginfo file for the Veritas Volume Manager package, VRTSvxvm.
To modify the pkginfo description:
1) Change to the /var/sadm/pkg/VRTSvxvm/pkginfo directory:
# cd /var/sadm/pkg/VRTSvxvm/pkginfo
2) Edit the following line in the pkginfo file:
NAME=Binaries for VERITAS Volume Manager by Symantec
Change the line to the following:
NAME=VERITAS Volume Manager, Binaries
3) Restart the VRAdvisor GUI wizard on Solaris.
Veritas Storage Foundation 5.0 Maintenance Pack 1 release supports Solaris Logical Domains
For more information please refer to this guide:
http://support.veritas.com/docs/293324
Documentation Errata in the Veritas Storage Foundation 5.0 MP1 Release Notes
It is not necessary to unmirror and unencapsulate the system disk for the installation of Maintenance Pack 1 (MP1) for Veritas Volume Manager 5.0 (Solaris/SPARC). The Storage Foundation 5.0 MP1 Release Notes incorrectly state that unmirroring and unencapsulation are required (pages 13 and 17).
Version 5.0:
Documentation Errata: 5.0 Veritas Cluster Server Agent Developers Guide
The following content replaces the description of the LogFileSize attribute in the Veritas Cluster Server Agent Developers Guide.
LogFileSize
Sets the size of an agent log file. Value must be specified in bytes. Minimum is 65536 bytes (64KB). Maximum is 134217728 bytes (128MB). Default is 33554432 bytes (32MB).
For example,
hatype -modify FileOnOff LogFileSize 2097152
Values specified less than the minimum acceptable value are changed to 65536 bytes. Values specified greater than the maximum acceptable value are changed to 134217728 bytes. Therefore, out-of-range values displayed for the command:
hatype -display restype -attribute LogFileSize
are those entered with the -modify option, not the actual values. The LogFileSize attribute value cannot be overridden.
Additions to the Veritas Storage Foundation and High Availability Solutions by Symantec Hardware TechNote 5.0RP1
Errata in the Veritas Storage Foundation and High Availability Solutions by Symantec Hardware
TechNote 5.0RP1
In the EMC arrays section, EMC Symmetrix DMX and 8000 series arrays on page 9, the setting for
"D-Bit" is missing under the column "Setting 4".
For all platforms, "The disable queue reset on unit attention mode (D-Bit)" must be set for all
channels that participate in the DMP.
Errata in the Veritas Storage Foundation 5.0 Installation Guide:
Under the section "Installing the Japanese language packages",
use this procedure in place of the one in the Installation Guide:
To install the Japanese language packages on the server
1. Make sure the VEA Service is not running.
# /opt/VRTS/bin/vxsvcctrl status
Current state of server : RUNNING
2. If the VEA Service is running, stop it by using the vxsvcctrl stop command.
# /opt/VRTS/bin/vxsvcctrl stop
3. Insert the "Language" disc into the DVD-ROM or CD-ROM drive. If you are using Solaris volume management software, the disc is automatically mounted as /cdrom/cdrom0.
4. For the Japanese language packages, copy the ja/volume_manager/pkgs directory to a temporary directory on your system, such as /tmp/pkgs.
# cp -r /cdrom/cdrom0/ja/volume_manager/pkgs /tmp/pkgs
5. Decompress the packages, and extract the contents.
# cd /tmp/pkgs
# /cdrom/cdrom0/ja/gnu/gunzip *.gz
# tar xvf *.tar
6. Use the pkgadd command to install the packages for the selected product (see below).
7 After installing the language packages, restart the VEA Service.
# /opt/VRTS/bin/vxsvcctrl start
To install the Japanese language packages for Veritas Storage Foundation (non-HA), use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSjaap \
VRTSjafas VRTSjafad VRTSjafsc VRTSjafsd VRTSjafsm VRTSmufsp \
VRTSjamsa VRTSjagap VRTSjampr VRTSjavvr VRTSjavmc VRTSjavmm \
VRTSjavmd VRTSmualc VRTSmuvmp VRTSmuddl VRTSjavrd VRTSatJA
To install the Japanese language packages for Veritas Storage Foundation (HA), use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSjaap \
VRTSjafas VRTSjafag VRTSjafad VRTSjafsc VRTSjafsd VRTSjafsm \
VRTSmufsp VRTSjamsa VRTSjagap VRTSjampr VRTSjavvr VRTSjacs \
VRTSjacsd VRTSjacsu VRTSjacsj VRTSjacsm VRTSjavmc VRTSjavmm \
VRTSjavmd VRTSmualc VRTSmuvmp VRTSmuddl VRTSjavrd VRTSatJA
To install the Japanese language packages for SF Veritas Storage Foundation for DB2, use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSjaap \
VRTSjafsc VRTSjafsd VRTSjafsm VRTSmufsp VRTSjamsa VRTSjadcm \
VRTSjadb2 VRTSjad2g VRTSjagap VRTSjadbd VRTSjavvr VRTSjavmc \
VRTSjavmm VRTSjavmd VRTSmualc VRTSmuvmp VRTSmuddl VRTSjavrd \
VRTSatJA
To install the Japanese language packages for Veritas Storage Foundation for Oracle, use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSjaap \
VRTSjafas VRTSjafad VRTSjafsc VRTSjafsd VRTSjafsm VRTSmufsp \
VRTSjamsa VRTSjadcm VRTSjagap VRTSjadbd VRTSjadbe VRTSjaodm \
VRTSjaorg VRTSjavvr VRTSjavmc VRTSjavmm VRTSjavmd VRTSmualc \
VRTSmuvmp VRTSmuddl VRTSjavrd VRTSatJA
To install the Japanese language packages for Veritas Storage Foundation for Oracle RAC, use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSjaap \
VRTSjafsc VRTSjafsd VRTSjafsm VRTSmufsp VRTSjacav VRTSjamsa \
VRTSjadcm VRTSjagap VRTSjadbe VRTSjaodm VRTSjacso VRTSjadba \
VRTSjavvr VRTSjacs VRTSjacsd VRTSjacsu VRTSjacsj VRTSjacsm \
VRTSjavmc VRTSjavmm VRTSjavmd VRTSmualc VRTSmuvmp VRTSmuddl \
VRTSjavrd VRTSatJA
To install the Japanese language packages for Symantec Product Authentication Service, use the following command:
# pkgadd -d . VRTSjaico VRTSjapbx VRTSatJA
To install the Japanese language packages for Veritas Cluster Management Console, use the following command:
# pkgadd -d . VRTSjaico VRTSjapbx VRTSjaweb VRTSjacmc VRTSatJA
To install the Japanese language packages for Web Server for Storage Foundation Host Management, use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSmuobw \
VRTSjaap VRTSjafas VRTSjafad VRTSjafsc VRTSjafsd VRTSjafsm \
VRTSmufsp VRTSjamsa VRTSjagap VRTSjampr VRTSjavvr VRTSjavmc \
VRTSjavmm VRTSjavmd VRTSmualc VRTSmuvmp VRTSmuddl VRTSjavrd \
VRTSatJA
-----------------
Additional errata in the Veritas Storage Foundation Installation Guide:
- For Solaris 10, Patch 119254-06 or higher is a prerequisite.
- VRTSvxvm Patch 122058-01 is not required for Storage Foundation Basic, although it can optionally be installed by patchadd.
- VRTSvxvm Patch 122058-01 is required if Veritas Volume Replicator (VVR) is licensed, or if Storage Foundation Basic is upgraded to Storage Foundation Enterprise. The patch must be applied by using the patchadd command.
- If the upgrade scripts are used to upgrade a system with an encapsulated root disk from VxVM 3.5 MP4 to VxVM 5.0, the upgrade completes successfully, but the root disk does not appear to be encapsulated. Use the following workaround:
1. Copy the /VXVM5.0-UPGRADE/upgrade_start_system.SAV file to /etc/system
2. Copy the/VXVM5.0-UPGRADE/upgrade_start_vfstab.SAV file to /etc/vfstab
3. Edit the/etc/vfstab file, change all occurrences of "rootdg" in paths to read "bootdg", and then save the file
4. Reboot the system
- Using the installsf or installvm installation scripts with the -configure option to complete the upgrade for Veritas Storage Foundation 5.0, may fail with the following error:
CPI ERROR V-9-10-1052 Cannot upgrade SF to version 5.0 on vm240v5 as 3.5MP4
Use the following workaround:
1. Remove the .SF.upgrade file:
# rm /opt/VRTS/install/.SF.upgrade
2. Recreate the .SF.upgrade file:
# touch /opt/VRTS/install/.SF.upgrade
3. Reenter the installsf or installvm command, for example:
# installvm -configure <hostname>
- (page 59) Storage Foundation Basic can be installed on Solaris 8, 9, and 10 systems (both 32 and 64-bit) and not just on Solaris 10 (64-bit) systems.
- (page 65) If a Storage Foundation Basic system is upgraded to Storage Foundation Enterprise with the Veritas Volume Replicator licensed feature, you must additionally use the product installer to add the VVR packages (available under item 4). VRTSvxvm Patch 122058-01 must be applied after VVR packages are installed by the patchadd command.
- (page 86) In the procedure "To upgrade on a system with an encapsulated root disk," step 2 should read:
2 Run the upgrade_start command with the -check option specified to verify the status of
the root disk.
# upgrade_start -check
- (page 87) There should be an additional step between steps 14 and 15 to configure the software:
14 Perform a reconfiguration reboot.
# reboot -- -r
At this point, your pre-upgrade configuration should be in effect and any file systems
previously defined on volumes should be defined and mounted.
>>Run the installer script with the -configure option specified to configure the software.
15 Importing a pre-5.0 Veritas Volume Manager disk group does not automatically upgrade
the disk group version to the VxVM 5.0 level. You may need to manually upgrade each
of your disk groups following a VxVM upgrade. See "Upgrading the disk group version
separately" on page 80.
- (page 90) After step 2 in the procedure "To upgrade the operating system," there should be the following additional step:
Run the installer script with the -configure option specified to configure the software.
- (page 91) After step 10 in the procedure "To upgrade the Veritas Storage Foundation packages after upgrading the operating system," there should be the following additional step:
Run the installer script with the -configure option specified to configure the software.
- (page 98) Step 6 in the procedure "To upgrade from SUNWvxvm if the root disk is unencapsulated" should read as follows:
6 Run the installsf program.
* If the disc is mounted automatically, enter:
# cd /cdrom/cdrom0/storage_foundation
# installsf -installonly <hostname>
* If the disc is mounted manually, enter:
# cd /mount_point/storage_foundation
# installsf -installonly <hostname>
- (page 98) After step 10 in the procedure "To upgrade from SUNWvxvm if the root disk is unencapsulated," there should be the following additional step:
Run the installer with the -configure option specified to configure the software.
- (page 154) The procedure in the section "Upgrading VxVM and the Solaris OS" cannot be used to upgrade from VxVM 3.5 MP4. This is because the upgrade_start and upgrade_finish scripts are not supported for such an upgrade path.
Additions to the Veritas Cluster Server (VCS) 5.0 Release Notes:
VCS requires that all nodes in the cluster use the same processor architecture and run the same operating system. For example, in a cluster with nodes running Solaris, all nodes must run Solaris SPARC or Solaris x64.
All nodes in the cluster must run the same VCS version. Each node the cluster may run a different version of the operating system, as long as the operating system is supported by the VCS version in the cluster.
See the Veritas Cluster Server Installation Guide for supported operating systems. See the Hardware Compatibility List for Veritas Storage Foundation (tm) and High Availability Solutions for supported hardware.
Additions to the Veritas Storage Foundation for Oracle RAC (SFRAC) 5.0 Release Notes:
The System Requirements section of the SFRAC Installation and Configuration Guide on page 72 in
Table 2-1 states:
"Two to eight systems with two or more CPUs at 2GHz or higher. "This is an error. It should read as "Two to eight systems with two or more CPUs at 1GHz or higher."
In addition, in Table 2-1, the information about CPU speed and swap space size is just a recommendation. Other things to consider before choosing the system configuration are the size of the database, Oracle recommendations, the amount of activity, etc.
Etrack incident: 319114
Previously, Cluster Ready Service (CRS) sometimes did not work on a Japanese OS. This issue has been fixed. In the VERITAS Storage Foundation for Oracle RAC 5.0 Release Notes, a known issue is included that states that CRS may not work on a Japanese OS. This statement is incorrect. CRS works on a Japanese OS starting with 4.1 MP1 and later releases which includes 5.0.
The Veritas Storage Foundation for Oracle RAC 5.0 Installation and Configuration Guide on page 114, under the section "Creating the coordinator disk group (vxfencoorddg)", contains a procedure that is incorrect.
On page 114, it currently displays this incorrect procedure:
To create the coordinator disk group
1 On one node, create the disk group by specifying the device name of one of the disks; the option coordinator=on sets the coordinator attribute:
# vxdg -o coordinator=on init vxfencoorddg c1t1d0
2 Add the other two disks to the disk group:
# vxdg -g vxfencoorddg adddisk c2t1d0
# vxdg -g vxfencoorddg adddisk c3t1d0
Refer to the Veritas Volume Manager documentation for details on creating disk groups.
Replace this procedure with the one shown below:
To create the coordinator disk group
1. On one node, create the disk group by specifying the device name of one of the disks:
# vxdg init vxfencoorddg c1t1d0
2. Add the other two disks to the disk group:
# vxdg -g vxfencoorddg adddisk c2t1d0
# vxdg -g vxfencoorddg adddisk c3t1d0
Refer to the Veritas Volume Manager documentation for details on creating disk groups.
3. Set the option coordinator=on to set the coordinator attribute:
# vxdg -g vxfencoorddg set coordinator=on
Additions to Veritas Storage Foundation 5.0 Release Notes:
Documentation errata relating to dynamic multipathing (DMP)
The "Performance monitoring and tuning" chapter of the Veritas Volume Manager Administrator's Guide (pages 482-486) is not clear about the different methods that may be used to change the values of the available DMP tunables.
The following DMP tunables can be changed online by using the vxdmpadm settune command:
dmp_cache_open
dmp_daemon_count
dmp_delayq_interval
dmp_failed_io_threshold
dmp_fast_recovery
dmp_health_time
dmp_log_level
dmp_path_age
dmp_pathswitch_blks_shift
dmp_probe_idle_lun
dmp_queue_depth
dmp_retry_count
dmp_retry_timeout
dmp_scsi_timeout
dmp_stat_interval
The following DMP tunables can be changed by editing the /kernel/drv/vxdmp.conf file and rebooting the system:
dmp_failed_io_threshold
dmp_pathswitch_blks_shift
dmp_restore_cycles
dmp_retry_count
The following DMP tunables can be changed online by using the vxdmpadm start restore command:
dmp_restore_cycles
dmp_restore_interval
dmp_restore_policy
Errata in the Veritas Volume Manager 5.0 Administrator's Guide
In the chapter "Administering dynamic multipathing (DMP)", in the section "Enabling I/O for paths, controllers or array ports", the following note is incorrect:
Note: This operation is not supported for controllers that are used to access disk arrays on which cluster-shareable disk groups are configured
The correct note is below:
Note: From release 5.0 of VxVM, this operation is supported for controllers that are used to access disk arrays on which cluster-shareable disk groups are configured.
In the Veritas Volume Manager Administrator's Guide and the vxdmpadm(1M) manual page, the dmp_restore_cycles, dmp_restore_interval and dmp_restore_policy tunables are incorrectly named as dmp_restore_daemon_cycles, dmp_restore_daemon_interval and dmp_restore_daemon_policy.
The dmp_restore_cycles, dmp_restore_interval and dmp_restore_policy tunables correspond to the period, interval, and policy attributes of the vxdmpadm start restore command.
The correct syntax for the vxdmpadm start restore command is:
vxdmpadm start restore [interval=<seconds>] policy=check_all vxdmpadm start restore [interval=<seconds>] policy=check_alternate vxdmpadm start restore [interval=<seconds>] policy=check_disabled vxdmpadm start restore interval=<seconds> policy=check_periodic [period=<number>]
That is, the interval attribute, if specified, must precede the policy attribute, and the policy attribute must precede the period attribute.
DMP tunable changes not shown by prtconf
Some DMP tunables can be changed either by editing the /kernel/drv/vxdmp.conf file and rebooting the system, or by using the vxdmpadm settune command. If the vxdmpadm settune command is used, the change to the tunable is visible only in the output from the vxdmpadm gettune command, and the output from the prtconf -Pv command shows the old value.
(Etrack incident 928000)
Symantec License Inventory Manager (SLIM) Server 4.0 Authentication credentials are lost when installing Veritas Storage Foundation
If you install Veritas Storage Foundation 5.0 on a machine that has SLIM Server 4.0 installed, the SLIM server authentication credentials are lost. This prevents users from logging in to the SLIM server. Manually restoring the authentication credentials results in the following error when users attempt to log into the SLIM server:
User cannot be authenticated
Workaround: Use the following procedure to install Veritas Storage Foundation if SLIM Server 4.0 is installed:
1. Back up the authentication data:
# vssat showbackuplist
2. Install Veritas Storage Foundation (refer to the Veritas Storage Foundation Installation Guide)
3. Shut down the authentication service by issuing a kill command on the process ID of the vxatd service. For example:
# kill 12345
4. Manually restore the authentication credentials:
# cp -r /var/VRTSatSnapShot/* /var/VRTSat/.VRTSat
5. Restart the authentication service:
# vxatd
If you already attempted to install Veritas Storage Foundation without backing up the authentication credentials, the credentials are lost and you must reconfigure the credentials.
To reconfigure authentication credentials with the Root Broker and Authentication Broker:
1. Reconfigure the credentials using the vxatd command:
# vxatd -o -r -a
To reconfigure Authentication credentials with only the Root Broker:
1. Reconfigure the credentials using the vxatd command:
# vxatd -o -r
To reconfigure Authentication credentials with only the Authentication Broker:
1. On a system with the Authentication Broker, set up trust with the Root Broker:
# vssat setuptrust --broker Root_Broker_machine:port \
--securitylevel high
2. On a system with the Root Broker, create an account for the Authentication Broker under the root Authentication Private Domain Repository:
# vssat addprpl --pdrtype root --domain root_domain_name \
--prplname prplname --password password
3. On the system with the Authentication Broker, configure the Authentication Broker:
# vxatd -o -a -n prplname -p password -x vx \
-y root_domain_name -q Root_Broker_machine_or_IP -z port \
-h root_hash_filename
The values for the prplname, password, and root_domain_name arguments are the same as those used to create the account.
4. Start the Authentication service:
# vxatd
Installing the Web server for Veritas Storage Foundation Host Management package
The VRTSobweb package (Web server for SF Host Management) can only be installed successfully if the VRTSob package (Veritas Enterprise Administrator) has already been installed on the system. You can use the following command to determine whether the VRTSob package is present:
# pkginfo | grep VRTSob
Software disc cannot be ejected during installation:
During installation, if any of the products that contain Veritas Volume Manager (tm) were configured and started, the software disc cannot be ejected. This will prevent further use of the disc drive and will impact installation of packages from the language pack disc. This problem is not an issue if a product was installed or upgraded that required a system reboot to complete the installation. To avoid this problem at installation:
1. Specify the -installonly option to the installation script in addition to any other options. This will install the packages only.
2. Eject the software disc
3. Run the appropriate installation script , which is in /opt/VRTS/install, with the -configure option specified
If a software disc cannot be ejected:
1. Stop the event source daemon:
# /usr/sbin/vxddladm stop eventsource
2. Eject the software disc
3. Restart the event source daemon:
# /usr/sbin/vxddladm start eventsource
Errata in the Veritas File System 5.0 Administrator's Guide
(Page 126) Step 3 in the procedure under the section "Assigning Allocation Properties" is incorrect. Step 3 should read as follows:
Define two allocation policies called metadatapolicy and datapolicy to refer to the vol1 and vol2 volumes:
# fsapadm define /mnt1 metadatapolicy vol1
# fsapadm define /mnt1 datapolicy vol2
(Page 127) Step 1 in the procedure under the section "Assigning Pattern Tables to Directories" is incorrect. Step 1 should read as follows:
Define two allocation policies called mp3meta and mp3data to refer to the vol1 and vol2 volumes:
# fsapadm define /mnt1 mp3meta vol1
# fsapadm define /mnt1 mp3data vol2
(Page 128) Step 1 in the procedure under the section "Assigning Pattern Tables to File Systems" is incorrect. Step 1 should read as follows:
Define two allocation policies called mymeta and mydata to refer to vol1 and vol2 volumes:
# fsapadm define /mnt1 mymeta vol1
# fsapadm define /mnt1 mydata vol2
Direct Mounts section missing in the Veritas File System 5.0 Administrator's Guide
Direct mounts
To direct mount a VxFS file system in a non-global zone, the directory to mount must be in the non-global zone and the mount must take place from the global zone. Using direct mounts limits the visibility of and access to the file system to only that non-global zone.
The following procedure describes mounting the directory dirmnt in the non-global zone zone1 with a mount path of /zonedir/zone1/root/dirmnt.
Note: VxFS entries in the global zone /etc/vfstab file for non-global zone direct mounts are not supported, as the non-global zone may not yet be booted at the time of /etc/vfstab execution.
To direct mount a VxFS file system in a non-global zone
1. Log in to the zone and make the mount point:
global# zlogin zone1
zone# mkdir dirmnt
zone# exit
2. Mount the VxFS file system:
global# mount -F vxfs /dev/vx/dsk/dg/vol1 /zonedir/zone1/root/dirmnt
3. Check if the file system is not mounted or is not visible in the global zone:
global# df | grep dirmnt
4. Log in to the non-global zone and ensure that the file system is mounted:
global# zlogin zone1
zone# df | grep dirmnt
/dirmnt (/dirmnt):142911566 blocks 17863944 files
Additions to the Veritas Storage Foundation Cluster File System (SFCFS) 5.0 Release Notes:
Addition to the Known Issues section in the SFCFS Release Notes:
If a large message of the day or other notification is present, the installation scripts might be unable to complete the OS detect and therefore fail.
Workaround: Minimize or remove the large message of the day or other notification that is present on your system and try the installation script again.
----------
For Veritas Storage Foundation Cluster File System Administrator's Guide 5.0 in the section "Setting up the disk group for coordinator disks" on page 45, step 6 is incorrect.
It should read as follows:
6) Add the other two disks to the disk group.
# vxdg -g vxfencoorddg set coordinator=off
# vxdg -g vxfencoorddg adddisk c2t1d0
# vxdg -g vxfencoorddg adddisk c3t1d0
# vxdg -g vxfencoorddg set coordinator=on
See the Veritas Volume Manager Administrator's Guide.
----------
Documentation Errata for the Veritas Storage Foundation Cluster File System 5.0 - Installation Guide - Phased upgrade
In the SFCFS Installation Guide, "Phased upgrade" section on page 37, ignore the following note:
Note: Each phase of the phased upgrade should be performed on more than one node of the cluster. A phased upgrade should not be performed from one of the nodes in the cluster.
----------
On page 43 of the SFCFS Installation Guide, step 5 and 6 of the "Phased upgrade" procedure in the "Shutting down VCS (phased only)" section is incorrect and missing commands. It should read as:
5. On each node that is not being upgraded, shut down VCS.
a. Enter the following commands:
# /opt/VRTSvcs/bin/hastop -local
# /etc/init.d/vxfen stop
# /opt/VRTS/bin/fsclustadm cfsdeinit
b. Check to see if the qlog module is loaded:
# /usr/sbin/modinfo | grep qlog
c. If the qlog module is loaded, then unload it:
# /usr/sbin/modunload -i <module_id>
d. Enter the following commands to stop GAB and LLT:
# /etc/init.d/gab stop
# /etc/init.d/llt.rc stop
6. Proceed to updating the configuration and confirm startup (phased and full)
----------
Documentation Errata for the Veritas Storage Foundation Cluster File System 5.0 - Release Notes
Version 4 and Version 5 file system disk layouts
On page 9 of the Veritas Storage Foundation Cluster File System Release Notes, the "Version 4 and Version 5 file system disk layouts" feature in the section "No longer supported and future support issues" should have the following first sentence instead of the existing first sentence:
VxFS disk layout Version 4 and 5 are not supported for cluster mounts in SFCFS 5.0.
Support for SFCFS configurations larger than 16 nodes
On page 12 in the "Known issues" section for Veritas Storage Foundation Cluster File System Release Notes, the heading "Support for SFCFS configurations larger than 16 nodes" section should be replaced by the following text:
SFCFS 5.0 is capable of supporting cluster file systems with up to 32 nodes. Symantec has tested and qualified SFCFS 5.0 cluster file system configurations of up to 16 nodes at product release time. For the latest information on SFCFS support issues, refer back to this TechNote on a regular basis.
Additions to the Veritas Volume Replicator (VVR) 5.0 Release Notes:
When VVR is added to a Veritas Volume Manager (VxVM) installation, VVR patch 122058-01 is not installed.
When VxVM 5.0 is installed, you can add VVR by adding a VVR license and installing VVR. In this scenario, the VVR patch 122058-01 is not automatically installed. You must add the patch manually. For more
information, refer to the README-122058-01 file in the volume_replicator/patches directory.
To locate the most current product patch releases including Maintenance Packs, Rolling Patches, and Hot Fixes visit https://vos.symantec.com/patch/matrix
Documentation
5.0 MP3 Documentation List http://entsupport.symantec.com/docs/307509
5.0 MP1 Documentation List http://entsupport.symantec.com/docs/307438
5.0 Documentation List http://support.veritas.com/docs/307436
Product documentation, man pages and error messages for the 5.0 and 5.0 MP3 releases are available at http://sfdoccentral.symantec.com/index.html
Downloads
5.0 Maintenance Pack 3 for Solaris is available at https://fileconnect.symantec.com
5.0 Maintenance Pack 3 Rolling Patch 1 for Solaris Sparc is available at http://entsupport.symantec.com/docs/316671
The latest patches are available on Patch Central https://vias.symantec.com/labs/patch
Tools
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)
Forums
Discuss support issues and find solutions in the Support Forums:
Storage Management Forums http://www.symantec.com/connect/storage-management/forums
Clustering and Replication Forums http://www.symantec.com/connect/clustering-and-replication/forums
Support of ZFS Root Devices
The 5.0 version of Storage Foundation is supported on servers with ZFS root devices, however care must be taken to ensure that devices managed by ZFS are excluded from being managed by Storage Foundation. ZFS root disk encapsulation is not supported by this version of storage foundation. Running ZFS on top of DMP or Veritas Volume Manager is not supported in this release. The 5.1 version of Storage Foundation includes functionality to detect and protect ZFS devices and is recommended when ZFS will be used on devices not specifically used for root functionality.
Multiple product versions per server: Licensees of Storage Foundation/High Availability (SFHA) products may run different versions of (SFHA) products on different virtual machines in the same physical server/CPU, provided that the versions of the SFHA products are still supported by Symantec Corporation.
SF Basic Virtual Machine Entitlements: Licensees of Storage Foundation Basic products may use a maximum of 4 volumes and 4 file systems per virtual machine. Storage Foundation Basic can only be used on a server that has a maximum of 2 CPU's.
Addition to all Release Notes:
For all Veritas Storage Foundation 5.0 Release Notes
On a Solaris system with root disk encapsulated and mirrored, if a third party driver (TPD) driver like mpxio is
doing the multipathing, the following steps are required to boot from the mirrored boot disk (Example below):
A. Procedure to boot from the mirrored boot disk when system is still running:
1. Locate the mirror disk device
# vxprint -g bootdg
dm rootdisk c8t20000011C637214Fd0s2 - 143278080 - - - -
dm rootmir c8t20000011C637232Cd0s2 - 143278080 - - - -
2. Determine the TPD mirror path
# ls -l /dev/dsk/c8t20000011C637232Cd0s0
lrwxrwxrwx 1 root other 47 Oct 21 09:33 /dev/dsk/c8t20000011C637232Cd0s2 ->
../../devices/scsi_vhci/ssd@g20000011c637232c:a
3. Set the 'dmp_tpd_root_device' tunable in the vxdmp.conf to
the mirror device path:
# vi /kernel/drv/vxdmp.conf
#
# comment out 'dmp_tpd_root_device' for boot device:
#
# dmp_tpd_root_device="/scsi_vhci/ssd@g2000000087146f57:a";
#
# set 'dmp_tpd_root_device' to mirror device:
dmp_tpd_root_device="/scsi_vhci//ssd@g20000011c637232c:a";
4. Boot from mirror device
NOTE: It is recommended to set the 'dmp_tpd_root_device' tunable
settings in the vxdmp.conf file after the mirror operation completes.
The 'dmp_tpd_root_device' tunable setting can be commented/uncommented
as needed.
B. Procedure to boot from the mirrored boot disk when system is not running:
1. boot system to single user mode from cdrom:
# boot cdrom -s
or from network:
# boot net -s
2. mount the mirror device
# mount /dev/dsk/c8t20000011C637232Cd0s0 /a
3. Determine the TPD mirror path
# ls -l /mnt/dev/dsk/c8t20000011C637232Cd0s0
lrwxrwxrwx 1 root other 47 Oct 21 09:33 /mnt/dev/dsk/c8t20000011C637232Cd0s2
-> ../../devices/scsi_vhci/ssd@g20000011c637232c:a
4. Set the 'dmp_tpd_root_device' tunable in the vxdmp.conf to
the mirror device path:
# ksh
# export TERM=vt100
# vi /mnt/kernel/drv/vxdmp.conf
#
# comment out 'dmp_tpd_root_device' for boot device:
#
# dmp_tpd_root_device="/scsi_vhci/ssd@g2000000087146f57:a";
#
# set 'dmp_tpd_root_device' to mirror device:
dmp_tpd_root_device="/scsi_vhci//ssd@g20000011c637232c:a";
5. boot the mirror
# umount /a
# shutdown -g0 -i0 -y
ok> boot <mirror_devalias>
For all Veritas Cluster Server (VCS) Release Notes
VCS requires that all nodes in the cluster use the same processor architecture and
run the same operating system.
All nodes in the cluster must run the same VCS version. Each node in the cluster
may run a different version of the operating system, as long as the operating
system is supported by the VCS version in the cluster.
Daylight Saving Time Issues
For information about Daylight Saving Time issues, refer to this technote: http://support.veritas.com/docs/286461
NetApp Solaris sparc 5.0 MP3 SSI mode support with qLogic HBA
Under heavy load, it has been observed that i/o response time may exceed
137 seconds.
To workaround that issue, you need to set 2 tunable parameters.
Example:
1. dmpnetapp reconf_time.
To change the apm reconf time use "vxdmpadm cfgapm dmpnetapp reconf_time=0"
to check the reconf time, you will see a message in the messages file:
Apr 3 10:52:25 s445sb1 dmpnetapp: [ID 998758 kern.notice] NOTICE: dmpnetapp_da_configure_apm setting netapp_filer_reconf_time to 0
Other option is to use adb :
# adb -kw
physmem fb360
netapp_filer_reconf_time/D
netapp_filer_reconf_time:
netapp_filer_reconf_time: 0
$q
***Special Note: The setting for this tunable is not persistent across reboot.
Please reset this tunable after the system is rebooted.
2. dmp restore daemon interval time.
To set the dmp restore deamon interval time to 60 seconds instead of the default
of 300 seconds.
# vxdmpadm stop restored
# vxdmpadm start restored interval=60
To check to make sure that the interval is correctly set:
# vxdmpadm stat restored
The number of daemons running : 1
The interval of daemon: 60
The policy of daemon: check_disabled
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.
Recommendations on use of Space-Optimized (SO) snapshots in Storage Foundation for
Oracle RAC 5.0
If you use Volume Manager mirroring, Space-Optimized (SO) snapshots are recommended for Oracle data volumes.
Keep the Fast Mirror Resync regionsize equal to the database block size to reduce the copy-on-write
(COW) overhead.
Reducing the regionsize increases the amount of Cache Object allocations leading to performance overheads.
Do not create Oracle redo log volumes on a space-optimized snapshot.
Use "third-mirror break-off" snapshots for cloning the Oracle redo log volumes.
Permission issues while applying Oracle Bundled Patches
While applying an Oracle bundled patch to Oracle Clusterware (CRS),
at the step when you execute prepatch.sh script with oracle user,
the following error is displayed.
chmod: can't change <ORA_CRS_HOME>/css/admin/init.cssd: Not owner
Workaround:
The solution is to change the owner of init.cssd file as oracle user
before applying Oracle bundled patches to Oracle Clusterware.
$ chown <oracle user>:<oracle group> <ORA_CRS_HOME>/css/admin/init.cssd
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]
VEA service takes a long time to start
VEA service takes a long time to start if the configuration contains large number of LUNs (1403191)
In configurations with large numbers of LUNS which need to be discovered, the VEA service may take a long time to start. The long start-up time may cause the boot time to be longer than is allowed.
Workaround:
The solution is to start the VEA service in the background, so that the boot continues while the LUNs are discovered.
To start the VEA service in the background:
1. Edit the VEA start-up script.
For Storage Foundation 5.x, use the following command:
# edit shell script /opt/VRTSobc/pal33/bin/vxpalctrl
2. In the start_agent() function, add the following line:
exit 0
Before the lines:
max=10
count=0
Support for Branded Zones
Support for Branded Zones is now documented at http://entsupport.symantec.com/docs/315575
and the required patch is available at http://entsupport.symantec.com/docs/309206
Veritas Cluster Server Agent Support Matrix
The Veritas Cluster Server Agents Support Matrix is available at http://www.symantec.com/business/products/agents_options.jsp?pcid=psc_disaster_recov&pvid=20_1
Oracle 11gR1 RAC Support
Oracle 11gR1 RAC (11.1.0.7) is now supported with the 5.0 Maintenance Pack 3 (5.0MP3) version of Storage Foundation For Oracle RAC for Solaris 9 and Solaris 10.
SF Oracle RAC 5.0 MP1 requires the point patch 5.0MP1+e1221809a for Oracle RAC 11g Release 1. The patch is available for download at http://entsupport.symantec.com/docs/303872
Version 5.0 Maintenance Pack 3 (MP3) Rolling Patch 2 (RP2):
Errata for the Veritas Storage Foundation 5.0 MP3 RP2 Read This First document
In the upgrade procedures, the list of patches with the patchadd command for Storage
Foundation on Solaris 8, 9, and 10 SPARC contains some incorrect patch numbers.
Use the corrected procedure below.
On pages 63, 70, 86, and 99, the patchadd command should be as follows:
* For Storage Foundation on Solaris 8 SPARC:
# patchadd -M patch_dir 122058-12 123200-05 123722-02 \
123823-05 139354-01 139356-02 139737-01 139739-01 \
139741-02 139742-02 139743-01 139744-01 140657-01 \
140661-01 141279-01 141745-01
* For Storage Foundation on Solaris 9 SPARC:
# patchadd -M patch_dir 122058-12 123201-05 123722-02\
123823-05 139354-01 139357-02 139737-01 139739-01\
139741-02 139742-02 139743-01 139744-01 140657-01\
140661-01 141279-01 141745-01
* For Storage Foundation on Solaris 10 SPARC:
# patchadd -M patch_dir 122058-12 123202-05 123722-02 \
123823-05 139354-01 139358-02 139359-02 139737-01 \
139739-01 139741-02 139742-02 139743-01 139744-01 \
140657-01 140661-01 141279-01 141745-01
In addition - the patch number included in the installation media is incorrectly numbered in ALL occurrences.
Patch number 139362-01 should be changed to 139362-02 on pages 51, 56, 65, 70, 79, 80, 87, 95, 96, 100, 110.
Patch number 139367-01 should be changed to 139367-02 on pages 52, 70, 79, 80, 87, 95, 96, 100, 110.
Version 5.0 Maintenance Pack 3 (MP3) Rolling Patch 1 (RP1):
Veritas Storage Foundation and High Availability Solutions 5.0 Maintenance Pack 3 Rolling Patch 1 is now available
Veritas Storage Foundation (tm) and High Availability Solutions 5.0 Maintenance Pack 3 Rolling Patch 1 Read This First - Solaris
http://entsupport.symantec.com/docs/316673
Veritas Storage Foundation (tm) and High Availability Solutions 5.0 Maintenance Pack 3 Rolling Patch 1 - Solaris Sparc
http://entsupport.symantec.com/docs/316671
For all products that use Veritas Volume Manager, the vxdiskadm utility fails to replace a failed or removed non-root disk (1434779)
The vxdiskadm utility fails to replace a failed or removed disk using the options:
4 Remove a disk for replacement
5 Replace a failed or removed disk
This issue is specific to the replacement of a non-root disk.
An error message displays similar to the following example:
VxVM ERROR V-5-2-281
Replacement of disk rootdg02 in group rootdg with device c1t1d0
VxVM vxdg ERROR V-5-1-559 Disk rootdg02: Name is already used
Replace a different disk? [y,n,q,?] (default: n)
Workaround:
Replace the disk using the following command:
# vxdg -g $repldgname -k adddisk $repldmname=$repldaname
For example:
vxdg -g rootdg -k adddisk rootdg02=c1t1d0
This issue is seen in the following releases:
5.0 MP3 RP1
The issue will be fixed in the following releases:
5.0 MP3 RP2
Storage Foundation Cluster File System and Storage Foundation for Oracle Real Application Clusters Kernel memory leak
A Kernel memory leak occurs after upgrading to Veritas Volume Manager 5.0 MP3 RP1 for Solaris in a Cluster environment:
http://entsupport.symantec.com/docs/317647
Additions to the Veritas Storage Foundation and High Availability Solutions Read This First for 5.0 MP3 RP1 document:
Software Limitations section
Veritas Cluster Server (VCS) known issue:
Ignore certain warning messages on nodes that run VCS on Solaris 10 update 6 with a ZFS root file system
You can safely ignore the following warning messages on systems that run VCS on Solaris10 update 6 that have the ZFS root file system [1466460]:
"unix: [ID 338433 kern.notice] vn_rdwr failed with error 0x15"
"unix: [ID 689466 kern.notice] kobj_load_module: read header failed"
Storage Foundation for Oracle RAC known issue:
Joining a new node to the cluster may fail [1390591]
If you have a RAC cluster that has fencing enabled and a Sun StorageTek 2540 machine configured in A/PF mode, joining a new node to the cluster may fail if the cluster has a failover in progress.
Workaround
There is no known workaround at this time, check back for the latest status.
Version 5.0 Maintenance Pack 3 (MP3):
5.0 Maintenance Pack 3 for Solaris is available at https://fileconnect.symantec.com
The Veritas Volume Manager 5.0 Maintenance Pack 3 SmartMove Hot Fix 1 for Solaris (SPARC) is available at http://entsupport.symantec.com/docs/311468
The Veritas Cluster Server 5.0 Maintenance Pack 3 Hotfix 1 for Solaris (SPARC) is available at:
http://entsupport.symantec.com/docs/311938
This Hotfix fixes the below issues:
VRTSvcs
1404384: HAD crashing when switching over a global group when PreSwitch is TRUE.
1397692: VCS engine clients hang in connect() if the target system is down
1414219 HostMonitor objects:
HostMonitor objects are internal-use only. While these objects appear in the UI for the 5.0 MP3 release, in later releases these objects are not displayed.
The Storage Foundation Simple Admin 1.0 for Solaris is available at http://entsupport.symantec.com/docs/303625
Incorrect Oracle bug id in the 5.0MP3 Release Notes for Solaris
In the section "Support for new database", the Oracle bug id is incorrect. The correct text is as follows:
For 11g on Solaris:
If you are using ODM and and plan to use the init_ora "memory_target", you
must apply the patch for Oracle bug 6647246.
NetApp Solaris Sparc 5.0 MP3 SSI mode support with qLogic HBA
Under heavy load, it has been observed that i/o response time may exceed 137 seconds.
To workaround that issue, you need to set 2 tunables parameters.
1. dmpnetapp reconf_time.
To change the apm reconf time use "vxdmpadm cfgapm dmpnetapp reconf_time=0"
to check the reconf time, you will see a message in the messages file:
Apr 3 10:52:25 s445sb1 dmpnetapp: [ID 998758 kern.notice] NOTICE: dmpnetapp_da_configure_apm setting netapp_filer_reconf_time to 0
Other option is to use adb :
# adb -kw
physmem fb360
netapp_filer_reconf_time/D
netapp_filer_reconf_time:
netapp_filer_reconf_time: 0
$q
***Special Note: The setting for this tunable is not persistent across reboot.
Please reset this tunable after the system is rebooted.
2. dmp restore daemon interval time.
To set the dmp restore deamon interval time to 60 seconds instead of the default
of 300 seconds.
vxdmpadm stop restored
vxdmpadm start restored interval=60
To check to make sure that the interval is correctly set:
vxdmpadm stat restored
s445sb1:~ # vxdmpadm stat restored
The number of daemons running : 1
The interval of daemon: 60
The policy of daemon: check_disabled
ODM support for Storage Foundation 5.0 MP3
The Veritas extension for ODM is now supported for Storage Foundation Standard 5.0MP3 and Storage Foundation Enterprise 5.0MP3.
In order to use this functionality, you must install a hotfix for the Veritas licensing package at http://support.veritas.com/docs/316720
You may also need to manually install the support packages. See Installing ODM for details.
Using ODM with Storage Foundation or Storage Foundation Cluster File System - http://support.veritas.com/docs/316757
Veritas Storage Foundation and High Availability Solutions 5.0 Maintenance Pack 3 is now supported on Solaris 10 Update 6.
The following are Known Issues on this Update Release:
1) Root disk encapsulation is not supported for ZFS boot disks.
2) The following warning messages can be safely ignored on systems running VCS on a system with ZFS root file system:
"unix: [ID 338433 kern.notice] vn_rdwr failed with error 0x15"
"unix: [ID 689466 kern.notice] kobj_load_module: read header failed"
This issue will be addressed in future release under Etrack incident: 1466460
3) Veritas Volume Manager does not update boot-archive on SPARC Solaris 10 Update 6 and up [1471606]
The SPARC version of Solaris 10 Update 6 adds use of boot-archive. VxVM does not update the boot-archive after installation. Usually this limitation causes no issues; however, there could be an issue if an unclean shutdown occurs prior to the next clean shutdown.
Workaround:
After installation has completed, run the following command:
/sbin/bootadm update-archive
Additions to Veritas Cluster Server 5.0 MP3 Release Notes:
Starting with 5.0MP3, Symantec has added the feature of one-way link detection in LLT (Etrack Incident# 1031514)
Prior to this, (i.e. until 5.0MP1), LLT used broadcast heartbeats by default. Beginning with 5.0MP3, instead of using broadcast heartbeats, LLT uses unicast heartbeats.
LLT considers a link to be in trouble for a peer node when it finds that the link has not been up for that node for 2 seconds (peertrouble 200). On lo-pri links, LLT sends heartbeats just once every second; on hi-pri links, it is twice every second. With the above described change in LLT, it is possible that for lo-pri links, the troubled condition is hit more often. And hence the corresponding LLT messages will be printed more often in the system log. While this message is only informational, frequent appearance in the system logs may alarm the customer.
Therefore, it is recommended that the LLT peertrouble tunable should be increased to 400, so that link inactivity for up to 4 seconds is ignored by LLT before printing out the message in the system log.
As noted before, the trouble message is only informational and changing the trouble time to 4 seconds from 2 seconds is harmless.
If the following messages are seen frequently for an LLT lo-pri link, then change the LLT tunable named peertrouble to 400. Its default value is 200.
LLT INFO V-14-1-10205 link 2 (eri0) node 1 in trouble LLT INFO V-14-1-10024 link 2 (eri0) node 1 active
The peertrouble tunable can be changed with the following command on all the nodes in the cluster:
lltconfig -T peertrouble:400
It is recommended that the following line be added to /etc/llttab on all the nodes in the cluster in order to ensure that this value is used across server reboots. On each node, the change will take effect only after restarting LLT.
set-timer peertrouble:400
Example:
# lltconfig -T query
Current LLT timer values (.01 sec units):
. . .
peertrouble = 200 <--------- before
peerinact = 1600
. . .
# lltconfig -T peertrouble:400 <--- cmd
Use the following command to ensure that the values are indeed changed:
# lltconfig -T query
Current LLT timer values (.01 sec units):
. . .
peertrouble = 400 <--------- after
peerinact = 1600
. . .
Veritas Cluster Server Bundled Agents Reference Guide, Apache agent, non-global zone support
The Apache agent supports non-global zones through the use of the ContainerName attribute. The ContainerName attribute's description is: Non-global zone support for Solaris 10 and later. Defines the name of the non-global zone. Its type-dimension is string-scalar, and an example is "zone1".
Do not change the ContainerType attribute, it is for internal use only. [1249495]
Veritas Cluster Server Zone Agent in the local and branded zone environment
Monitor script fails to work correctly in the Secured Cluster for the 12th month of the year (December).
The workaround is to run VCS in non-secure mode.
Additions to Veritas Storage Foundation 5.0 MP3 Release Notes:
Veritas File System has increased the default value for the tunable max_seqio_extent_size
Veritas File System (VxFS) 5.0 MP3 has an increased default value for the max_seqio_extent_size tunable for better performance in modern file systems.
The max_seqio_extent_size tunable value is the maximum size of an individual extent. Prior to the VxFS 5.0 MP3 release, the default value for this tunable was 2048 blocks. Database tests showed that this default value was outdated and resulted in slower than expected throughput on modern larger file systems. To improve performance and reduce fragmentation, the default value of max_seqio_extent_size was changed to 1 gigabyte in VxFS 5.0 MP3. VxFS allocates extents in a way that allows VxFS to use only the necessary percentage of the 1 gigabyte extent size, avoiding over allocation.
The minimum value allowed for the max_seqio_extent_size tunable is 2048 blocks--the default value prior to the VxFS 5.0 MP3 release.
Known Issue:
Processes that relied on extents being allocated in smaller chunks could result in unneeded extent space being given to other processes. This could lead to file systems getting full.
Workaround:
Change the max_seqio_extent_size tunable back to the pre-5.0MP3 value of 2048.
Disk Group Failure Policy: requestleave
As of 5.0 MP3, Veritas Volume Manager (VxVM) supports 'requestleave' as a valid disk group failure policy. This new disk group failure policy is not currently documented in the 5.0MP3 Veritas Volume Manager Administrator's Guide. The Administrator's Guide will be updated with this information in the next major release.
When the disk group failure policy is set to 'requestleave', the master node gracefully leaves the cluster if the master node loses access to all log/config copies of the diskgroup. If the master node loses access to the log/config copies of a shared diskgroup, Cluster Volume Manager (CVM) signals the CVM Cluster Veritas Cluster Server agent. Veritas Cluster Server (VCS) attempts to take offline the CVM group on the master node. When the CVM group is taken offline, the dependent services groups are also taken offline. If the dependent applications managed by VCS cannot be taken offline for some reason, the master node may not be able to leave the cluster gracefully.
Use the 'requestleave' disk group failure policy together with the 'local' detach policy. Use this combination of disk detach policy and disk group failure policy when the availability of the configuration change records is more important than the availability of nodes. In other words, if you prefer to let a node leave the cluster rather than risk having the disk group be disabled cluster-wide, because of a loss of access to all copies of the disk configuration.
Set the requestleave disk group failure policy as follows:
# vxdg -g mydg set dgfailpolicy=requestleave
Refer to the 5.0MP3 Veritas Volume Manager Administrator's Guide for more information about the disk group failure policy and the disk detach policy.
Upgrade to 5.0MP3 fails if Storage Foundation Manager is installed (Etrack incident #1423124)
Upgrading the Storage Foundation products to 5.0MP3 may fail if Storage Foundation
Manager is installed. The product installer exits with a message indicating that a patch
is missing in the media.
Workaround:
Start the product installer with the following option:
# ./installmp -mpok
If the umask is 0077, the installation or upgrade can fail
Check the umask setting:
# umask
0077
Change umask to 0022:
# umask 0022
# umask
0022
The Local detach policy support documented in the Storage Foundation Release Notes is not correct
The 5.0 MP3 Storage foundation Release Notes included a section titled: "Local detach policy now supported with Veritas Cluster Server clusters and with Dynamic Multipathing Active/Passive arrays." This section is not correct and should be ignored. The restrictions in using the local detach policy still apply for the 5.0MP3 release.
Fire Drill with VVR not supported in SF Oracle RAC environments
SF Oracle RAC now supports Veritas Cluster Server (VCS) Fire Drill. Fire Drill enables organizations to validate the ability of business-critical applications in resuming operations at hot standby data centers following critical outages and disasters. Fire Drill automates creation of point-in-time snapshots and testing of the applications that use the replicated data in the event of a site-to-site application failover, often referred to as a High Availability Disaster Recovery (HA/DR) failover.
Note: All operations are managed within the VCS HA/DR framework through hardware replication technologies that use VCS agents. Replication using VVR is not supported for Fire Drill in an SF Oracle RAC environment. This note corrects a related documentation errata in the Veritas Storage Foundation for Oracle RAC Release Notes, which implies support for VVR.
The Fire Drill setup wizard allows automated configuration of a Fire Drill. The resultant Fire Drill configuration is also fully customizable. The Fire Drill wizard is invoked from the disaster recovery site using hardware replication by executing the script shipped with the hardware replication agents.
Veritas Volume Manager may not restart correctly after patch removal (Etrack 1416930; Sun Bugid 6747492)
On a Solaris 10 system, removing a patch for Veritas Volume Manager
(VxVM) could prevent VxVM from starting correctly after a system reboot.
This issue may occur when you remove any 5.0 Maintenance Pack 1 Rolling Patch or the 5.0 Maintenance Pack 3 patch. The system boots into the maintenance mode of Service Management Facility (SMF).
Workaround:
To recover from the situation, start the Volume Manager processes by using the following commands:
# rm /VRTS5.0-UPGRADE/.start_runed
# svcadm enable vxvm-sysboot
# svcadm enable vxvm-startup1
# svcadm enable vxvm-startup2
# svcadm enable vxvm-reconfig
# svcadm enable vxvm-recover
# svcadm enable vxvm-startvc
Check that the VxVM SMF services are enabled:
# svcs -x
Veritas Volume Manager 5.0 MP3 fixed issues section
The following additional incidents are fixed in 5.0MP3 but were not listed in the Veritas Volume Manager
5.0 MP3 fixed issues section or in the Volume Manager patch README.122058-11:
(e1095411) Need to be able to disable boot disk's last path for DR
(e1095411) Sun Bugid 6277129 UNABLE TO SUPPRESS BOOT DISK FROM VXVM 4.0 control
(e803949) Opteron_x86 - removeable device not being ignored
(e803949) Sun Bugid 6534693 "vxdisk list" lists FDD
Volume Manager 5.0 MP1 Rolling Patch 5
Volume Manager 5.0 MP1 Rolling Patch 5 for Solaris is now available at http://entsupport.symantec.com/docs/306441
File System 5.0 MP1 Rolling Patch 4
File System 5.0 MP1 Rolling Patch 4 for Solaris is now available at http://entsupport.symantec.com/docs/305740
Version 5.0 Maintenance Pack 1 (MP1):
5.0 Maintenance Pack 1 is Available
Veritas Storage Foundation (tm) and High Availability Solutions 5.0 Maintenance Pack 1 (Solaris) is available at:
http://support.veritas.com/docs/288505
Storage Foundation for Oracle RAC support for Oracle 11GR1 RAC
Oracle 11gR1 RAC (11.1.0.6) is now supported with the 5.0 Maintenance Pack 1 (5.0MP1) version of Storage Foundation For Oracle RAC for Solaris 9 and Solaris 10.
An additional patch needs to be installed and the patch is available for download at:
http://entsupport.symantec.com/docs/303872
Please note that DBED checkpoint, DBED flashsnap, Deep Mapping are not supported with Oracle 11gR1 RAC with 5.0MP1 version of Storage Foundation for Oracle RAC for Solaris.
The complete support matrix for Storage Foundation For Oracle RAC is available at:
http://entsupport.symantec.com/docs/280186
VIAS (Formerly known as Prep Utility)
The Veritas Installation Assessment Service ( VIAS , a.k.a Prep Utility ) is a new tool for Storage Foundation users that simplifies and automates the installation and upgrade process to Storage Foundation 5.0 and above. This utility is for anyone preparing for an Storage Foundation-related installation or upgrade.
More information is available at:
https://vias.symantec.com/main.php (VIAS Website)
http://seer.entsupport.symantec.com/docs/308158.htm (Informational Technote)
Note: Please read all relevant README files before downloading.
Addition to the Veritas Storage Foundation Cluster File System (SFCFS) 5.0 MP1 Release Notes:
Support statement for the new feature for the Solaris 10 operating environment in a non-global zone is missing in the SFCFS 5.0 Release Notes:
Solaris 10 operating environment non-global zone support
As of the 5.0 MP1 release, VRTSvxfs and VRTSodm now support clustered file systems mounted within Solaris 10 operating environment non-global zones. This includes lofs and direct mounts.
Additions to Veritas Storage Foundation 5.0 MP1 Release Notes:
Replication may stop responding after upgrading to Volume Replicator 5.0 or 5.0 MP1 if the disk group version is not upgraded at the same time http://support.veritas.com/docs/308183
VRAdvisor wizard fails to detect that Veritas Volume Manager is installed
Releases affected:
SF 5.0 and 5.0MP1 on Solaris
This issue will be fixed in 5.0MP3 (incident 1030193).
Problem:
The VRAdvisor wizard, which is part of the VRTSvradv package, is used to collect data on the host on which VRAdvisor is installed. If you have Veritas Volume Manager (VxVM) installed, the VRAdvisor wizard supports collecting data for a specified VxVM disk group. For Storage Foundation 5.0 and 5.0MP1, the VRAdvisor wizard fails to detect that Veritas Volume Manager is installed. The VRAdvisor wizard reports the following message on the "Data Collection" page:
Note: VxVM is not installed. "iostat" process will be used to collect the data samples.
Workaround:
Modify the description in the pkginfo file for the Veritas Volume Manager package, VRTSvxvm.
To modify the pkginfo description:
1) Change to the /var/sadm/pkg/VRTSvxvm/pkginfo directory:
# cd /var/sadm/pkg/VRTSvxvm/pkginfo
2) Edit the following line in the pkginfo file:
NAME=Binaries for VERITAS Volume Manager by Symantec
Change the line to the following:
NAME=VERITAS Volume Manager, Binaries
3) Restart the VRAdvisor GUI wizard on Solaris.
Veritas Storage Foundation 5.0 Maintenance Pack 1 release supports Solaris Logical Domains
For more information please refer to this guide:
http://support.veritas.com/docs/293324
Documentation Errata in the Veritas Storage Foundation 5.0 MP1 Release Notes
It is not necessary to unmirror and unencapsulate the system disk for the installation of Maintenance Pack 1 (MP1) for Veritas Volume Manager 5.0 (Solaris/SPARC). The Storage Foundation 5.0 MP1 Release Notes incorrectly state that unmirroring and unencapsulation are required (pages 13 and 17).
Version 5.0:
Documentation Errata: 5.0 Veritas Cluster Server Agent Developers Guide
The following content replaces the description of the LogFileSize attribute in the Veritas Cluster Server Agent Developers Guide.
LogFileSize
Sets the size of an agent log file. Value must be specified in bytes. Minimum is 65536 bytes (64KB). Maximum is 134217728 bytes (128MB). Default is 33554432 bytes (32MB).
For example,
hatype -modify FileOnOff LogFileSize 2097152
Values specified less than the minimum acceptable value are changed to 65536 bytes. Values specified greater than the maximum acceptable value are changed to 134217728 bytes. Therefore, out-of-range values displayed for the command:
hatype -display restype -attribute LogFileSize
are those entered with the -modify option, not the actual values. The LogFileSize attribute value cannot be overridden.
Additions to the Veritas Storage Foundation and High Availability Solutions by Symantec Hardware TechNote 5.0RP1
Errata in the Veritas Storage Foundation and High Availability Solutions by Symantec Hardware
TechNote 5.0RP1
In the EMC arrays section, EMC Symmetrix DMX and 8000 series arrays on page 9, the setting for
"D-Bit" is missing under the column "Setting 4".
For all platforms, "The disable queue reset on unit attention mode (D-Bit)" must be set for all
channels that participate in the DMP.
Errata in the Veritas Storage Foundation 5.0 Installation Guide:
Under the section "Installing the Japanese language packages",
use this procedure in place of the one in the Installation Guide:
To install the Japanese language packages on the server
1. Make sure the VEA Service is not running.
# /opt/VRTS/bin/vxsvcctrl status
Current state of server : RUNNING
2. If the VEA Service is running, stop it by using the vxsvcctrl stop command.
# /opt/VRTS/bin/vxsvcctrl stop
3. Insert the "Language" disc into the DVD-ROM or CD-ROM drive. If you are using Solaris volume management software, the disc is automatically mounted as /cdrom/cdrom0.
4. For the Japanese language packages, copy the ja/volume_manager/pkgs directory to a temporary directory on your system, such as /tmp/pkgs.
# cp -r /cdrom/cdrom0/ja/volume_manager/pkgs /tmp/pkgs
5. Decompress the packages, and extract the contents.
# cd /tmp/pkgs
# /cdrom/cdrom0/ja/gnu/gunzip *.gz
# tar xvf *.tar
6. Use the pkgadd command to install the packages for the selected product (see below).
7 After installing the language packages, restart the VEA Service.
# /opt/VRTS/bin/vxsvcctrl start
To install the Japanese language packages for Veritas Storage Foundation (non-HA), use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSjaap \
VRTSjafas VRTSjafad VRTSjafsc VRTSjafsd VRTSjafsm VRTSmufsp \
VRTSjamsa VRTSjagap VRTSjampr VRTSjavvr VRTSjavmc VRTSjavmm \
VRTSjavmd VRTSmualc VRTSmuvmp VRTSmuddl VRTSjavrd VRTSatJA
To install the Japanese language packages for Veritas Storage Foundation (HA), use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSjaap \
VRTSjafas VRTSjafag VRTSjafad VRTSjafsc VRTSjafsd VRTSjafsm \
VRTSmufsp VRTSjamsa VRTSjagap VRTSjampr VRTSjavvr VRTSjacs \
VRTSjacsd VRTSjacsu VRTSjacsj VRTSjacsm VRTSjavmc VRTSjavmm \
VRTSjavmd VRTSmualc VRTSmuvmp VRTSmuddl VRTSjavrd VRTSatJA
To install the Japanese language packages for SF Veritas Storage Foundation for DB2, use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSjaap \
VRTSjafsc VRTSjafsd VRTSjafsm VRTSmufsp VRTSjamsa VRTSjadcm \
VRTSjadb2 VRTSjad2g VRTSjagap VRTSjadbd VRTSjavvr VRTSjavmc \
VRTSjavmm VRTSjavmd VRTSmualc VRTSmuvmp VRTSmuddl VRTSjavrd \
VRTSatJA
To install the Japanese language packages for Veritas Storage Foundation for Oracle, use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSjaap \
VRTSjafas VRTSjafad VRTSjafsc VRTSjafsd VRTSjafsm VRTSmufsp \
VRTSjamsa VRTSjadcm VRTSjagap VRTSjadbd VRTSjadbe VRTSjaodm \
VRTSjaorg VRTSjavvr VRTSjavmc VRTSjavmm VRTSjavmd VRTSmualc \
VRTSmuvmp VRTSmuddl VRTSjavrd VRTSatJA
To install the Japanese language packages for Veritas Storage Foundation for Oracle RAC, use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSjaap \
VRTSjafsc VRTSjafsd VRTSjafsm VRTSmufsp VRTSjacav VRTSjamsa \
VRTSjadcm VRTSjagap VRTSjadbe VRTSjaodm VRTSjacso VRTSjadba \
VRTSjavvr VRTSjacs VRTSjacsd VRTSjacsu VRTSjacsj VRTSjacsm \
VRTSjavmc VRTSjavmm VRTSjavmd VRTSmualc VRTSmuvmp VRTSmuddl \
VRTSjavrd VRTSatJA
To install the Japanese language packages for Symantec Product Authentication Service, use the following command:
# pkgadd -d . VRTSjaico VRTSjapbx VRTSatJA
To install the Japanese language packages for Veritas Cluster Management Console, use the following command:
# pkgadd -d . VRTSjaico VRTSjapbx VRTSjaweb VRTSjacmc VRTSatJA
To install the Japanese language packages for Web Server for Storage Foundation Host Management, use the following command:
# pkgadd -d . VRTSmulic SYMCjalma VRTSjaico VRTSjapbx VRTSjasmf \
VRTSmuc33 VRTSmuob VRTSmuobg VRTSmusfm VRTSjaweb VRTSmuobw \
VRTSjaap VRTSjafas VRTSjafad VRTSjafsc VRTSjafsd VRTSjafsm \
VRTSmufsp VRTSjamsa VRTSjagap VRTSjampr VRTSjavvr VRTSjavmc \
VRTSjavmm VRTSjavmd VRTSmualc VRTSmuvmp VRTSmuddl VRTSjavrd \
VRTSatJA
-----------------
Additional errata in the Veritas Storage Foundation Installation Guide:
- For Solaris 10, Patch 119254-06 or higher is a prerequisite.
- VRTSvxvm Patch 122058-01 is not required for Storage Foundation Basic, although it can optionally be installed by patchadd.
- VRTSvxvm Patch 122058-01 is required if Veritas Volume Replicator (VVR) is licensed, or if Storage Foundation Basic is upgraded to Storage Foundation Enterprise. The patch must be applied by using the patchadd command.
- If the upgrade scripts are used to upgrade a system with an encapsulated root disk from VxVM 3.5 MP4 to VxVM 5.0, the upgrade completes successfully, but the root disk does not appear to be encapsulated. Use the following workaround:
1. Copy the /VXVM5.0-UPGRADE/upgrade_start_system.SAV file to /etc/system
2. Copy the/VXVM5.0-UPGRADE/upgrade_start_vfstab.SAV file to /etc/vfstab
3. Edit the/etc/vfstab file, change all occurrences of "rootdg" in paths to read "bootdg", and then save the file
4. Reboot the system
- Using the installsf or installvm installation scripts with the -configure option to complete the upgrade for Veritas Storage Foundation 5.0, may fail with the following error:
CPI ERROR V-9-10-1052 Cannot upgrade SF to version 5.0 on vm240v5 as 3.5MP4
Use the following workaround:
1. Remove the .SF.upgrade file:
# rm /opt/VRTS/install/.SF.upgrade
2. Recreate the .SF.upgrade file:
# touch /opt/VRTS/install/.SF.upgrade
3. Reenter the installsf or installvm command, for example:
# installvm -configure <hostname>
- (page 59) Storage Foundation Basic can be installed on Solaris 8, 9, and 10 systems (both 32 and 64-bit) and not just on Solaris 10 (64-bit) systems.
- (page 65) If a Storage Foundation Basic system is upgraded to Storage Foundation Enterprise with the Veritas Volume Replicator licensed feature, you must additionally use the product installer to add the VVR packages (available under item 4). VRTSvxvm Patch 122058-01 must be applied after VVR packages are installed by the patchadd command.
- (page 86) In the procedure "To upgrade on a system with an encapsulated root disk," step 2 should read:
2 Run the upgrade_start command with the -check option specified to verify the status of
the root disk.
# upgrade_start -check
- (page 87) There should be an additional step between steps 14 and 15 to configure the software:
14 Perform a reconfiguration reboot.
# reboot -- -r
At this point, your pre-upgrade configuration should be in effect and any file systems
previously defined on volumes should be defined and mounted.
>>Run the installer script with the -configure option specified to configure the software.
15 Importing a pre-5.0 Veritas Volume Manager disk group does not automatically upgrade
the disk group version to the VxVM 5.0 level. You may need to manually upgrade each
of your disk groups following a VxVM upgrade. See "Upgrading the disk group version
separately" on page 80.
- (page 90) After step 2 in the procedure "To upgrade the operating system," there should be the following additional step:
Run the installer script with the -configure option specified to configure the software.
- (page 91) After step 10 in the procedure "To upgrade the Veritas Storage Foundation packages after upgrading the operating system," there should be the following additional step:
Run the installer script with the -configure option specified to configure the software.
- (page 98) Step 6 in the procedure "To upgrade from SUNWvxvm if the root disk is unencapsulated" should read as follows:
6 Run the installsf program.
* If the disc is mounted automatically, enter:
# cd /cdrom/cdrom0/storage_foundation
# installsf -installonly <hostname>
* If the disc is mounted manually, enter:
# cd /mount_point/storage_foundation
# installsf -installonly <hostname>
- (page 98) After step 10 in the procedure "To upgrade from SUNWvxvm if the root disk is unencapsulated," there should be the following additional step:
Run the installer with the -configure option specified to configure the software.
- (page 154) The procedure in the section "Upgrading VxVM and the Solaris OS" cannot be used to upgrade from VxVM 3.5 MP4. This is because the upgrade_start and upgrade_finish scripts are not supported for such an upgrade path.
Additions to the Veritas Cluster Server (VCS) 5.0 Release Notes:
VCS requires that all nodes in the cluster use the same processor architecture and run the same operating system. For example, in a cluster with nodes running Solaris, all nodes must run Solaris SPARC or Solaris x64.
All nodes in the cluster must run the same VCS version. Each node the cluster may run a different version of the operating system, as long as the operating system is supported by the VCS version in the cluster.
See the Veritas Cluster Server Installation Guide for supported operating systems. See the Hardware Compatibility List for Veritas Storage Foundation (tm) and High Availability Solutions for supported hardware.
Additions to the Veritas Storage Foundation for Oracle RAC (SFRAC) 5.0 Release Notes:
The System Requirements section of the SFRAC Installation and Configuration Guide on page 72 in
Table 2-1 states:
"Two to eight systems with two or more CPUs at 2GHz or higher. "This is an error. It should read as "Two to eight systems with two or more CPUs at 1GHz or higher."
In addition, in Table 2-1, the information about CPU speed and swap space size is just a recommendation. Other things to consider before choosing the system configuration are the size of the database, Oracle recommendations, the amount of activity, etc.
Etrack incident: 319114
Previously, Cluster Ready Service (CRS) sometimes did not work on a Japanese OS. This issue has been fixed. In the VERITAS Storage Foundation for Oracle RAC 5.0 Release Notes, a known issue is included that states that CRS may not work on a Japanese OS. This statement is incorrect. CRS works on a Japanese OS starting with 4.1 MP1 and later releases which includes 5.0.
The Veritas Storage Foundation for Oracle RAC 5.0 Installation and Configuration Guide on page 114, under the section "Creating the coordinator disk group (vxfencoorddg)", contains a procedure that is incorrect.
On page 114, it currently displays this incorrect procedure:
To create the coordinator disk group
1 On one node, create the disk group by specifying the device name of one of the disks; the option coordinator=on sets the coordinator attribute:
# vxdg -o coordinator=on init vxfencoorddg c1t1d0
2 Add the other two disks to the disk group:
# vxdg -g vxfencoorddg adddisk c2t1d0
# vxdg -g vxfencoorddg adddisk c3t1d0
Refer to the Veritas Volume Manager documentation for details on creating disk groups.
Replace this procedure with the one shown below:
To create the coordinator disk group
1. On one node, create the disk group by specifying the device name of one of the disks:
# vxdg init vxfencoorddg c1t1d0
2. Add the other two disks to the disk group:
# vxdg -g vxfencoorddg adddisk c2t1d0
# vxdg -g vxfencoorddg adddisk c3t1d0
Refer to the Veritas Volume Manager documentation for details on creating disk groups.
3. Set the option coordinator=on to set the coordinator attribute:
# vxdg -g vxfencoorddg set coordinator=on
Additions to Veritas Storage Foundation 5.0 Release Notes:
Documentation errata relating to dynamic multipathing (DMP)
The "Performance monitoring and tuning" chapter of the Veritas Volume Manager Administrator's Guide (pages 482-486) is not clear about the different methods that may be used to change the values of the available DMP tunables.
The following DMP tunables can be changed online by using the vxdmpadm settune command:
dmp_cache_open
dmp_daemon_count
dmp_delayq_interval
dmp_failed_io_threshold
dmp_fast_recovery
dmp_health_time
dmp_log_level
dmp_path_age
dmp_pathswitch_blks_shift
dmp_probe_idle_lun
dmp_queue_depth
dmp_retry_count
dmp_retry_timeout
dmp_scsi_timeout
dmp_stat_interval
The following DMP tunables can be changed by editing the /kernel/drv/vxdmp.conf file and rebooting the system:
dmp_failed_io_threshold
dmp_pathswitch_blks_shift
dmp_restore_cycles
dmp_retry_count
The following DMP tunables can be changed online by using the vxdmpadm start restore command:
dmp_restore_cycles
dmp_restore_interval
dmp_restore_policy
Errata in the Veritas Volume Manager 5.0 Administrator's Guide
In the chapter "Administering dynamic multipathing (DMP)", in the section "Enabling I/O for paths, controllers or array ports", the following note is incorrect:
Note: This operation is not supported for controllers that are used to access disk arrays on which cluster-shareable disk groups are configured
The correct note is below:
Note: From release 5.0 of VxVM, this operation is supported for controllers that are used to access disk arrays on which cluster-shareable disk groups are configured.
In the Veritas Volume Manager Administrator's Guide and the vxdmpadm(1M) manual page, the dmp_restore_cycles, dmp_restore_interval and dmp_restore_policy tunables are incorrectly named as dmp_restore_daemon_cycles, dmp_restore_daemon_interval and dmp_restore_daemon_policy.
The dmp_restore_cycles, dmp_restore_interval and dmp_restore_policy tunables correspond to the period, interval, and policy attributes of the vxdmpadm start restore command.
The correct syntax for the vxdmpadm start restore command is:
vxdmpadm start restore [interval=<seconds>] policy=check_all vxdmpadm start restore [interval=<seconds>] policy=check_alternate vxdmpadm start restore [interval=<seconds>] policy=check_disabled vxdmpadm start restore interval=<seconds> policy=check_periodic [period=<number>]
That is, the interval attribute, if specified, must precede the policy attribute, and the policy attribute must precede the period attribute.
DMP tunable changes not shown by prtconf
Some DMP tunables can be changed either by editing the /kernel/drv/vxdmp.conf file and rebooting the system, or by using the vxdmpadm settune command. If the vxdmpadm settune command is used, the change to the tunable is visible only in the output from the vxdmpadm gettune command, and the output from the prtconf -Pv command shows the old value.
(Etrack incident 928000)
Symantec License Inventory Manager (SLIM) Server 4.0 Authentication credentials are lost when installing Veritas Storage Foundation
If you install Veritas Storage Foundation 5.0 on a machine that has SLIM Server 4.0 installed, the SLIM server authentication credentials are lost. This prevents users from logging in to the SLIM server. Manually restoring the authentication credentials results in the following error when users attempt to log into the SLIM server:
User cannot be authenticated
Workaround: Use the following procedure to install Veritas Storage Foundation if SLIM Server 4.0 is installed:
1. Back up the authentication data:
# vssat showbackuplist
2. Install Veritas Storage Foundation (refer to the Veritas Storage Foundation Installation Guide)
3. Shut down the authentication service by issuing a kill command on the process ID of the vxatd service. For example:
# kill 12345
4. Manually restore the authentication credentials:
# cp -r /var/VRTSatSnapShot/* /var/VRTSat/.VRTSat
5. Restart the authentication service:
# vxatd
If you already attempted to install Veritas Storage Foundation without backing up the authentication credentials, the credentials are lost and you must reconfigure the credentials.
To reconfigure authentication credentials with the Root Broker and Authentication Broker:
1. Reconfigure the credentials using the vxatd command:
# vxatd -o -r -a
To reconfigure Authentication credentials with only the Root Broker:
1. Reconfigure the credentials using the vxatd command:
# vxatd -o -r
To reconfigure Authentication credentials with only the Authentication Broker:
1. On a system with the Authentication Broker, set up trust with the Root Broker:
# vssat setuptrust --broker Root_Broker_machine:port \
--securitylevel high
2. On a system with the Root Broker, create an account for the Authentication Broker under the root Authentication Private Domain Repository:
# vssat addprpl --pdrtype root --domain root_domain_name \
--prplname prplname --password password
3. On the system with the Authentication Broker, configure the Authentication Broker:
# vxatd -o -a -n prplname -p password -x vx \
-y root_domain_name -q Root_Broker_machine_or_IP -z port \
-h root_hash_filename
The values for the prplname, password, and root_domain_name arguments are the same as those used to create the account.
4. Start the Authentication service:
# vxatd
Installing the Web server for Veritas Storage Foundation Host Management package
The VRTSobweb package (Web server for SF Host Management) can only be installed successfully if the VRTSob package (Veritas Enterprise Administrator) has already been installed on the system. You can use the following command to determine whether the VRTSob package is present:
# pkginfo | grep VRTSob
Software disc cannot be ejected during installation:
During installation, if any of the products that contain Veritas Volume Manager (tm) were configured and started, the software disc cannot be ejected. This will prevent further use of the disc drive and will impact installation of packages from the language pack disc. This problem is not an issue if a product was installed or upgraded that required a system reboot to complete the installation. To avoid this problem at installation:
1. Specify the -installonly option to the installation script in addition to any other options. This will install the packages only.
2. Eject the software disc
3. Run the appropriate installation script , which is in /opt/VRTS/install, with the -configure option specified
If a software disc cannot be ejected:
1. Stop the event source daemon:
# /usr/sbin/vxddladm stop eventsource
2. Eject the software disc
3. Restart the event source daemon:
# /usr/sbin/vxddladm start eventsource
Errata in the Veritas File System 5.0 Administrator's Guide
(Page 126) Step 3 in the procedure under the section "Assigning Allocation Properties" is incorrect. Step 3 should read as follows:
Define two allocation policies called metadatapolicy and datapolicy to refer to the vol1 and vol2 volumes:
# fsapadm define /mnt1 metadatapolicy vol1
# fsapadm define /mnt1 datapolicy vol2
(Page 127) Step 1 in the procedure under the section "Assigning Pattern Tables to Directories" is incorrect. Step 1 should read as follows:
Define two allocation policies called mp3meta and mp3data to refer to the vol1 and vol2 volumes:
# fsapadm define /mnt1 mp3meta vol1
# fsapadm define /mnt1 mp3data vol2
(Page 128) Step 1 in the procedure under the section "Assigning Pattern Tables to File Systems" is incorrect. Step 1 should read as follows:
Define two allocation policies called mymeta and mydata to refer to vol1 and vol2 volumes:
# fsapadm define /mnt1 mymeta vol1
# fsapadm define /mnt1 mydata vol2
Direct Mounts section missing in the Veritas File System 5.0 Administrator's Guide
Direct mounts
To direct mount a VxFS file system in a non-global zone, the directory to mount must be in the non-global zone and the mount must take place from the global zone. Using direct mounts limits the visibility of and access to the file system to only that non-global zone.
The following procedure describes mounting the directory dirmnt in the non-global zone zone1 with a mount path of /zonedir/zone1/root/dirmnt.
Note: VxFS entries in the global zone /etc/vfstab file for non-global zone direct mounts are not supported, as the non-global zone may not yet be booted at the time of /etc/vfstab execution.
To direct mount a VxFS file system in a non-global zone
1. Log in to the zone and make the mount point:
global# zlogin zone1
zone# mkdir dirmnt
zone# exit
2. Mount the VxFS file system:
global# mount -F vxfs /dev/vx/dsk/dg/vol1 /zonedir/zone1/root/dirmnt
3. Check if the file system is not mounted or is not visible in the global zone:
global# df | grep dirmnt
4. Log in to the non-global zone and ensure that the file system is mounted:
global# zlogin zone1
zone# df | grep dirmnt
/dirmnt (/dirmnt):142911566 blocks 17863944 files
Additions to the Veritas Storage Foundation Cluster File System (SFCFS) 5.0 Release Notes:
Addition to the Known Issues section in the SFCFS Release Notes:
If a large message of the day or other notification is present, the installation scripts might be unable to complete the OS detect and therefore fail.
Workaround: Minimize or remove the large message of the day or other notification that is present on your system and try the installation script again.
----------
For Veritas Storage Foundation Cluster File System Administrator's Guide 5.0 in the section "Setting up the disk group for coordinator disks" on page 45, step 6 is incorrect.
It should read as follows:
6) Add the other two disks to the disk group.
# vxdg -g vxfencoorddg set coordinator=off
# vxdg -g vxfencoorddg adddisk c2t1d0
# vxdg -g vxfencoorddg adddisk c3t1d0
# vxdg -g vxfencoorddg set coordinator=on
See the Veritas Volume Manager Administrator's Guide.
----------
Documentation Errata for the Veritas Storage Foundation Cluster File System 5.0 - Installation Guide - Phased upgrade
In the SFCFS Installation Guide, "Phased upgrade" section on page 37, ignore the following note:
Note: Each phase of the phased upgrade should be performed on more than one node of the cluster. A phased upgrade should not be performed from one of the nodes in the cluster.
----------
On page 43 of the SFCFS Installation Guide, step 5 and 6 of the "Phased upgrade" procedure in the "Shutting down VCS (phased only)" section is incorrect and missing commands. It should read as:
5. On each node that is not being upgraded, shut down VCS.
a. Enter the following commands:
# /opt/VRTSvcs/bin/hastop -local
# /etc/init.d/vxfen stop
# /opt/VRTS/bin/fsclustadm cfsdeinit
b. Check to see if the qlog module is loaded:
# /usr/sbin/modinfo | grep qlog
c. If the qlog module is loaded, then unload it:
# /usr/sbin/modunload -i <module_id>
d. Enter the following commands to stop GAB and LLT:
# /etc/init.d/gab stop
# /etc/init.d/llt.rc stop
6. Proceed to updating the configuration and confirm startup (phased and full)
----------
Documentation Errata for the Veritas Storage Foundation Cluster File System 5.0 - Release Notes
Version 4 and Version 5 file system disk layouts
On page 9 of the Veritas Storage Foundation Cluster File System Release Notes, the "Version 4 and Version 5 file system disk layouts" feature in the section "No longer supported and future support issues" should have the following first sentence instead of the existing first sentence:
VxFS disk layout Version 4 and 5 are not supported for cluster mounts in SFCFS 5.0.
Support for SFCFS configurations larger than 16 nodes
On page 12 in the "Known issues" section for Veritas Storage Foundation Cluster File System Release Notes, the heading "Support for SFCFS configurations larger than 16 nodes" section should be replaced by the following text:
SFCFS 5.0 is capable of supporting cluster file systems with up to 32 nodes. Symantec has tested and qualified SFCFS 5.0 cluster file system configurations of up to 16 nodes at product release time. For the latest information on SFCFS support issues, refer back to this TechNote on a regular basis.
Additions to the Veritas Volume Replicator (VVR) 5.0 Release Notes:
When VVR is added to a Veritas Volume Manager (VxVM) installation, VVR patch 122058-01 is not installed.
When VxVM 5.0 is installed, you can add VVR by adding a VVR license and installing VVR. In this scenario, the VVR patch 122058-01 is not automatically installed. You must add the patch manually. For more
information, refer to the README-122058-01 file in the volume_replicator/patches directory.
Related Documents:
http://support.veritas.com/docs/283877
http://support.veritas.com/docs/283878
http://support.veritas.com/docs/283879
http://support.veritas.com/docs/283880
http://support.veritas.com/docs/283882
http://support.veritas.com/docs/280186
http://support.veritas.com/docs/283161
http://support.veritas.com/docs/283282
http://support.veritas.com/docs/283794
http://support.veritas.com/docs/283867
http://support.veritas.com/docs/283868
http://support.veritas.com/docs/283869
http://support.veritas.com/docs/283870
http://support.veritas.com/docs/283871
http://support.veritas.com/docs/283872
http://support.veritas.com/docs/283873
http://support.veritas.com/docs/283874
http://support.veritas.com/docs/283875
http://support.veritas.com/docs/283883
http://support.veritas.com/docs/283884
http://support.veritas.com/docs/283885
http://support.veritas.com/docs/283886
http://support.veritas.com/docs/283887
http://support.veritas.com/docs/283888
http://support.veritas.com/docs/283889
http://support.veritas.com/docs/283890
http://support.veritas.com/docs/283891
http://support.veritas.com/docs/283892
http://support.veritas.com/docs/283893
http://support.veritas.com/docs/283894
http://support.veritas.com/docs/283895
http://support.veritas.com/docs/283896
http://support.veritas.com/docs/283897
http://support.veritas.com/docs/283898
http://support.veritas.com/docs/283899
http://support.veritas.com/docs/283900
http://support.veritas.com/docs/283901
http://support.veritas.com/docs/283907
http://support.veritas.com/docs/283908
http://support.veritas.com/docs/283916
http://support.veritas.com/docs/283876
http://support.veritas.com/docs/283918
http://support.veritas.com/docs/283919
http://support.veritas.com/docs/283914
http://support.veritas.com/docs/283917
http://support.veritas.com/docs/283920
http://support.veritas.com/docs/283921
http://support.veritas.com/docs/283922
http://support.veritas.com/docs/283923
http://support.veritas.com/docs/283924
http://support.veritas.com/docs/283931
http://support.veritas.com/docs/283974
http://support.veritas.com/docs/284542
http://support.veritas.com/docs/284730
http://support.veritas.com/docs/285063
http://support.veritas.com/docs/285357
http://support.veritas.com/docs/285611
http://support.veritas.com/docs/286461
http://support.veritas.com/docs/286878
http://support.veritas.com/docs/288497
http://support.veritas.com/docs/288505
http://support.veritas.com/docs/288510
http://support.veritas.com/docs/290041
http://support.veritas.com/docs/290278
http://support.veritas.com/docs/290484
http://support.veritas.com/docs/291059
http://support.veritas.com/docs/292363
http://support.veritas.com/docs/292592
http://support.veritas.com/docs/293324
http://support.veritas.com/docs/294266
http://support.veritas.com/docs/294428
http://support.veritas.com/docs/294994
http://support.veritas.com/docs/295237
http://support.veritas.com/docs/297327
http://support.veritas.com/docs/297464
http://support.veritas.com/docs/297646
http://support.veritas.com/docs/297865
http://support.veritas.com/docs/300626
http://support.veritas.com/docs/302453
http://support.veritas.com/docs/303230
http://support.veritas.com/docs/303625
http://support.veritas.com/docs/303872
http://support.veritas.com/docs/305740
http://support.veritas.com/docs/306479
http://support.veritas.com/docs/306648
http://support.veritas.com/docs/307436
http://support.veritas.com/docs/307509
http://support.veritas.com/docs/307635
http://support.veritas.com/docs/308158
http://support.veritas.com/docs/308183
http://support.veritas.com/docs/309206
http://support.veritas.com/docs/310872
http://support.veritas.com/docs/311451
http://support.veritas.com/docs/311468
http://support.veritas.com/docs/311938
http://support.veritas.com/docs/314537
http://support.veritas.com/docs/315575
http://support.veritas.com/docs/316671
http://support.veritas.com/docs/316673
http://support.veritas.com/docs/316720
http://support.veritas.com/docs/316757
http://support.veritas.com/docs/317647
http://support.veritas.com/docs/319248
http://support.veritas.com/docs/319358
http://support.veritas.com/docs/320169
http://support.veritas.com/docs/320199
http://support.veritas.com/docs/320308
http://support.veritas.com/docs/322815
http://support.veritas.com/docs/322915
http://support.veritas.com/docs/324934
http://support.veritas.com/docs/338185
http://support.veritas.com/docs/283877
http://support.veritas.com/docs/283878
http://support.veritas.com/docs/283879
http://support.veritas.com/docs/283880
http://support.veritas.com/docs/283882
http://support.veritas.com/docs/280186
http://support.veritas.com/docs/283161
http://support.veritas.com/docs/283282
http://support.veritas.com/docs/283794
http://support.veritas.com/docs/283867
http://support.veritas.com/docs/283868
http://support.veritas.com/docs/283869
http://support.veritas.com/docs/283870
http://support.veritas.com/docs/283871
http://support.veritas.com/docs/283872
http://support.veritas.com/docs/283873
http://support.veritas.com/docs/283874
http://support.veritas.com/docs/283875
http://support.veritas.com/docs/283883
http://support.veritas.com/docs/283884
http://support.veritas.com/docs/283885
http://support.veritas.com/docs/283886
http://support.veritas.com/docs/283887
http://support.veritas.com/docs/283888
http://support.veritas.com/docs/283889
http://support.veritas.com/docs/283890
http://support.veritas.com/docs/283891
http://support.veritas.com/docs/283892
http://support.veritas.com/docs/283893
http://support.veritas.com/docs/283894
http://support.veritas.com/docs/283895
http://support.veritas.com/docs/283896
http://support.veritas.com/docs/283897
http://support.veritas.com/docs/283898
http://support.veritas.com/docs/283899
http://support.veritas.com/docs/283900
http://support.veritas.com/docs/283901
http://support.veritas.com/docs/283907
http://support.veritas.com/docs/283908
http://support.veritas.com/docs/283916
http://support.veritas.com/docs/283876
http://support.veritas.com/docs/283918
http://support.veritas.com/docs/283919
http://support.veritas.com/docs/283914
http://support.veritas.com/docs/283917
http://support.veritas.com/docs/283920
http://support.veritas.com/docs/283921
http://support.veritas.com/docs/283922
http://support.veritas.com/docs/283923
http://support.veritas.com/docs/283924
http://support.veritas.com/docs/283931
http://support.veritas.com/docs/283974
http://support.veritas.com/docs/284542
http://support.veritas.com/docs/284730
http://support.veritas.com/docs/285063
http://support.veritas.com/docs/285357
http://support.veritas.com/docs/285611
http://support.veritas.com/docs/286461
http://support.veritas.com/docs/286878
http://support.veritas.com/docs/288497
http://support.veritas.com/docs/288505
http://support.veritas.com/docs/288510
http://support.veritas.com/docs/290041
http://support.veritas.com/docs/290278
http://support.veritas.com/docs/290484
http://support.veritas.com/docs/291059
http://support.veritas.com/docs/292363
http://support.veritas.com/docs/292592
http://support.veritas.com/docs/293324
http://support.veritas.com/docs/294266
http://support.veritas.com/docs/294428
http://support.veritas.com/docs/294994
http://support.veritas.com/docs/295237
http://support.veritas.com/docs/297327
http://support.veritas.com/docs/297464
http://support.veritas.com/docs/297646
http://support.veritas.com/docs/297865
http://support.veritas.com/docs/300626
http://support.veritas.com/docs/302453
http://support.veritas.com/docs/303230
http://support.veritas.com/docs/303625
http://support.veritas.com/docs/303872
http://support.veritas.com/docs/305740
http://support.veritas.com/docs/306479
http://support.veritas.com/docs/306648
http://support.veritas.com/docs/307436
http://support.veritas.com/docs/307509
http://support.veritas.com/docs/307635
http://support.veritas.com/docs/308158
http://support.veritas.com/docs/308183
http://support.veritas.com/docs/309206
http://support.veritas.com/docs/310872
http://support.veritas.com/docs/311451
http://support.veritas.com/docs/311468
http://support.veritas.com/docs/311938
http://support.veritas.com/docs/314537
http://support.veritas.com/docs/315575
http://support.veritas.com/docs/316671
http://support.veritas.com/docs/316673
http://support.veritas.com/docs/316720
http://support.veritas.com/docs/316757
http://support.veritas.com/docs/317647
http://support.veritas.com/docs/319248
http://support.veritas.com/docs/319358
http://support.veritas.com/docs/320169
http://support.veritas.com/docs/320199
http://support.veritas.com/docs/320308
http://support.veritas.com/docs/322815
http://support.veritas.com/docs/322915
http://support.veritas.com/docs/324934
http://support.veritas.com/docs/338185
Supplemental Material:
| System: Ref.# | Description |
| ETrack: 633703 | Installer does not install package VRTSobweb |
| ETrack: 629042 | Upgrading from 3.5 MP4 to SF 5.0 fails to re-encapsulate the root disk. |
| ETrack: 601588 | Installation scripts fail to configure the system after upgrading from VxVM 3.5 MP4 to SF 5.0 |
| ETrack: 630009 | Installer didn't install VVR 5.0 patch 122058-01 while upgrading from VM only installation |
| ETrack: 794321 | SFRAC 5.0 Installation and Configuration Guide contains errors in the Creating the coordinator disk group Section |
| ETrack: 319114 | Incorrect statement for CRS on a Japanese operating system in SFRAC 5.0 Release Notes |
| ETrack: 928000 | DMP tunable changes not shown by prtconf |
| ETrack: 771998 | Added SFCFS support for Solaris 10 Local Zones |
| ETrack: 1067699 | SUN 6540/STK FLX200/300 series arrays, there is a known fencing issue with Persistent Group Reservation(PGR) keys |
| ETrack: 1099152 | VRTSvsvc is obsolete and needs to be removed |
| ETrack: 1087985 | VRTSvsvc issue: vxpal/vxsmf dumps core on reboot |
Products Applied:
Cluster Server for UNIX 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
File System for UNIX/Linux 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation Basic 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation Cluster File System 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation for DB2 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation for Oracle 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation for Oracle Real Application Clusters 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation for Sybase 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation for UNIX/Linux 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Volume Manager for UNIX/Linux 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Volume Replicator 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Cluster Server for UNIX 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
File System for UNIX/Linux 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation Basic 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation Cluster File System 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation for DB2 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation for Oracle 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation for Oracle Real Application Clusters 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation for Sybase 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Storage Foundation for UNIX/Linux 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Volume Manager for UNIX/Linux 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Volume Replicator 5.0 (Solaris), 5.0 MP1 (Solaris), 5.0 MP3 (Solaris)
Last Updated: January 26 2010 06:56 PM GMT
Expires on: 11-18-2010
Subscribe to receive critical updates about this document
Expires on: 11-18-2010
Subscribe to receive critical updates about this document
Subjects:
Cluster Server for UNIX
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
File System for UNIX/Linux
Application: Informational
Publishing Status: Documentation, Manuals
Storage Foundation Basic
Application: Informational
Publishing Status: Documentation, Manuals
Storage Foundation Cluster File System
Application: Documentation, Information, Release Notes
Publishing Status: Documentation, Manuals
Storage Foundation for DB2
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Storage Foundation for Oracle
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Storage Foundation for Oracle Real Application Clusters
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Storage Foundation for Sybase
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Storage Foundation for UNIX/Linux
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Volume Manager for UNIX/Linux
Application: Informational
Publishing Status: Documentation, Manuals
Volume Replicator
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Cluster Server for UNIX
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
File System for UNIX/Linux
Application: Informational
Publishing Status: Documentation, Manuals
Storage Foundation Basic
Application: Informational
Publishing Status: Documentation, Manuals
Storage Foundation Cluster File System
Application: Documentation, Information, Release Notes
Publishing Status: Documentation, Manuals
Storage Foundation for DB2
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Storage Foundation for Oracle
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Storage Foundation for Oracle Real Application Clusters
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Storage Foundation for Sybase
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Storage Foundation for UNIX/Linux
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Volume Manager for UNIX/Linux
Application: Informational
Publishing Status: Documentation, Manuals
Volume Replicator
Application: Documentation, Informational, Release Notes
Publishing Status: Documentation, Manuals
Languages:
English (US)
English (US)
Operating Systems:
Solaris
Solaris
10, 8.0, 9.0
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
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.