Veritas Storage Foundation

6.0.1 Release Notes - Linux

June 2014

Veritas Storage Foundation Release Notes

The software described in this book is furnished under a license agreement and may be used
only in accordance with the terms of the agreement.
Product version: 6.0.1
Document version: 6.0.1 Rev 4

Legal Notice
Copyright 2014 Symantec Corporation. All rights reserved.
Symantec, the Symantec Logo, the Checkmark Logo, Veritas, Veritas Storage Foundation,
CommandCentral, NetBackup, Enterprise Vault, and LiveUpdate are trademarks or registered
trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other
names may be trademarks of their respective owners.
The product described in this document is distributed under licenses restricting its use, copying,
distribution, and decompilation/reverse engineering. No part of this document may be
reproduced in any form by any means without prior written authorization of Symantec
Corporation and its licensors, if any.
THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED
CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED
WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR
NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH
DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL
NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION
WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE
INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE
WITHOUT NOTICE.
The Licensed Software and Documentation are deemed to be commercial computer software
as defined in FAR 12.212 and subject to restricted rights as defined in FAR Section 52.227-19
"Commercial Computer Software - Restricted Rights" and DFARS 227.7202, "Rights in
Commercial Computer Software or Commercial Computer Software Documentation", as
applicable, and any successor regulations. Any use, modification, reproduction release,
performance, display or disclosure of the Licensed Software and Documentation by the U.S.
Government shall be solely in accordance with the terms of this Agreement.

Symantec Corporation
350 Ellis Street
Mountain View, CA 94043
http://www.symantec.com

Technical Support
Symantec Technical Support maintains support centers globally. Technical Supports
primary role is to respond to specific queries about product features and functionality.
The Technical Support group also creates content for our online Knowledge Base.
The Technical Support group works collaboratively with the other functional areas
within Symantec to answer your questions in a timely fashion. For example, the
Technical Support group works with Product Engineering and Symantec Security
Response to provide alerting services and virus definition updates.
Symantecs support offerings include the following:

A range of support options that give you the flexibility to select the right amount
of service for any size organization

Telephone and/or Web-based support that provides rapid response and

up-to-the-minute information

Upgrade assurance that delivers software upgrades

Global support purchased on a regional business hours or 24 hours a day, 7

days a week basis

Premium service offerings that include Account Management Services

For information about Symantecs support offerings, you can visit our website at
the following URL:
www.symantec.com/business/support/index.jsp
All support services will be delivered in accordance with your support agreement
and the then-current enterprise technical support policy.

Contacting Technical Support

Customers with a current support agreement may access Technical Support
information at the following URL:
www.symantec.com/business/support/contact_techsupp_static.jsp
Before contacting Technical Support, make sure you have satisfied the system
requirements that are listed in your product documentation. Also, you should be at
the computer on which the problem occurred, in case it is necessary to replicate
the problem.
When you contact Technical Support, please have the following information
available:

Product release level

Hardware information

Available memory, disk space, and NIC information

Operating system

Version and patch level

Network topology

Router, gateway, and IP address information

Problem description:

Error messages and log files

Troubleshooting that was performed before contacting Symantec

Recent software configuration changes and network changes

Licensing and registration

If your Symantec product requires registration or a license key, access our technical
support Web page at the following URL:
www.symantec.com/business/support/

Customer service
Customer service information is available at the following URL:
www.symantec.com/business/support/
Customer Service is available to assist with non-technical questions, such as the
following types of issues:

Questions regarding product licensing or serialization

Product registration updates, such as address or name changes

General product information (features, language availability, local dealers)

Latest information about product updates and upgrades

Information about upgrade assurance and support contracts

Information about the Symantec Buying Programs

Advice about Symantec's technical support options

Nontechnical presales questions

Issues that are related to CD-ROMs or manuals

Support agreement resources

If you want to contact Symantec regarding an existing support agreement, please
contact the support agreement administration team for your region as follows:
Asia-Pacific and Japan

[email protected]

Europe, Middle-East, and Africa

[email protected]

North America and Latin America

[email protected]

Documentation
Product guides are available on the media in PDF format. Make sure that you are
using the current version of the documentation. The document version appears on
page 2 of each guide. The latest product documentation is available on the Symantec
website.
https://sort.symantec.com/documents
Your feedback on product documentation is important to us. Send suggestions for
improvements and reports on errors or omissions. Include the title and document
version (located on the second page), and chapter and section titles of the text on
which you are reporting. Send feedback to:
[email protected]
For information regarding the latest HOWTO articles, documentation updates, or
to ask a question regarding product documentation, visit the Storage and Clustering
Documentation forum on Symantec Connect.
https://www-secure.symantec.com/connect/storage-management/
forums/storage-and-clustering-documentation

About Symantec Connect

Symantec Connect is the peer-to-peer technical community site for Symantecs
enterprise customers. Participants can connect and share information with other
product users, including creating forum posts, articles, videos, downloads, blogs
and suggesting ideas, as well as interact with Symantec product teams and
Technical Support. Content is rated by the community, and members receive reward
points for their contributions.
http://www.symantec.com/connect/storage-management

Storage Foundation Release

Notes
This document includes the following topics:

About this document

Component product release notes

About Veritas Storage Foundation

About Symantec Operations Readiness Tools

Important release information

Changes introduced in SF 6.0.1

No longer supported

System requirements

SF: Issues fixed in 6.0.1

Known issues

Software limitations

Documentation

About this document

This document provides important information about Veritas Storage Foundation
(SF) version 6.0.1 for Linux. Review this entire document before you install or
upgrade SF.

Storage Foundation Release Notes

Component product release notes

The information in the Release Notes supersedes the information provided in the
product documents for SF.
This is "Document version: 6.0.1 Rev 4" of the Veritas Storage Foundation Release
Notes. Before you start, make sure that you are using the latest version of this
guide. The latest product documentation is available on the Symantec Web site at:
https://sort.symantec.com/documents

Component product release notes

In addition to reading this Release Notes document, review the component product
release notes before installing the product.
Product guides are available at the following location on the software media in PDF
formats:
/docs/product_name

Symantec recommends copying the files to the /opt/VRTS/docs directory on your

system.

About Veritas Storage Foundation

Veritas Storage Foundation by Symantec includes Veritas File System (VxFS) and
Veritas Volume Manager (VxVM.)
Veritas File System is a high performance journaling file system that provides easy
management and quick-recovery for applications. Veritas File System delivers
scalable performance, continuous availability, increased I/O throughput, and
structural integrity.
Veritas Volume Manager removes the physical limitations of disk storage. You can
configure, share, manage, and optimize storage I/O performance online without
interrupting data availability. Veritas Volume Manager also provides easy-to-use,
online storage management tools to reduce downtime.
VxFS and VxVM are included in all Veritas Storage Foundation products. If you
have purchased a Veritas Storage Foundation product, VxFS and VxVM are installed
and updated as part of that product. Do not install or update them as individual
components.
Veritas Storage Foundation includes the dynamic multi-pathing functionality.
The Veritas Replicator option, which replicates data to remote locations over an IP
network, can also be licensed with this product.
Before you install the product, read the Veritas Storage Foundation Release Notes.

Storage Foundation Release Notes

About Symantec Operations Readiness Tools

To install the product, follow the instructions in the Veritas Storage Foundation
Installation Guide.

About Symantec Operations Readiness Tools

Symantec Operations Readiness Tools (SORT) is a Web site that automates and
simplifies some of the most time-consuming administrative tasks. SORT helps you
manage your datacenter more efficiently and get the most out of your Symantec
products.
SORT can help you do the following:
Prepare for your next
installation or upgrade

Manage risks

Improve efficiency

List product installation and upgrade requirements, including

operating system versions, memory, disk space, and
architecture.
Analyze systems to determine if they are ready to install or
upgrade Symantec products.
Download the latest patches, documentation, and high
availability agents from a central repository.
Access up-to-date compatibility lists for hardware, software,
databases, and operating systems.
Get automatic email notifications about changes to patches,
array-specific modules (ASLs/APMs/DDIs/DDLs), and high
availability agents from a central repository.
Identify and mitigate system and environmental risks.

Display descriptions and solutions for hundreds of Symantec

error codes.

Find and download patches based on product version and

platform.
List installed Symantec products and license keys.

Tune and optimize your environment.

Note: Certain features of SORT are not available for all products. Access to SORT
is available at no extra cost.
To access SORT, go to:
https://sort.symantec.com

Storage Foundation Release Notes

Important release information

Important release information

For important updates regarding this release, review the Late-Breaking News
TechNote on the Symantec Technical Support website:
http://www.symantec.com/docs/TECH164885

For the latest patches available for this release, go to:

https://sort.symantec.com/

The hardware compatibility list contains information about supported hardware

and is updated regularly. For the latest information on supported hardware visit
the following URL:
http://www.symantec.com/docs/TECH170013
Before installing or upgrading Storage Foundation and High Availability Solutions
products, review the current compatibility list to confirm the compatibility of your
hardware and software.

Changes introduced in SF 6.0.1

This section lists the changes in Veritas Storage Foundation 6.0.1.

New versioning process for SFHA Solutions products

Symantec made some changes to simplify the versioning process to ensure that
customers have a unified experience when it comes to deploying our different
products across Storage, Availability, Backup, Archiving and Enterprise Security
products. With this change, all the products will have a 3 digit version. In complying
with this approach, the current SFHA Solutions release is available as version 6.0.1.

New directory location for the documentation on the software media

The PDF files of the product documentation are now located in the /docs directory
on the software media. Within the /docs directory are subdirectories for each of
the bundled products, which contain the documentation specific to that product.
The sfha_solutions directory contains documentation that applies to all products.

Changes related to installation and upgrades

The product installer includes the following changes in 6.0.1.

10

Storage Foundation Release Notes

Changes introduced in SF 6.0.1

Locally-installed installation and uninstallation scripts now

include the release version
When you run local scripts (/opt/VRTS/install) to configure Veritas products, the
names of the installed scripts now include the release version.
Note: If you install your Veritas product from the install media, continue to run the
installsf command without including the release version.
To run the script from the installed binaries, run the installsf<version> command.
Where <version> is the current release version with no periods or spaces.
For example, to configure the 6.0.1 version of your product, run this command:
# /opt/VRTS/install/installsf601 -configure

VxVM private region backup pre-checks for disk groups prior

to upgrade
The installer verifies that recent backups of configuration files of all the disk groups
in VxVM private region have been saved in the /etc/vx/cbr/bk directory prior
to doing an upgrade. If not, a warning message is displayed.
Warning: Backup /etc/vx/cbr/bk directory.

Support for tunables file templates

You can use the installer to create a tunables file template. If you start the installer
with the -tunables option, you see a list of all supported tunables, and the location
of the tunables file template.

Additional installation postcheck options

The postcheck option has been enhanced to include additional checks.
You can use the installers post-check option to perform the following checks:

General checks for all products.

Checks for Volume Manager (VM).

Checks for File System (FS).

Checks for Cluster File System (CFS).

11

Storage Foundation Release Notes

Changes introduced in SF 6.0.1

Changes related to Veritas Storage Foundation (SF)

Veritas Storage Foundation includes the following changes in 6.0.1:

Changes related to Veritas Volume Manager

Veritas Volume Manager (VxVM) includes the following changes in 6.0.1:

Enhancements to vxassist for controlling storage allocations and managing

volume intents
In this release, the vxassist command has been enhanced to provide more flexibility
and control in volume allocations and intent management.
The following list describes the enhancements:

A rich set of new predefined disk classes.

The new disk classes cover comprehensive characteristics of the available
storage. These disk properties are automatically discovered. You can use these
disk classes to select the required type of storage for allocations.

Ability to define alias names for predefined disk classes.

For administrative convenience, you can customize alias names that are shorter
or more user-friendly.

Ability to change the precedence order for the predefined disk classes that are
supported for mirror or stripe separation and confinement.
You can now customize the precedence order for the predefined disk classes
that are supported for mirror or stripe separation and confinement. The mirror
or stripe operation honors the higher priority disk class specified in the custom
precedence order.

Ability to define new disk classes.

You can associate user-defined properties to disks that satisfy a particular
criterion. This functionality enables you to customize device classification or
grouping. You can use these custom disk classes to specify storage selections.

New clauses for precise disk selection.

The new use and require clauses enable you to select storage from well-defined
sets of intended disk properties. The require type of clauses select disks from
an intersection set where all specified properties are met. The use type of clauses
select disks from a union set where at least one of the specified properties is
met. The use and require constraints are made persistent by default, for disk
group version 180 and onwards.

Management commands for the volume intents.

12

Storage Foundation Release Notes

Changes introduced in SF 6.0.1

Use the volume intent management commands to manage the use and require
type of persistent intents. You can set, clear, update, and list the use and require
intents for the volume, after the volume is created.
For more information about vxassist and these enhancements, see the
Administrator's Guide and the vxassist(1M) manual page.

Upgrade for instant snap Data Change Objects (DCOs)

