This chapter describes the following TMF administration topics:
Users can access tapes attached to an SGI system by one of two interfaces:
TMF, which is described in this manual.
The character-special tape interface (TS). For more information, see the ts(7M) man page.
This section describes how TMF interacts with the tape library software subsystem and also covers some high-level configuration information:
TMF always communicates with the tape loader via an intermediate software system that is provided by the library vendor. TMF supports the following:
StorageTek libraries using the ACSLS software interface running on a SUN host. TMF communicates with the ACSLS software via a child process called stknet, which TMF starts after the library is configured up (up means that it is running and waiting for tape requests). Check with your StorageTek representative to validate the values of CSI_UDP_RPCSERVICE and CSI_TCP_RPCSERVICE.
IBM libraries using the controlled path service (CPS) software interface running on an IBM RISC System/6000 platform. TMF communicates with the IBM CPS software via a child process called ibmnet, which TMF starts after the library is configured up.
EMASS libraries using the VolServ software interface running on a SUN host. TMF communicates with the vendor-supplied software interface, VolServ, via a child process called esinet which TMF starts after the library is configured up.
ACSLS, CPS, and VolServ receive requests from TMF and pass them on to the actual tape libraries for processing. They also send responses back to TMF for any given action.
Figure 2-1 shows the software and hardware configuration between the local host and the StorageTek, IBM, and EMASS libraries.
A mixed environment consists of devices serviced by a manual operator (attended mode) and devices serviced by a library (unattended mode). If TMF services mount requests in a mixed environment, you must organize the devices to use both devices and loaders in the most efficient manner possible.
A volume has a domain associated with it and, as such, has a preferred or best loader to service a mount request. If the domain of a tape cartridge is a tape vault, the best loader is an operator. If the tape cartridge resides in the library's domain (silo), the best loader is the library.
Each tape device belongs to a device group, which is a collection of devices with equivalent physical characteristics. Although cartridge devices can have equivalent physical characteristics, you should consider the manner in which the devices will be serviced to determine whether or not they should be grouped.
One of the principal reasons for using a library is that the loader can be run in unattended mode (that is, without an operator). Using the library in this manner means that no imports or exports are considered, and a user-requested tape mount that cannot be satisfied by the library is canceled.
The easiest way to prevent canceled mounts is to assign the library drives to a device group different from the one serviced by manual operators. A user can then determine whether the required device group is available before requesting a tape mount. The only drawback to this method is that the user must be aware of the domain in which the tape resides and, if necessary, make changes to scripts if the domain of the tape changes.
For operations that have 24-hour operator coverage, all tape cartridges can be assigned to one device group, with the operator deciding whether the mount request should be queued or canceled, or whether the volume should be imported or exported. In this case, the user need not be concerned about the domain of the tape.
Another administration issue is the accessibility of tape cartridges in a library. In the past, control of a volume serial number (VSN) was provided by an operator or by security programs on a front-end computer. With a library, control of VSNs does not exist; therefore, with the distributed TMF software, any user may request the mounting of any VSN in the domain of the library.
A site may provide access control to VSNs through two user exits. For information on user exits, see the TMF Release and Installation Guide.
You can use the OpenVault storage library management facility as a TMF loader. You can configure it on your local host or on a remote host. Figure 2-2 shows OpenVault on the same host as TMF and Figure 2-2 shows OpenVault on a different host than TMF.
OpenVault supports a wide range of removable media libraries as well as a variety of drives associated with these libraries. The checklists in “Checklists for Using OpenVault with TMF” provide information on using OpenVault with TMF. For detailed information on using OpenVault, see the OpenVault Operator's and Administrator's Guide.
The following terms are used in this section:
ovserver_host_name: The name of the host on which the OpenVault server is running. When configuring TMF and OpenVault, use the results of executing the hostname command on the OpenVault server host to obtain this value.
tmf_host_name: The name of the host on which TMF will run. Use the results of executing the hostname command on the TMF host to obtain this value.
tmf_node_name: The node name of the host on which TMF will run. This may or may not be the same as the TMF hostname. Use the results of executing the uname -n command on the TMF host to obtain this value.
tmf_application_name: The OpenVault application name to be used by TMF. If you do not specify a value in the TMF configuration file, TMF uses the default name tmf.
tmf_instance_name: The OpenVault instance name to be used by this instance of TMF. If you do not specify a value in the TMF configuration file, TMF uses the following default name:
tmf_node_name.tmf_application_name
tmf_key: The TMF security key to be used for TMF. This alphanumeric string is used as a password by TMF to secure the connection with the OpenVault server. If you want to enable security, you must create and configure a tmf_keyfile containing the tmf_key that you want to use. If you do not specify a tmf_keyfile in the TMF configuration file, TMF uses none as the tmf_key, which means that security checking between TMF and the OpenVault server is disabled.
tmf_keyfile: The OpenVault keyfile to be used by TMF when communicating with the OpenVault server. The tmf_keyfile contains the private security key tmf_key that TMF uses to establish an authorized connection with the OpenVault server. This file is required only if you decide that you want to enable security checking between TMF and the OpenVault server.
When the key file is created, use the chown command to set the user ownership to root, use the chgrp command to set its group ownership to sys, and use the chmod command to set its files permissions to 0500. The key file should contain a single line consisting of 5 blank or tab-separated fields in the following format:
ovserver_host_name tmf_application_name tmf_instance_name CAPI tmf_key
The ovserver_host_name, tmf_application_name, tmf_instance_name values in the tmf_keyfile must match the values specified in the TMF configuration file or the TMF default values if you do not specify them in the TMF configuration file. Mismatches between the TMF configuration file and the tmf_keyfile prevent TMF from contacting the OpenVault server.
Procedure 2-1 and Procedure 2-2, list the steps you need to take before you use TMF with OpenVault.
Procedure 2-1. OpenVault Checklist
Configure the drives and libraries in OpenVault so that TMF can use them. The following steps ensure that the TMF and OpenVault counterparts match.
Using the OpenVault configuration command, define a list of OpenVault drives and libraries. If you are using a version of OpenVault prior to 1.5, the configuration command is /usr/OpenVault/setup . For OpenVault 1.5 and later, the configuration command is /usr/sbin/ov_admin.
Note: TMF devices are defined subsequently. TMF device names must match the drive names used by OpenVault. TMF supports device names only up to 8 characters long. With that in mind, be sure to define OpenVault drive names consisting of 1 to 8 characters.
TMF devices are grouped as follows:
In TMF, every drive belongs to a device group
In OpenVault, every drive belongs to a drive group
For every TMF device group to be managed by OpenVault, there must be a matching OpenVault drive group
Create an OpenVault application name so that a group of tapes, defined as a cartridge group, can later be used by the tmf application. For example, where tmf is the application name:
# ov_app -c tmf Created Application: tmf
In OpenVault, only one application can be assigned to a cartridge. OpenVault mounts a cartridge only if the request comes from the assigned application. Cartridges have the following characteristics:
In OpenVault, a cartridge is a physical cartridge (also called a physical tape in TMF)
Each cartridge is assigned to a cartridge group
Each cartridge group is assigned to an application (a client)
A cartridge is identified by its physical cartridge label (PCL), which is used to identify a cartridge in an OpenVault loader library
Create any new drive groups and/or cartridge groups, according to the following steps. The default group names are drives and carts, respectively.
Use the following OpenVault commands to list the drive groups and cartridge groups:
# ov_drivegroup group unload time drives 60 # ov_cartgroup group group prio carts 1000
Create a new drive group appropriate for your drive type(s). Keep in mind that this is the same name you will give to the device group you define in TMF. The following example uses DLT8000 as a drive group name.
# ov_drivegroup -c DLT8000 created drive group: DLT8000
To simplify things in the preceding example, the default cartridge group, carts is used. However, if you choose to create a new cartridge group, you can do so by using the following command:
# ov_cartgroup -c new_cartgroup_name
Verify that the new drive group (and any new cartridge groups) have been created, as follows:
# ov_drivegroup group unload time DLT8000 60 drives 60 # ov_cartgroup group group prio carts 1000
Allow the OpenVault application name, tmf, to use the cartridge groups and drive groups that will be used by TMF (defined in step 3).
In OpenVault, more than one application can be assigned to a drive group; OpenVault uses a drive within a drive group only if the request comes from an assigned application. OpenVault drives have the following characteristics:
In OpenVault, a drive is a TMF device
Each drive is assigned to a drive group
Each drive group is assigned to one or more applications (clients)
Use the following steps for all drive and cartridge groups:
List applications (for all drive groups and cartridge groups).
Use the following commands to list the application information for all drive groups and cartridge groups. The default OpenVault application name is ov_umsh. (Notice that the drive groups (and cartridge group) that were created in step 3 do not appear here. This is because they have not yet been given an application to use.)
# ov_drivegroup -s -A '.*' application group group app prio unload time ov_umsh drives 1000 60 # ov_cartgroup -s -A '.*' application group group app prio ov_umsh carts 1000
Add TMF applications. Use the following commands with the -a option to add the default TMF application name, tmf, to any drive groups and cartridge groups that will be used by TMF.
# ov_drivegroup -a -G DLT8000 -A tmf Drive-group-application creation: Application: tmf Group: DLT8000# ov_cartgroup -a -G carts -A tmf Cartridge-group-application creation: Application: tmf Group: carts
Recheck: List applications (for all drive groups and cartridge groups), as follows:
# ov_drivegroup -s -A '.*' application group group app prio unload time ov_umsh drives 1000 60 tmf DLT8000 1000 60 # ov_cartgroup -s -A '.*' application group group app prio ov_umsh carts 1000 tmf carts 1000
Create a group of physical cartridges, assigned to the default cartridge group, carts, and to be used by the tmf application. The fields in the following example are as follows:
Cartridge PCL name OpenVault cartridge type Volume name (should match the PCL name) Application name # ov_import -g carts DLT014 DLTIV DLT014 tmf DLT015 DLTIV DLT015 tmf <ctrl-d> #
You can use the following command to list all of the PCLs/volumes used by the tmf application:
# ov_lscarts -A tmf DLT014 DLT015
Or, for a more extensive look:
# ov_lscarts -l -A tmf PCL cart type owner state part volume DLT014 DLTIV tmf ok PART 1 DLT014 DLT015 DLTIV tmf ok PART 1 DLT015
Make sure that the following line is in the core_keys file. If you are using an OpenVault version prior to 1.5, the core_keys file is /usr/OpenVault/var/core_keys. For OpenVault version 1.5 and later, the core_keys file is /var/opt/openvault/server/config/core_keys.
tmf_host_name tmf_application_name tmf_instance_name CAPI tmf_key
For example, if armadillo is the host that TMF is running on (tmf_host_name), the TMF application name (tmf_application_name) is tmf , the TMF instance name (tmf_instance_name) is armadillo.tmf, the language is CAPI, and the security key (tmf_key) is not used (none), you would enter the following line in the core_keys file:
armadillo tmf armadillo.tmf CAPI none
In the OpenVault documentation, the terminology may differ: the tmf_keyfile file is the key authorization file, and the TMF application name (tmf_application_name) is the client.
To collect debugging information in the OVLOG file, enter the following command:
ov_msg -s -t core -m debug
If you are using an OpenVault version prior to 1.5, the OVLOG file is /usr/OpenVault/var/OVLOG .YYYYMMDD, where YYYYMMDD represents the year (YYYY), month (MM), and day (DD) that the file was created. For OpenVault version 1.5 and later, the OVLOG file is /var/opt/openvault/server/logs/OVLOG .YYYYMMDD.
When you have finished debugging the OVLOG file, you can use the following command to reset the messages back to the information level:
ov_msg -s -t core -m information
Modify the tmf.config file to support the OpenVault loader, device groups, and devices. For information on the tmf.config file, including a complete example file, see the tmf.config(5) man page.
Define an OpenVault LOADER statement, as follows:
Define the type to be OPENVAULT:
type = OPENVAULT
Specify where the OpenVault server is running by entering the name of the host:
server = ovserver_host_name
Either use the TMF default, tmf, for the OpenVault application name or specify a different name for TMF with the following parameter:
ov_tmf_application_name = tmf_application_name
If this line is omitted from the LOADER statement, the default application name will be tmf.
Either use the TMF default instance name or specify a different instance name for TMF with the following parameter:
ov_tmf_instance_name = tmf_instance_name
If you omit this line from the LOADER statement, a default instance name of tmf_node_name.tmf_application_name will be used, where the value of tmf_application_name is taken from step c, previously.
If the OpenVault communication security feature is to be enabled, specify the pathname of the key file which will contain the TMF security key (tmf_key):
ov_tmf_keyfile = tmf_keyfile
If this line is omitted from the LOADER statement, the OpenVault communication security feature will not be used ( tmf_key equals none). For more information on the key file and security keys, see the OpenVault Operator's and Administrator's Guide.
Make sure the DEVICE_GROUP names match the OpenVault drive group names.
Make sure the name field in each of the DEVICE statements match the corresponding OpenVault drive names.
Automatic volume recognition (AVR) is a TMF feature that allows TMF to recognize volumes mounted on drives prior to them actually being requested by applications, and it allows an operator to direct the mounting of tapes to specific devices.
Tape mount messages request that the operator mount a tape on a device in a device group. Upon receiving a message, you locate the tape and choose the device to be used.
The overcommit option is an extension to AVR. It allows you to set the number of outstanding mount requests to a number larger than the actual number of tape devices. It gives you additional flexibility in choosing which request to satisfy and on which device.
| Note: Only those requests that cannot cause a device to deadlock are allowed into the overcommitted request process. |
You may enable or disable the AVR and overcommit options on a global or on a specific device-group basis. Neither option is available to device groups that also contain devices serviced by a tape library (automatic loader).
When a device that has been configured to use AVR is configured up with the tmconfig(8) command, a child process called tmavr is created to monitor the device and wait for a volume to be mounted. When tmavr detects a mounted volume, the label and ring status information is sent to the TMF daemon. If tmavr cannot determine the volume label, an operator message is issued for the correct volume information to send to the TMF daemon. The child process waits for the TMF daemon to direct it to exit or look for a new volume to mount.
The message daemon and its associated operator interface provide mount messages for administrators and operators who are loading and unloading tapes. This section provides a brief overview of the daemon and interface:
You must have superuser privileges to start or stop the message daemon.
Start the message daemon prior to starting TMF by entering the following command:
/usr/sbin/msgdaemon |
To stop the message daemon, enter the following command:
/usr/sbin/msgdstop |
Only one message daemon can be running at any time. If you attempt to start the message daemon while it is already running, you will receive an error message.
All messages are logged by the message daemon as they are received. The logs are kept in the msglog.log log file in the /var/spool/msg directory. The newmsglog shell script saves the last several versions of the log. The newmsglog script resides /usr/sbin. The versions are called msglog.log.0, msglog.log.1, and so on, with msglog.log.0 being the most recent. This script also instructs the message daemon to reopen the log file; it should be run from the crontab(1) command.
The message daemon request pipe is located in the /var/spool/msg directory. Table 2-1 shows the message daemon commands and the permissions required to access them.
Table 2-1. Message Daemon Commands
Command | Permission | Description |
|---|---|---|
msgdaemon(8) | Administrator | Starts the message daemon |
msgdstop(8) | Administrator | Stops the message daemon |
oper(8) | Administrator | Invokes the operator display; displays messages |
msgr(1) | All users | Sends action message to operator |
The operator display provided by the oper (8) command can be run from any terminal defined in the /usr/lib/terminfo file. It requires at least 80 columns and 24 lines. The three lines at the bottom of the operator display screen are used for input and for running commands that do not display information on the screen. The rest of the screen is used as a refresh display to display messages and to run other display commands.
The $HOME/.operrc configuration file lists the commands to be run as refresh displays and those that require full control of the screen. $HOME is the user's home directory. If this file does not exist, the default configuration file is used. The default configuration file resides in /etc/tmf/oper.
Commands not listed in the configuration file are assumed to be nondisplay commands, which are also called action commands.
Table 2-2 describes two of the action commands available from the operator display.
Table 2-2. Operator Action Commands
Command | Description |
|---|---|
msgd(8) | Displays action messages |
rep(8) | Replies to action messages |
Action messages that require replies from the operator are primarily tape mount messages, but they may be other types of messages to which users need responses. These messages are logged by the message daemon. An action message is deleted when the operator replies to it or the sender cancels it.
Installing TMF does not enable starting TMF automatically at system startup. To enable automatic startup of TMF and the message daemon, execute the following chkconfig(1m) command as root:
chkconfig tmf on |
To stop TMF from starting automatically at system startup, execute the following as root:
chkconfig tmf off |
If you chose not to use the chkconfig(1m) command, you can start and stop TMF with the tmdaemon(8) and tmstop(8) commands. You can also use these commands to stop and start TMF once it has been started automatically when the system is booted.
To start TMF explicitly, enter the following tmdaemon(8) command:
/usr/sbin/tmdaemon |
Options exist for the tmdaemon(8) command. For descriptions of these, see the tmdaemon (8) man page.
TMF is stopped by the following tmstop(8) command:
/usr/sbin/tmstop |
The tmstop(8) command has no options.
Table 2-3 shows these commands and the permissions required to access them.
Command | Permission | Description |
|---|---|---|
tmdaemon(8) | Administrator | Starts TMF |
tmstop(8) | Administrator | Stops TMF |
When you use the xfsdump (1m) command to dump files to tape, the command uses 262144 as the block size. As a result, you must issue the tmmnt (1) command with the -v option set to the number of volumes needed and the -b option set to 262144, which is 2^18.
When you are using TMF, xfsdump(1m) knows nothing about end of volume. If you expect the dump to occupy more than one tape volume, you must specify the volumes on the tmmnt(1) command with the -v option. If you specify multiple volumes, you do not really know how many xfsdump(1m) will use.
If you do not specify enough volumes to hold the dump, you will receive an error message. If this happens, you can restart the dump by issuing another tmmnt(1) command with the -b option set to 262144 and with additional volumes specified on the -v option. Then you enter a xfsdump(1m) command with the -R option to resume the interrupted dump session.
To restore tape files from dumps produced by xfsdump(1m), use the xfsrestore(1m) command.