Configuring VERITAS Volume Manager

This section explains how to set up VxVM enclosure-based naming. To complete further tasks such as disk initialization, please see the VERITAS Volume Manager System Administrator's Guide.

Enabling Enclosure-based Naming

Because you are no longer required to configure VxVM disks straightaway, vxinstall no longer invokes the vxdiskadm program, so it is much simpler than in previous versions, and will cover the following three functions:

• Licensing VxVM
• Enabling Enclosure-based naming
• Setting up a system-wide default group

To run the command, enter:

which will prompt you to enter a license key:

• If you don't have a license key, see VERITAS Product Licensing.

---

  Note    The presence of certain hardware arrays (for example, A5000) automatically generates a key.

---

The vxinstall program then asks if you want to use enclosure-based naming:

After installation, disks use the traditional naming format, usually c#t#d#s#. Enclosure-based naming provides an alternative that allows disk devices to be named for enclosures rather than for the controllers through which they are accessed. In a Storage Area Network (SAN) that uses Fibre Channel hubs or fabric switches, information about disk location provided by the operating system may not correctly indicate the physical location of the disks. Enclosure-based naming allows Volume Manager to access enclosures as separate physical entities. By configuring redundant copies of your data on separate enclosures, you can safeguard against failure of one or more enclosures.

If you want to use enclosure-based naming, enter 'y' and vxinstall asks you whether you want to set up a systemwide default disk group:

[y,n,q,?] (default: y)

VxVM will continue with the question:

Which disk group ?

If you know the name of the disk group that you want to use as the default disk group, enter it at the prompt, or use the list option and make a selection.

In releases prior to Volume Manager 4.1, the default disk group was rootdg (the root disk group). For Volume Manager to function, the rootdg disk group had to exist and it had to contain at least one disk. This requirement no longer exists, however you may find it convenient to create a system-wide default disk group. For operations that require a disk group, the system-wide default disk group will be used if the VxVM command is not specified with the -g option. The main benefit of creating a default disk group is that VxVM commands default to the default disk group and you will not need to use the -g option. To verify the default disk group after it has been created, enter the command:

At this stage, the installation of VxVM is complete. To complete further tasks such as disk initialization, please see the VERITAS Volume Manager Administrator's Guide.

Using Storage Expert

System administrators often find that gathering and interpreting data about large and complex configurations can be a difficult task. VERITAS Storage Expert (vxse) is designed to help in diagnosing configuration problems with VxVM.

Storage Expert consists of a set of simple commands that collect VxVM configuration data and compare it with "best practice." Storage Expert then produces a summary report that shows which objects do not meet these criteria and makes recommendations for VxVM configuration improvements. These user-configurable tools help you as an administrator to verify and validate systems and non-optimal configurations in both small and large VxVM installations. Storage Expert components include a set of rule scripts and a rules engine. The rules engine runs the scripts and produces ASCII output, which is organized and archived by Storage Expert's report generator. This output contains information about areas of VxVM configuration that do not meet the set criteria. By default, output is sent to the screen, but you can redirect it to a file using standard UNIX redirection. For more information on using Storage Expert, see the VERITAS Volume Manager System Administrator's Guide.

Starting and Enabling the Configuration Daemon

The VxVM configuration daemon (vxconfigd) maintains VxVM disk and disk group configurations. The vxconfigd communicates configuration changes to the kernel and modifies configuration information stored on disk.

Startup scripts usually invoke vxconfigd at system boot time. The vxconfigd daemon must be running for VxVM to operate properly.

The following procedures describe how to check that vxconfigd is started, whether it is enabled or disabled, how to start it manually, or how to enable it as required.

To determine whether vxconfigd is enabled, use the following command:

The following message indicates that the vxconfigd daemon is running and enabled:

This message indicates that vxconfigd is not running:

To start the vxconfigd daemon, enter the following command:

This message indicates that vxconfigd is running, but not enabled:

To enable the volume daemon, enter the following command:

Once started, vxconfigd automatically becomes a background process.

By default, vxconfigd writes error messages to the console. However, you can configure it to write errors to a log file. For more information, see the vxconfigd(1M) and vxdctl(1M) manual pages.

Starting Volume I/O Daemons