Instant snap Data Change Objects (DCOs), formerly known as version 20 DCOs,
support the creation of instant snapshots for VxVM volumes. Starting with release
6.0, the internal format for instant DCOs changed. Upgrade the instant snap DCOS
and DCO volumes to ensure compatability with the latest version of VxVM. The
upgrade operation can be performed while the volumes are online.
The upgrade operation does not support upgrade from version 0 DCOs.
See the Administrator's Guide and the vxsnap(1M) manual page.

Dynamic Reconfiguration tool

Dynamic Multi-Pathing provides a Dynamic Reconfiguration tool. The Dynamic
Reconfiguration tool is an interactive tool to automate dynamic reconfiguration of
LUNs or HBAs. Dynamic reconfiguration includes addition, removal or replacement
of LUNs, and replacement of certain HBAs, without requiring a reboot. The Dynamic
Reconfiguration tool simplifies the process, so that you do not need a complex set
of DMP and operating system related commands.

Enhanced support for Fusion-io iodrive and iodrive2 on Linux

In this release, support for Fusion-io iodrive and iodrive2 is enhanced to support
TRIM operations. TRIM operations erase unused blocks of data to improve SSD
performance. The future writes on the Fusion-io cards are more efficient.
The SF components, Veritas File System (VxFS) and Veritas Volume Manager
(VxVM), use the TRIM operations to free up the blocks that do not contain valid
data. The TRIM cabaility is simliar to thin reclamation , and is performed with the
same commands.
SF supports the TRIM operation for Fusion-io devices for Red Hat Linux 6.0 (RHEL6)
and SUSE Linux Enterprise Server 11 (SLES11).

Changes related to Veritas File System

Veritas File System includes the following changes in 6.0.1:

13

Storage Foundation Release Notes

Changes introduced in SF 6.0.1

Support for Thin Reclamation on a Thin Reclaimable LUN and TRIMs for an
SSD on Linux
The fsadm -R command and the vxfs_ts_reclaim() call can perform Thin
Reclamation on a Thin Reclaimable LUN and TRIMs for an SSD. In a volume set,
the action taken is as per the type of device.
For more information, see the fsadm(1M) manual page.

The glmstat command can display GLM cache memory usage information
You can use the glmstat -M command to display GLM cache memory usage
information.
For more information, see the glmstat(1M) manual page.

The vxfsstat command can display pinned memory counters information

You can use the vxfsstat -m command to display pinned memory counters
information.
For more information, see the vxfsstat(1M) manual page.

SmartTier can compress or uncompress files

SmartTier can compress or uncompress files during relocation, or can perform
in-place compression or uncompression of an entire tier.
See the Administrator's Guide.

Changes related to SFDB tools

The following sections describe the changes related to Storage Foundation for
Databases (SFDB) tools in 6.0.1.

Support for FlashSnap and Database Storage Checkpoint for DB2

In this release, the SFDB tools support FlashSnap (Third-mirror break-off snapshots)
and Database Storage Checkpoint operations for DB2 databases.
You can capture an online image of actively changing data at a given instant: a
point-in-time copy. You can perform system backup, upgrade and other maintenance
tasks on point-in-time copies while providing continuous availability of your critical
data. You can also offload processing of the point-in-time copies onto another host.
Database FlashSnap lets you make backup copies of your volumes online and with
minimal interruption to users.
Database Storage Checkpoint quickly creates a persistent image of a file system
at an exact point in time. It reduces I/O overhead by identifying and maintaining

14

Storage Foundation Release Notes

Changes introduced in SF 6.0.1

only the file system blocks that have changed since the last Storage Checkpoint or
backup via a copy-on-write technique.

Support for creation of Golden Image snapshots using FlashSnap for Oracle
In this release, the SFDB tools support the creation of Golden Image snapshots
using FlashSnap for Oracle databases.
Online mode, third-mirror-break-off type snapshot i.e. online FlashSnap snapshot
of a database instance contains all the information needed to create a clone of the
database instance. It can act as a template for creating clone database instances.
You can thus allocate a FlashSnap snapshot that can be used as a master copy
for creating one or more clone instances. The clone instances created from a
FlashSnap image, termed as the 'golden image', are incremental copies of the
master or the golden image. These depend on the FlashSnap image for their
operations.

Support for Flashsnap at the VVR Secondary site for Oracle

In this release, the SFDB tools support Flashsnap operation at the VVR Secondary
site for Oracle databases.
Online mode snapshots (i.e. traditional, third-mirror-break-off snapshots) are
supported in VVR replication environment. Also, support for more than one
secondary site is added. For online mode snapshots in VVR environment, IBC
(In-Band Control) messages are used to synchronize activities on the Primary and
Secondary sites. Snapshot is initiated from VVR Secondary site.

Introduction of the Compression Advisor tool for Oracle

In this release, the SFDB tools provide the Compression Advisor tool for Oracle
databases.
Veritas File System (VxFS) provides the vxcompress utility that can be used to
compress individual files transparent to the underlying applications. An application
reading a compressed file automatically receives the uncompressed data that is
uncompressed in memory only; the on-disk part of the data remains compressed.
If an application writes to a compressed file, parts of the file are uncompressed on
disk.
Compression Advisor provides extended compression functionality for Oracle
database files in Oracle single instance and Oracle RAC environments. The
Compression Advisor command sfae_comp_adm resides in the /opt/VRTS/bin
directory, and it must be run by the DBA user.

15

Storage Foundation Release Notes

Changes introduced in SF 6.0.1

Changes related to replication

Veritas Storage Foundation and High Availability Solutions includes the following
changes related to replication in 6.0.1:

Protection of the VFR target file system from accidental writes (on Linux)
The protected=off|on option of the mount_vxfs command protects the target file
system from accidental writes. Modifications to the target file system by anything
other than the file replication job may cause replication to fail. The new
protected=off|on option mounts the file system at the target system as read-write,
and only allows the replication daemon to apply updates, thus preventing accidental
writes that could cause replication to fail.

Finer granularity of replication at the file and directory level using VFR
consistency groups (on Linux)
VxFS supports replication at the file and directory level to a single target using a
consistency group. A consistency group consists of an include list and an exclude
list, which specify a combination of files and directories within a file system that
needs to be replicated as a single consistent unit, and files and directories that
should not be replicated, respectively. Both include and exclude lists are optional,
and if no path is specified in the include list, the entire file system is replicated. The
consistency group must be configured on both the source and the target systems.

VVR CPU utilization improvements with fine granular locking and

optimizations
CPU usage is reduced due to VVR lock and code optimization. I/O throughput is
improved due to faster I/O processing.

CPU utilization improvements and memory optimizations in VVR

compression engine
CPU usage is reduced while compression is enabled. The reduced CPU footprint
is achieved by memory pre-allocation optimizations, and changing the compression
window size and memory levels to provide optimum compression performance.

VVR replication performance improvements in TCP protocol

Overall improvement of replication throughput due to introducing the following:

An I/O throttling implementation at the VVR layer to improve network bandwidth

usage for TCP. (Not applicable to UDP protocol).

Per RVG read-back memory pool to avoid contention of memory between the
RVGs in the SRL read-back.

16

Storage Foundation Release Notes

Changes introduced in SF 6.0.1

A separate read-back thread to read the data from the SRL. This is disabled by
default.

Improved resiliency in case of VVR data volume failure in clustered storage

environments using CVM I/O shipping framework
In the event of a data volume failure, there may be some writes to the SRL that do
not also write to the data volume due to an I/O failure. To make the data consistent,
the writes are flushed to the data volume. In previous releases, there was no
mechanism to flush the writes from the node with storage connectivity; to avoid
data inconsistency, the data volume was detached cluster wide. Using the I/O
shipping framework, in flight I/Os (where the I/O finishes on the SRL but does not
write to the data volume) are now shipped to the node with storage connectivity
and written to the data volume. As a result, the data volume remains consistent
and is available on all nodes that have storage connectivity.

Changes in supported Linux virtualization technologies

Veritas Storage Foundation and High Availability (SFHA) Solutions 6.0.1 products
support the following virtualization technologies in Linux environments:

Kernel-based Virtual Machine (KVM) technology for Red Hat Enterprise Linux
(RHEL)

Kernel-based Virtual Machine (KVM) technology for SUSE Linux Enterprise

Server (SLES)

SFHA Solutions products provide the following functionality for KVM guest virtual
machines:

Storage visibility

Storage management

High availability

Cluster failover

Replication support

Table 1-1

SFHA Solutions supported configurations in guest and host for KVM

technologies

Objective

Recommended SFHA
Solutions product
configuration

KVM technology

Storage visibility for KVM

guest virtual machines

Dynamic Multi-Pathing (DMP) in RHEL

the KVM guest virtual machines
SLES

17

Storage Foundation Release Notes

Changes introduced in SF 6.0.1

Table 1-1

SFHA Solutions supported configurations in guest and host for KVM

technologies (continued)

Objective

Recommended SFHA
Solutions product
configuration

KVM technology

Storage visibility for KVM

hosts

DMP in the KVM hosts

RHEL
SLES

Storage management
Storage Foundation (SF) in the
features and replication
KVM guest virtual machines
support for KVM guest virtual
machines

RHEL

Advanced storage
management features and
replication support for KVM
hosts

RHEL

Storage Foundation Cluster File

System (SFCFSHA) in the KVM
hosts

SLES

SLES

End-to-end storage visibility DMP in the KVM host and guest RHEL
in KVM hosts and guest
virtual machines
SLES
virtual machines
Storage management
DMP in the KVM host and SF in
features and replication
the KVM guest virtual machines
support in the KVM guest
virtual machines and storage
visibility in in the KVM host

RHEL

Application monitoring and

availability for KVM guest
virtual machines

Symantec ApplicationHA in the

KVM guest virtual machines

RHEL

Virtual machine monitoring

and failover for KVM hosts

Veritas Cluster Server (VCS) in

the KVM hosts

RHEL

Application failover for KVM VCS in the KVM guest virtual

guest virtual machines
machines
Application availability and
virtual machine availability

SLES

SLES
RHEL
SLES

Symantec Application HA in the RHEL

KVM guest virtual machines and
VCS in the KVM host

Application failover across

VCS in KVM guest virtual
RHEL
KVM guest virtual machines machines and KVM physical host
SLES
and physical hosts
machines

18

Storage Foundation Release Notes

No longer supported

VCS provides virtual to virtual (in-guest) clustering support for the following Linux
virtualization environments:

Red Hat Enterprise Virtualization (RHEV)

Microsoft Hyper-V

Oracle Virtual Machine (OVM)

For implementation details:

See the Veritas Storage Foundation and High Availability Solutions Virtualization
Guide for Linux.
For VMware support, see Veritas Storage Foundation in a VMware ESX
Environment.

No longer supported
The following features are not supported in this release of SF products:

The fsppmk command is deprecated and can no longer be used to create

SmartTier placement policies.

Veritas Storage Foundation for Databases (SFDB) tools features

which are no longer supported
The following Storage Foundation for Databases (SFDB) tools features are not
supported in this release:

FlashSnap reverse resync

Checkpoint policy and Checkpoint quotas

Interactive modes in clone and rollback

System requirements
This section describes the system requirements for this release.

Supported Linux operating systems

This section lists the supported operating systems for this release of Veritas
products. For current updates, visit the Symantec Operation Readiness Tools
Installation and Upgrade page: https://sort.symantec.com/land/install_and_upgrade.
Table 1-2 shows the supported operating systems for this release.

19

Storage Foundation Release Notes

System requirements

Table 1-2

Supported operating systems

Operating systems

Levels

Kernel version

Red Hat Enterprise Linux 6

Update 1, 2, 3 2.6.32-131.0.15.el6
2.6.32-220.el6

Chipsets
64-bit x86,
EMT*/Opteron 4.1
64-bit only

2.6.32-279.el6
Red Hat Enterprise Linux 5

Update 5, 6, 7, 2.6.18-194.el5
8, 9
2.6.18-238.el5

64-bit x86,
EMT*/Opteron 4.1
64-bit only

2.6.18-274.el5
2.6.18-308.el5
2.6.18-348.el5
SUSE Linux Enterprise 11

SP1, SP2

2.6.32.12-0.7.1
3.0.13-0.27.1

SUSE Linux Enterprise 10

SP4

2.6.16.60-0.85.1

Oracle Linux 6

Update 1, 2, 3 2.6.32-131.0.15.el6
2.6.32-220.el6

64-bit x86,
EMT*/Opteron 4.1
64-bit only
64-bit x86,
EMT*/Opteron 4.1
64-bit only
64-bit x86,
EMT*/Opteron 4.1
64-bit only

2.6.32-279.el6
Oracle Linux 5

Update 5, 6, 7, 2.6.18-194.el5
8, 9
2.6.18-238.el5

64-bit x86,
EMT*/Opteron 4.1
64-bit only

2.6.18-274.el5
2.6.18-308.el5
2.6.18-348.el5

* Extended Memory Technology

Note: Only 64-bit operating systems are supported.

