VERITAS Volume Manager™ (Vxvm¨) Release 3.5

VERITAS Volume Managerª 3.5

Release Notes

HP-UX

November 2002 30-00856-011 Disclaimer The information contained in this publication is subject to change without notice. VERITAS Software Corporation makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and ﬁtness for a particular purpose. VERITAS Software Corporation shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this manual.

Copyright Copyright © 2002 VERITAS Software Corporation. All rights reserved. VERITAS, VERITAS SOFTWARE, the VERITAS logo, and all other VERITAS product names and slogans are trademarks or registered trademarks of VERITAS Software Corporation in the USA and/or other countries. Other product names and/or slogans mentioned herein may be trademarks or registered trademarks are the property of their respective companies. VERITAS Software Corporation 350 Ellis Street Mountain View, CA 94043 Phone 650–527–8000 Fax 650-527-2908 www.veritas.com

Data Encryption Standard (DES) Copyright Copyright © 1990 Dennis Ferguson. All rights reserved. Commercial use is permitted only if products that are derived from or include this software are made available for purchase and/or use in Canada. Otherwise, redistribution and use in source and binary forms are permitted. Copyright 1985, 1986, 1987, 1988, 1990 by the Massachusetts Institute of Technology. All rights reserved. Export of this software from the United States of America may require a speciﬁc license from the United States Government. It is the responsibility of any person or organization contemplating export to obtain such a license before exporting. WITHIN THAT CONSTRAINT, permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the software without speciﬁc, written prior permission. M.I.T. makes no representations about the suitability of this software for any purpose. It is provided as is without express or implied warranty. Contents

Organization ...... 1 Getting Help ...... 2 Using VRTSexplorer ...... 3 Downloading VRTSexplorer from the Web ...... 3 Conventions ...... 5 Overview of VxVM 3.5 for HP-UX ...... 6 Features of VxVM compared to LVM ...... 7 New Features in VxVM 3.5 ...... 7 Working With VxVM 3.5 Root Disks ...... 8 VERITAS VxVM 3.5 Licenses ...... 10 Feature Availability by Product ...... 10 VEA Graphical User Interface and SAM ...... 14 Coexistence with HP Logical Volume Manager (LVM) ...... 14 Limitations of this Release ...... 14 Supported Migration Scenarios ...... 15 Documentation ...... 15 Compatibility Information and Installation Notes ...... 17 Software Requirements ...... 17 Other Requirements ...... 17 Installing Previous Versions of HP-UX 11i ...... 17 Patches and Fixes in This Version ...... 17 Support for the HP Process Resource Manager ...... 18 Required and Recommended Patches ...... 18

iii Getting Product Information Updates ...... 19 Known Problems and Workarounds ...... 20 Installation Issues ...... 20 Cautionary Note when using HP-UX Maintenance Mode Boot (MMB) ...... 21 vxassist Issues ...... 22 VEA Issues ...... 24 VxVM DMP Issues ...... 28 Miscellaneous Issues ...... 29 Using FUJITSU Disks ...... 36

iv VERITAS Volumen Manager Release Notes VERITAS Volume Managerª Release Notes

This document provides release information for the VERITAS Volume Manager™ (VxVM¨) Release 3.5. This release also includes the new VERITAS Enterprise Administrator™ (VEA™) graphical user interface. Release Notes are not installed along with any Volume Manager package. VERITAS recommends that you copy this document to the /opt/VRTS/doc directory so that the information is available for your future reference. VxVM product enhancement is an ongoing process. To check for any additional information about this release, please use the steps shown in the section called “New Features in VxVM 3.5” on page 7.

Note Before you install the packages, please review this entire document.

Organization

Note Before you install the packages, please review this entire document.

◆ “Getting Help” on page 2 ◆ “Conventions” on page 5 ◆ “Overview of VxVM 3.5 for HP-UX” on page 6 ◆ “VERITAS VxVM 3.5 Licenses” on page 10 ◆ “Known Problems and Workarounds” on page 20 ◆ “Compatibility Information and Installation Notes” on page 17 ◆ “Patches and Fixes in This Version” on page 17

1 Getting Help

Getting Help

If you have any comments or problems with the VERITAS products, contact the VERITAS Technical Support: ◆ U.S. and Canadian Customers: 1-800-342-0652 ◆ International Customers: +1 (650) 527-8555 ◆ E-mail: [email protected] For license information: ◆ Phone: 1-925-931-2464 ◆ Email: [email protected] ◆ Fax: 1-925-931-2908 For software updates: ◆ Email: [email protected] For late-breaking news about this release, please see the section called “Known Problems and Workarounds” on page 20. For additional technical support information, including - TechNotes - Product alerts - Hardware compatibility lists visit the VERITAS Technical Support Web site at: http://support.veritas.com For information about VERITAS products and services: Phone 1-800-258-UNIX (1-800-258-8649) or 1-650-527-8000 Email [email protected] For additional information about VERITAS and VERITAS products, visit the Web site at: http://www.veritas.com

2 VERITAS Volume Manager Release Notes Using VRTSexplorer

Using VRTSexplorer

The VRTSexplorer program can help VERITAS Technical Support engineers diagnose the cause of technical problems associated with VERITAS products. You can download this program from the VERITAS FTP site or install it from the VERITAS Installation CD. For more information, consult the README ﬁle in the support directory on the VERITAS Installation CD.

Downloading VRTSexplorer from the Web

If you have access to the Internet, you can use the VRTSexplorer program to assist Technical Support in diagnosing the cause of your technical or software problem as follows:

1. Use a web browser or the ftp program to download the VRTSexplorer program at the following URL: ftp://ftp.veritas.com/pub/support/vxexplore.tar.Z Save the ﬁle to a temporary directory such as /tmp as shown in these instructions. If you download the ﬁle to a different directory, substitute its path name for /tmp throughout.

2. Log in as root on the affected system, and use the following commands to extract the contents of the downloaded ﬁle to the directory /tmp/VRTSexplorer: # cd /tmp # zcat vxexplore.tar.Z | tar xvf -

3. Run the VRTSexplorer program located in the VRTSexplorer directory by entering the following command: # /tmp/VRTSexplorer/VRTSexplorer

4. When VRTSexplorer prompts you for a destination directory for the information that it collects, press Return to accept the default directory /tmp, or enter a path name of your own choice. VRTSexplorer writes the results of its investigations to a compressed tar ﬁle named VRTSexplorer_casenumber_hostname.tar.Z in the speciﬁed directory.

5. Use the ﬁle upload facility of your web browser or the ftp program to transfer the ﬁle output by VRTSexplorer to the VERITAS Customer Support anonymous FTP site: ftp://ftp.veritas.com/incoming

VERITAS Volume Managerª Release Notes 3 Using VRTSexplorer

6. Call VERITAS Customer Support on 1-800-342-0652, inform them that you have run VRTSexplorer and tell them the name of the ﬁle that you transferred to the FTP site. Alternatively, if you have already been assigned a call ID number by Customer Support, email [email protected] including your case ID number in the subject line.

4 VERITAS Volume Manager Release Notes Conventions

Conventions

