Chapter 4. Administering OpenVault
Prev |  | Next

## Chapter 4. Administering OpenVault

This chapter describes how to set up and configure OpenVault, as well how to perform some basic management tasks. The sections in this chapter are:

- “OpenVault Configuration Files” describes configuration files.

- “Administering OpenVault ”, describes how to administer OpenVault.

- “Monitoring OpenVault”, describes how to monitor OpenVault.

## OpenVault Configuration Files

OpenVault uses configuration files to initiate a communication session between device components on OpenVault clients and server. Configuration files are automatically created by the OpenVault `setup` script, and contain information to bootstrap pieces of the system into full functionality. Once the various components have booted, the OpenVault server controls and manages clients and their components.

The following list defines terms used for OpenVault setup and administration:

Default access path
| Path used to access the drive via normal I/O channels, under `/dev/rmt`.
Drive handles
| Directory for creating `attach` nodes for applications, often `/tmp/mlm`.
Instance name
| You assign an arbitrary name to each drive and library. The instance name distinguishes between DCPs or LCPs controlling the same drive or library from different hosts (hopefully not simultaneously).
Passthrough driver
| Path used to access a device for direct SCSI control, under `/dev/scsi`.
Security key
| A password for authorizing client or application access to OpenVault.
Port number
| TCP port for OpenVault communication services, usually 44444.
Throttling
| After a certain number of clients are connected, the connection rate is reduced to minimize contention.

OpenVault configuration files are described in detail in the following sections.

### Server Configuration

When first configuring OpenVault, login to the OpenVault server system as superuser and run `setup`, with its menu-based interface that helps guide you. For more information about setup procedures, see Chapter 2, “Installing OpenVault”.

The OpenVault server configuration is stored in the `/usr/OpenVault/mlm/config` file.

### Clients Configuration

OpenVault client software must run on all systems where OpenVault-managed drives and libraries are attached, in particular on systems not designated as the OpenVault server. These non-server systems are called OpenVault clients.

If you want to implement security, an authorization key must be created, as described in “Setting Up Security”. Client security keys are part of their library, drive, and application configuration files--they are not in a separate file by themselves.

#### Setting Up Drives

Each drive needs its own drive control program (DCP) and configuration description, located in the `/usr/OpenVault/dcp/*/config` file. A drive-specific DCP should be installed using the standard OpenVault installation procedure.

For DCPs that are provided by SGI, DCP installation produces an interactive `setup` script that requests the configuration information that is necessary to create the configuration file. For DCPs supplied by other venders, consult their documentation.

The `setup` script asks similar questions as for autoconfiguration of the OpenVault server, but limited to information needed for drive and DCP configuration.

#### Setting Up Libraries

Each library needs its own library control program (LCP) and configuration description, located in the `/usr/OpenVault/lcp/*/config` file. A library-specific LCP should be installed using the standard OpenVault installation procedure.

For LCPs that are supplied by SGI, LCP installation produces an interactive `setup` script that requests the configuration information that is necessary to create the configuration file. For LCPs supplied by other venders, consult their documentation.

The `setup` script asks similar questions as for autoconfiguration of the OpenVault server, but limited to information needed for library and LCP configuration.

### Applications Configuration

The `setup` script asks you questions for configuring and storing the hostname of the OpenVault server used for the TCP interface. If you want to implement security, the application's OpenVault password must also be given. For details, see “Setting Up Application Security”.

### Setting Up Security

An ASCII authorization key file must be created on each AAPI/CAPI client and server system, and the client must be configured to use Open Vault with each key file. The authorization key file uses a shared secret--the client and server share a secret password. The server has one key file (`/usr/OpenVault/var/core_keys`) containing the passwords of each of the clients it knows about (drives, libraries, and applications). The clients each have an authorization key file listing the servers it knows about.

Example 4-1 shows a key file that can be used on either a client or a server.

Example 4-1. Client and Server Key Authorization File

    #Host           Client        Instance     Language      Key
    moon            System        OnlyInstance AAPI          a4sum
    moon            Robbie        one          ALI           a2by4
    moon            Herbie        alpha        ADI           gr8day
    earth           networker     *            CAPI          un2