Note: For SLES11 SP2 kernel versions later than February, 2012, you need to apply
the following Veritas patch: sf-sles11_x86_64-6.0.1.100. This patch is available on
the patch download page at https://sort.symantec.com/patch/detail/6732.

20

Storage Foundation Release Notes

System requirements

If your system is running an older version of either Red Hat Enterprise Linux, SUSE
Linux Enterprise Server, or Oracle Linux, upgrade it before attempting to install the
Veritas software. Consult the Red Hat, SUSE, or Oracle documentation for more
information on upgrading or reinstalling your operating system.
Symantec supports only Oracle, Red Hat, and SUSE distributed kernel binaries.
Symantec products operate on subsequent kernel and patch releases provided the
operating systems maintain kernel Application Binary Interface (ABI) compatibility.

Mandatory patch required for Oracle Bug 4130116

If you are running Oracle versions 9.2.0.6 or 9.2.0.7, you must apply the Oracle
patch for Oracle Bug 4130116. Contact Oracle to obtain this patch, and for details
on how to apply it.
For more information, refer to the following TechNote:
http://www.symantec.com/docs/HOWTO19718

Storage Foundation for Databases features supported in database

environments
Storage Foundation for Databases (SFDB) product features are supported for the
following database environments:
Table 1-3

SFDB features supported in database environments

Veritas Storage
Foundations feature

DB2

Oracle

Oracle
RAC

Sybase

Sybase
ASE CE

Oracle Disk Manager

No

Yes

Yes

No

No

Cached Oracle Disk Manager No

Yes

No

No

No

Concurrent I/O

Yes

Yes

Yes

Yes

Yes

Storage Checkpoints

Yes

Yes

Yes

Yes

Yes

Flashsnap

Yes

Yes

Yes

Yes

Yes

SmartTier

Yes

Yes

Yes

Yes

Yes

Database Storage
Checkpoints

Yes

Yes

Yes

No

No

Note: Requires Enterprise

license

21

Storage Foundation Release Notes

SF: Issues fixed in 6.0.1

Table 1-3

SFDB features supported in database environments (continued)

Veritas Storage
Foundations feature

DB2

Oracle

Oracle
RAC

Sybase

Sybase
ASE CE

Database Flashsnap

Yes

Yes

Yes

No

No

No

Yes

Yes

No

No

Note: Requires Enterprise

license
SmartTier for Oracle

Note: Requires Enterprise

license

Notes:

SmartTier is an expanded and renamed version of Dynamic Storage Tiering

(DST).

Storage Foundation for Databases (SFDB) tools Database Checkpoints,

Database Flashsnap, and SmartTier for Oracle are supported with an Enterprise
product license.

For the most current information on Storage Foundation products and single instance
Oracle versions supported, see:
http://www.symantec.com/docs/DOC4039
Review the current Oracle documentation to confirm the compatibility of your
hardware and software.

Veritas Storage Foundation memory requirements

Symantec recommends 2 GB of memory over the minimum requirement for the
operating system.

SF: Issues fixed in 6.0.1

This section covers the incidents that are fixed in SF 6.0.1.

Installation and upgrades: issues fixed in 6.0.1

This section describes the incidents that are fixed related to installation and upgrades
in this release.

22

Storage Foundation Release Notes

SF: Issues fixed in 6.0.1

Table 1-4

Fixed issues related to installation and upgrades

Incident

Description

2329580

Unable to stop some SFCFSHA processes.

2873102

Perl module error on completion of SFHA installation

2627076

Incorrect server names sometimes display if there is a clock

synchronization issue.

2622987

sfmh discovery issue when you upgrade your Veritas product to 6.0.1

2585899

On RHEL, unable to create storage for OCR and Vote disk when using
FQDN instead of using only the node name.

2526709

DMP-OSN tunable value not get persistence after upgrade from 5.1SP1
to 6.0.

2088827

During product migration the installer overestimates disk space use.

Installation and upgrades: Issues fixed in 6.0 RP1

There are no new fixed incidents for installation and upgrades in 6.0 RP1.

Veritas Storage Foundation fixed issues

Issues fixed for Veritas Storage Foundation (SF) includes issues fixed for Veritas
File System and Veritas Volume Manager.
See Veritas File System: issues fixed in 6.0.1 on page 23.
See Veritas Volume Manager: issues fixed in 6.0.1 on page 26.

Veritas File System: issues fixed in 6.0.1

This section describes the incidents that are fixed in Veritas File System in this
release.
Table 1-5

Veritas File System fixed issues

Incident

Description

2764861

Uncompress by vxcompress ignores quota limitation.

2753944

The file creation threads can hang.

2735912

The performance of tier relocation using fsppadm enforce is poor when moving
a large amount of files.

23

Storage Foundation Release Notes

SF: Issues fixed in 6.0.1

Table 1-5

Veritas File System fixed issues (continued)

Incident

Description

2712392

Threads hung in VxFS.

2709869

System panic with redzone violation when vx_free() tried to free fiostat.

2682550

Access a VxFS file system via NFS could cause system panic on Linux while
unmount is in progress.

2674639

The cp(1) command with the p option may fail on a file system whose File
Change Log (FCL) feature is enabled. The following error messages are
displayed: cp: setting permissions for 'file_name': Input/output error cp:
preserving permissions for 'file_name': No data available.

2670022

Duplicate file names can be seen in a directory.

2655788

Using cross-platform data sharing to convert a file system that has more than
32k nlinks does not update the vx_maxlink and maxlink_enable tunables.

2651922

ls -l command on local VxFS file system is running slow and high CPU usage
is seen.

2597347

fsck should not coredump when only one of the device record has been
corrupted and the replica is intact.

2584531

vxfs hangs on ls, du and find.

2566875

The write(2) operation exceeding the quota limit fails with an EDQUOT error
(Disc quota exceeded) before the user quota limit is reached.

2559450

Command fsck_vxfs(1m) may core-dump with SEGV_ACCERR error.

2536130

fscdsconv fails to convert FS between specific platforms if FCL is enabled.

2272072

GAB panics the box because VCS engine HAD did not respond. The lobolt
wraps around.

2086902

Spinlock held too long on vxfs spinlock, and there is high contention for it.

1529708

Formatting issue with the output of vxrepquota.

Veritas File System: Issues fixed in 6.0 RP1

This section describes the incidents that are fixed in Veritas File System (VxFS) in
6.0 RP1.

24

Storage Foundation Release Notes

SF: Issues fixed in 6.0.1

Table 1-6

Veritas File System 6.0 RP1 fixed issues

Fixed
issues

Description

2679361

Network Customization screen doesn't show any NICs in I18N-level0

environment.

2678096

The fiostat command dumps core when the count value is 0.

2672201

Certain commands get blocked by kernel, causing EACCES(ERRNO = 13).

2672148

vxdelestat (1M) when invoked with -v option goes into infinite loop.

2663750

Abrupt messages are seen in engine log after complete storage failure in cvm
resiliency scenario.

2655786

Shared' extents are not transferred as 'shared' by the replication process.

2655754

Deadlock because of wrong spin lock interrupt level at which delayed allocation
list lock is taken.

2653845

When the fsckptadm(1M) command with the '-r' and '-R' option is executed,
two mutually exclusive options gets executed simultaneously.

2649367

Kernel crashes in vx_fopen because of NULL pointer dereference.

2646936

The replication process dumps core when shared extents are present in the
source file system.

2646930

Permission denied errors(EACCES) seen while doing I/O's on nfs shared

filesystem.

2645435

The following error message is displayed during the execution of the

fsmap(1M) command:'UX:vxfs fsmap: ERROR: V-3-27313'.

2645112

write operation on a regular file mapping to shared compressed extent results

in corruption.

2645109

In certain rare cases after a successful execution of vxfilesnap command, if

the source file gets deleted in a very short span of time after the filesnap
operation, then the destination file can get corrupted and this could also lead
to setting of VX_FULLFSCK flag in the super block.

2645108

In certain cases write on a regular file which has shared extent as the last
allocated extent can fail with EIO error.

2634483

On RHEL6U1 writing to VxFS /proc hidden interface fails with EINVAL.

2630954

The fsck(1M) command exits during an internal CFS stress reconfiguration

testing.

25

Storage Foundation Release Notes

SF: Issues fixed in 6.0.1

Table 1-6

Veritas File System 6.0 RP1 fixed issues (continued)

Fixed
issues

Description

2613884

Metadata corruption may be seen after recovery.

2609002

The De-duplication session does not complete.

2599590

Expanding or shrinking a DLV5 file system using the fsadm(1M)command

causes a system panic.

2583197

Upgrade of a file system from version 8 to 9 fails in the presence of partition

directories and clones.

2552095

The system may panic while re-organizing the file system using the fsadm(1M)
command.

2536130

The fscdsconv(1M) command which is used to convert corrupted or non-VxFS

file systems generates core.

2389318

Enabling delayed allocation on a small file system sometimes disables the

file system.

Veritas Volume Manager: issues fixed in 6.0.1

This section describes the incidents that are fixed in Veritas Volume Manager in
this release. This list includes Veritas Volume Replicator fixed issues.
Table 1-7

Veritas Volume Manager fixed issues

Incident

Description

2838059

VVR Secondary panic in vol_rv_update_expected_pos.

2832784

ESX panicked after applying a template file from GUI.

2826958

The pwwn number is not displayed in the output of command vxdmpadm

list dmpnode dmpnodename=dmpnode name.

2818840

Enhance the vxdmpraw utility to support permission and "root:non-system"

ownership to be set and make it persistent.

2794625

Unable to configure ASM to use DMP native block device path.

2792242

I/O hang after performing zone remove/add operations.

2774406

The svol_flush_srl_to_dv_start fails to start.

2771452

IO hung because of hung port deletion.

26

Storage Foundation Release Notes

SF: Issues fixed in 6.0.1

Table 1-7

Veritas Volume Manager fixed issues (continued)

Incident

Description

2763206

The vxdisk rm command core dumps when list of disknames is very long.

2756059

Panic in voldco_or_drl_to_pvm when volume started at boot.

2754819

Live deadlock seen during disk group rebuild when the disk group contains
cache object.

2751102

Random panics seen in vx_worklist_thr on SLES11 and VxFS.

2747032

Write is taking long time to complete when read/write happen simultaneously.

2743926

DMP restored daemon fails to restart during system boot.

2741240

The vxdg join transaction failed and did not rollback to the sourcedg.

2739709

Disk group rebuild related issues.

2739601

VVR: repstatus output occasionally reports abnormal timestamp.

2737420

The vxconfigd daemon dumps core while onlining of the disk.

2729501

Exclude path not working properly and can cause system hang while coming
up after enabling native support.

2726148

System unbootable after /usr/lib/vxvm/bin/vxupdatelvm script

updates filter in lvm.conf file.

2721807

Root disk encapsulation: On SLES11 SP2, machine went to maintenance

mode during final reboot after encap.

2711312

Missing symbolic link is created after pulling FC cable on RHEL6.

2710579

Do not write backup labels for CDS disk - irrespective of disk size.

2710147

Node panics in dmp_pr_do_reg during key registration with fencing enabled.

2709743

Inplace upgrade is not working from 6.0.

2701654

Phantom DMP disk partition causes panic.

2700792

SEGV in vxconfigd daemon during CVM startup.

2700486

The vradmind daemon coredumps when Primary and Secondary have the
same hostname and an active Stats session exists on Primary.

2700086

EMC BCV (NR) established devices are resulting in multiple DMP events
messages (paths being disabled/enabled).

27

Storage Foundation Release Notes

SF: Issues fixed in 6.0.1

Table 1-7

Veritas Volume Manager fixed issues (continued)

Incident

Description

2698860

The vxassist mirror command failed for thin LUN because statvfs failed.

2689845

After upgrade, some VxVM disks changed to error status and the disk group
import failed.

2688747

Logowner local sequential I/Os starved with heavy I/O load on logclient.

2688308

Do not disable other disk groups when a re-import of a disk group fails during
master take-over.

2680482

Empty vx.* directories are left in the /tmp directory.

2679917

Corrupt space optimized snapshot after a refresh with CVM master switching.

2675538

The vxdisk resize command may cause data corruption.

2664825

Disk group import fails when disk contains no valid UDID tag on config copy
and config copy is disabled.

2660151

The vxconfigd daemon is generating a series of LVM header messages

for devices (CLONES/replicated devices). Secondary EMC MirrorView LUNS
in an error state.

2656803

Race between vxnetd start and stop operations causes panic.

2652485

Inactive snapshot LUNs cause trespassing.

2644248

The vxunroot command fails as root partition "logvol" mounted on

/var/log.

2643634

Message enhancement for a mixed (non-cloned and cloned) disk group import.

2627126

Lots of I/Os and paths are stuck in dmp_delayq and dmp_path_delayq

respectively. DMP daemon did not wake up to process them.

2626199

The vxdmpadm list dmpnode printing incorrect path type.

2623182

vxvm-boot not cleaning up /tmp/vx.* directories whenever system reboot

is done for Linux environment.

2612301