The following table describes the typographic conventions used in this document.

Typeface Usage Examples monospace Computer output, ﬁles, Read tunables from the directories, software elements /etc/vx/tunefstab ﬁle. such as command options, See the ls(1) manual page for more function names, and parameters information. monospace User input # mount -F vxfs /h/filesys (bold) italic New terms, book titles, See the User’s Guide for details. emphasis, variables replaced The variable ncsize determines the with a name or value value of...

Symbol Usage Examples % C shell prompt $ Bourne/Korn shell prompt # Superuser prompt (all shells) Continued input on the # mount -F vxfs \ \ following line /h/filesys [ ] In a command synopsis, brackets ls [ -a ] indicates an optional argument | In a command synopsis, a mount [ suid | nosuid ] vertical bar separates mutually exclusive arguments

Note “Dynamic Disk Groups" were formerly known as "Disk Groups." They are still sometimes referred to as "Disk Groups" in documentation, menu displays, and the CLI.

VERITAS Volume Managerª Release Notes 5 Overview of VxVM 3.5 for HP-UX

Overview of VxVM 3.5 for HP-UX

Note Since the initial writing of this document and the Volume Manager 3.5 Installation Guide, there has been a change of terminology: In both manuals, depending on the context in which it is used, “AR0902” should be interpreted as follows: Wherever AR0902 refers to the software received by new customers, it should be interpreted as referring to the Operating Environment September 2002 HP-UX 11i version 1.0 release. In all other cases, AR0902 refers to the Application September 2002 Application Release (existing HP-UX 11i customers will receive this release, which includes the Base-VxVM, but does not provide the capability for installing IUX VxVM). ¨ VERITAS Volume Manager™ (VxVM ) Release 3.5 for HP-UX provides state-of-the-art online disk management for HP-UX. It consists of several related bundles: ◆ Base VERITAS Volume Manager 3.5 for HP-UX (Base VXVM) [Base-VXVM]: Provides basic volume manager features, including a Java-based GUI, and is included with all HP-UX 11i AR0902 Operating Environments, as well as with the HP-UX 11i Application Release for no additional fee. When MC/ServiceGuard or ServiceGuard OPS Edition is installed on your system, the Base VERITAS Volume Manager 3.5 for HP-UX also provides some basic clustering features. The Base-VXVM bundle installed by default contains VRTSvxvm, VRTSvmdoc, VRTSvlic, VRTSob, VRTSobgui, VRTSvmpro, and VRTSfspro. ◆ VERITAS Volume Manager 3.5 for HP-UX (VxVM) [B9116AA]: Provides a full set of enhanced volume manager capabilities, including mirroring, and is available for an additional fee. ◆ VERITAS Cluster Volume Manager 3.5 for HP-UX (CVM) [B9117AA]: Provides enhanced volume manager functionality for clustered environments, is integrated with MC/ServiceGuard and ServiceGuard OPS Edition, and is available for an additional fee. B9117AA requires B9116AA. ◆ VERITAS Volume Manager 3.5 FastResync Option for HP-UX (FR) [B9118AA]: Reduces the time taken to resynchronize a split mirror to the volume, and is available for an additional fee. B9118AA requires B9116AA. This release also includes the new VERITAS Enterprise Administrator™ (VEA™) graphical user interface. The VERITAS Volume Manager for HP-UX is an alternative to the HP Logical Volume Manager and HP MirrorDisk/UX products. This document describes the 3.5 release of the VERITAS Volume Manager for HP-UX products. Base-VxVM is included with the HP-UX 11i Operating Environments.

6 VERITAS Volume Manager Release Notes Overview of VxVM 3.5 for HP-UX

Features of VxVM compared to LVM

The VERITAS Volume Manager for HP-UX 3.5 (VxVM) includes many features that are not available with LVM on HP-UX. Some of these features are: ◆ VEA—a Java-based administrative GUI ◆ RAID-5 ◆ Dynamic multipathing for I/O load balancing ◆ Support for up to 32 mirrors ◆ Striped mirrors ◆ Online relayout of volumes ◆ Device Discovery Layer (DDL) ◆ Boot performance enhancements ◆ Support for striped mirrors (layered volumes), online relayout, and Oracle resilvering with CVM ◆ CVM infrastructure changes to support VERITAS Cluster File System

New Features in VxVM 3.5

◆ GAB messaging In a cluster environment, support has been included for using GAB as the transport agent for messaging. This means that you do not need to assign IP addresses for the endpoints of your cluster’s private network when you configure the clustering functionality of VxVM. ◆ Large file system support VxVM now supports the use of 64-bit block numbers with file systems that can understand these. ◆ Rootability Support The capability to allow the VERITAS Volume Manager to manage the root disk selectable at installation time. ◆ New licensing package A new licensing package, VRTSvlic, has been introduced. In time VRTSvlic will become the common licensing solution for all VERITAS products. Existing license keys are automatically translated into license keys that can be used with the

VERITAS Volume Managerª Release Notes 7 Overview of VxVM 3.5 for HP-UX

VRTSvlic package. Both licensing packages can co-exist on the same system to support older VERITAS products that do not understand the new licensing utilities. For more information, see the VERITAS Volume Manager 3.5 Installation Guide. ◆ VxVM tunables The values of various tunables have been adjusted to match the performance expected from current systems. For more information about conﬁguring VxVM tunables, see the “Performance Monitoring and Tuning” chapter in the VERITAS Volume Manager 3.5 Administrator’s Guide. ◆ VERITAS Enterprise Administrator (VEA) VEA replaces the VERITAS Volume Manager Storage Administrator (VMSA) as the graphical conﬁguration tool for VxVM.

Note For information about new features in VERITAS Volume Replicator (VVR), please see the VVR Release Notes.

Working With VxVM 3.5 Root Disks

This section describes: ◆ Adding Dump Volumes Using Volume Manager Disks ◆ Changing the Boot Disk to be the New Volume Manager Root Disk ◆ Removing a Mirrored Volume Manager Root Disk

Adding Dump Volumes Using Volume Manager Disks Volume Manager volumes can be used for additional dump volumes in conﬁgurations with LVM or VxVM root disks.

1. Remove a disk from LVM control. Execute the following: # pvcreate -f /dev/rdsk/c#t#d# # pvremove /dev/rdsk/c#t#d#

2. Put a disk under Volume Manager control and place in rootdg: Use vxdiskadm option 1, or VEA.

3. Add a volume to this disk: Use vxassist or VEA.

4. Add the new volume as a target for dumps:

8 VERITAS Volume Manager Release Notes Overview of VxVM 3.5 for HP-UX

First make sure you have the UNOF_init_dump patch, then use crashconf as you would under LVM. For example; # crashconf /dev/vx/dsk/rootdg/your_dump_volume

Changing the Boot Disk to be the New Volume Manager Root Disk

1. Get the current boot disk: # cat /stand/bootconf

2. Extract resultant device path: # ioscan -k node_path_from_bootconf

3. Change primary boot path back to current boot device: # setboot -p device_path_from_above (Use -a if you want to change the alternate bootpath.)