The meanings for each column in the key authorization file are described in Table 4-1.

Table 4-1. Key Authorization File Description

Column Title | Description
--- | ---
Host | IP hostname of the system that communicates with this system. If this is a CAPI client, give the OpenVault server hostname. If this is the OpenVault server, give the IP hostname of the client running the application.
Client | Name of the application.
Instance | The instance name of the application. If more than one version is running, use asterisk (*) as a wildcard for multiple instances of the same application.
Language | The language used for the connection, either AAPI, CAPI, ADI, or ALI.
Key | A password used to secure the connection, or “none” for no security.

Any field in the key file can contain an asterisk “*” to specify all conditions. For example, if * appears in the Host column, all OpenVault clients can connect with the server. If * appears in the Host column, all OpenVault servers can connect with a client. If * appears in the Key column, it indicates no password, and OpenVault runs with security disabled.

| Note: Use asterisks carefully; too many asterisks in this file make the OpenVault system vulnerable to security violations. Also ensure that wildcard entries appear at the bottom of the file, after non-wildcard entries.

On the server host, the shared secret key is stored in `/usr/OpenVault/var/core_keys`.

### Setting Up Non-Robotic Libraries

| Note: Non-robotic libraries are not supported in the OpenVault releases 1.x.

Non-robotic libraries are controlled and manipulated by a human operator rather than by a robotics interface. Organization of your cartridges is key to keeping your library accessible and usable. OpenVault can help by tracking the location of cartridges within a library. Assigning cartridges to a bay can further pinpoint cartridge location.

A bay is a storage location within the library. In the case of robotic libraries, bays can be a range of slots, a removable tray, or a storage silo. In the case of non-robotic libraries, a bay could be a bookshelf, a file drawer, or a storage closet. In these examples, a bookcase, file cabinet, or hallway is the library, partitioned into bays as you prefer.

Planning is important in determining how many bays and how many libraries are necessary for your storage needs. Be sure to plan adequate space to allow your library to grow and allow for further separation, based on detail (you may start with a “project,” but then add more bays for phase 1, phase 2, and so forth).

Another major difference with a manual library is the need for communications with the operator. OpenVault needs to send messages to the operator, via a terminal, to prompt for action, such as loading a cartridge or removing a cartridge. Be sure to put the terminal that the operator uses in a convenient location so that timely communication is possible.

### Setting Up Offsite Libraries

| Note: Offsite libraries are not supported in the OpenVault releases 1.x.

An offsite library is a special type of manual library, differing in that an offsite library has no drive. Storage bins (which can be referred to as bays) contain the cartridges. OpenVault tracks the location of offsite storage cartridges. If a cartridge is needed from an offsite storage area, it must manually be located and moved into another library (see “Moving Cartridges within Libraries” in Chapter 5). The chosen library must contain a drive that is compatible with the cartridge type.

## Administering OpenVault

Once OpenVault has been set up, as described in “OpenVault Configuration Files”, you can start to configure it to meet your storage management needs. This section describes some basic configuration tasks, such as:

- “Setting Logging Levels”setting logging levels.

- “Registering Applications”, registering applications.

- “Unregistering Applications”, unregistering applications.

- “Setting Up Application Security”, setting up application security.

- “Enabling Application Access to a Drive”, enabling application access to a drive.

- “Managing Cartridge Groups”, managing cartridge groups.

- “Introducing Cartridges”, introducing cartridges.

  | Tip: When using the OpenVault administrative commands, you can assign environment variable `OVSERVER` to name a default server. For example, if you add this line to your .`login` file, administrative commands use the OpenVault server hostname.

      setenv OVSERVER hostname

If you want to use a different server, use the `-S` command-line option to specify another server (`-S` newOVserver). This overrides the `OVSERVER` environment variable.

### Setting Logging Levels

You can configure the degree of system status reporting and message logging that you want to have. You can also specify a different name for the message log file. By default, system message logging sends all error messages to the file `/usr/OpenVault/var/OVLOG`. Example 4-2 shows how to set the “information” log level.