Upgrading kernel on encapsulated boot disk does not work on Red Hat
Enterprise Linux (RHEL) 5, 6, and SUSE Linux Enterprise Server (SLES) 10.

2607706

Encapsulation of a multi-pathed root disk fails if the dmpnode name and any
of its path names are not the same.

28

Storage Foundation Release Notes

SF: Issues fixed in 6.0.1

Table 1-7

Veritas Volume Manager fixed issues (continued)

Incident

Description

2580393

Removal of SAN storage cable on any node brings Oracle Application Groups
down on all nodes.

2566174

Null pointer dereference in volcvm_msg_rel_gslock().

2564092

Automate the LUN provisioning (addition) / removal steps using vxdiskadm.

2553729

Status of the EMC Clariion disk changed to "online clone_disk" after upgrade.

2486301

"VXFS" RPM installation failed.

2441283

The vxsnap addmir command sometimes fails under heavy I/O load.

2427894

Opaque disk support for VIS appliance.

2249445

Develop a tool to get the disk-related attributes like geometry, label, media
capacity, partition info etc.

2240056

The vxdg move transaction not completing and backups fail.

2227678

The second rlink gets detached and does not connect back when overflowed
in a multiple-secondaries environment.

1675482

The vxdg list dgname command gives error 'state=new failed'.

1533134

DMP: depreciated SCSI ioctl use sg_io type of error.

1190117

vxdisk -f init can overwrite some of the public region contents.

2698035

Tunable values do not change as per the values applied through vxtune.

2682491

The vxvmconvert command displays an error message while converting an

LVM volume.

Veritas Volume Manager: Issues fixed in 6.0 RP1

This section describes the incidents that are fixed in Veritas Volume Manager
(VxVM) in 6.0 RP1.
Table 1-8

Veritas Volume Manager 6.0 RP1 fixed issues

Fixed
issues

Description

2674465

Data Corruption while adding/removing LUNs.

29

Storage Foundation Release Notes

SF: Issues fixed in 6.0.1

Table 1-8

Veritas Volume Manager 6.0 RP1 fixed issues (continued)

Fixed
issues

Description

2666163

A small portion of possible memory leak introduced due to addition of

enhanced messages.

2660151

vxconfigd is generating a series of LVM header messages for devices

(CLONES/replicated devices)Secondary EMC MirrorView LUNS in an error
state.

2657797

Starting 32TB RAID5 volume fails with unexpected kernel error in configuration
update.

2649958

vxdmpadm dumps core due to null pointer reference.

2647795

Intermittent data corruption after a vxassist move.

2629429

vxunroot does not set original menu.lst and fstab files, SUSE 10.0 NETAPP
FAS3000 ALUA SANBOOT.

2627056

vxmake -g <DGNAME> -d <desc-file> fails with very large configuration due

to memory leaks.

2626741

Using vxassist -o ordered and mediatype:hdd options together do not work

as expected.

2621465

When detached disk after connectivity restoration is tried to reattach gives

'Tagid conflict' error.

2620556

I/O hung after SRL overflow.

2620555

I/O hang due to SRL overflow and CVM reconfig.

2608849

Logowner local I/O starved with heavy I/O load from Logclient.

2607519

Secondary master panics in case of reconfig during autosync.

2607293

Primary master panic'ed when user deleted frozen RVG.

2605702

Bail out initialising disk with large sector size and its foreign device.

2600863

vxtune doesn't accept tunables correctly in human readable format.

2591321

while upgrading dg version if rlink is not up-to-date the vxrvg command shows
error but dg version gets updated.

2590183

write fails on volume on slave node after join which earlier had disks in "lfailed"
state.

30

Storage Foundation Release Notes

SF: Issues fixed in 6.0.1

Table 1-8

Veritas Volume Manager 6.0 RP1 fixed issues (continued)

Fixed
issues

Description

2576602

vxdg listtag should give error message and display correct usage when
executed with wrong syntax.

2575581

vxtune -r option is printing wrong tunable value.

2574752

Support utility vxfmrmap (deprecating vxfmrshowmap) to display DCO map

contents and verification against possible state corruptions.

2565569

read/seek i/o errors during init/define of nopriv slice.

2562416

vxconfigbackup throws script errors due to improper handling of arguments.

2556467

disabling all paths and rebooting host causes /etc/vx/.vxdmprawdev record

loss.

2535142

New crash was detected on RHEL6.1 during upgrade due to mod unload,
possibly of vxspec.

2530698

after "vxdg destroy" hung (for shared DG), all vxcommands hang on master.

2526498

Memory leaks seen in some I/O code path.

2516584

startup scripts use 'quit' instead of 'exit', causing empty directories in /tmp.

2402774

Install Upgrade : After upgrade to 6.0 encapsulated root disk is marked as

'clone_disk'.

2348180

Failure during validating mirror name interface for linked mirror volume.

2176084

Intermittent failure to start ESD on a node.

1765916

Correcting World Writable and unapproved file permissions.

Storage Foundation for Databases (SFDB) tools: issues fixed in 6.0.1

Table 1-9 describes the Veritas Storage Foundation for Databases (SFDB) tools
issues fixed in this release.

31

Storage Foundation Release Notes

Known issues

Table 1-9

32

SFDB tools fixed issues

Incident Description
2585643 If you provide an incorrect host name with the -r option of vxsfadm, the command
fails with an error message similar to one of the following:
FSM Error: Can't use string ("") as a HASH ref while
"strict refs" in use at /opt/VRTSdbed/lib/perl/DBED/SfaeFsm.pm
line 776. SFDB vxsfadm ERROR V-81-0609 Repository location is
invalid.
The error messages are unclear.
2703881 The FlashSnap validation operation fails with the following error if the mirrors for
(2534422) data volumes and archive log volumes share the same set of disks:
SFAE Error:0642: Storage for diskgroup oradatadg is not
splittable.

2582694 After you have done FlashSnap cloning using a snapplan, any further attempts to
(2580318) create a clone from the same snapplan using the dbed_vmclonedb continue to
use the original clone SID, rather than the new SID specified using the new_sid
parameter. This issue is also observed when you resynchronize the snapplan,
take a snapshot again without specifying the new clone SID, and then try to clone
with the new SID.
2579929 The sfae_auth_op -o auth_user command, used for authorizing users, fails
with the following error message:
SFDB vxsfadm ERROR V-81-0384 Unable to store credentials
for <username>
The authentication setup might have been run with a strict umask value, which
results in the required files and directories being inaccessible to the non-root users.

Known issues
This section covers the known issues in this release.

Installation known issues

This section describes the known issues during installation and upgrade.

Storage Foundation Release Notes

Known issues

NetBackup 6.5 or older version is installed on a VxFS file

system (2056282)
If you have NetBackup 6.5 or older version installed on a VxFS file system and
before upgrading to Veritas Storage Foundation (SF) 6.0.1, if you unmount all VxFS
file systems including the one that hosts the NetBackup binaries (/usr/openv),
then while upgrading to SF 6.0.1, the installer fails to check if NetBackup is installed
on the same machine and uninstalls the shared infrastructure RPMs VRTSpbx,
VRTSat, and VRTSicsco. This causes NetBackup to stop working.
Workaround: Before you unmount the VxFS file system that hosts NetBackup,
copy the /usr/openv/netbackup/bin/version file and
/usr/openv/netbackup/version file to the /tmp directory. If you have clustered
NetBackup installed, you must also copy the
/usr/openv/netbackup/bin/cluster/NBU_RSP file to the /tmp directory. After you
unmount the NetBackup file system, manually copy these two version files from
/tmp to their original directories. If you have clustered NetBackup installed, you
must also copy the /usr/openv/netbackup/bin/cluster/NBU_RSP file from /tmp
to its original directory.
If the version files' directories do not exist, create the directories:
# mkdir -p /usr/openv/netbackup/bin

Run the installer to finish the upgrade process. After upgrade process completes,
remove the two version files and their directories.
If your system is already affected by this issue, then you must manually install the
VRTSpbx, VRTSat, and VRTSicsco RPMs after the upgrade process completes.

Error messages in syslog (1630188)

If you install or uninstall a product on a node, you may see the following warnings
in syslog: /var/log/message. These warnings are harmless and can be ignored.
Jul 6 10:58:50 swlx62 setroubleshoot: SELinux is preventing the
semanage from using potentially mislabeled files
(/var/tmp/installer-200907061052eVe/install.swlx62.VRTSvxvm). For
complete SELinux messages. run sealert -l ed8978d1-0b1b-4c5b-a08667da2a651fb3
Jul 6 10:58:54 swlx62 setroubleshoot: SELinux is preventing the
semanage from using potentially mislabeled files
(/var/tmp/installer-200907061052eVe/install.swlx62.VRTSvxvm). For
complete SELinux messages. run sealert -l ed8978d1-0b1b-4c5b-a08667da2a651fb3

33

Storage Foundation Release Notes

Known issues

Jul 6 10:58:59 swlx62 setroubleshoot: SELinux is preventing the

restorecon from using potentially mislabeled files

Ignore certain errors after an operating system upgradeafter

a product upgrade with encapsulated boot disks (2030970)
Ignore certain errors after an operating system upgrade after a product upgrade
with encapsulated boot disks.
You can ignore the following errors after you upgrade the operating system after a
product upgrade that occurred with an encapsulated boot disk. Examples of the
errors follow:
The partioning on disk /dev/sda is not readable by
The partioning tool parted, which is used to change the
partition table.
You can use the partitions on disk /dev/sda as they are.
You can format them and assign mount points to them, but you
cannot add, edit, resize, or remove partitions from that
disk with this tool.

Or
Root device: /dev/vx/dsk/bootdg/rootvol (mounted on / as reiserfs)
Module list: pilix mptspi qla2xxx silmage processor thermal fan
reiserfs aedd (xennet xenblk)
Kernel image; /boot/vmlinuz-2.6.16.60-0.54.5-smp
Initrd image: /boot/initrd-2.6.16.60-0.54.5-smp

The operating system upgrade is not failing. The error messages are harmless.
Workaround: Remove the /boot/vmlinuz.b4vxvm and /boot/initrd.b4vxvm files (from
an un-encapsulated system) before the operating system upgrade.

Upgrading from Veritas Storage Foundation 5.1 Service Pack

1 Rolling Patch 2 to 6.0.1 with rootability enabled fails
(2581313)
Upgrading from Veritas Storage Foundation (SF) 5.1 Service Pack (SP) 1 Rolling
Patch (RP) 2 to 6.0.1 while using an encapsulated root disk fails because the post
installation scripts of Veritas Volume Manager (VxVM) are unable to start the initrd
daemon.
Workaround: To upgrade from 5.1 SP1 RP2 to 6.0.1 while using an encapsulated
root disk, you must reinstall the nash utility on the system prior to the upgrade.

34

Storage Foundation Release Notes

Known issues

To upgrade from 5.1 SP1 RP2 to 6.0.1 while using an encapsulated root disk

Encapsulate the root disk.

Reinstall the nash utility.

Upgrade to the SF 6.0.1 release.

During upgrade from 5.1SP1 with an encapsulated root disk,

splitting the root mirror fails if the target disk group name is
used by a deported disk group (2280560)
During an upgrade from SF 5.1 SP1 with an encapsulated root disk, splitting the
root mirror fails if the target disk group name for the split operation is used by an
existing deported disk group.
Workaround:
Specify a different disk group name as a target for the split operation.

Web installer does not ask for authentication after the first
session if the browser is still open (2509330)
If you install or configure SF and then close the Web installer, if you have other
browser windows open, the Web installer does not ask for authentication in the
subsequent sessions. Since there is no option to log out of the Web installer, the
session remains open as long as the browser is open on the system.
Workaround: Make sure that all browser windows are closed to end the browser
session and subsequently log in again.

Stopping the Web installer causes Device Busy error messages

(2633924)
If you start the Web installer, and then perform an operation (such as prechecking,
configuring, or uninstalling), you may get an error message saying the device is
busy.
Workaround: Do one of the following:

Kill the start.pl process.

Start the webinstaller again. On the first Web page you see that the session is
still active. Either take over this session and finish it or terminate it directly.

35

Storage Foundation Release Notes

Known issues

After finishing a kernel upgrade on a master node the cvm

group on a slave node does not come online (2439439)
After successfully finishing a kernel upgrade on one node, the cvm group does not
come online on the second node.
Workaround: Check that your cluster is not in a jeopardy state before you perform
a rolling upgrade.

After upgrade from VxVM version 6.0, 6.0.1, or 6.0.3 with an

encapsulated boot disk, the system fails to boot (2750782)
On Red Hat Enterprise Linux 6 (RHEL6), during the Veritas Volume Manager (VxVM)
upgrade from 6.0, 6.0.1, or 6.0.3 to higher versions, the RPM runs the installation
scripts of the VxVM higher version first.Then, the RPM runs the uninstallation scripts
of the VxVM 6.0, 6.0.1, or 6.0.3 version. Due to a defect in the 6.0, 6.0.1, and 6.0.3
uninstallation scripts, it corrupts the file installed by the higher version. This leads
to the boot failure.
Workaround:

Unroot the encapsulated root disk.

Uninstall VRTSvxvm (6.0, 6.0.1, or 6.0.3) RPM.

Install VRTSvxvm of higher version (above 6.0.3).

The uninstaller does not remove all scripts (2696033)

After removing SF, some of the RC scripts remain in the /etc/rc*.d/ folder. This
is due to an issue with the chkconfig rpm in RHEL6 and updates. You can manually
remove the scripts from the /etc/rc*.d/ folder after removing the VxVM packages.
Workaround:
Install the chkconfig-1.3.49.3-1 chkconfig rpm from the RedHat portal. Refer to the
following links:
http://grokbase.com/t/centos/centos/117pfhe4zz/centos-6-0-chkconfig-strange-behavior
http://rhn.redhat.com/errata/RHBA-2012-0415.html

Veritas File System modules fail to unload during uninstall or

upgrade if a break-off snapshot volume is created or reattached
(2851403)
If a break-off snapshot volume is created or reattached on the system, the Veritas
File System modules, vxportal and vxfs, may fail to unload during uninstall or
upgrade. The situation occurs if the SmartMove feature is enabled, which is the

36

Storage Foundation Release Notes

Known issues

default setting. When you use the installer to uninstall or upgrade, you may see a
message similar to the following:
Veritas Storage Foundation Shutdown did not complete successfully
vxportal failed to stop on dblxx64-21-v1
vxfs failed to stop on dblxx64-21-v1

Workaround:

Open a new session and manually unload the modules that failed to unload.
Use commands similar to the following:
# /sbin/modprobe -r vxportal
# /sbin/modprobe -r vxfs

Because some processes failed to stop, the installer recommends a reboot

and asks you if you want to continue.
Press y to continue to the next phase. You can ignore the reboot requirement.

Veritas Storage Foundation known issues

This section describes the known issues in this release of Veritas Storage
Foundation (SF).

Not all the objects are visible in the VOM GUI (1821803)
After upgrading SF stack from 5.0MP3RP2 to 5.1, the volumes are not visible under
the Volumes tab and the shared diskgroup is discovered as Private and Deported
under the Disgroup tab in the SFM GUI.
Workaround:
To resolve this known issue

On each manage host where VRTSsfmh 2.1 is installed, run:

# /opt/VRTSsfmh/adm/dclisetup.sh -U

A volume's placement class tags are not visible in the Veritas

Enterprise Administrator GUI when creating a dynamic storage
tiering placement policy (1880081)
A volume's placement class tags are not visible in the Veritas Enterprise
Administrator (VEA) GUI when you are creating a SmartTier placement policy if

37

Storage Foundation Release Notes

Known issues

38

you do not tag the volume with the placement classes prior to constructing a volume
set for the volume.
Workaround:
To see the placement class tags in the VEA GUI, you must tag the volumes prior
to constructing the volume set. If you already constructed the volume set before
tagging the volumes, restart vxsvc to make the tags visible in the GUI.

Veritas Volume Manager known issues

The following are the Veritas Volume Manager known issues for this release.

device.map must be up to date before doing root disk

encapsulation (2202047)
If you perform root disk encapsulation while the device.map file is not up to date,
the vxdiskadm command displays the following error:
VxVM vxencap INFO V-5-2-6098 Missing entry for root disk <rootdisk name>
in /boot/grub/device.map

Workaround:
Before you perform root disk encapsulation, run the the following command to
regenerate the device.map file:
grub-install --recheck /dev/sdb

Required attributes for Veritas Volume Manager (VxVM) devices

to avoid boot failures (1411526)
To support iSCSI devices, Veritas Volume Manager (VxVM) does not start non-root
devices until runlevel2. The boot process expects all local (non-NFS) mount points
in the /etc/fstab file to be present at boot time. To avoid boot failures, all VxVM
entries in the /etc/fstab file must have the _netdev attribute, and must not have
the fsck required flag set. These attributes enable VxVM to defer mounting of VxVM
devices until after VxVM has started.

vxrestored daemon fails to restore disabled paths (1663167)

The vxrestored daemon fails to restore disabled paths on RHEL 5 with direct
attached disks.
Workaround:

Storage Foundation Release Notes

Known issues

Enable the mpt_disable_hotplug_remove tunable so that path level failover and

failback function properly on RHEL 5 machines with direct attached disks.
To enable the mpt_disable_hotplug_remove tunable

Edit the /etc/modprobe.conffile and add the following line to the end of the file:
options mptsas mpt_disable_hotplug_remove=0

Rebuild the initrd image:

# mkinitrd -f /boot/initrd-`uname -r`.img `uname -r`

Reboot the system.

System hangs or panics after disabling 3 of 4 arrayside ports

(1724260)
The system hangs or panics after you disable 3 of 4 arrayside ports.
Workaround:
This issue is fixed with a Novell patch for SLES 11 as indicated in Bugzilla ID
524347:
https://bugzilla.novell.com/show_bug.cgi?id=524347

Machine fails to boot after root disk encapsulation on servers

with UEFI firmware (1842096)
Certain new servers in the market such as IBM x3650 M2, Dell PowerEdge T610,
come with support for the UEFI firmware. UEFI supports booting from legacy MBR
type disks with certain restrictions on the disk partitions. One of the restrictions is
that each partition must not overlap with other partitions. During root disk
encapsulation, it creates an overlapping partition that spans the public region of
the root disk. If the check for overlapping partitions is not disabled from the UEFI
firmware, then the machine fails to come up following the reboot initiated after
running the commands to encapsulate the root disk.
Workaround:
The following workarounds have been tested and are recommended in a single-node
environment.
For the IBM x3650 series servers, the UEFI firmware settings should be set to boot
with the "Legacy Only" option.
For the Dell PowerEdge T610 system, set "Boot Mode" to "BIOS" from the "Boot
Settings" menu.

39

Storage Foundation Release Notes

Known issues

Veritas Volume Manager (VxVM) might report false serial split

brain under certain scenarios (1834513)
VxVM might detect and report a false serial split brain when all of the following
conditions are met:

One or more arrays that provide the shared storage for the cluster are being
powered off

At the same time when the arrays are being powered off, an operation that
requires an internal transaction is initiated (such as VxVM configuration
commands)

In such a scenario, disk group import will fail with a split brain error and the
vxsplitlines output will show 0 or 1 pools.
Workaround:
To recover from this situation

Retrieve the disk media identifier (dm_id) from the configuration copy:
# /etc/vx/diag.d/vxprivutil dumpconfig device-path

The dm_id is also the serial split brain id (ssbid)

Use the dm_id in the following command to recover from the situation:
# /etc/vx/diag.d/vxprivutil set device-path ssbid=dm_id

Root disk encapsulation is not supported if the root disk (DMP

node) has customized name or user-defined name (1603309)
Encapsulation of the root disk fails if it has been assigned a customized name with
vxdmpadm(1M) command. If you want to encapsulate the root disk, make sure that
you have not assigned a customized name to its corresponding DMP node.
See the vxdmpadm(1M) manual page.
See the "Setting customized names for DMP nodes" section of the Veritas Storage
Foundation Administrator's Guide.

VxVM starts before OS device scan is done (1635274)

While working with some arrays, VxVM may start before all devices are scanned
by the OS. This slow OS device discovery may result in malfunctioning of VM,
fencing and VCS due to partial disks seen by VxVM.
Workaround:

40

Storage Foundation Release Notes

Known issues

After the fabric discovery is finished, issue the vxdisk scandisks command to
bring newly discovered devices into the VxVM configuration.

System panic occurs on RHEL6.0 when VxVM is installed on

EMC PowerPath managed devices (2573229)
System panic occurs on RHEL6.0 due to page cache issue when VxVM is installed
on top of EMC PowerPath managed devices.
Workaround :
Install VxVM before installing and configuring EMC PowerPath

Hardware paths for operating system paths have changed in

DMP 6.0 (2410716)
In DMP 6.0, the hardware paths for operating system paths have changed. After
upgrading to DMP 6.0, path attributes are reset to the default values. You must
reconfigure any path-level attributes that were defined in the /etc/vx/dmppolicy.info
file.
Workaround:
To configure path-level attributes

Remove the path entries from the /etc/vx/dmppolicy.info file.

Reset the path attributes.

The vxsnap print command shows incorrect value for

percentage dirty (2360780)
The vxsnap print command can display the percentage of regions that differ
between snapshots, shown as the %dirty. In SF 6.0, if this command is run while
the volumes are online and being actively used, the shown %dirty may lag from
actual percentage dirty for instant snap data cache object (DCO) volumes. That is,
the command output may show less %dirty than actual.

During system boot, some VxVM volumes fail to mount

(2622979)
During system boot, some VxVM volumes that exist in the /etc/fstab file fail to
mount with the following error messages:
# fsck
Checking all file systems.

41

Storage Foundation Release Notes

Known issues

42

error on stat() /dev/vx/dsk//volume: No such

file or directory

The load order of kernel modules in Linux results in the VxFS file system driver
loading late in the boot process. Since the driver is not loaded when the /etc/fstab
file is read by the operating system, file systems of the type vxfs will not mount.
Workaround:
To resolve the failure to mount VxFS file systems at boot, specify additional options
in the /etc/fstab file. These options allow the filesystems to mount later in the
boot process. An example of an entry for a VxFS file system:
/dev/vx/dsk/testdg/testvolume /mountpoint

vxfs

_netdev,hotplug

1 1

To resolve the issue, the fstab entry for VxVM data volumes should be as per
following template:
/dev/vx/dsk/testdg/testvol

/testmnt

vxfs

_netdev

0 0

Unable to upgrade the kernel on an encapsulated boot disk on

SLES 11 (2612301)
Upgrading the kernel on an encapsulated boot disk does not work on SUSE Linux
Enterprise Server (SLES) 11.
Workaround: Perform the following procedure on the system with the encapsulated
root disk to upgrade the kernel.
To upgrade the kernel on a system with an encapsulated root disk

Unroot the encapsulated root disk:

# /etc/vx/bin/vxunroot

Upgrade the kernel:

# rpm -Uvh Kernel-upgrade_version

Reboot the system.

Re-encapsulated the root disk:

# /etc/vx/bin/vxencap -c -g root_diskgroup rootdisk=root_disk

Storage Foundation Release Notes

Known issues

Removing an array node from an IBM Storwize V7000 storage

system also removes the controller (2816589)
When using an IBM Storwize V7000 storage system, after removing one array
node, the corresponding controller is also removed.
Workaround: The following procedure resolves this issue.
To resolve this issue

Set the iotimeout tunable to 600:

# vxdmpadm setattr enclosure encl1 recoveryoption=throttle \
iotimeout=600

After you re-add the SAN VC node, run the vxdctl enable command for
Dynamic Multi-Pathing (DMP) to detect the added paths:
# vxdctl enable

Upgrading from Veritas Storage Foundation 5.x to 6.0.1 may

fail for IBM XIV Series arrays (2715119)
Starting in the Veritas Storage Foundation 5.1 SP1 release, the Array Support
Library (ASL) for the IBM XIV enclosures converts the LUN Serial Number from
Hexadecimal to Decimal. Because of this change, the enclosure names differ from
releases prior to the 5.1 SP1 releases. When you upgrade Veritas Storage
Foundation from a release prior to that release to the current 6.0.1 release, XIV
LUNs may go into an error state. Note that the latest RPs on 5.1/5.1SP1 are already
modified to use the same logic for enclosure naming.
Workaround:
After the upgrade, run vxddladm assign names.

Cannot grow Veritas Volume Manager (VxVM) disk using the

vxdisk resize command during Dynamic LUN Expansion
operation (2064510)
The following error message is displayed during the Dynamic LUN Expansion
operation of a LUN with the SIMPLE format:
VxVM vxdisk ERROR V-5-1-8643 Device <device name>: resize failed:
Invalid data in request

The vxdisk resize command keeps the cylinder size (number of the heads * total
number of the sectors per track) constant before and after the resize operation,

43

Storage Foundation Release Notes

Known issues

unless the number of cylinders go beyond 2^16-1 (65535) . Because of the VTOC
limitation of storing geometry values only till 2^16 -1, if the number of cylinders
increases beyond the limit, vxdisk resize increases the cylinder size. If this
happens, the private region will overlap with the public region data and corrupt the
user data.
As a result of this LUN geometry change, VxVM is unable to complete vxdisk
resize on simple format disks. VxVM was not designed to handle such geometry
changes during Dynamic LUN Expansion operations on simple disks.
Workaround:
The VxVM vxdisk resize command behaves differently depending on whether
the disk is simple, sliced, or CDS format.
The problem shown above only occurs on simple disk configurations. As a result
of this difference in behavior, if the geometry changes during a Dynamic LUN
Expansion operation at the LUN level, you can convert the disk to a CDS format
disk. Use the vxcdsconvert command on the disk. Then you can issue the vxdisk
resize command.
See http://www.symantec.com/docs/TECH136240 for more information.