Removing a Mirrored Volume Manager Root Disk Use the following commands to remove the mirrored Volume Manager Root Disk: # daname= /* of mirrored root disk */ # dmname=`vxprint -g rootdg -F %dmname -e sd_da_name~/$daname/|head -1` # plxnames=`vxprint -g dg -F "%assoc" -e sd_dm_name==\"$dmname\"` # vxplex -o rm dis $plxnames # vxdg -g rootdg rmdisk $dmname

VERITAS Volume Managerª Release Notes 9 VERITAS VxVM 3.5 Licenses

VERITAS VxVM 3.5 Licenses

The following table shows the supported features available with VERITAS Volume Manager 3.5 licensing

VxVM License Description of Supported Features VERITAS Volume Concatenation, spanning, striping, root disk mirroring, rootability, volume Manager, 3.5 resizing, multiple disk groups, co-existence with native volume manager, task monitor, VEA., user data mirroring, DRL logging for mirrors, striping plus mirroring, mirroring plus striping, RAID-5, RAID-5 logging, Smartsync, hot sparing, hot-relocation, online data migration, online relayout, volume snapshots, and multipath DMP. Add-on Licenses Features that augment the VERITAS VxVM 3.5 license such as FlashSnap™ (FastResync and Dynamic Disk Group Split and Join), and clustering functionality (cluster-shareable disk groups and shared volumes).

Unless you have installed the required license, you may not be able to use certain features of VERITAS VxVM 3.5. For example, you require a VERITAS VxVM 3.5 license to be able to create mirrored volumes other than the root disk. You also require a VERITAS VxVM 3.5 license to make effective use of an Add-on licenses to VxVM. For example, FastResync (a FlashSnap license feature) reduces the time taken to resynchronize volume snapshots (a VERITAS VxVM 3.5 license feature).

Feature Availability by Product

The following table lists the features available with the VERITAS Volume Manager for HP-UX products.

Note When MC/ServiceGuard or ServiceGuard OPS Edition is installed, then Base VERITAS Volume Manager 3.5 for HP-UX (Base-VXVM) includes some basic clustering features, in addition to basic VxVM features. These basic clustering

10 VERITAS Volume Manager Release Notes VERITAS VxVM 3.5 Licenses

features are known as base CVM. These basic clustering features can be used without the purchase of VERITAS Cluster Volume Manager 3.5 for HP-UX (B9117AA).

VERITAS Volume Manager 3.5 for HP-UX Feature Availability

Feature AR 0902 Base AR 0902 AR 0902 AR0902 VERITAS VERITAS VERITAS VERITAS VERITAS Volume Volume Volume Cluster Volume Manager Manager 3.5 Manager 3.5 Volume Manager 3.5 for for HP-UX for HP-UX Manager 3.5 3.5 HP-UX (Base-VXVM) (B9116AA) for HP-UX FastResync (B9117AA) Option for HP-UX (B9118AA)

Java-based Supported Supported Supported - Supported admin GUI

Striping Supported Supported Supported - Supported (RAID 0)

Concatenation Supported Supported Supported - Supported

Path failover Supported Supported Supported - Supported support (active/passiv e peripherals)

Online Supported Supported Supported - Supported resizing of volumes

Load - Supported Supported - Supported balancing — DMP (active/active peripherals)

Hot-relocation - Supported Supported - Supported and unrelocation

VERITAS Volume Managerª Release Notes 11 VERITAS VxVM 3.5 Licenses

VERITAS Volume Manager 3.5 for HP-UX Feature Availability

Mirroring - Supported Supported - Supported (RAID-1)

Number of - 32 32 - Supported mirrors supported

Mirrored - Supported Supported - Supported Stripes (RAID 0+1)

Striped - Supported Supported - Supported Mirrors (RAID 1+0)

RAID-5 - Supported - - Supported

Online - Supported Supported - Supported migration

Online relayout - Supported Supported - Supported

Task monitor Supported for Supported Not supported - Supported base VXVM but not for CVM

FastResync - - Yes With additional license

12 VERITAS Volume Manager Release Notes VERITAS VxVM 3.5 Licenses

VERITAS Volume Manager 3.5 for HP-UX Feature Availability

Support for Supported Supported Supported With MC/SG additional (A.11.13 and license A.11.14)

Support for SG Supported for - Supported - Supported OPS Edition CVM but not for CVM for base VxVM but not for base VxVM

Multiple node 16 MC/SG 16 MC/SG - - 16 MC/SG cluster support with VxVM

Multiple node 4 MC/SG - 4 MC/SG - 4 MC/SG cluster 2 SG OPS 4 SG OPS 2 SG OPS support with CVM

Online Disk group can - Disk group can - Disk group Reconﬁguratio be activated on be activated on can be n for shared only one node up to four activated on disk groups nodes only one node

Note In an active/passive peripheral, LUNs only accept I/O on one path at any time. In an active/active peripheral, LUNs accept I/O on either path at any time.

VERITAS Volume Managerª Release Notes 13 VERITAS VxVM 3.5 Licenses

VEA Graphical User Interface and SAM

The VERITAS Enterprise Administrator (VEA) provides a Java-based graphical user interface for managing VxVM. VEA has two parts: a server and a client. The server must run on the system running VxVM. The client can run on the server machine, or the client software can be installed on a different HP-UX 11i system to manage VxVM remotely. Note that only HP-UX 11i clients are supported. SAM, the HP-UX system administration manager, and VEA exist as independent entities. SAM is used to manage LVM objects and the VEA is used to manage VxVM objects. However, VEA recognizes and labels LVM volumes and disks, and similarly, SAM recognizes and labels VxVM volumes and disks. To manage VxVM disks graphically, you must use VEA. For information about VEA, see the VERITAS Volume Manager 3.5 User’s Guide—VEA.

Coexistence with HP Logical Volume Manager (LVM)

The VERITAS Volume Manager for HP-UX coexists with HP Logical Volume Manager (LVM). Before VxVM 3.5, the VERITAS Volume Manager could not be used to control the root/boot disk. Both LVM and VxVM utilities are aware of the other volume manager, and will not overwrite disks that are being managed by the other volume manager. As mentioned above, the administrative utilities (SAM and VEA) recognize and identify all disks on the system. Although this release is targeted at new customer installations, a conversion utility, vxvmconvert, is provided for converting LVM volume groups to VxVM volume groups. Refer to the VERITAS Volume Manager 3.5 Migration Guide for details on using vxvmconvert.

Limitations of this Release

VERITAS Volume Manager 3.5 for HP-UX has the following limitations, which will be removed in subsequent releases: ◆ Only versions A.11.13 and A.11.14 of MC/ServiceGuard and ServiceGuard OPS Edition for HP-UX 11i will work with VERITAS Cluster Volume Manager 3.5 for HP-UX. ◆ Only version A.11.13 of MC/ServiceGuard for HP-UX 11i will work with VERITAS Volume Manager 3.5 for HP-UX.

14 VERITAS Volume Manager Release Notes VERITAS VxVM 3.5 Licenses