Example 4-2. `information` Log Level

To set logging level to the information level:

    ov_msg -s -t core -m information

See the `ov_msg(1M)` man page for details and “Accessing OpenVault Messages” in Appendix A, for message log information.

### OpenVault Timestamps

Internally OpenVault keeps time in UCT (universal coordinated time, also called GMT) and writes UCT timestamps into the message log file. The administrative commands translate UCT into the client's local time zone when displaying time values.

### Registering Applications

Applications are client programs that can read data from or write data to (or both) removable media after OpenVault has found and mounted the desired media element. Reads and writes are performed using POSIX standard I/O facilities.

Applications can be added to (registered with) the OpenVault system at any time without the need to take OpenVault offline or perform a software upgrade. Registering an application introduces it to the OpenVault system so resources can be allocated for its use. See the `ov_app(1M)` man page for a description of options.

An authorization key, or password, can be added when registering an application to ensure secure transactions; see “Setting Up Application Security”. Unless an application is registered, it cannot connect to the OpenVault server.

To register an application without using security, follow the steps in Procedure 4-1:

Procedure 4-1. Registering an Application

1. Check to make sure that the application is not already registered.

       ov_app -l '.*'

   A listing appears of applications that are registered with the default OpenVault server. To check on other hosts, use the `-H` host1, host2 option. If you do not see your application named, continue with the next step.

2. Register the application (appName) with the default server.

       ov_app -c appName

### Unregistering Applications

Unregistering an application from the OpenVault system means the application can no longer connect to OpenVault as shown in Example 4-3:

Example 4-3. Unregistering an Application

To unregister the application, use the `ov_app` command with the `--d` option:

    ov_app -d networker

In this example, the application is called `networker` (IRIX NetWorker).

### Setting Up Application Security

Application security setup is similar to client security setup. Setting up an application with an authorization key ensures that, without the security key, no other application can connect to OpenVault masquerading as the originally authorized application.

As shown in the first and last lines of Example 4-1, the application name is used as a Client for the OpenVault server, which is named as the Host. The first line is an example that secures the OpenVault administrative tools and the last line is an example that secures the IRIX Networker application. The middle two lines appear only in the server keyfile and describe options for a library named `moon` and a drive named “moon”.

The key that is assigned in the key authorization file, also known as the password, must already exist in the configuration file for the application. See “Applications Configuration”, for details on setting up his file.

### Enabling Application Access to a Drive

A drive is in exactly one drive group. Each application can be given access to one or more drive groups (all drives in a group). To enable a drive for a specific application, allowing the application to run on the drive, follow the steps in Procedure 4-2. This might be necessary if the application uses special features of the drive.

Procedure 4-2. Enabling a Drive for a Specific Application

1. To enable a drive for the `tar` application, use the following command:

       ov_drive -c Herbie targroup false

   This command creates the drive named `Herbie` in the group `targroup`. The `false` argument indicates that the drive is not disabled for group `Herbie`.

2. Create the drive group `tardrive` and add the `tar` application with a prime precedence rating `-p 1` (lower number drives are used first).

       ov_drivegroup -c tardrive -A tar -p 1

   Now the `tar` command tends to use drives in this drive group. A `-p` precedence value organizes all accessible drive groups into a preference list for the application.

Drive groups allow a set of drives to be specified for a particular use, most likely to be available for a particular application. You can set up drive groups by repeating the `ov_drivegroup` `-c` command for each drive group you want, allocating applications to each. Adding a `-p` precedence flag when you specify the application allows you to make certain applications more or less likely to use drives in that drive group.

### Managing Cartridge Groups

Cartridge groups allow sets of cartridges to be allocated for specific applications or purposes. You may want to do this, for example, based on the capacity of the cartridge or its content (for example, the existing data on the cartridge is related to other cartridges in the group). Creating cartridge groups helps you organize your media and fulfills the demands of the application for available storage.

Figure 4-1 shows an environment with several cartridge groups.