Continuous trespass loop when a CLARiiON LUN is mapped to

a different host than its snapshot (2761567)
If a CLARiiON LUN is mapped to a different host than its snapshot, a trespass on
one of them could cause a trespass on the other. This behavior could result in a
loop for these LUNs, as DMP tries to fail back the LUNs if the primary paths are
available.
Workaround:
To avoid this issue, turn off the dmp_monitor_ownership tunable:
# vxdmpadm settune dmp_monitor_ownership=off

The vxrecover command does not handle RAID5 volumes

correctly (2715124)
The vxrecover command calls the recovery process for the top-level volume, which
internally takes care of recovering its subvolumes. The vxrecover command does
not handle RAID5 volumes correctly. The recovery process fails to recover the
subvolumes, which remain in the NEEDSYNC state.
Workaround:
Manually recover the RAID5 volumes using the vxvol utility, as follows:

44

Storage Foundation Release Notes

Known issues

# vxvol -g diskgroup resync volume

Diskgroup import of BCV luns using -o updateid and -o

useclonedev options is not supported if the diskgroup has
mirrored volumes with DCO or has snapshots. (2831658)
VxVM uses guid stored in configuration to uniquely identify all objects. The DCO
volume stores the guid of mirrors and snapshots. If the diskgroup is imported with
-o updateid and -o useclonedev, it changes the guid of objects in VxVM configuration
database and the guids stored in DCO volume are not updated. So the operations
involving DCO will not be able to find objects with the stored guid and this could
lead to failure of certain operations involving DCO or could lead to unexpected
behaviour.
Workaround:
No workaround available.

After devices that are managed by EMC PowerPath lose access

to storage, Veritas Volume Manager commands are delayed
(2757198)
In an enviroment which includes devices that are managed by EMC PowerPath, a
storage loss causes Veritas Volume Manager commands to be delayed. In the
event of storage loss, VxVM sends SCSI inquiry from each LUN path to check the
health of path, which are delayed by the presence of EMC PowerPath.

Importing a disk group fails with incorrect error message

(2149922)
Importing a disk group using clone disks fails with "wrong usage" or "invalid attribute"
error. For example, the following command may show the error.
# vxdg -o useclonedev=on import dgname

This error message may display if the correct feature licenses are not installed.
Workaround:
Check that the Fast Mirror Resync and Disk Group Split and Join licenses are
installed. If not, install the licenses.

45

Storage Foundation Release Notes

Known issues

Dynamic LUN expansion is not supported for EFI disks in simple

or sliced formats (2836798)
Dynamic LUN expansion is not supported for EFI (Extensible Firmware Interface)
disks in simple or sliced formats. It may lead to corruption. The recommended
format is the Cross-platform Data Sharing (CDS) disk format.
Workaround:
Convert the disk format to CDS using the vxcdsconvert utility.

Veritas File System known issues

This section describes the known issues in this release of Veritas File System
(VxFS).

Taking a FileSnap over NFS multiple times with the same target
name can result in the 'File exists' error (2353352)
The "File exists" error occurs as a result of the caching behavior of the NFS client.
Because the link operation is successful, the NFS client assumes that a file with
the specified target name, such as file2::snap:vxfs:, was created.. As a result,
the NFS client caches a file with this name.
Workaround: Remove the target file after a snapshot is created. This forces the
NFS client to remove the name from the cache. For example:
# ln file1 file2::snap:vxfs:
# rm file2::snap:vxfs:

Enabling delayed allocation on a small file system sometimes

disables the file system (2389318)
When you enable delayed allocation on a small file system, such as around 100
MB, the file system can get disabled. In this case, the following error message
,displays in the system console log:
mesg 001: V-2-1: vx_nospace - file_system file system full
(size block extent)

Workaround:
Use the vxtunefs command to turn off delayed allocation for the file system.

46

Storage Foundation Release Notes

Known issues

47

Delayed allocation sometimes gets turned off automatically

when one of the volumes in a multi-volume file system nears
100% usage even if other volumes have free space (2438368)
Delayed allocation sometimes gets turned off automatically when one of the volumes
in a multi-volume file system is nearing 100% usage even if other volumes in the
file system have free space.
Workaround:
After sufficient space is freed from the volume, delayed allocation automatically
resumes.

Task blocked messages display in the console for RHEL6

(2560357)
On RHEL6, the kernel occasionally displays messages in the console similar to the
following example:
INFO: task seq:16957 blocked for more than 120 seconds.

These messages display because the task is blocked for a long time on sleep locks.
However, the task is not hung and the messages can be safely ignored.
Workaround: You can disable these messages by using the following command:
# echo 0 > /proc/sys/kernel/hung_task_timeout_secs

Deduplication can fail with error 110 (2591473)

In some cases, data deduplication fails with a message similar to the following
example:
Saving
Status
Node
Type
Filesystem
--------------------------------------------------------------------00%
FAILED
node01
MANUAL
/data/fs1
2011/10/26 01:38:58 End full scan with error

In addition, the deduplication log contains an error similar to the following example:
2011/10/26 01:35:09 DEDUP_ERROR AddBlock failed. Error = 110

These errors indicate that the deduplication process is running low on space and
needs more free space to complete.
Workaround:
Make more space available on the file system.

Storage Foundation Release Notes

Known issues

48

vxresize fails while shrinking a file system with the "blocks are
currently in use" error (2437138)
The vxresize shrink operation may fail when active I/Os are in progress on the file
system and the file system is being shrunk to a size closer to its current usage. You
see a message similar to the following example:
UX:vxfs fsadm: ERROR: V-3-20343: cannot shrink /dev/vx/rdsk/dg1/vol1 blocks are currently in use.
VxVM vxresize ERROR V-5-1-7514 Problem running fsadm command for volume
vol1, in diskgroup dg1

Workaround:
Rerun the shrink operation after stopping the I/Os.

Possible assertion failure in vx_freeze_block_threads_all()

(2244932)
There is a possible assertion failure in the vx_freeze_block_threads_all() call
when the pdir_threshold tunable is set to 1.
Workaround:
There is no workaround for this issue.

A mutex contention in vx_worklist_lk() can use up to 100% of

a single CPU (2086902)
A mutex contention in the vx_worklist_lk() call can use up to 100% of a single
CPU.
Workaround:
There is no workaround for this issue.

System unable to select ext4 from the file system (2691654)

The system is unable to select ext4 from the file system.
Workaround: There is no workaround.

Storage Foundation Release Notes

Known issues

49

fsppadm operations issued on multi-volume file system fail if

there are other mounted file systems with a disk layout Version
less than 6 (2909206, 2909203)
The fsppadm command checks all mounted file systems, and if it finds any file
systems with a disk layout Version that is less than 6, then it exits with the following
error message:
# fsppadm assign /dst_vset /tmp/pol_test.xml
UX:vxfs fsppadm: ERROR: V-3-26510: Low level Volume enumeration failure
on / with message Function not implemented

This error occurs because the fsppadm command functionality is not supported on
a disk layout Version that is less than 6.
Workaround:
There is no workaround for this issue.

Replication known issues

This section describes the replication known issues in this release of Veritas Storage
Foundation.

vradmin syncvol command compatibility with IPv6 addresses

(2075307)
The vradmin syncvol command does not work with the compressed form of IPv6
addresses if the target disk group and volume names are not specified.
Workaround:
In IPv6 environments, if you run the vradmin syncvol command and identify the
target host using the compressed form of the IPv6 address, then you also need to
specify the target disk group and volume names.

RVGPrimary agent operation to start replication between the

original Primary and the bunker fails during failback (2054804)
The RVGPrimary agent initiated operation to start replication between the original
Primary and the bunker fails during failback when migrating back to the original
Primary after disaster recovery with the error message:
VxVM VVR vxrlink ERROR V-5-1-5282 Error getting information from
remote host. Internal Error.

Storage Foundation Release Notes

Known issues

The issue applies to global clustering with a bunker configuration, where the bunker
replication is configured using storage protocol. It occurs when the Primary comes
back even before the bunker disk group is imported on the bunker host to initialize
the bunker replay by the RVGPrimary agent in the Secondary cluster.
Workaround:
To resolve this issue

Before failback, make sure that bunker replay is either completed or aborted.

After failback, deport and import the bunker disk group on the original Primary.

Try the start replication operation from outside of VCS control.

Bunker replay did not occur when the Application Service Group
was configured on some of the systems in the Primary cluster,
and ClusterFailoverPolicy is set to "AUTO" (2047724)
The time that it takes for a global cluster to fail over an application service group
can sometimes be smaller than the time that it takes for VVR to detect the
configuration change associated with the primary fault. This can occur in a bunkered,
globally clustered configuration when the value of the ClusterFailoverPolicy
attribute is Auto and the AppGroup is configured on a subset of nodes of the primary
cluster.
This causes the RVGPrimary online at the failover site to fail. The following
messages appear in the VCS engine log:
RVGPrimary:RVGPrimary:online:Diskgroup bunkerdgname could not be
imported on bunker host hostname. Operation failed with error 256
and message VxVM VVR vradmin ERROR V-5-52-901 NETWORK ERROR: Remote
server unreachable... Timestamp VCS ERROR V-16-2-13066 (hostname)
Agent is calling clean for resource(RVGPrimary) because the resource
is not up even after online completed.

Workaround:
To resolve this issue

When the configuration includes a bunker node, set the value of the
OnlineRetryLimit attribute of the RVGPrimary resource to a non-zero value.

50

Storage Foundation Release Notes

Known issues

The RVGPrimary agent may fail to bring the application service

group online on the new Primary site because of a previous
primary-elect operation not being run or not completing
successfully (2043831)
In a primary-elect configuration, the RVGPrimary agent may fail to bring the
application service groups online on the new Primary site, due to the existence of
previously-created instant snapshots. This may happen if you do not run the
ElectPrimary command to elect the new Primary or if the previous ElectPrimary
command did not complete successfully.
Workaround:
Destroy the instant snapshots manually using the vxrvg -g dg -P snap_prefix
snapdestroy rvg command. Clear the application service group and bring it back
online manually.

A snapshot volume created on the Secondary, containing a

VxFS file system may not mount in read-write mode and
performing a read-write mount of the VxFS file systems on the
new Primary after a global clustering site failover may fail
(1558257)
Issue 1:
When the vradmin ibc command is used to take a snapshot of a replicated data
volume containing a VxFS file system on the Secondary, mounting the snapshot
volume in read-write mode may fail with the following error:
UX:vxfs mount: ERROR: V-3-21268: /dev/vx/dsk/dg/snapshot_volume
is corrupted. needs checking

This happens because the file system may not be quiesced before running the
vradmin ibc command and therefore, the snapshot volume containing the file
system may not be fully consistent.
Issue 2:
After a global clustering site failover, mounting a replicated data volume containing
a VxFS file system on the new Primary site in read-write mode may fail with the
following error:
UX:vxfs mount: ERROR: V-3-21268: /dev/vx/dsk/dg/data_volume
is corrupted. needs checking

51

Storage Foundation Release Notes

Known issues

52

This usually happens because the file system was not quiesced on the original
Primary site prior to the global clustering site failover and therefore, the file systems
on the new Primary site may not be fully consistent.
Workaround:
The following workarounds resolve these issues.
For issue 1, run the fsck command on the snapshot volume on the Secondary, to
restore the consistency of the file system residing on the snapshot.
For example:
# fsck -t vxfs /dev/vx/dsk/dg/snapshot_volume

For issue 2, run the fsck command on the replicated data volumes on the new
Primary site, to restore the consistency of the file system residing on the data
volume.
For example:
# fsck -t vxfs /dev/vx/dsk/dg/data_volume

Running SUSE Linux and using Novell's YaST tool to configure

an IPv6 address may result in an error (1679261)
When Novell's YaST tool is invoked to configure an IPv6 address on a different
network interface and if:

the host name, the DNS server name and domain name are specified to the
YaST tool.

IPv6 address is assigned by the Dynamic Host Configuration Protocol (DHCP).

the "Write Hostname to /etc/hosts" option is selected (this is selected by default).

This results in the vradmin command returning the following error:

VxVM VVR vradmin ERROR V-5-52-488 RDS has configuration error related
to the master and logowner.

This happens because the YaST tool can replace the /etc/hosts entry containing
127.0.0.2 from the IPv4 host name to the specified new IPv6 host name. For
example:
127.0.0.2 v6hostname.space.ipv6.com v6hostname

Workaround:
The following procedure resolves this issue.

Storage Foundation Release Notes

Known issues

To resolve this issue

Edit the /etc/hosts file to specify the correct IPv6 address.

Restart the vradmind daemon on all VVR hosts:

# /etc/init.d/vras-vradmind.sh restart

In an IPv6-only environment RVG, data volumes or SRL names

cannot contain a colon (1672410, 1672417, 1825031)
Issue: After upgrading VVR to an IPv6-only environment in 6.0 release, vradmin
commands may not work when a colon is specified in the RVG, data volume(s)
and/or SRL name. It is also possible that after upgrading VVR to an IPv6-only
environment, vradmin createpri may dump core when provided with RVG, volume
and/or SRL names containing a colon in it.
Workaround:
Make sure that colons are not specified in the volume, SRL and RVG names in the
VVR configuration