◆ The VERITAS Volume Manager 3.5 for HP-UX now supports the HP Process Resource Manager (PRM) product. An HP OS patch is required to be able to gather statistics on disks managed by VxVM. The patch number was not known at the time this document was written. See Patches and Fixes in This Version for instructions on ﬁnding the latest patches. ◆ A disk monitor integrated with the EMS framework is not yet available for disks being managed by VERITAS Volume Manager 3.5 for HP-UX. ◆ You must use LVM to manage your cluster lock disk; you cannot use VERITAS Volume Manager for HP-UX or VERITAS Cluster Volume Manager 3.5 for HP-UX to manage a cluster lock disk with this release. ◆ The maximum number of nodes in a ServiceGuard cluster is 4 in this release of VERITAS Cluster Volume Manager 3.5 for HP-UX. HP is continually adding support for additional hardware and software. Contact your HP Service Representative for information about additional support or refer to the latest edition of these Release Notes on http://docs.hp.com. Refer to Hardware Requirements later in this document for the current list of platforms and peripherals that are supported with VERITAS Volume Manager 3.5 for HP-UX.

Supported Migration Scenarios

The upgrade procedure allows you to retain your existing HP-UX 11.11 or HP-UX 11i VxVM conﬁguration when migrating to VxVM 3.5 on HP-UX 11i. After upgrading, you can resume using VxVM on the same host with an upgraded operating system without running the vxinstall procedure. Refer to the VERITAS Volume Manager 3.5 Installation Guide for details

Documentation

The following documents describe the VERITAS Volume Manager for HP-UX. They are available with the VRTSvmdoc package which is installed by default with the HP AR0902 CD in the Base-VXVM bundle, or can be installed from the VERITAS CD. ◆ VERITAS Volume Manager 3.5 Administrator’s Guide ◆ VERITAS Volume Manager 3.5 Troubleshooting Guide ◆ VERITAS Volume Manager 3.5 User’s Guide—VEA ◆ VERITAS Volume Manager 3.5 Migration Guide ◆ VERITAS Volume Manager 3.5 Installation Guide ◆ VERITAS Volume Manager 3.5 Hardware Notes

VERITAS Volume Managerª Release Notes 15 VERITAS VxVM 3.5 Licenses

Manual pages are also available on your system via the man(1) command when you install the software. The following documents describe MC/ServiceGuard and ServiceGuard OPS Edition. They are available in hardcopy or on the web at http://docs.hp.com/hpux/ha. ◆ Managing MC/ServiceGuard ◆ Conﬁguring OPS Clusters with ServiceGuard OPS Edition ◆ MC/ServiceGuard Release Notes for Versions A.11.13 and A.11.14 ◆ ServiceGuard OPS Edition Version A.11.13 Release Notes

16 VERITAS Volume Manager Release Notes Compatibility Information and Installation Notes

Compatibility Information and Installation Notes

Software Requirements

◆ HP-UX 11i 32-bit OS ◆ HP-UX 11i 64-bit OS

Note The VERITAS File System Manager (VxFS), which can be used with VxVM, operates and is supported only on the HP-UX 11i 64-bit OS. (The HP VxFS 3.3 product is supported on both 32-bit and 64-bit OS.)

OS Platform and Version Compatibility HP-UX 11i

Other Requirements

During vxinstall, it is advisable to have at least two disks (preferably on separate controllers) in the default VxVM disk group, rootdg. Having at least two disks guarantees that multiple copies of the VxVM conﬁguration database exist. This database is required not only to start VxVM, but is also required when making VxVM conﬁguration changes (for example, creating volumes).

Note Despite its name, rootdg does not necessarily include your root disk.

Installing Previous Versions of HP-UX 11i

If you are setting up an Ignite server with the latest IUX from HP-UX 11i AR0902 (or later), and if you are planning to use this same Ignite server to install previous versions of HP-UX 11i, then do NOT select the option “VERITAS Volume Manager (VxVM) with VxFS” at OS installation time. This option is not supported on releases prior to HP-UX 11i AR0902, and your installation will fail.

Patches and Fixes in This Version

This section describes patches that are required and defects that have been ﬁxed in VERITAS Volume Manager 3.5 for HP-UX.

VERITAS Volume Managerª Release Notes 17 Patches and Fixes in This Version

Support for the HP Process Resource Manager

VxVM 3.5 for HP-UX now supports the HP Process Resource Manager (PRM) product. A HP OS patch is required to be able to gather statistics on disks managed by VxVM. The patch number was not known at the time this document was published. See “Required and Recommended Patches” for instructions on ﬁnding the latest patches.

Required and Recommended Patches

The following table lists patches required or recommended for Version 3.5 of VERITAS Volume Manager for HP-UX. This list is subject to change without notice. Patches can be superseded or withdrawn at any time, so always be sure to check the status of a patch before downloading it. Patch numbers for some VERITAS Volume Manager for HP-UX ﬁxes were not known at the time this document was published. For the latest information about available patches, see the IT Resource Center, http://ITresourcecenter.hp.com. ◆ If you have a support contract, select Browse Support Info By Product. ◆ If you do not have a support contract, select Individual Patches to search the Patch Database. Then select HP-UX Patches, select 11.11 as the OS version, and search for the keyword “VxVM” to get a list of VERITAS Volume Manager for HP-UX patches.

Note You must register with the IT Resource Center to search the patch database

Patch Number Description Mandatory/Recommended PHKL_27563 SCSI IO Subsystem Cumulative Patch Recommended PHKL_27096 VxVM rootability changes to HP-UX Kernel Mandatory (needed for successful VxVM 3.5 installation) PHKL_27177 VxVM boot support changes for OS Recommended bootloader PHCO_27100 VxVM rootability changes to HFS mkfs Recommended command PHCO_27101 VxVM rootability changes to mkboot Mandatory (needed for commands successful VxVM 3.5 installation) PHCO_27243 VxVM rootability changes to the insf Mandatory (needed for command successful VxVM 3.5 installation) PHCO_27099 VxVM rootability changes to LVM commands Recommended

18 VERITAS Volume Manager Release Notes Patches and Fixes in This Version

Patch Number Description Mandatory/Recommended PHCO_27103 Patch for VxVM rootability changes to Recommended /sbin/pre_init_rc

PHCO_27185 ioinitrc(iM) patch Recommended

HP may release patches that supersede those in the above list. To verify that you have the latest HP-UX patches, you should refer to the patchlist at the VERITAS support website: http://seer.support.veritas.com/docs/250499.htm Alternatively, you can use Hewlett-Packard's Patch Database, offered under the Maintenance and Support section of the HP Services & Support - IT Resource Center. HP's Patch Database provides fast, accurate searches for the latest recommended and superseded patches available for the VERITAS File System or VERITAS Volume Manager.

Getting Product Information Updates

There may be additional product information about this release which is available on the VERITAS Technical Support website. To check for any new or updated information, do the following:

1. Go to the VERITAS Technical Support website at http://support.veritas.com.

2. Click on the Knowledge Base Search section.

3. Select Volume Manager for UNIX from the Search Product pull-down menu and enter the search phrase “late breaking information”. This will show you any information that has been amended or added to the VxVM 3.5 product documentation.

VERITAS Volume Managerª Release Notes 19 Known Problems and Workarounds