Figure 4-1. Example Cartridge Group (Engineering)

Cartridges move in and out of groups (shown by the arrows) based upon demands made by the application or by their place in the media life cycle (see “Preventative Maintenance” in Chapter 7). The cartridge groups in the figure are Void, Unallocated, and Degauss.

Void | A set of cartridges whose labels are not in the OpenVault library. This is a holding place until you move the cartridge to another group, such as Scratch, or find out why the catalog entry for the cartridge is missing.
Unallocated | A set of unallocated cartridges that are available for allocation by any application. These cartridges have been introduced into the OpenVault system and are ready to be allocated to some application.
Degauss | A set of cartridges that are ready to be demagnetized or destroyed. Cartridges are demagnetized to ensure all data is destroyed. Some of these cartridges may need to be terminated if they are approaching the end of their media life span.
Full | IRIX NetWorker manages this set of cartridges. When a volume fills up, NetWorker marks it as full and holds it for a specified retention period.
Recyclable | IRIX NetWorker manages this set of cartridges, too. When the retention period expires and its cycle ends, a volume is marked for recycling.

#### Setting Up Cartridge Groups

Before setting up a cartridge group, plan where the group will reside and which drives or applications need to access it. Does the cartridge group require high throughput or high availability? Consider the network environment and any limitations it may impose when deciding where to locate the group. Consider the drives that will be servicing the group. What advantages or limitations do they impose? Also consider the growth potential for your storage requirements and choose a library that is adequate for its needs both now and for its projected future.

To create a cartridge group, follow the steps in Procedure 4-3.

Procedure 4-3. Creating a Cartridge Group

1. Be sure you have registered the application that will manage this group. See “Registering Applications”, for details.

2. Determine whether to assign drives to the application. If you decide to do so, see “Enabling Application Access to a Drive”, for details.

3. Create the cartridge group and assign its access permission. For example, the following command creates the `NWbackup` group with high priority (`-p 1`) and permits only the IRIX Networker application access to its cartridges (`-q 1`).

       ov_cartgroup -c NWbackup -p 1 -A networker -q 1

4. Introduce cartridges into the cartridge group. Continue with the next section, “Introducing Cartridges”, for details.

5. If necessary, move cartridges between groups or within the library. The following sections describes situtions when you may need to move cartridges:

   - If a cartridge is no longer needed by an application, see “Removing Cartridges from Libraries” in Chapter 5.

   - If a cartridge can be moved back into the Unallocated group, see “Recycling Cartridges” in Chapter 5.

   - If a cartridge should go to the Degauss group for erasure, see “Destroying Cartridges” in Chapter 5.

   - If a cartridge needs to be moved within its own group, see “Moving Cartridges within Libraries” in Chapter 5.

#### Introducing Cartridges