While vradmin commands are running, vradmind may

temporarily lose heart beats (2071568, 2275444)
This issue may occasionally occur when you use vradmin commands to administer
VVR. While the vradmin commands run, vradmind may temporarily lose heartbeats,
and the commands terminate with the following error message:
VxVM VVR vradmin ERROR V-5-52-803 Lost connection to host host;
terminating command execution.

Workaround:

53

Storage Foundation Release Notes

Known issues

To resolve this issue

Depending on the application I/O workload and network environment,

uncomment and increase the value of the IPM_HEARTBEAT_TIMEOUT variable
in the /etc/vx/vras/vras_env on all the hosts of the RDS to a higher value.
The following example increases the timeout value to 120 seconds.
export IPM_HEARTBEAT_TIMEOUT
IPM_HEARTBEAT_TIMEOUT=120

Restart vradmind on all the hosts of the RDS to put the new
IPM_HEARTBEAT_TIMEOUT value into affect. Enter the following on all the hosts
of the RDS:
# /etc/init.d/vras-vradmind.sh restart

vxassist relayout removes the DCM (145413)

If you perform a relayout that adds a column to a striped volume that has a DCM,
the DCM is removed. There is no message indicating that this has happened. To
replace the DCM, enter the following:
# vxassist -g diskgroup addlog vol logtype=dcm

vxassist and vxresize operations do not work with layered

volumes that are associated to an RVG (2162579)
This issue occurs when you try a resize operation on a volume that is associated
to an RVG and has a striped-mirror layout.
Workaround:
To resize layered volumes that are associated to an RVG

Pause or stop the applications.

Wait for the RLINKs to be up to date. Enter the following:

# vxrlink -g diskgroup status rlink

Stop the affected RVG. Enter the following:

# vxrvg -g diskgroup stop rvg

Disassociate the volumes from the RVG. Enter the following:

# vxvol -g diskgroup dis vol

54

Storage Foundation Release Notes

Known issues

Resize the volumes. In this example, the volume is increased to 10 GB. Enter
the following:
# vxassist -g diskgroup growto vol 10G

Associate the data volumes to the RVG. Enter the following:

# vxvol -g diskgroup assoc rvg vol

Start the RVG. Enter the following:

# vxrvg -g diskgroup start rvg

Resume or start the applications.

vradmin verifydata operation fails when replicating between

versions 5.1 and 6.0 (2360713)
When replicating in a cross-version VVR environment consisting of hosts running
Storage Foundation 5.1 and hosts running Storage Foundation 6.0, the vradmin
verifydata command fails with the following error:
VxVM VVR vxrsync ERROR V-5-52-2222 [from host]: VxVM in.vxrsyncd
ERROR V-5-36-2125 Server volume access error during [assign volids]
volume path: [/dev/vx/dsk/dg/snapshot_volume] reason: [this could be
because a target volume is disabled or an rlink associated with a
target volume is not detached during sync operation].

Workaround:
There are two workarounds for this issue.

Upgrade the hosts running Storage Foundation 5.1 to Storage Foundation

5.1SP1 or later and re-run the vradmin verifydata command.

Follow the offline verification procedure in the "Verifying the data on the
Secondary" section of the Veritas Storage Foundation and High Availability
Solutions Replication Administrator's Guide. This process requires ensuring that
the secondary is up-to-date, pausing replication, and running the vradmin
syncrvg command with the -verify option.

Cannot relayout data volumes in an RVG from concat to

striped-mirror (2129601)
This issue occurs when you try a relayout operation on a data volume which is
associated to an RVG, and the target layout is a striped-mirror.

55

Storage Foundation Release Notes

Known issues

Workaround:
To relayout a data volume in an RVG from concat to striped-mirror

Pause or stop the applications.

Wait for the RLINKs to be up to date. Enter the following:

# vxrlink -g diskgroup status rlink

Stop the affected RVG. Enter the following:

# vxrvg -g diskgroup stop rvg

Disassociate the volumes from the RVG. Enter the following:

# vxvol -g diskgroup dis vol

Relayout the volumes to striped-mirror. Enter the following:

# vxassist -g diskgroup relayout vol layout=stripe-mirror

Associate the data volumes to the RVG. Enter the following:

# vxvol -g diskgroup assoc rvg vol

Start the RVG. Enter the following:

# vxrvg -g diskgroup start rvg

Resume or start the applications.

vradmin verifydata may report differences in a cross-endian

environment (2834424)
When replicating between two nodes in a cross-platform environment, and
performing an autosync or replication, the vradmin verifydata command may report
differences. This is due to different endianness between the platforms. However,
the file system on the secondary node will be consistent and up to date.

vradmin repstatus operation may display configuration error

after cluster reconfiguration in a CVR environment (2779580)
In a CVR environment, if there is a cluster reconfiguration, the vradmin repstatus
command may display the following error message:
No Primary RVG

56

Storage Foundation Release Notes

Known issues

57

The vradmin repstatus command functions normally on the Primary site.

Workaround:
Restart the vradmind daemon on both the Primary and Secondary nodes.

I/O hangs on the primary node when running vxrvg snaprestore

operation (2762147)
In a CVR environment, if a secondary node is set as the logowner for an RVG,
issuing the vxrvg snaprestore command on the primary node may result in an
I/O hang.

The vxrecover command does not automatically recover layered

volumes in an RVG (2866299)
The vxrecover command calls the recovery process for the top-level volume, which
internally takes care of recovering its subvolumes. The vxrecover command does
not handle layered volumes correctly. The recovery process fails to recover the
subvolumes, which remain in the NEEDSYNC state.
Workaround:
Manually recover the layered volumes using the vxvol utility, as follows:
# vxvol -g diskgroup resync volume

RVG monitor script may display command not found messages

(1709034)
On VCS hosts with VVR resources configured, the following error message displayed
in engine_A.log indicates a script error:
/opt/VRTSvcs/bin/RVG/monitor: line 124: {print $6}: command not found
/opt/VRTSvcs/bin/RVG/monitor: line 124: {print $6}: command not found
/opt/VRTSvcs/bin/RVG/monitor: line 124: {print $6}: command not found

This may fail online/monitor the bunker RVG resources, when they are configured.
Workaround:
Manually edit the following files to update the script:
/opt/VRTSvcs/bin/RVG/monitor
/opt/VRTSvcs/bin/RVG/online
/opt/VRTSvcs/bin/RVG/offline

In each file, modify the following line:

Storage Foundation Release Notes

Known issues

sys=`LC_ALL=C; export LC_ALL; $hasys -nodeid | $awk '{print $6}'`

to
sys=`LC_ALL=C; export LC_ALL; $hasys -nodeid | awk '{print $6}'`

Veritas Storage Foundation for Databases (SFDB) tools known issues

The following are known issues in this release of Veritas Storage Foundation for
Databases (SFDB) tools.

SFDB commands do not work in IPV6 environment (2619958)

In IPV6 environment, SFDB commands do not work for SF. There is no workaround
at this point of time.

Database Storage Checkpoint unmount may fail with device

busy (2591463)
In some cases, when a database that is cloned using a Database Storage
Checkpoint is shut down, an error similar to the following may occur:
SFAE Error:0457: Failed to unmount device
/dev/vx/dsk/datadg/datavol:Ckpt_1317707593_rw_1317708154.
Reason: VxFS returned error : umount: /tmp/clonedb/data: device is
busy

Workaround:
As an Oracle user, force shut down the clone database if it is up and then retry the
unmount operation.

Attempt to use SmartTier commands fails (2332973)

The attempts to run SmartTier commands such as dbdst_preset_policy
ordbdst_file_move fail with the following error:
fsppadm: ERROR: V-3-26551: VxFS failure on low level mechanism
with message - Device or resource busy

This error occurs if a sub-file SmartTier command such as dbdst_obj_move has

been previously run on the file system.
There is no workaround for this issue. You cannot use file-based SmartTier and
sub-file SmartTier simultaneously.

58

Storage Foundation Release Notes

Known issues

Attempt to use certain names for tiers results in error

(2581390)
If you attempt to use certain names for tiers, the following error message is
displayed:
SFORA dbdst_classify ERROR V-81-6107 Invalid Classname BALANCE

This error occurs because the following names are reserved and are not permitted
as tier names for SmartTier:

BALANCE

CHECKPOINT

METADATA

Workaround:
Use a name for SmartTier classes that is not a reserved name.

Clone operation failure might leave clone database in

unexpected state (2512664)
If the clone operation fails, it may leave the clone database in an unexpected state.
Retrying the clone operation might not work.

Workaround:
If retrying does not work, perform one the following actions depending on the
point-in-time copy method you are using:

For FlashSnap, resync the snapshot and try the clone operation again.

For FileSnap and Database Storage Checkpoints, destroy the clone and create
the clone again.

For space-optimized snapshots, destroy the snapshot and create a new

snapshot.

Contact Symantec support if retrying using the workaround does not succeed.

FlashSnap resync fails if there is an existing space-optimized

snapshot (2479901)
If you try a FlashSnap resync operation when there is an existing space-optimized
snapshot, the resync operation fails with the following error:

59

Storage Foundation Release Notes

Known issues

Error: VxVM vxdg ERROR V-5-1-4597 vxdg join FS_oradg oradg failed
datavol_snp : Record already exists in disk group
archvol_snp : Record already exists in disk group

Workaround:
Destroy the space-optimized snapshot first and then perform the FlashSnap resync
operation.

Upgrading Veritas Storage Foundation for Databases (SFDB)

tools from 5.0x to 6.0.1 (2184482)
The sfua_rept_migratecommand results in an error message after upgrading
SFHA or SF for Oracle RAC version 5.0 to SFHA or SF for Oracle RAC 6.0.1.
When upgrading from SF version 5.0 to SF 6.0.1 the S*vxdbms3 startup script is
renamed to NO_S*vxdbms3. The S*vxdbms3 startup script is required by
sfua_rept_upgrade. Thus when sfua_rept_upgrade is run, it is unable to find the
S*vxdbms3 startup script and gives the error message:
/sbin/rc3.d/S*vxdbms3 not found
SFORA sfua_rept_migrate ERROR V-81-3558 File: is missing.
SFORA sfua_rept_migrate ERROR V-81-9160 Failed to mount repository.

Workaround
Before running sfua_rept_migrate, rename the startup script NO_S*vxdbms3 to
S*vxdbms3.

Clone command fails if PFILE entries have their values spread

across multiple lines (2844247)
If you have a log_archive_dest_1 in single line in the init.ora file, then
dbed_vmclonedb will work but dbed_vmcloneb will fail if you put in multiple lines for
log_archive_dest_1.

Workaround
There is no workaround for this issue.

SFDB commands do not work with the ZHS16GBK character

set (2715323)
SFDB commands do not work if the character set of the Oracle database is set to
ZHS16GBK. This occurs because SFDB commands are not supported with

60

Storage Foundation Release Notes

Known issues

61

multi-byte character sets except AL32UTF8 and ZHS16GBK is a multi-byte character

set.
There is no workaround for this issue.

Clone fails with error "ORA-01513: invalid current time

returned by operating system" with Oracle 11.2.0.3 (2804452)
While creating a clone database using any of the point-in-time copy services such
as Flashsnap, SOS, Storage Checkpoint, or Filesnap, the clone fails. This problem
appears to affect Oracle versions 11.2.0.2 as well as 11.2.0.3.
You might encounter an Oracle error such as the following:

/opt/VRTSdbed/bin/vxsfadm -s flashsnap -o clone

-a oracle -r dblxx64-16-v1 --flashsnap_name TEST11 --clone_path
/tmp/testRecoverdb --clone_name clone1
USERNAME: oragrid
STDOUT:
Retrieving snapshot information ...
Done
Importing snapshot diskgroups ...
Done
Mounting snapshot volumes ...
Done
ORA-01513: invalid current time returned by operating system

This is a known Oracle bug documented in the following Oracle bug IDs:

Bug 14102418: DATABASE DOESNT START DUE TO ORA-1513

Bug 14036835: SEEING ORA-01513 INTERMITTENTLY

Workaround:
Retry the cloning operation until it succeeds.

Frequent occurrence of SFDB remote or privileged command

error (2869262)
If you installed a single instance database and try to run SFDB-related commands,
then an error similar to the following might occur:
$ /opt/VRTSdbed/bin/dbed_update
No repository found for database faildb, creating new one.
SFDB vxsfadm ERROR V-81-0450 A remote or privileged command could not
be executed on host1

Storage Foundation Release Notes

Known issues

62

Reason: This can be caused by the host being unreachable or the vxdbd
daemon not running on that host.
Action: Verify that the host swpa04 is reachable. If it is, verify
that the vxdbd daemon is running using the /opt/VRTS/bin/vxdbdctrl
status command, and start it using the /opt/VRTS/bin/vxdbdctrl start
command if it is not running.