Known Problems and Workarounds

The following known problems and workarounds have been identiﬁed: Installation Issues vxassist Issues VEA Issues VxVM DMP Issues Miscellaneous Issues

Installation Issues

Removal of HPvxvm Product after Installing VxVM 3.5 Products Causes License Files to be Removed ◆ Problem: The HPvxvm postremove script removes directories in /etc/vx, apart those named /etc/vx/elm, /etc/vx/type or /etc/vx/emc.d. Thus VxVM 3.5 products installed on the system lose their licensing files since they get installed in /etc/vx/licenses. Also, files created with the VRTSvlic product also get removed. ◆ Workaround: Reinstall the VRTSvlic product if it had been installed. Remember to use the "-x reinstall=true" flag for the swinstall. For product specific licenses, simply reapply the licenses using the vxlicinst(1) command. (See also Technote at http://seer.support.veritas.com/docs/244257.htm.)

Machine Apparently Hangs After Installing AR1201 If you have a machine that has AR0902 installed with VxVM root, and then you attempt to install 11i AR1201 to a different disk; then rebooting the machine after the AR1201 installation will initiate a question that will wait for user input. ◆ Problem: If you are installing from an Ignite-UX server, you will not see the question and it will appear that the machine is hung. The question should appear after the following message on the console: * Bringing up Network (lan0) * NFS mounting clients directory. The question that is being asked is: This appears to be a VxVM boot disk device. Overwriting it will destroy the current LIF directory

20 VERITAS Volume Manager Release Notes Known Problems and Workarounds

Should the current LIF directory be destroyed [y/n]? ◆ Type “n” after the console message, if you suspect that the system is waiting for an answer.

Note This is ﬁxed in AR0902. The problem does not arise if you install AR0902 on different disk on a machine that already has a vxvm root disk.

Cautionary Note when using HP-UX Maintenance Mode Boot (MMB)

HPUX Maintenance Mode Boot (MMB) is meant to used in the recovery from catastrophic failures that have prevented the target machine from booting. If a mirrored root is configured, then when booting in MMB mode, only one mirror is activated. Therefore, any writes to the root filesystem in this mode could cause root filesystem corruption later when both mirrors are configured. The vx_emerg_start script is provided to be used when starting the Volume Manager in MMB mode. This script will avoid writing to the root filesystem, unless absolutely necessary. If it needs to update the volboot file, then it will request that you reinvoke t the vx_emerg_start script, using the -f option, to perform the write. It is recommended that after the vx_emerg_start script has been run to start the Volume Manager while in MMB mode on a mirrored root, that the half of the mirror not booted from is removed. This can be carried out as follows: ◆ Determine which disk you booted from. ◆ Use the vxdisk list command to find your boot disk in the DEVICE column on the far left. ◆ Find the Disk Media (DM) name of your boot device by looking up your boot device in the DISK column. This will be a name such as rootdisk01, rootdisk02, and so on. Also note the name of the mirror disk DM. ◆ Use the vxprint -g rootdg rootvol command. If you have a mirrored root volume, you will see two lines with "pl" on the far left side. Look at each pl (or "plex") entry and immediately below it will be the subdisk associated with the plex. It will start with an "sd" in the far left column. ◆ Look at the NAME field immediately to the right of the "sd" column. This will show the subdisk name, which is made up of the DM name followed by -nn, where nn is a number such as 03, 04, and so on. This should allow you to identify the DM name of the disk that is not your boot disk. You can remove the plex and its associated subdisk by executing the vxplex command as follows: vxplex -o rm dis plex name

VERITAS Volume Managerª Release Notes 21 Known Problems and Workarounds

For example, to remove the rootvol plex associated with rootdisk02: vxprint -g rootdg rootvol

TY NAME ASSOC KSTATE LENGTH PLOFFS STATE v rootvol root ENABLED 524288 - ACTIVE pl rootvol-01 rootvol ENABLED 524288 - ACTIVE sd rootdisk01-03 rootvol-01 ENABLED 524288 0 - pl rootvol-02 rootvol ENABLED 524288 - ACTIVE sd rootdisk02-03 rootvol-02 ENABLED 524288 0 -

vxplex -o rm dis rootvol-02

Note The TUTIL0 and PUTIL0 ﬁelds have been removed in the above vxprint output for readability.

Once the system has been repaired and is up in normal mode, the root volume can be remirrord using the command: vxassist -g rootdg mirror rootvol dm:rootdisk02

vxassist Issues

vxassist relayout Considerations ◆ Problem: The vxassist relayout operation requires all mirrors in the volume to have the same layout (ref. incident 90840). ◆ Workaround: If the volume is contains mirrors with different layouts, then you need to relayout the mirror plexes to the same layout before performing the volume relayout operation.

vxassist Sometimes Applies the Wrong Layout to a Mirrored Volume ◆ Problem: While doing relayout on a mirrored volume, the vxassist command keeps the volume as mirrored even if the layout attribute is speciﬁed as stripe or nomirror. For example, see the following commands: # vxassist make vol 1g layout=mirror-stripe ncol=3 # vxassist relayout vol layout=stripe ncol=2 The volume vol is converted to a 2-column volume, but it is still mirrored even if the layout attribute is speciﬁed as stripe and nomirror. ◆ Workaround: None.

22 VERITAS Volume Manager Release Notes Known Problems and Workarounds

vxassist Command Does not Add a Mirror and a Log ◆ Problem: The vxassist command does not add a mirror and a log when processing a command such as the following: # vxassist mirror volume layout=log ... The mirror is added, but the log is silently omitted. ◆ Workaround: If a log and a mirror are to be added, add the mirror and the log in two separate vxassist invocations, as follows: # vxassist mirror volume ... # vxassist addlog volume ...

Crash Recovery Following Snapback Operations There are two scenarios that demand action when the system crashes during a snapback operation. The two scenarios involve the use of the vxassist command with resyncfromoriginal and resyncfromreplica options.

Crash Recovery after using vxassist -o resyncfromoriginal snapback snapvol ◆ Problem: When you use the following command: # vxassist -o resyncfromoriginal snapback snapvol to execute a default snapback operation (resynchronizing from the original volume), and the system crashes while the operation is still in progress, you will ﬁnd, when the system comes back up and the volumes are restarted, that the snapshot plexes are not associated with any volume. ◆ Workaround: To recover from this situation, you should use the following procedure:

a. Use the following commands to discover the original volume name of each snapshot plex: # volrid=‘vxprint -g diskgroup -p -F “%snap_rid” plexname‘ # vxprint -g diskgroup -n -v -e v_rid=$volrid

b. Using the information discovered in step a, identify the volumes to which the snapshot plexes originally belonged, and reattach them to those original volume as in the following command: # vxplex att original_volume plex1 [plex2 ...]

Crash Recovery after using vxassist -o resyncfromreplica snapback snapvol ◆ Problem: When you use the following command:

VERITAS Volume Managerª Release Notes 23 Known Problems and Workarounds

# vxassist -o resyncfromreplica snapback snapvol to execute a snapback operation (resynchronizing from the replica volume), and the system crashes while the operation is still in progress, you will ﬁnd, when the system comes back up, that the original volume fails with the following error message: vxvm:vxvol: ERROR: Volume original_volume has no CLEAN or \ non-volatile ACTIVE plexes ◆ Workaround: To correct this situation, you should use the following procedure:

a. Disassociate all STALE plexes from the original volume: # vxplex dis staleplex1 [staleplex2 ...]

b. Convert all SNAPTMP plexes in the original volume to ACTIVE: # vxplex convert state=ACTIVE tmpplex1 [tmpplex2 ...]

c. Restart the original volume: # vxvol start original_volume

d. Reattach the plexes that you disassociated in step 1: # vxplex att original_volume staleplex1 [staleplex2 ...] This procedure results in a full synchronization of these plexes from the original volume.

VEA Issues

The following issues have been identiﬁed as VEA problems, and will be ﬁxed in either patches or a future release of VxVM.

Connecting to X Windows The following X Window System error may occur when starting VEA:

Xlib: connection to "hostname:0.0" refused by server Xlib: Client is not authorized to connect to Server Workaround: Allow X server access by typing: xhost + [hostname]

24 VERITAS Volume Manager Release Notes Known Problems and Workarounds

VxVM and Multi-Host Failover Configurations Outside the context of clustering functionality, VxVM disk groups can be imported (made available) from only one host at any given time. When a host imports a disk group as private, the volumes and configuration of that disk group becomes accessible to the host. If the administrator or system software wants to privately use the same disk group from another host, the host that already has the disk group imported (importing host) must deport (give up access to) the disk group. Once deported, the disk group can be imported by another host. If two hosts are allowed to access a disk group concurrently without proper synchronization, such as that provided by the Oracle Parallel Server, the configuration of the disk group, and possibly the contents of volumes, can be corrupted. Similar corruption can also occur if a file system or database on a raw disk partition is accessed concurrently by two hosts, so this is not a problem limited to VxVM.

Import Lock When a host in a non-clustered environment imports a disk group, an import lock is written on all disks in that disk group. The import lock is cleared when the host deports the disk group. The presence of the import lock prevents other hosts from importing the disk group until the importing host has deported the disk group. Specifically, when a host imports a disk group, the import normally fails if any disks within the disk group appear to be locked by another host. This allows automatic re-importing of disk groups after a reboot (autoimporting) and prevents imports by another host, even while the first host is shut down. If the importing host is shut down without deporting the disk group, the disk group can only be imported by another host by clearing the host ID lock first (discussed later). The import lock contains a host ID (in VxVM, this is the host name) reference to identify the importing host and enforce the lock. Problems can therefore arise if two hosts have the same host ID.

Note Since VxVM uses the host name as the host ID (by default), it is advisable to change the host name of one machine if another machine shares its host name. To change the host name, use the vxdctl hostid new_hostname command.

Failover The import locking scheme works well in an environment where disk groups are not normally shifted from one system to another. However, consider a setup where two hosts, Node A and Node B, can access the drives of a disk group. The disk group is ﬁrst imported by Node A, but the administrator wants to access the disk group from Node B if Node A crashes. This kind of scenario (failover) can be used to provide manual high

VERITAS Volume Managerª Release Notes 25 Known Problems and Workarounds

availability to data, where the failure of one node does not prevent access to data. Failover can be combined with a “high availability” monitor to provide automatic high availability to data: when Node B detects that Node A has crashed or shut down, Node B imports (fails over) the disk group to provide access to the volumes. VxVM can support failover, but it relies on the administrator or on an external high-availability monitor to ensure that the ﬁrst system is shut down or unavailable before the disk group is imported to another system. For details on how to clear locks and force an import, see the vxdg(1M) manual page and the section on moving disk groups between systems in the VERITAS Volume Manager Administrator’s Guide.

Corruption of Disk Group Configuration If vxdg import is used with -C (clears locks) and/or -f (forces import) to import a disk group that is still in use from another host, disk group configuration corruption is likely to occur. Volume content corruption is also likely if a file system or database is started on the imported volumes before the other host crashes or shuts down. If this kind of corruption occurs, you must probably rebuild your configuration from scratch and reload all volumes in the disk group from a backup. To backup and rebuild the configuration, if nothing has changed, use vxprint -mspvd and store the output which can be fed to vxmake to restore the layouts. There are typically numerous configuration copies for each disk group, but corruption nearly always affects all configuration copies, so redundancy does not help in this case. Disk group configuration corruption usually shows up as missing or duplicate records in the configuration databases. This can result in a variety of vxconfigd error messages, including errors such as: Association not resolved Association count is incorrect Duplicate record in configuration Configuration records are inconsistent These errors are typically reported in association with specific disk group configuration copies, but usually apply to all copies. The following is usually displayed along with the error: Disk group has no valid configuration copies

See the VERITAS Volume Manager Troubleshooting Guide for more information on VxVM error messages. If you use the VERITAS VCS product, all disk group failover issues can be managed correctly. VCS includes a high availability monitor and includes failover scripts for VxVM, VxFS, and for several popular databases.

26 VERITAS Volume Manager Release Notes Known Problems and Workarounds

The -t option to vxdg prevents automatic re-imports on reboot, and is necessary when used with a host monitor (such as VCS) that controls imports itself, rather than relying on automatic imports by VxVM.

Restarting VEA after Obtaining New Licenses If, after installing and starting VEA, you obtain a new license (either explicitly, using vxlicinst, or implicitly, by installing bundles B9116AA, B9117AA, or B9118AA), you will not have access to the newly licensed features until you restart the VEA service:

1. Stop the VEA backend service: # /opt/VRTSob/bin/vxsvc -k

2. Start the VEA backend service: # /opt/VRTSob/bin/vxsvc

Updating Objects in Volume View ◆ Problem: Object updates in the Volume View may be incorrect. ◆ Workaround: Close then re-open the Volume View.

Updating Objects in Disk/Volume Map View ◆ Problem: Object updates in the Disk/Volume Map View may be incorrect. ◆ Workaround: Close then re-open the Disk/Volume Map View.

Mirroring Disks ◆ Problem: The Actions > Disk Mirror menu is incorrectly disabled if you do not have a full VxVM license. ◆ Workaround: Use the vxmirror command line to mirror the disk.

Splitting and Joining Shared Disk Groups ◆ Problem: VEA currently does not allow you to split/join shared disk groups. ◆ Workaround: Use the command line interface to effect the split/join.

VERITAS Volume Managerª Release Notes 27 Known Problems and Workarounds

Note After using the command line to split the disk group, VEA will not allow you to split/join the same disk group. However, if you right-click on the split disk group, the source and target disk groups are displayed, allowing you to rejoin the split.

VxVM DMP Issues

VxVM DMP Lists Disabled Paths That Have Been Reused ◆ Problem: When one of multiple paths or cables to a disk array is disconnected, fails, or is swapped with another path, and then that same path or cable is reconnected or replaced, it is possible that HP-UX will recognize the recovered path as a new path, not as the same path that has simply recovered. In this case, DMP will list twice as many paths: the “new” ones in the ENABLED state and the “old” ones (that is, from before the paths were swapped, removed or replaced) in the DISABLED state. I/O continues to be routed correctly. ◆ Workaround: None necessary. VxVM DMP will not automatically clean up the paths that are no longer in use, or that are in the DISABLED state. When the host is rebooted, the DMP database will be rebuilt without the DISABLED path deﬁnitions.

VxVM 3.5 Does not Support DMP Disabling The disabling of DMP is not supported in VxVM 3.2 and VxVM 3.5. The utilities that existed prior to VxVM 3.2 to disable DMP (vxdmpdis) and enable DMP (vxdmpen)areno longer provided.

Removing DMP Disks ◆ Problem: The vxdisk rm command only logically removes a disk. It does not remove the disk from DMP. Therefore, the disk may re-appear after a vxdctl enable even if the disk has been physically removed. ◆ Workaround: Restart usingvxconfigd. This causes the DMP database to be updated, and the physically removed device will no longer appear.

28 VERITAS Volume Manager Release Notes Known Problems and Workarounds

Miscellaneous Issues

Rootability Cloning Script May Yield "Too Many Processes" Error ◆ Problem: Running the VxVM rootability cloning script, vxcp_lvmro, may yield the following error message if your nproc tunable is set to the default of 276: /etc/vx/bin/vxcp_lvmroot[47]: The fork function failed. Too many already exist. sh: The fork function failed. Too many processes already exist. ◆ Workaround: Increase the nproc static tunable to 1024 using sam(1M), rebuild a new kernel, reboot your machine, and try the vxcp_lvmroot again.

Slow Disk Group Import for FC60 ◆ Problem: Importing a disk group made up of LUNs of an FC60 disk array is slow, requiring as much as 90 seconds to complete. Subsequent I/O operations, however, are normal with the FC60. ◆ Fix: A SCSI patch, PHKL_26519, fixes this problem. The fix is included in the “11.11 SCSI IO Subsystem Cumulative Patch.” See Patches and Fixes in This Version for instructions on finding the latest patches. Use SCSI or the CR number JAGad46688 as the search string. (JAGad46688 is the change request number for the SCSI problem that this patch fixes.)

Long Delay Time when Running vxconﬁgd ◆ Problem: You may experience a long (20 seconds) delay time when running vxconfigd without a CD-ROM in the CD/DVD drive. ◆ Workaround: Ensure there is a CD in the CD-ROM drive.

Business Copy (BC) Limitation on XP Disk Arrays ◆ Problem: VxVM will allow an import of the volumes from only one BC on a node where volumes have the same disk and group identiﬁcation. If the Primary (P-Vol) is accessible, then this volume will be used. The Secondary (S-Vol) is only imported if the P-Vol is inaccessible at the time of import. There is currently no ability to change the disk group identiﬁcation (group id) on XP BC volumes. ◆ Workaround: None

VERITAS Volume Managerª Release Notes 29 Known Problems and Workarounds

Note In the case where VxVM and XP512 BCs are being used together; if the BCs are split, you cannot then import the split BC to the machine on which P-Vol is currently being used. The reason for this is that the split BC and the P-Vol will have the same private region, and VxVM allows you to import only one of them; by default, it chooses P-Vol. If you want, however, you can import the split BC (S-Vol) onto a secondary host.

VxVM Commands Do Not Always Show Current Status of VxVM Disks ◆ Problem: The VEA and frequently used VxVM commands, such as vxdisk and vxprint, do not necessarily show the current status of disks managed by VxVM. VxVM builds and maintains a configuration database in system memory. This configuration database also includes Disk Access (DA) records with information about the disk devices obtained by the vxconfigd scan pass. VxVM relies on the operating system kernel to notify it of disk status changes. The HP-UX kernel does not currently notify VxVM of disk status changes. ◆ Workaround: Use either of the following commands to force an update of the VxVM configuration database: # vxdisk online diskname This command updates the status of the diskname disk. # vxdctl enable This command updates the status of all the VxVM disks.

Note The vxdctl enable command initiates an entire disk device scan. Therefore the length of time VxVM takes to scan all of the devices in the environment of that particular host will increase as the number of devices increases. If you know which disk’s state has been changed, it is faster to use vxdisk online diskname to update that disk only.

Run vxdctl enable to Show Status Changes for LVM Disks ◆ Problem: VxVM output will not reﬂect status changes for LVM disks until vxdctl(1M) is run. For example, if you clear an LVM disk with pvremove(1M), vxdiska_list will still list the status of that disk as “LVM,” until you run vxdctl enable. This is also true for VEA output and the output from other VxVM commands. ◆ Workaround: Run vxdctl enable after making any changes to LVM disks to update VxVM’s database.

30 VERITAS Volume Manager Release Notes Known Problems and Workarounds

VEA Continues Running With No rootdg ◆ Problem: If rootdg is on an external device which must be shut down, then VxVM commands cannot run. ◆ Workaround: None needed—VEA continues to run, although it cannot complete operations (commands are not being executed).

VxVM and Older Quantum Disk Drives ◆ Problem: The VxVM makes use of the kernel-to-kernel passthrough ioctl SCSI command feature in HP-UX. VxVM issues SCSI inquiry commands to devices on the system to recognize individual disks and sort out host to device connection pathways. Some older Quantum disks (models PD210S and PD425S) do not respond properly to SCSI inquiry command when the device is in certain states. As a consequence, these devices are not recognized by VxVM and, as such, cannot be used as disks for VxVM. A vxdisk command may list the device in error state or may not list at all. ◆ Workaround: Do not attempt to deﬁne the device for VxVM.

Duplicate Device Name Creation in rootdg ◆ Problem: When you create new volumes in the rootdg disk group, two sets of device nodes are created: under both /dev/vx/[r]dsk/ and /dev/vx/[r]dsk/rootdg. Although either path can be used for mkfs(1M) or mount(1M), the duplicate sets of device node names can be confusing. ◆ Workaround: We recommend using the full pathname to rootdg disk devices in command line arguments. This is consistent with the naming of device nodes in other disk groups. For example, to mount a rootdg volume use: # mount -F vxfs /dev/vx/dsk/rootdg/vol01 /vol01 Do not use /dev/vx/dsk/vol01 as the pathname. VEA always uses the full pathname.

vxrecover Needs at Least One ACTIVE or CLEAN Plex to Start a Volume ◆ Problem: The vxrecover command starts a volume only if it has at least one plex that is in the ACTIVE or CLEAN state and is not marked STALE, IOFAIL, REMOVED, or NODAREC. If such a plex is not found, VxVM assumes that the volume no longer contains valid up-to-date data, so the volume is not started automatically. A plex can be marked STALE or IOFAIL as a result of a disk failure or an I/O failure. ◆ Workaround: In such cases, to force the volume to start, use the following command:

VERITAS Volume Managerª Release Notes 31 Known Problems and Workarounds

# vxvol -f start volume However, try to determine what caused the problem before you run this command. It is likely that the volume needs to be restored from backup, and it is also possible that the disk needs to be replaced.

Free Space Reported Differently ◆ Problem: vxdg free reports free space differently than vxprint -ht. ◆ Workaround: None.

Subdisks are not Aligned on Cylinder Boundaries After a Relayout ◆ When relayout is performed on a volume, VxVM does not grow subdisks such that they end on cylinder boundaries. If you subsequently increase the size of the volume, its subdisks are not grown using contiguous disk space. ◆ To ensure that a volume’s subdisks are grown using contiguous disk space, specify the attribute layout=nodiskalign to vxassist, as shown here: # vxassist growby volume length layout=nodiskalign

Note Specifying layout=nodiskalign permanently enforces this layout policy on the volume.

Resizing Layered Volumes Fails while Resynchronization is Ongoing. ◆ Problem: Due to the current implementation to handle the resize of layered volumes, it is recommended that you do not grow or shrink layered volumes (stripe-mirror, concat-mirror, and so on) while resynchronization is ongoing. Internally, VxVM converts the layout of layered volumes and updates the conﬁguration database before it shrinks or grows their sizes. This causes any ongoing operation, such as the resynchronization, to fail. ◆ Workaround: If the system reboots before the grow or shrink of a layered volume completes, the volume is left with an intermediate layout. In this case, the user has to use vxassist convert to restore the volume to its original layout. After a layered volume is resized, the volume names, the plex names and the subdisk names associated with the subvolumes, are changed.

32 VERITAS Volume Manager Release Notes Known Problems and Workarounds

Stopping and Starting Layered Volumes If a layered volume is in use when a vxvol stopall command is issued, then only the sub-volumes are disabled. The layered volume remains enabled. When a vxvol stop layered-volume command is issued, then only the top layered volume is stopped. The sub-volumes remain enabled. When a vxvol start layered-volume command is issued, then only the top layered volume is started. The sub-volumes remain disabled.

Adding Swap Space Using VxVM Volumes The HP System Administration Manager (SAM) currently does not have the capability to add swap space using VxVM volumes. Please refer to the VERITAS Volume Manager Installation Guide for more information and workarounds for this problem.

Using SAM to Launch the VEA Client ◆ Problem: It is currently not possible to launch the VEA client from SAM. ◆ Workaround: Until a patch to overcome this problem becomes available, you should use the CLI to launch VEA. Please continue to check the HP patch web site for future availability of this patch.

Enclosure-based Naming on Persistent Simple or Nopriv Disks For users with persistent simple or nopriv disks, enclosure-based naming can cause errors in two situations:

1. After Upgrading to VxVM 3.5.

2. After Changing Your Disk Naming Scheme.

(For more information, refer to “Issues Regarding Persistent Simple/Nopriv Disks with Enclosure-Based Naming” in the VERITAS Volume Manager Administrator’s Guide. See also vxdarestore (1M) manual page.)

After Upgrading to VxVM 3.5 If you upgrade your system to VxVM 3.5 and you have persistent simple or nopriv disks and you select to change from c#t#d# naming to enclosure-based naming, these disks may be in an error state after upgrading. To recover these disks, run vxdarestore after you have completed the upgrade.

VERITAS Volume Managerª Release Notes 33 Known Problems and Workarounds

After Changing Your Disk Naming Scheme If you change your VxVM 3.5 system to enclosure-based naming using vxdiskadm, you need to check any persistent simple or nopriv disks, as these disks may be in an error state after the change. To recover these disks, run vxdarestore.

Converting a Plex into a Snapshot Plex VxVM 3.5 does not currently support the conversion of an underlying volume in a layered volume to a snapshot plex. You should use the procedure described in the section "Converting a Plex into a Snapshot Plex" in the VERITAS Volume Manager Administrator's Guide only to convert non-layered volumes, or the upper level volume of a layered volume.

Deleting the Last Disk in a Dynamic Group The VERITAS Volume Manager 3.5 User's Guide incorrectly states that it is not possible to remove the last disk in a dynamic group (Chapter 3, Disk Tasks, Removing a Disk from a Dynamic Disk Group). In fact, the VxVM 3.5 VEA allows you to delete the last disk in a dynamic group, provided that the disk to be removed is empty, and is not the last disk in the rootdg dynamic disk group.

FMR Does Not Resync Properly After Disk Replacement ◆ Problem: For non-persistent FMR, when a disk is removed, the corresponding plexes get disabled. This turns the FMR tracking ON and starts tracking the writes for the plex(es). When the diskgroup is deported and then re-imported (or the system is rebooted), the previous FMR map information is lost. Upon volume start, VxVM detects that the plex is inactive and turns the FMR tracking on for the plex, but fails to detect the fact that the plex was already stale. The entire FMR map for this plex should have been dirtied to avoid insufﬁcient sync'ing of the plex. Upon reboot or diskgroup deport-import for persistent FMR, the FMR related kernel data structures are initialized by reading the persistent on-disk maps. However, in the mentioned scenario, VxVM ends up clearing the on-disk maps before initializing the kernel data structures. Due to this, the I/Os that were tracked before the reboot (or the disk group deport) are lost. ◆ Workaround: None.

34 VERITAS Volume Manager Release Notes Known Problems and Workarounds

Possible Incorrect I/O Counts On Objects ◆ Problem: The VxVM configuration daemon may hang inside the kernel while processing a 'configuration change,' because of incorrect object I/O counts. The I/O count could become incorrect due to a race condition in the VxVM kernel. Since vxconfigd is hanging inside the kernel, VxVM utilities will not work. ◆ Workaround: A system reboot would be needed at this point for VxVM utilities to start functioning.

Replacing Disks When Using Persistent FMR ◆ Problem: If you replace a disk by another disk when using persistent FMR, then, in the unlikely event that a system crash occurs during the disk replacement, the plex resync on the newly added disk may not be completed. This will lead to data corruption. ◆ Workaround: None.

Plexes in SNAPDONE State not Detached on Write Errors ◆ Problem: Plexes in SNAPDONE state may remain active after disk write errors. The plex does not get detached, and will miss further writes to the volume. Although you can take a snapshot using this plex, the snapshot does not represent a point in time copy of the volume. Also, on snapback, the plex might not get synch'd with the volume's content if fmr is used. Data corruption may occur if you convert this plex to ACTIVE plex using vxplex convert. ◆ Workaround: If you ﬁnd any disk with STATE as "FAILING", you should perform the following procedure:

1. Find the plexes in SNAPDONE state that reside on the failing disk. For each plex, perform steps 2 and 3, as follows:

2. Disassociate each plex (plex-name) from the disk group (dg-name), using the command:

VERITAS Volume Managerª Release Notes 35 Using FUJITSU Disks

# vxplex -g dg-name> dis plex-name

3. Attach the plex to the original volume (vol-name) using the command: # vxplex -g dg-name att vol-name plex-name The plexes are now synch'd with the contents of the volume.

Using FUJITSU Disks

FUJITSU disks have now replaced the SEAGATE internal disks originally shipped with HP hosts. These disks will be classiﬁed by the vxinstall installation process as “OTHER_DISKS,” instead of “disks,” unless the following command is used before running vxinstall: # vxddladm addjbod vid=FUJITSU length=10 (the length of the lun serial number is 10 bytes for FUJITSU disks).

36 VERITAS Volume Manager Release Notes