Cartridges must be introduced into the OpenVault system before they can be used by an application. When a cartridge is introduced, an entry in the OpenVault catalog is created for the cartridge and the cartridge is assigned a cartridge ID. The entry, or cartridge ID, tracks information such as the PCL or bar code, application ID (if it's associated with an application), number of reads and writes, form factor, capacity, and so forth.

Client applications may choose their own names for cartridges. Because OpenVault client applications operate in separate name spaces, different applications may use the same name for different cartridges. Moreover, cartridges used by one application are not visible to or accessible from another application, unless the system administrator permits specific cartridges to be moved from one application to another.

Cartridges can be introduced in two ways, as shown in Figure 4-1:

- Cartridges without data (including data that can be overwritten)

- Cartridges containing data that is needed by an application (partition needed)

To introduce a cartridge without data, follow the steps in Procedure 4-4:

Procedure 4-4. Introducing a Cartridge without Data

1. To facilitate the cartridge identification, create its PCL by attaching a bar code or a label to the outside of the cartridge. The PCL is tracked in the catalog entry for this cartridge and is used as the default identification for the cartridge in most commands.

2. Signal the library to open its inject port so you can insert the cartridge. You must specify the library name (`-l` libraryName).

       ov_inject -l libraryName

3. Insert the cartridge into the inject port.

4. Create a new (`ov_cart` `-n -T`) cartridge entry in the OpenVault catalog so the cartridge can be recognized and accessed. The `-n` label gives the PCL affixed to the cartridge. Also, assign the cartridge to a cartridge group (`-p` cartridgeGroup) so it can be used by an application needing a new cartridge:

       ov_cart -n label -p cartridgeGroup -T cartridgeType

   OpenVault checks its catalog to ensure the PCL is unique (new) and rejects the entry if that PCL already exists. Then `ov_cart` automatically creates sides on the cartridge, depending on the cartridgeType argument. The group name, form factor, media type, PCL and other identifying information are recorded in the OpenVault catalog for this cartridge.

   | Note: This command (`ov_cart` `-n -T`) is a good way to enter each new cartridge into the OpenVault system. Bulk insertion of cartridges into OpenVault may also be done using the `ov_import` command.

5. Create a partition on side 1 of the cartridge.

       ov_part -n cartridgeID -p partitionName -s SideA

To introduce a cartridge that already contains data, follow the steps in Procedure 4-5:

Procedure 4-5. Introducing a Cartridge with Data

1. Follow Procedure 4-4, for introducing cartridges without data, including step 5.

2. Create volumes for this cartridge. A volume allows the cartridge to be segmented so separate areas of the media can be used by an application:

       ov_vol -n volumeName -a applicationName -c cartridgeID -p "PART 1" -s SideA

   Use this command for each volume you are creating. OpenVault checks that the applicationName and volumeName combination is unique. Standard attributes are assigned to the volume and given default values if the values are not specified.

   | Note: This `ov_import` command optionally allows you to automatically create volume records for cartridges with data, in addition to creating the cartridge, side, and partition information for OpenVault.

You have now successfully introduced a cartridge and associated it with an application. Repeat this procedure for each new cartridge you are adding to the OpenVault system. You can now perform operations on the cartridge, as described in Chapter 5, “Operating OpenVault”.

## Monitoring OpenVault

Monitoring OpenVault helps you spot potential problems so that you can take appropriate action, and allows you to track the OpenVault system usage. If reconfiguration is necessary, it can be done before it becomes critical.

Probably most helpful in daily operations, monitoring can help you track the data you have on your media and where the media is located. The following subsections describe these monitoring tasks:

- “Checking Server Status and Configuration”, describes checking server status.

- “Checking Media Inventory”, describes checking media inventory.

- “Listing Cartridge Information”, describes how to list cartridge information.

OpenVault can be monitored on several levels and to varying degrees of detail. From the general to the specific, some of the areas that can be monitored are:

- OpenVault server status, including whether the server is up or down and by listing system error messages

- Library status, including names, types, whether the library is up or down, and slotmaps (showing occupancy and reservations)

- Drive status, including names, types, whether the drive is up or down, and cartridge occupancy

- Libraries and drives without active LCPs and DCPs

- Cartridge group status, including names of groups, number and names of cartridges in them

- Names of registered applications

- Cartridge status, including listing of all known cartridges, cartridge locations, and cartridge characteristics

- Volume status, including cartridge ID and PCL, and the owning application

- System messages, including by library, drive, and type (warning, error, operator)

Check the OpenVault man pages for a complete description of available commands and options (see Appendix B, “OpenVault Man Pages”, for a complete listing of man pages).

### Checking Server Status and Configuration

Using the `ov_stat` command to check the status of the OpenVault server allows you to view your system from a top-level viewpoint. Some things to check for are:

- Check that the default server is up:

      ov_stat

- Check that a specific server is up:

      ov_stat -S serverName

- Show the task queue for the default server:

      ov_stat -q

- Display status of all items for the server, LCPs, DCPs, and applications:

      ov_stat -a

- Show configuration (`-c`) and drive (`-d`) mode information for a drive:

      ov_stat -D driveName -d -c
      Drive    Mode     Slot Type   Cart Type   Bit Format  Capacity  ...
      ...

- Show library (-`l`), configuration (`-c`), and slot map (`-s`) information for a library:

      ov_stat -L libName -l -c -s
      Library Name  Broken  Disabled  State  LCP SoftState  LCP HardState
      lib1          false   false     ready  inactive       ready
      ...

  | Note: A drive or library cannot spontaneously become Disabled. The system administrator disables a drive or library; it does not happen automatically. If a library or drive fails an internal hardware diagnostic, its LCP or DCP can report the device as Broken. No currently shipping LCP or DCP does this, however. The Access heading indicates whether the library believes it can mount and unmount cartridges in a particular drive. It is possible for a drive to be in perfect running order, but nonetheless unreachable by the library.

OpenVault tracks up to 8 status items for drives and libraries, as shown in Table 4-2.

Table 4-2. `ov_stat` Headings Explained

| Software | Hardware
--- | --- | ---
LCP | State of the LCP: “ready”, “not ready”, “disconnected”, “inactive”, or ”active”. | Always set to “ready”.
DCP | State of the DCP: “ready”, “not ready”, “disconnected”, “inactive”, or ”active”. | DCP's view of the drive: “loaded”, “unloading”, “unloaded”, or “loading”.
library | Always set to “ready”. | Always set to “ready”.
drive | Whether the drive being used by an application: “inuse” or “ready”. | Drive state: “loaded”, “unloaded”, “loading”, or “unloading”.

The meaning of tokens shown in `ov_stat` output is as shown in Table 4-3:

Table 4-3. `ov_stat` Tokens Explained

Token | Meaning of Token
--- | ---
`ready` | Can accept commands, or is working properly, or is unallocated.
`not ready` | Temporarily unable to accept commands (the door might be open).
`disconnected` | The LCP or DCP is communicating with the MLM, but not with the hardware.
`inactive` | The LCP or DCP is not communicating with the MLM.
`inuse` | A drive has been allocated for use by an application.
`unloaded` | There is no cartridge in the drive.
`loading` | A cartridge is being loaded into the drive.
`loaded` | A cartridge is loaded in the drive.
`unloading` | A cartridge is being unloaded from the drive.
`active` | The LCP or DCP is becoming ready, but is not yet able to take commands.

### Checking Media Inventory

Knowing your media inventory is essential for a well-organized site. OpenVault helps track the contents of libraries and cartridge groups so you know the whereabouts of your cartridges, including those that are currently loaded into drives.

The following `ov_lscarts` commands can be used to check the media inventory:

- Show location information for all cartridges, such as the library location, slot assignment, presence in slot, or if loaded in a drive, the name of that drive:

      ov_lscarts -w '.*'

- Show cartridges assigned to the IRIX Networker application, in long format:

      ov_lscarts -A networker -l '.*'

### Listing Cartridge Information

Other information that is important to a smooth-running site is information regarding cartridge contents and usage, such as the number of reads, writes, mounts, and so forth.

The following `ov_lscarts` commands can be used to check information about cartridges:

- Show a summary of all cartridge information on the default server:

      ov_lscarts '.*'

- Show the application and cartridge group associated with each cartridge:

      ov_lscarts -g -a '.*'

### Backing Up OpenVault

If your site performs system-wide backups, then the OpenVault database files will be included in these backups. If the OpenVault server is running at the time of the backup, the catalog files may not get backed up properly. These files can change in the middle of a backup session, especially if your backup scheme employs OpenVault.

To ensure backup of the OpenVault catalog files, follow the steps in Procedure 4-6:

Procedure 4-6. Backing Up OpenVault

1. Shut down OpenVault.

2. Copy the `/usr/OpenVault/var/` directory to another location.

3. Restart OpenVault.

4. Perform the normal backup procedure, making sure to back up the copy you made of the `/usr/OpenVault/var/` directory.

Of course, any single-user mode level-0 dumps, which you should be doing, will also backup the OpenVault catalog files.

To recover the catalog files, just restore them from tape to the temporary location, then copy them back into `/usr/OpenVault/var/`.

Prev | Table of Contents | Next
Chapter 3. Cartridge Life Cycle |  | Chapter 5. Operating OpenVault