There is no workaround at this point of time.

Data population fails after datafile corruption, rollback, and

restore of offline checkpoint (2869259)
Sometimes when a datafile gets corrupted below its reservation size, the rollback
may not pass and the file may not be rolled back correctly.
There is no workround at this point of time.

Checkpoint clone fails if the archive log destination is same

as the datafiles destination (2869266)
Checkpoint cloning fails if the archive log destination is the same as the datafiles
destination. The error is similar to:
Use of uninitialized value $path in hash element
at /opt/VRTSdbed/lib/perl/DBED/CkptOracle.pm line
Use of uninitialized value $path in concatenation
at /opt/VRTSdbed/lib/perl/DBED/CkptOracle.pm line
Use of uninitialized value $path in pattern match
at /opt/VRTSdbed/lib/perl/DBED/CkptOracle.pm line

121.
(.) or string
124.
(m//)
126.

SFDB vxsfadm ERROR V-81-0564 Oracle returned error.

Reason: ORA-02236: invalid file name (DBD ERROR: error possibly near
<*> indicator at char 172 in 'CREATE CONTROLFILE REUSE SET DATABASE
'TClone03' RESETLOGS NOARCHIVELOG

Workaround:
For the 6.0.1 release, create distinct archive and datafile mounts for the checkpoint
service.

Storage Foundation Release Notes

Known issues

63

FileSnap detail listing does not display the details of a

particular snap (2846382)
FileSnap does not support displaying a detailed listing of a snapshot or clone.
FileSnap only supports displaying a summary of all the snapshots or clones. For
example, for the CLI vxsfadm -s filesnap -a oracle --name=snap1 -o list,
a summary listing all the snapshots is displayed, instead of a detailed listing of a
particular snapshot.
Workaround:
There is no workaround for this issue.

Checkpoint clone fails in CFS environment if cloned using same

checkpoint and same clone name on both nodes (2869268)
The Checkpoint clone of an oracle database fails in a CFS environment, if you
create a clone with a clone name and checkpoint name same as another clone up
on a different CFS node.
Workaround:
There is no workaround. Create a clone with a different clone name.

Very long off-host cloning times for large number of datafiles

(2849540)
When cloning off-host in certain Oracle database configurations, particularly with
several hundred datafiles, the cloning can take a very long time, upto an hour or
more. This problem does not cause the cloning to fail. The problem applies to all
services such as FlashSnap, Space-optimized snapshots, FileSnap, and Checkpoint.
Workaround:
There is no workaround at this point of time.

sfua_rept_migrate fails after phased SFRAC upgrade from

5.0MP3RP5 to 6.0.1 (2874322)

Command sfua_rept_migrate sometimes gives an error when upgrading to 6.0.1,
and fails to unmount the repository volume. The error message is similar to:
# ./sfua_rept_migrate
Mounting SFUA Sybase ASA repository.
Unmounting SFUA Sybase ASA repository.
UX:vxfs umount: ERROR: V-3-26388: file system /rep has been mount
locked
SFORA sfua_rept_migrate ERROR V-81-5550 umount /dev/vx/dsk/repdg/repvol

Storage Foundation Release Notes

Software limitations

failed.
SFORA sfua_rept_migrate ERROR V-81-9162 Failed to umount repository.

Workaround:
The error does not hamper the upgrade. The repository migration works fine, but
the old repository volume does not get unmounted. Unmount the mount using the
manual option.
For example, use /opt/VRTS/bin/umount -o mntunlock=VCS /rep.
For more information, see TECH64812.

Software limitations
This section covers the software limitations of this release.
See the corresponding Release Notes for a complete list of software limitations
related to that component or product.
See Documentation on page 68.

Veritas Volume Manager software limitations

The following are software limitations in this release of Veritas Volume Manager.

Snapshot configuration with volumes in shared disk groups

and private disk groups is not supported
A snapshot configuration with volumes in the shared disk groups and private disk
groups is not a recommended configuration. In this release, this configuration is
not supported.

Storage reclamation does not happen on volumes with

break-off snapshot (2798523)
In this release, storage reclamation on a volume is prevented when it has a break-off
type snapshot. If storage reclamation is allowed on such volumes, it can lead to
the following undesired situation. Instant snapshot operations, including vxsnap
refresh and vxsnap restore operations, lead to full synchronization of either the
snapshot or the primary volume depending on the operation.
In this release, if the volume has a snapshot, the storage reclamation is silently
prevented. The physical storage is not reduced. The reclaim command reports that
the reclamation is done on the disks but the actual storage is not reclaimed for
volumes with snapshots:

64

Storage Foundation Release Notes

Software limitations

# vxdisk -o full reclaim dg1

Reclaiming storage on:
Disk xiv0_617 : Done.
Disk xiv0_616 : Done.
Disk
Disk
Disk
Disk
Disk

xiv0_618
xiv0_612
xiv0_613
xiv0_614
xiv0_615

:
:
:
:
:

Done.
Done.
Done.
Done.
Done

As shown in the following example output, the storage is not actually reclaimed.
# vxdisk -o thin list
DEVICE
xiv0_612
xiv0_613
xiv0_614
xiv0_615
xiv0_616
xiv0_617
xiv0_618

SIZE(MB)
19313
19313
19313
19313
19313
19313
19313

PHYS_ALLOC(MB)
2101
2108
35
32
31
31
31

GROUP
dg1
dg1
dg1
dg1
dg1
dg1
dg1

TYPE
thinrclm
thinrclm
thinrclm
thinrclm
thinrclm
thinrclm
thinrclm

SF does not support thin reclamation of space on a linked

mirror volume (2729563)
The thin reclamation feature does not support thin reclamation for a linked mirror
volume.

DMP does not support devices in the same enclosure that are
configured in different modes (2643506)
DMP does not support the configuration where two devices in the same enclosure
are configured in different modes. For example, if one device is configured as ALUA
and another one is configured as Active/Passive (A/P).

Veritas File System software limitations

The following are software limitations in the 6.0.1 release of Veritas Storage
Foundation.

Linux I/O Scheduler for Database Workloads

Symantec recommends using the Linux deadline I/O scheduler for database
workloads on both Red Hat and SUSE distributions.

65

Storage Foundation Release Notes

Software limitations

To configure a system to use this scheduler, include the elevator=deadline

parameter in the boot arguments of the GRUB or LILO configuration file.
The location of the appropriate configuration file depends on the systems
architecture and Linux distribution:
Configuration File

Architecture and Distribution

/boot/grub/menu.lst

RHEL5 x86_64, RHEL6 x86_64, SLES10

x86_64, and SLES11 x86_64

For the GRUB configuration files, add the elevator=deadline parameter to the
kernel command.
For example, for RHEL5, change:
title RHEL5UP3
root (hd1,1)
kernel /boot/vmlinuz-2.6.18-128.el5 ro root=/dev/sdb2
initrd /boot/initrd-2.6.18-128.el5.img

To:
title RHEL5UP3
root (hd1,1)
kernel /boot/vmlinuz-2.6.18-128.el5 ro root=/dev/sdb2 \
elevator=deadline
initrd /boot/initrd-2.6.18-128.el5.img

For RHEL6, change:

title RHEL6
root (hd1,1)
kernel /boot/vmlinuz-2.6.32-71.el6 ro root=/dev/sdb2
initrd /boot/initrd-2.6.32-71.el6.img

To:
title RHEL6
root (hd1,1)
kernel /boot/vmlinuz-2.6.32-71.el6 ro root=/dev/sdb2 \
elevator=deadline
initrd /boot/initrd-2.6.32-71.el6.img

A setting for the elevator parameter is always included by SUSE in its LILO and
GRUB configuration files. In this case, change the parameter from elevator=cfq
to elevator=deadline.

66

Storage Foundation Release Notes

Software limitations

Reboot the system once the appropriate file has been modified.
See the Linux operating system documentation for more information on I/O
schedulers.

Recommended limit of number of files in a directory

To maximize VxFS performance, do not exceed 100,000 files in the same directory.
Use multiple directories instead.

The vxlist command cannot correctly display numbers greater

than or equal to 1 EB
The vxlist command and all of the other commands that use the same library as
the vxlist command cannot correctly display numbers greater than or equal to 1
EB.

Limitations with delayed allocation for extending writes feature

The following limitations apply to the delayed allocation for extending writes feature:

In the cases where the file data must be written to disk immediately, delayed
allocation is disabled on that file. Examples of such cases include Direct I/O,
concurrent I/O, FDD/ODM access, and synchronous I/O.

Delayed allocation is not supported on memory mapped files.

Delayed allocation is not supported with BSD quotas. When BSD quotas are
enabled on a file system, delayed allocation is turned off automatically for that
file system.

Delayed allocation is not supported for shared mounts in a cluster file system.

FlashBackup in NetBackup 7.1 and prior does not support disk

layout Version 8 and 9
The FlashBackup feature of NetBackup 7.1 or prior does not support a VxFS file
system with disk layout Version 8 or 9.

Compressed files that are backed up using NetBackup 7.1 or

prior become uncompressed when you restore the files
The NetBackup 7.1 release and prior does not support the file compression feature.
If you back up compressed files using NetBackup 7.1 or a prior release, the files
become uncompressed when you restore the files.

67

Storage Foundation Release Notes

Documentation

Veritas Storage Foundation for Databases (SFDB) tools software

limitations
The following are the SFDB tools software limitations in this release.

Parallel execution of vxsfadm is not supported (2515442)

Only one instance of the vxsfadm command can be run at a time. Running multiple
instances of vxsfadm at a time is not supported.

Creating point-in-time copies during database structural

changes is not supported (2496178)
SFDB tools do not support creating point-in-time copies while structural changes
to the database are in progress, such as adding or dropping tablespaces and adding
or dropping data files.
However, once a point-in-time copy is taken, you can create a clone at any time,
regardless of the status of the database.

Documentation
Product guides are available in the PDF format on the software media in the
/docs/product_name directory. Additional documentation is available online.
Make sure that you are using the current version of documentation. The document
version appears on page 2 of each guide. The publication date appears on the title
page of each document. The latest product documentation is available on the
Symantec website.
http://sort.symantec.com/documents

Documentation set
Table 1-10 lists the documentation for Veritas Storage Foundation.
Table 1-10

Veritas Storage Foundation documentation

Document title

File name

Veritas Storage Foundation Release Notes

sf_notes_601_lin.pdf

Veritas Storage Foundation Installation Guide

sf_install_601_lin.pdf

Veritas Storage Foundation Administrator's Guide sf_admin_601_lin.pdf

68

Storage Foundation Release Notes

Documentation

Table 1-10

Veritas Storage Foundation documentation (continued)

Document title

File name

Veritas Storage Foundation: Storage and

Availability Management for Oracle Databases

sfhas_oracle_admin_601_unix.pdf

Veritas File System Programmer's Reference

Guide (This document is available online, only.)

vxfs_ref_601_lin.pdf

Table 1-11 lists the documentation for Veritas Storage Foundation and High
Availability Solutions products.
Table 1-11

Veritas Storage Foundation and High Availability Solutions products

documentation

Document title

File name

Veritas Storage Foundation and High Availability

Solutions Solutions Guide

sfhas_solutions_601_lin.pdf

Veritas Storage Foundation and High Availability

Solutions Virtualization Guide

sfhas_virtualization_601_lin.pdf

Veritas Storage Foundation and High Availability

Solutions Replication Administrator's Guide

sfhas_replication_admin_601_lin.pdf

If you use Veritas Operations Manager (VOM) to manage Veritas Storage Foundation
and High Availability products, refer to the VOM product documentation at:
http://sort.symantec.com/documents

Manual pages
The manual pages for Veritas Storage Foundation and High Availability Solutions
products are installed in the /opt/VRTS/man directory.
Set the MANPATH environment variable so the man(1) command can point to the
Veritas Storage Foundation manual pages:

For the Bourne or Korn shell (sh or ksh), enter the following commands:
MANPATH=$MANPATH:/opt/VRTS/man
export MANPATH

For C shell (csh or tcsh), enter the following command:

setenv MANPATH ${MANPATH}:/opt/VRTS/man

69

Storage Foundation Release Notes

Documentation

See the man(1) manual page.

Manual pages are divided into sections 1, 1M, 3N, 4, and 4M. Edit the man(1)
configuration file /etc/man.config to view these pages.
To edit the man(1) configuration file

If you use the man command to access manual pages, set LC_ALL to C in
your shell to ensure that the pages are displayed correctly.
export LC_ALL=C

See incident 82099 on the Red Hat Linux support website for more information.

Add the following line to /etc/man.config:

MANPATH /opt/VRTS/man

where other man paths are specified in the configuration file.

Add new section numbers. Change the line:

MANSECT

1:8:2:3:4:5:6:7:9:tcl:n:l:p:o

to
MANSECT

1:8:2:3:4:5:6:7:9:tcl:n:l:p:o:3n:1m

The latest manual pages are available online in HTML format on the Symantec
website at:
https://sort.symantec.com/documents

70