The volume I/O daemon (vxiod) provides extended I/O operations without blocking calling processes. Several vxiod daemons are usually started at system boot time after initial installation, and they should be running at all times. The procedure below describes how to verify that the vxiod daemons are running, and how to start them if necessary.

To verify that vxiod daemons are running, enter the following command:

If, for example, 10 vxiod daemons are running, the following message displays:

where 10 is the number of vxiod daemons currently running. If no vxiod daemons are currently running, start some by entering this command:

where 10 is the desired number of vxiod daemons. It is recommended that at least one vxiod daemon should be run for each CPU in the system.

For more information, see the vxiod(1M) manual page.

Adding New Array Support

After installation, add any disk arrays that are unsupported by VERITAS to the JBOD category as described in the section Hot-Relocation.

Hot-Relocation

Hot-relocation automatically restores redundancy and access to mirrored and RAID-5 volumes when a disk fails. This is done by relocating the affected subdisks to disks designated as spares and/or free space in the same disk group.

The hot-relocation feature is enabled by default. The associated daemon, vxrelocd, is automatically started during system startup.

Follow these recommendations:

1. Leave the VxVM hot-relocation feature enabled to detect disk failures automatically. It will notify you of the nature of the failure, attempt to relocate any affected subdisks that are redundant, and initiate recovery procedures.
2. Configure at least one hot-relocation spare disk in each disk group. This will allow sufficient space for relocation in the event of a failure.

If you decide to disable hot-relocation, prevent vxrelocd from running after you load the VxVM software. See the section "Modifying the behavior of Hot-Relocation" in Chapter 9 of the VERITAS Volume Manager Administrator's Guide for details.

Placing Disks in another Disk Group

To place disks in another disk group, use VEA or the vxdiskadm program after completing the vxinstall program. See the VERITAS Volume Manager Administrator's Guide for information on how to create other disk groups for your disks.

Adding Disks After Initialization

Disks that are not initially placed under VxVM control by the vxinstall program can be added later using another VxVM interface (such as VEA or the vxdiskadm program). See the VERITAS Volume Manager Administrator's Guide for details.

Protecting Your System and Data

A disk failure can cause loss of data on the failed disk and loss of access to your system. Loss of access is due to the failure of a key disk used for system operations. VxVM can protect your system from these problems.

To maintain system availability, data important to running and booting your system must be mirrored. The data must be preserved so it can be used in case of failure.

The following are suggestions for protecting your system and data:

• Place the disk containing the root file system (the root or boot disk) under VxVM control.
• Mirror the root disk so that an alternate root disk exists for booting purposes. By mirroring disks critical to booting, you ensure that no single disk failure leaves your system unbootable and unusable.

For maximum availability of the system, create mirrors for the rootvol, swapvol, usr, and var volumes. For more information, see the VERITAS Volume Manager Troubleshooting Guide.

• Use mirroring to protect data against loss from a disk failure. To preserve data, create and use mirrored volumes that have at least two data plexes. The plexes must be on different disks. If a disk failure causes a plex to fail, the data in the mirrored volume still exists on the other disk.
• Leave the VxVM hot-relocation feature enabled to detect disk failures automatically. It will notify you of the nature of the failure, attempt to relocate any affected subdisks that are redundant, and initiate recovery procedures. Configure at least one hot-relocation spare disk in each disk group. This will allow sufficient space for relocation in the event of a failure.

If the root disk is mirrored, hot-relocation can automatically create another mirror of the root disk if the original root disk fails. The rootdg must contain enough contiguous spare or free space for the volumes on the root disk (rootvol and swapvol volumes require contiguous disk space).

• Use the DRL feature to speed up recovery of mirrored volumes after a system crash. Make sure that each mirrored volume has at least one log subdisk.

---

  Note    rootvol, swapvol, and usr volumes cannot be DRL volumes.

---

• Use logging to prevent corruption of recovery data in RAID-5 volumes. Make sure that each RAID-5 volume has at least one log plex.
• Perform regular backups to protect your data. Backups are necessary if all copies of a volume are lost or corrupted. Power surges can damage several (or all) disks on your system. Also, typing a command in error can remove critical files or damage a file system directly. Performing regular backups ensures that lost or corrupted data is available to be retrieved.