This chapter describes how to install and set up your OpenVault system. There are two types of OpenVault hosts: the server, with the media library manager (MLM), and remote hosts, with an LCP or DCP, but without the MLM.
Depending on which hosts have drives and libraries physically or logically connected, configurations fall into one of two categories:
Local configuration: all OpenVault-managed drives, libraries, and applications reside on the OpenVault server host.
Local-and-remote configuration: one or more libraries or drives (or both) reside on OpenVault hosts other than the OpenVault server host.
If you have already configured OpenVault and would like to change the configuration, see Chapter 4, “Administering OpenVault”.
OpenVault release 1.4.1 supports the following drives on IRIX versions 6.5.14 with patch (see the Release Notes for the specific patch number), 6.5.15, and later:
OpenVault release 1.4.1 supports the following libraries on IRIX versions 6.5.14 with patch (see the Release Notes for the specific patch number), IRIX 6.5.15, and later:
This release of OpenVault supports barcoded tape media only. You must have at least one tape for each drive type; the norm is to load a tape in each available library slot.
Though not required, if you configure OpenVault using a graphics console, resizing and backward scrolling (in xwsh for example) can make setup easier.
You must have a license installed to run the OpenVault server software. Licensing tools must be installed beforehand on the OpenVault server system. IRIX 6.2 users need to install the License Tools 2.1.1 or later package. IRIX 6.4 users require License Tools 3.0 or higher. IRIX 6.5 has the required License Tools. To check whether the License Tools are installed, enter the following command:
# versions -b license_eoe |
To obtain a license, visit the Web site http://www.sgi.com/support/licensing/index.html, or send e-mail to license@sgi.com, with a blank message, to obtain the license template. You may also use the FAX number, +1-650-920-0537, or this postal address:
SGI
1600 Amphitheatre Parkway
Mountain View, CA 94043
Attn: Software Licensing, MS 134
The OpenVault license you received includes instructions on how to install it.
If you have not already installed OpenVault, you can install it using the inst command or the graphical Software Manager.
For more information about IRIX install programs, see the inst(1M) and swmgr(1M) man pages. For information about last minute product changes, refer to the OpenVault release notes.
The default OpenVault product images include the following subsystems:
OpenVault.sw.core OpenVault core servers OpenVault.sw.admin OpenVault administrative tools OpenVault.sw.libs OpenVault core runtime libraries OpenVault.sw.user OpenVault end-user tools OpenVault.sw.config OpenVault setup scripts OpenVault.sw.core OpenVault core servers OpenVault.sw.admin OpenVault administrative tools OpenVault.sw.libs OpenVault core runtime libraries OpenVault.sw.user OpenVault end-user tools OpenVault.man.manpages OpenVault manual pages OpenVault.man.relnotes OpenVault release notes OpenVault.lcp.libs OpenVault run-time libraries for LCPs OpenVault.lcp.ATL2640 OpenVault LCP for ATL-2640 library OpenVault.lcp.EMASS_Grau OpenVault LCP for EMASS-Grau library OpenVault.lcp.EXABYTE210 OpenVault LCP for EXB-210 library OpenVault.lcp.IBM3494 OpenVault LCP for IBM-3494 library OpenVault.lcp.STK9700 OpenVault LCP for STK-97XX library1 OpenVault.lcp.STKACSLS OpenVault LCP for STK-ACSLS library2 OpenVault.lcp.pseudo OpenVault LCP for the “pseudo” library OpenVault.dcp.libs OpenVault run-time libraries for DCPs OpenVault.dcp.DLT2000 OpenVault DCP for DLT2000 drive OpenVault.dcp.DLT-7000 OpenVault DCP for DLT-7000 drive OpenVault.dcp.EXB8505XL OpenVault DCP for EXB-8505 drive OpenVault.dcp.IBM3590 OpenVault DCP for IBM-3590 drive OpenVault.dcp.STKredwood OpenVault DCP for STK-redwood drive OpenVault.dcp.STKtimberline OpenVault DCP for STK-timberline drive OpenVault.dcp.pseudo OpenVault DCP for the “pseudo” drive OpenVault.docs.adminguide OpenVault administrative guide OpenVault.docs.architecture OpenVault architecture specifications OpenVault.docs.developer OpenVault LCP/DCP/app developer guides OpenVault.dev.examples OpenVault sample source for applications OpenVault.dev.include OpenVault app C/C++ include headers |
1. This includes the STK-9710, STK-9714 and STK-9730 libraries.
2. Includes libraries that can be controlled via the StorageTek ACSLS interface.
Figure 2-1 shows an OpenVault local-only configuration.
This shows the OpenVault server named ursa, controlling two libraries: an STK-9730, connected at device address /dev/scsi/sc2d3l0, and an STK-9710, connected at device address /dev/scsi/sc3d1l0.
The STK-9730 at /dev/scsi/sc2d3l0 contains two drives:
DLT-7000 at /dev/rmt/tps2d1, physically located as the bottom drive in the library.
DLT-7000 at /dev/rmt/tps2d2, physically located as the top drive in the library.
The STK-9710 at /dev/scsi/sc3d1l0 contains two drives:
DLT-7000 at /dev/rmt/tps3d2, physically located as the bottom drive in the library.
DLT-7000 at /dev/rmt/tps3d3, physically located as the top drive in the library.
Figure 2-2 shows an OpenVault local-and-remote configuration.
In Figure 2-2, ursa is the designated OpenVault server host, with four libraries:
STK-9730 connected at device address /dev/scsi/sc2d3l0
STK-9710 connected at device address /dev/scsi/sc3d1l0
IBM 3494 connected via an IBM library server running on the host, tsm-ps2
StorageTek WolfCreek silo connected via the ACSLS server host, tsm-sun
The STK-9730 on ursa has the following drives, both of which are connected to the host:
DLT-7000 at /dev/rmt/tps2d1, physically located as the bottom drive in the library.
DLT-7000 connected at address /dev/rmt/tps2d2, physically located as the top drive.
The STK-9710 on ursa has the following drives, both of which are connected to the host:
DLT-7000 at /dev/rmt/tps3d2, physically located as the bottom drive in the library.
DLT-7000 at /dev/rmt/tps3d3, physically located as the top drive.
The IBM 3494 on host ursa has the following drive, connected to the host ursa:
IBM-3590 at /dev/rmt/tps4d6, identified by the IBM Library Server as drive 0
The StorageTek ACSLS-controlled WolfCreek silo has the following drives, all of which are connected to vega, not ursa:
STK-RedWood at /dev/rmt/tps3d1, located physically in LSM 2, Panel 3, as Drive 1
STK-RedWood at /dev/rmt/tps3d3, located physically in LSM 2, Panel 3, as Drive 3
STK-TimberLine at /dev/rmt/tps3d2, located physically in LSM 2, Panel 1, as Drive 1
STK-TimberLine at /dev/rmt/tps3d4, located physically in LSM 2, Panel 1, as Drive 3
Host vega is an OpenVault client host with one library: STK-9714 connected at device address /dev/scsi/sc7d1l0. The STK-9714 has the following drives, both of which are connected to vega:
DLT-7000 at /dev/rmt/tps7d3, located physically as the bottom drive in the library.
DLT-7000 at /dev/rmt/tps7d2, located physically as the top drive.
Notice that vega has two STK-RedWood drives and two STK-TimberLine drives connected to it, but the library in which these drives reside is not connected to vega.
The OpenVault initial configuration tool (setup) automatically performs steps shown in Table 2-1. The details of each step are explained in the rest of this chapter. Some steps may not be relevant to your specific installation:
Table 2-1. OpenVault Configuration Roadmap
1. | Prepare OpenVault hosts and devices. Install OpenVault license. Collect information and complete worksheets. | This step is required for all OpenVault hosts. |
2. | Configure OpenVault core on the OpenVault server host. | This required step must be performed on the OpenVault server host. |
3. | Configure drives attached to the OpenVault server host. | This step is required for drives connected to the OpenVault server host, and must be performed on the OpenVault server host. |
4. | Configure libraries attached to the OpenVault server host. | This step is required for libraries connected to the OpenVault server host, and must be performed on the OpenVault server host. |
5. | Enable applications on OpenVault server. | This step is required for any applications. |
6. | Enable drives and libraries attached to remote OpenVault client hosts. | If you have remote libraries and drives, perform this step on the server host. |
7. | Enable applications to run on remote OpenVault client hosts. | If you have applications running on remote hosts that request services from OpenVault, perform this step on the server host. |
8. | Configure drives attached to OpenVault client hosts. | If you have drives attached to remote OpenVault client host(s), perform this step on the remote host(s). |
9. | Configure libraries attached to OpenVault client hosts. | If you have libraries attached to remote OpenVault client host(s), perform this step on the remote host(s). |
10. | Import media into OpenVault. | After configuring all libraries, perform this step on the OpenVault server host. |
11. | Custom installation. | If desired. |
This section explains how to prepare OpenVault managed devices for configuration. All drives you configure must be housed in a library, because OpenVault cannot manage standalone drives (that is, drives not housed in a robotic library). Procedure 2-1 describes the steps as preparation before configuring your OpenVault devices and hosts.
Procedure 2-1. Pre-Configuration Preparations
In this procedure, step 4 is required only if you are configuring a IBM 3494 library, and step 5 only if you are configuring a DAS library.
Cable all SCSI drives to appropriate hosts. Always ensure proper SCSI termination.
Cable all SCSI libraries to appropriate hosts.
For each host with an OpenVault controlled drive attached to it, run the following commands as root:
# killall mediad # chkconfig mediad off
Note: The mediad daemon interferes with OpenVault operation; so it is essential that you prevent mediad from accessing OpenVault drives. Refer to the mediad(1M) man page for information on how to prevent mediad from accessing drives. Prepare the IBM 3494 libraries that you are planning to configure:
Enable communication between the LCP host and the IBM 3494 server. The IBM 3494 library server runs on the PS/2 system located at the rear of the library. From the graphical administration interface for the library server available on the PS/2, inform the library server of the OpenVault host that will run the LCP for the IBM 3494. Refer to the IBM 3494 Library server documentation for details on how to do this.
On the OpenVault host that will run the LCP for the IBM 3494, prepare the /etc/ibmatl.conf file. If this file does not exist, you must create it. Briefly, this file contains three fields:
libraryname PS/2 hostname LCPhostname
Here libraryname can be any name not already in this file. The PS/2 hostname is the hostname or IP address of the PS/2 system that is running the IBM 3494 library server. The LCPhostname is the hostname of the machine that will run the LCP for the IBM 3494. Refer to the IBM 3494 documentation for details about the /etc/ibmatl.conf file.
Caution: It is critical that you remember LCPhostname (not libraryname as you might expect), which is also the OpenVault name for this library. As root, start lmcpd on the IBM 3494 LCP host,
# cd /usr/OpenVault/clients/lcp/IBM-3494 # ./lmcpd
Prepare the DAS PS/2 system for any ADIC DAS or EMASS Grau library you plan to configure.
Use the following worksheets an aid to collecting information that is required for configuring an OpenVault system.
Fill out Figure 2-3 with OpenVault server client host information.
Fill out Figure 2-4 for drives in a SCSI library.
Fill out Figure 2-5 for drives in an IBM 3494 library. Also use this form for any ADIC DAS or EMASS Grau library.
Fill out Figure 2-6 for drives in an ACSLS library.
Fill out Figure 2-7 and Figure 2-8 for each SCSI library.
Fill out Figure 2-9 and Figure 2-10 for each IBM 3494 library. Also use these forms for any ADIC DAS or EMASS Grau library.
Fill out Figure 2-11 and Figure 2-12 for each ACSLS library.
Follow the order outlined to record information on the worksheets:
Acquire the names of the OpenVault server and client hosts. See Figure 2-3.
Generate unique names of the libraries. See Figure 2-7 through Figure 2-11.
Collect information about the attached drives. See Figure 2-4 through Figure 2-6.
Collect information for SCSI-attached libraries. See Figure 2-7 and Figure 2-8.
Collect information for IBM 3494 libraries. See Figure 2-9 and Figure 2-10.
Collect information for ACSLS libraries. See Figure 2-11 and Figure 2-12.
Collect information for ADIC DAS or EMASS Grau libraries. See Figure 2-9 and Figure 2-10.
You need to identify all hosts that form your OpenVault system. Identify only one host as the OpenVault server host.
In addition, you need to identify OpenVault client hosts, other than the OpenVault server host. These include any host on which you plan to configure a DCP, LCP, application, or OpenVault administrative commands. Wherever hostnames are required, use the exact output of the hostname command.
Generate unique names for all OpenVault managed libraries. You may choose any naming scheme that suits your site, provided the names remain unique. If you prepared an IBM 3494 as described earlier, you must generate a library name, which must become the OpenVault name.
Determine which drives are attached to each host using the hinv command. Example 2-1 shows the drives in the configuration in Figure 2-2.
Example 2-1. Indentifying Drives
The following drives are on hosts ursa and vega:
ursa# hinv | grep Tape Tape drive: unit 1 on SCSI controller 2: DLT Tape drive: unit 2 on SCSI controller 2: DLT Tape drive: unit 2 on SCSI controller 3: DLT Tape drive: unit 3 on SCSI controller 3: DLT Tape drive: unit 6 on SCSI controller 4: IBM Magstar 3590 vega# hinv | grep Tape Tape drive: unit 1 on SCSI controller 3: STK SD3 Tape drive: unit 2 on SCSI controller 3: STK 9490 Tape drive: unit 3 on SCSI controller 3: STK SD3 Tape drive: unit 4 on SCSI controller 3: STK 9490 Tape drive: unit 2 on SCSI controller 7: DLT Tape drive: unit 3 on SCSI controller 7: DLT |
For each OpenVault-managed drive in an OpenVault library, follow these steps in Procedure 2-2:
Procedure 2-2. Collecting Drive Information
Determine to which OpenVault host the drive is physically cabled. Record this information in the drive worksheet. It may be necessary to follow SCSI cabling in order to determine this.
Determine the device path using the hinv command on that host.
It might be a good idea to insert a tape in the drive, unload all other drives that are on the same SCSI bus as this drive, and issue an mt status command.
For example, to determine this information for one of the two STK-SD3 (STK-RedWood) drives connected to vega, insert a cartridge into drive in question, unload the other drives on SCSI controller 3, and issue mt -f /dev/rmt/tps3d1 status and mt -f /dev/rmt/tps3d3 status commands. By process of elimination, you arrive at the required information.
Record the name of the library in which the device is physically housed.
Generate a unique name for this drive and record this name.
Record the physical location of drives in the library. For example, in SCSI libraries it is typical to find drives ordered in a linear fashion, either vertically or horizontally as viewed from the front of the library.
For SCSI libraries, a scheme that describes the location of the drive in relation to the topology of the other drives in the library might suffice. For example, “second drive from bottom” or “third drive from left” are descriptive terms. Typically, StorageTek SCSI libraries order drives from the bottom, EXABYTE SCSI libraries order drives from the top, while some SpectraLogic libraries order drives from left to right.
For drives in an ACSLS controlled robot, a physical description is not appropriate. You need to query ACSLS for more information. A summary of how you can do this is shown below. Refer to the ACSLS administration guide for details.
Log in to the ACSLS server with login acsss.
Run the command cmd_proc.
Issue the command query drive all.
Record the LSM ID, the Panel ID, and the drive # for the relevant drive(s).
ACSSA query drive all 08-28-98 04:49:16 Drive Status Identifier State Status Volume Type 0, 2, 1, 1 online available 9490 0, 2, 1, 3 online available 9490 0, 2, 3, 1 online available SD3 0, 2, 3, 3 online available SD3
The comma-separated tokens are the ACS ID, the LSM ID, the panel ID, and the drive number, respectively.
For drives in an IBM 3494 library, a physical description is also not appropriate. You need to query the IBM 3494 server for more information. A summary of how to do this is shown below. Refer to the IBM 3494 documentation for details.
Prepare the OpenVault host to run the LCP for the IBM 3494 as described in “Collecting Information for IBM 3494 Libraries”. As root, enter these commands:
# cd /usr/OpenVault/clients/lcp/IBM-3494 # ./mtlib -l libraryname -D
Here libraryname is the name that you generated earlier (in Procedure 2-2) when you prepared the /etc/ibmatl.conf file.
With the configuration in Figure 2-2, the first output field of this mtlib command is a drive number; refer to the IBM 3494 documentation concerning how to map drive numbers to physical locations:
ursa 9# ./mtlib -l ibm3494 -D 0, 00141700 003590B1A00
Record the drive number and physical location in the appropriate worksheets.
For drives in an ADIC DAS or EMASS Grau library, determine locality information similarly.
Follow the steps in Procedure 2-3 to obtain information for SCSI-Attached libraries.
Procedure 2-3. Collecting SCSI-Attached Libary Information
Record the device control path. On the OpenVault server, use the hinv command to determine connected SCSI libraries, and use the output of hinv with the scsicontrol command to determine the type of each attached SCSI library, as follows:
# hinv | grep Juke | \ awk '/Juke/ {printf "/dev/scsi/sc%dd%dl0\n", $7, $3}' | \ xargs /usr/sbin/scsicontrol -i /dev/scsi/sc2d3l0: Jukebox STK 9730 1300 /dev/scsi/sc3d1l0: Jukebox STK 9710 1805For each jukebox that hinv displays, issue a scsicontrol inquire command in the following form, where X is the controller number from the hinv output and Y is the unit number from the hinv output:
# scsicontrol -i /dev/scsi/scXdYl0
Repeat the previous step on every host with an OpenVault-controlled SCSI library.
Gather information about drives contained in libraries. For each SCSI library, enter these commands, where LCPtype is the LCP name, for example STK9700:
# cd /usr/OpenVault/clients/lcp/LCPtype # ./LCP* getlibinfo lcpcontrolpath | grep DRIVE
Here lcpcontrolpath is the /dev/scsi control path as described in the first step. In the sample local-only configuration on host ursa (shown in Figure 2-2), enter the following commands for the STK-9730 library:
ursa# cd /usr/OpenVault/clients/lcp/STK9700 ursa# ./LCP* getlibinfo /dev/scsi/sc2d3l0 | grep DRIVE DRIVE 1030 - - first_drive_from_BOTTOM DRIVE 1031 - - second_drive_from_BOTTOM
Use the output information to complete worksheets for SCSI-attached libraries.
Use Procedure 2-4 to collect information for IBM 3494 libraries.
Procedure 2-4. Collecting IBM 3494 Library Information
Record the hostname of the PS/2 system that is running the IBM 3494 server.
Record the drive information. The method for determining drive information is described in “Collecting Information for Attached Drives”.
Use Procedure 2-5 to collect information for ACSLS libraries.
Procedure 2-5. Collecting ACSLS Library Information
Record the hostname of the system running the ACSLS server.
Record the ACS ID of the ACSLS server that you plan to use. Refer to the documentation for the ACSLS server on how to obtain this ID.
Determine the packet version for ACSLS. The packet version is 1 less than the major version number of ACSLS running on the ACSLS server. For example, if you are running ACSLS version 5.1, use 4 as the packet version.
Record the drive information. The method for determining drive information is described in “Collecting Information for Attached Drives”.
Chapter 3, “Cartridge Life Cycle”, introduces the notion of cartridge and drive groups. The OpenVault setup script initially creates one cartridge group named carts, and one drive group named drives.
All media that you import by means of the initial configuration procedure are by default introduced into the carts cartridge group. If you would like to create more cartridge groups, to allow importing different media into different cartridge groups, you may do so by following the instructions provided in Chapter 6, “Reconfiguring OpenVault”. At initial configuration time, be sure to answer no when asked if you want to “Import Media.” The Import Media option is available as part of reconfiguration procedures--after creating the desired cartridge groups, you may import media.
As with cartridge groups, at initial configuration time all drives are introduced into the drives drive group. You may choose to add new drive groups and move drives from one drive group to another at a later time by following instructions provided in Chapter 6, “Reconfiguring OpenVault”.
| Note: When adding new cartridge and drive groups, remember to enable appropriate applications to use these cartridge groups and drive groups. |
If your site requires security, it is recommended that you create an OpenVault password. The setup script asks you to enter an OpenVault password, for authentication of initially configured applications, drives, and libraries. If you want individual libraries, drives, or applications to use passwords other than the default password that you enter during initial setup, see the instructions in the Chapter 6, “Reconfiguring OpenVault”.
The OpenVault setup procedure requires you to identify and provide OpenVault names for libraries and drives, each of which must have a unique OpenVault name. The setup script asks you to enter these names in one or more places. It is important that you enter all OpenVault drive and library names consistently and correctly. The configuration worksheets can help you do this.
If a library or drive is connected to the OpenVault server host, the OpenVault setup script requests the OpenVault name for that physical library or drive. The script offers a generated name as default, which you may override by entering a name you select.
If a library or drive is connected to a remote OpenVault client host, the OpenVault setup script requests an OpenVault name for that physical library/drive in these places:
When you configure the OpenVault server host, you must enable each library/drive by providing its OpenVault name. At such time you have the choice of accepting a name generated by the setup script, or entering a name you select.
When you actually configure the library/drive on the OpenVault client host, the script asks you for the OpenVault library/drive name that you entered when you enabled the library/drive on the OpenVault server host.
Be sure to enter the same OpenVault library or drive name in both places!
| Note: It is possible that drives are connected to remote OpenVault clients, but housed in a library connected to the OpenVault server host. In this case, configuration of the library requires entry of all drive names--the setup script cannot offer defaults. If you wrote drive names for this library on your worksheet, then enter those existing names. If you did not write drive names on your worksheet, you must create them. Be sure to record drive names and enter them exactly later in the configuration process. |
Regardless of where a drive is connected, at the time of configuring the library in which a drive is housed, you are asked to enter the OpenVault name of the drive. Be certain to enter the same OpenVault drive name in all three places!
Procedure 2-6 describes the steps required to configure the OpenVault server, following the “Configuration Roadmap”. Depending on the specific configuration at your site, some questions might not apply.
Procedure 2-6. Configuring the Server
You must configure the OpenVault server before any of its components.
Log in to the designated OpenVault server as root.
Ensure that the OpenVault license is installed in the /var/flexlm/license.dat file.
Go to the OpenVault directory and execute the setup script:
# cd /usr/OpenVault # ./setup
The setup script is the main OpenVault configuration tool. It sets up OpenVault based on installed hardware and software, and your input to various questions. If you do not see a choice you want, double check your installation to make sure the items are installed. Where possible, the setup script presents a default, indicated by “[value]:” at the end of line. You may accept this default by pressing the Enter key. Help is available at many prompts by entering a question mark (?).
The setup script goes through the following steps in setting the OpenVault server port:
The script starts by asking for the name of the OpenVault server:
What is the name of the OpenVault Server? [ursa]
Your answer informs setup whether it is executing on the OpenVault server or not. Press Enter if you are configuring the OpenVault server host.
The script continues:
What port number is OpenVault using? [44444]
The default port number for OpenVault communications is 44444. Press Enter if this is acceptable.
If anther application uses port number 44444, or if you prefer to select a different port, enter that port number. Make sure that no other application uses this port on the OpenVault server host.
The script continues:
What default security key would you like to use? [none]
The OpenVault server, LCPs, DCPs, and applications are by default configured without a security key, implying no security. If you enter a security key, the OpenVault server uses it to authenticate new connections from a client (an LCP, DCP, or application). If you have already selected a security key (password), enter it now.
You may choose to configure OpenVault initially without security, which simplifies setup. Later, you can establish OpenVault security passwords by following steps in Chapter 6, “Reconfiguring OpenVault”.
Note: If you have remote OpenVault client hosts, you are prompted for the security key value at the time of configuring remote OpenVault client hosts. It is imperative that you enter the same value that you chose while configuring the OpenVault server. Failure to do so prevents successful configuration of the OpenVault client host.
After you have configured the server port, you configure OpenVault on the OpenVault server:
The setup script prompts you with the following options:
OpenVault Configuration Menu Automatic Configuration Option 31 - Autoconfigure OpenVault on this host (setup OpenVault Server) (setup OpenVault Devices) q - Exit. Which operation would you like to do: [31]Accept the default (31) to continue with autoconfiguration of the OpenVault server.
Use this option for the designated OpenVault server:
Would you like to set up an OpenVault server on this system? [Yes]
If you selected the default option of setting up an OpenVault server, you see the following messages displayed, indicating successful configuration of the OpenVault server.
Waiting for OpenVault to initialize ... The OpenVault server was successfully started. Created Application: ov_umsh created cartridge group: carts Cartridge-group-application creation: Application: ov_umsh Group: carts created drive group: drives Drive-group-application creation: Application: ov_umsh Group: drives The OV server `ursa' is UP. The OpenVault server was successfully set up on this system.At this point, the following items have been configured:
The OpenVault core including its catalog and an ovroot process is ready to service connections from OpenVault clients.
A default cartridge group has been created named carts.
A default drive group has been created named drives.
The user mounting application ov_umsh has been enabled on the OpenVault server (this host); see the ov_umsh(1M) man page for information.
The ov_umsh application is eligible to use cartridges in the carts cartridge group, and drives in the drives drive group.
The setup script asks you to configure locally attached drives and libraries.
Would you like to configure local LCPs and DCPs? [Yes]
It is recommended that you press Enter to proceed with configuration of locally attached drives and libraries at this time.
The OpenVault setup script scans hardware to determine which SCSI tape drives are attached to this host.
If any drives are present, each drive is presented for configuration.
Do you want to configure the dtype drive at addr as “tape1”? [Yes]
This prompt offers you the choice of configuring the drive of type dtype (for example, DLT-7000) at address addr (for example, /dev/rmt/tps2d1).
The setup script proposes a name for the drive, tapeN. In this example, tape1, N is 1.
Consult the drive worksheets that you created in “Preparing OpenVault Devices and Hosts”.
Find an entry with “Drive Device Pathname” equal to the addr shown, and “Hostname Drive Is Connected to” equal to the current hostname.
If you find a matching addr entry and you wish to use the proposed name, press Enter.
Answer no under the following conditions:
If you do not find a matching entry, or do not want to configure this drive at all.
If you wish to configure this drive at a later time.
If you prefer a name other than tapeN, look in the worksheet under the column “OpenVault Name for Drive” and use the name you wrote there.
If you answer no to the question, the setup script asks you to enter the name of your choice, or to completely bypass configuring this drive.
Enter the name for dtype drive at addr, or Enter to bypass this device []
To bypass configuration of this drive, press Enter.
If you wish to configure this drive, enter its name from the entry in the drive worksheet. Type the name exactly as it appears in your worksheet.
The script proceeds to set up the drive, displaying steps as shown in Example 2-2. The configured DCP is started automatically.
Creating drive 9730-bottom-dlt in drive group drives Created Drive: 9730-bottom-dlt Updating core keys file for the new drive Configuring DLT-7000 at /dev/rmt/tps2d1 to be “9730-bottom-dlt” Starting the DCP for drive 9730-bottom-dlt
At this point, the following items have been configured:
The named drive entry has been added to the OpenVault catalog, and the drive has been added to the drives drive group.
An authentication entry has been added to the /usr/OpenVault/core_keys file.
The drive's configuration file has been created (/usr/OpenVault/dcp/dname/config, where dname is the name chosen for this drive).
Repeat the process described in this section for every drive connected to the system. If you want to add or delete drives at a later time, you can configure or deconfigure them by following instructions in Chapter 6, “Reconfiguring OpenVault”.
After drive configuration, the setup script examines the hardware for attached libraries, and presents each library for configuration.
This section describes how to configure SCSI libraries.
This prompt offers you the choice of configuring the drive of type ltype (for example, STK-9730) at address laddr (for example, /dev/scsi/sc2d3l0).
Do you want to configure the ltype library at laddr as “lib1”? [Yes]
The setup script proposes a name for the library, libN.” N is 1 in this example.
Consult the SCSI library worksheets that you created in “Preparing OpenVault Devices and Hosts”.
Find an entry with “Library Device Path” equal to the laddr shown, and “Hostname to Which Drive Is Connected to” equal to the current hostname.
If you find a matching addr entry and you wish to use the proposed name, press Enter.
Answer no under the following conditions:
If you do not find a matching entry, or do not want to configure this library at all.
If you wish to configure this SCSI library at a later time.
If you prefer a name other than libN, look in the worksheet under the column “OpenVault Name for Library” and use the name you wrote there.
If you answer no to the question, the setup script asks you to enter the name of your choice, or to completely bypass configuring this SCSI library.
Enter name for ltype library at laddr, or Enter to bypass this device []
To bypass configuration of this library, press Enter.
If you wish to configure this library, enter its name from the entry in the SCSI library worksheet. Type the name exactly as it appears in your worksheet.
If you chose to configure the SCSI library, the setup script also configures all drives contained in the library. The setup script queries the device to determine information about drives housed in this library. This device query might take a while, especially if the host has just been rebooted, if the device has just been power-cycled, or if the main door to the library has just been closed.
At this point, you see output similar to Example 2-3. lname is the name of the SCSI library that you chose, laddr is the SCSI library's device path, and ltype is the type of the SCSI library.
Example 2-3. SCSI-Attached Library Setup
Creating library lname Created Library: lname Updating core keys file for the new library Configuring ltype at laddr to be lname
After querying the information about contained drives, the setup script asks you to enter the OpenVault name for each drive contained in this SCSI library, one after the other:
For the drive at location dlocation, enter a drive name for the element address daddr
dlocation is a text description of the drive's location, and daddr is the drive's “slot” address (the slot number that the SCSI robot uses to address the drive).
You must enter the OpenVault name for the drive at the given physical location within the SCSI library.
Refer to the SCSI library worksheet for this library to determine the OpenVault name of this drive.
You need to match the description string dlocation with the column labeled “Description of Drive's Physical Location within Library.” Although your description may not exactly match the description provided by the setup script, choose the one that has the same meaning.
Tip: It is critical to the proper functioning of OpenVault that all drive names match up. If you have not already recorded a drive name on your worksheet, enter the correct name now. If you are running setup in a scrolling window, scroll up to where you configured this drive, and use the name that was entered there. The daddr (the drive's slot address) is offered as a guide to the expert user. If you are familiar with the SCSI library's addressing scheme, you may choose to use this as an unambiguous reference to the drive's physical location within the library.
If you do not want OpenVault to manage this drive, press Enter.
The setup script bypasses configuring the drive into the library; so OpenVault never mounts into this drive.
Note: If this drive is connected to a remote OpenVault client system, enter the name from your worksheet to configure this drive. If you have not yet recorded a name for this drive, select a unique drive name to enter at the prompt, and record this name on the worksheet. You will be required to enter this name when you later configure drives on the remote OpenVault client system to which the drive is attached.
After you enter the names (or bypass), you see output similar to the following:
OpenVault Server host name: ursa OpenVault Server port number: 44444 Library name: 9710 LCP name: 9710_lcp Security key: none LCP polling interval: 30 Library control path /dev/scsi/sc3d1l0 Drives in the Library: Name Address 9710-bottom-dlt 1030 9710-top-dlt 1031 Create it now (Y|N)? []The final line prompts you for confirmation:
If you are satisfied with the SCSI library configuration summary shown above, enter Y.
If you want to change one or more parameters, enter N and you are prompted again for the OpenVault drive names.
Note: The setup script does not allow you to change the name of the library at this time. However, you may do so at a later time by following steps in Chapter 6, “Reconfiguring OpenVault”.
Upon confirmation, the setup script proceeds to configure the SCSI library:
LCP successfully created Press enter to continue... Starting the LCP for library 9710
At this point, the following items have been configured:
The named library entry has been added to the OpenVault catalog.
An authentication entry has been added to the /usr/OpenVault/core_keys file.
The library's configuration file is created (/usr/OpenVault/lcp/lname/config, where lname is the name chosen for this library).
If you have software for the IBM 3494 LCP installed on an OpenVault host, then the setup script offers the option of configuring this library, regardless of whether you plan to configure one on this host or not.
This prompt offers you a choice of configuring this library with the name lib1.
Do you want to configure the IBM-3494 library at - as "lib1"? [Yes]
The setup script proposes a name for the library, libN where N is 1 in this example.
Consult the IBM 3494 library worksheets you created in “Preparing OpenVault Devices and Hosts”.
If you have multiple IBM 3494 libraries to be configured, select one of them.
If you have not yet chosen a name, or can accept the default name, press Enter. (When the library is being configured on an OpenVault client, the setup script does not propose a default library name, but instead asks you to enter the name.)
If you do not want to configure this library, answer no. If you have chosen another name for this library (see worksheet “OpenVault Name for Library”) and want to use that name, also answer no.
If you answer no, the setup script allows you to enter a name, or completely bypass configuring this library (to bypass, press Enter).
Enter name for IBM-3494 library at -, or Enter to bypass this device []
If you wish to configure this library, enter its name from the IBM 3494 library worksheet.
The setup script proceeds to configure the drives contained therein, and you see output similar to the following:
Creating library ibm3494 Created library ibm3494 Updating core keys file for the new library Configuring IBM-3494 at - to be “ibm3494”
You are then prompted for the hostname or TCP/IP address for the PS/2 that is running the IBM Library Server for this library:
What is the hostname or TCP/IP address of the PS/2 inside the library?
The setup script queries the device to get information about drives housed in this library. This device query might take a while, especially if the host has just been rebooted, if the device has just been power-cycled, or if the main door to the library has just been closed. Soon you see output like this:
waiting for lmcpd to become active ...
After querying information about contained drives, the setup script asks you to enter the OpenVault name for each drive in this library, one after the other.
For the drive at location “-” Enter a drive name for the element address daddr: 3590
Here daddr is the drive's address as reported by the IBM 3494 Library server, usually a number starting from 0. Enter the OpenVault name for the drive at the given address. Refer to the IBM 3494 library worksheet to determine the OpenVault name for this drive. You must match drive address daddr with the column “Drive Number as Described by mtlib Command.” See “Collecting Information for Attached Drives”, for details on how to run the mtlib command.
Tip: It is critical to the proper functioning of OpenVault that all drive names match up. If you have not already recorded a drive name on your worksheet, enter the correct name now. If you are running setup in a scrolling window, scroll up to where you configured this drive, and use the name that was entered there. If you do not want OpenVault to manage this drive, press Enter. The script bypasses configuring the drive in the library; so OpenVault does not mount cartridges in this drive.
Note: If this drive is connected to a remote OpenVault client system, enter the name from your worksheet to configure this drive. If you have not yet recorded a name for this drive, select a unique drive name to enter at the prompt, and record this name on the worksheet. You will be required to enter this name when you later configure drives on the remote OpenVault client system to which the drive is attached.
The script prompts you for OpenVault names for each drive housed in the library. After you enter names of all drives (or bypass) you see output similar to the following:
OpenVault Server host name: ursa OpenVault Server port number: 44444 Library name: ibm3494 LCP name: ibm3494_lcp TCP/IP Address of the Library: tsm-ps2 Security key: none LCP polling interval: 30 Drives in the Library: Name Address 3590 0 Create it now (Y|N)? []The final line prompts you for confirmation. If you are satisfied with the library and drive configuration shown, enter Y. If you want to change one or more parameters, enter N and you are prompted again for the OpenVault drive names. Upon confirmation, the setup script proceeds to configure the library:
LCP successfully created Press enter to continue... Starting the LCP for library ibm3494
Note: The setup script cannot change the name of the library at this time. However, you may do so at a later time by following steps in Chapter 6, “Reconfiguring OpenVault”. At this point the following items have been configured:
The named library entry has been added to the OpenVault catalog.
An authentication entry has been added to the /usr/OpenVault/core_keys file.
The library's configuration file is created (/usr/OpenVault/lcp/lname/config, where lname is the name chosen for this library).
If you have LCP software for the StorageTek ACSLS installed on an OpenVault host, the setup script offers the option of configuring this library, regardless of whether you plan to configure one on this host or not.
This prompt offers you a choice of configuring this library with the name lib1.
Do you want to configure the STK-ACSLS library at - as "lib1"? [Yes]
The setup script proposes a name for the library, libN. N is 1 in this example. If you have multiple ACSLS libraries to configure on this host, select one of them.
Consult the library worksheets you created in “Preparing OpenVault Devices and Hosts”.
If you have not yet chosen a name, or can accept the default name, press Enter. (When the library is being configured on an OpenVault client, the setup script does not propose a default library name, but instead asks you to enter the name.)
If you do not want to configure this library, answer no. If you have chosen another name for this library (see worksheet “OpenVault Name for Library”) and want to use that name, also answer no.
If you answer no, the setup script allows you to enter a name, or completely bypass configuring this library (to bypass, press Enter).
Enter name for STK-ACSLS library at - or Enter to bypass this device []
If you wish to configure this library, enter its name from the entry in the ACSLS library worksheet. Type the name exactly as it appears in your worksheet.
If you chose to configure the library, the setup script proceeds to configure the drives contained therein, and you see output similar to the following:
Creating library wolfcreek Created library wolfcreek Updating core keys file for the new library Configuring STK-ACSLS at - to be “wolfcreek”
You are then prompted for the hostname of the ACSLS server for this library:
What is the hostname of the ACSLS server? []
After entering this hostname, enter the version number of the ACSLS interface. Identify the version of ACSLS installed on the ACSLS server, subtract 1 from this number, and enter that value. See “Collecting Information for ACSLS Libraries ”, for details.
What is the version number of the ACSLS interface? [4]
Next enter the ID of the ACS that you are using for this LCP. Refer to the vendor's library documentation for information about obtaining the ACS ID.
What is the ACS ID of ACS? [0]
The setup script queries the device to determine information about drives housed in this library. This device query might take a while, especially if the host has just been rebooted, if the device has just been power-cycled, or if the main door to the library has just been closed.
Soon you see output similar to the following:
ONC RPC: csi_init(): Initiation Started ONC RPC: csi_init(): Initiation Completed Acquiring drive information from library (may take a while) ... ONC RPC: csi_init(): Termination Started ONC RPC: csi_init(): Termination Completed
Upon querying the information about contained drives, the setup script asks you to enter the OpenVault name for each drive in this library, one after the other.
For the drive at location “LSMid 2, Panelid 1,Driveid1” Enter a drive name for the element address 2,1,1: timberline1
The location string displayed is the LSM ID, Panel ID, and Drive number for the drive. See “Collecting Information for Attached Drives”, for steps to obtain information for drives in an ACSLS library. Consult the ACSLS library worksheet for this library and select the drive entry with the corresponding LSM ID, Panel ID, and Drive number.
Enter the OpenVault name you selected.
Tip: It is critical to the proper functioning of OpenVault that all drive names match up. If you have not already recorded a drive name on your worksheet, enter the correct name now. If you are running setup in a scrolling window, scroll up to where you configured this drive, and use the name that was entered there. If you do not want OpenVault to manage this drive, press Enter. The script bypasses configuring the drive in the library; so OpenVault does not mount cartridges in this drive.
Note: If this drive is connected to a remote OpenVault client system, enter the name from your worksheet to configure this drive. If you have not yet recorded a name for this drive, select a unique drive name to enter at the prompt, and modify your worksheet. You will be required to enter this name when you later configure drives on the remote OpenVault client system to which the drive is attached. The script prompts you for OpenVault names for each drive housed in the library.
After you enter names of all drives (or bypass) you see output similar to the following:
OpenVault Server host name: ursa OpenVault Server port number: 44444 Library name: wolfcreek LCP name: wolfcreek_lcp Security key: none ACSLS Server Host name: tsm-sun ACSLS Server Version: 4 ACSLS ACS ID: 0 LCP polling interval: 30 Drives in the Library: Name LSM Panel Drive redwood1 2 3 1 redwood3 2 3 3 timberline1 2 1 1 timberline3 2 1 3 Create it now (Y|N)? []The final line prompts you for confirmation. If you are satisfied with the library and drive configuration shown, enter Y. If you want to change one or more parameters, enter N and you are prompted again for the OpenVault drive names.
Note: The setup script does not allow you to change the name of the library at this time. However, you may do so at a later time by following steps in Chapter 7, “Tertiary Storage Management”. Upon confirmation, the setup script proceeds to configure the library:
LCP successfully created Press enter to continue... Starting the LCP for library stk-acsls
At this point the following items have been configured:
The named library entry has been added to the OpenVault catalog.
An authentication entry has been added to the /usr/OpenVault/core_keys file.
The library's configuration file is created (/usr/OpenVault/lcp/lname/config, where lname is the name chosen for this library).
This optional configuration step enables the following features:
Administration of the OpenVault server from remote OpenVault clients
LCPs and DCPs that connect to the OpenVault server from OpenVault clients
This step enables remote connections. You must also run the setup script on the remote OpenVault client(s) to configure libraries and drives on client host(s).
The script prompts:
Will remote OpenVault admin/LCP/DCP clients access this server? [No]
If you plan to enable one or more of these options, enter Yes; otherwise, accept the No default. You can add remote libraries, drives, administrative commands, or applications at a later time; see Chapter 6, “Reconfiguring OpenVault”.
The setup script first prompts for the name of a remote OpenVault client host, which is a system that meets one or more of the following tests:
You plan to connect libraries and/or drives to that host.
You plan to administer the OpenVault server from that host, by installing the OpenVault administrative subsystem.
You plan to run applications on the host that request services from OpenVault.
To identify remote client hostnames, consult the host worksheet that you generated in “Preparing OpenVault Devices and Hosts”.
Enter the name of a remote OpenVault client host at the following prompt:
Enter a remote OpenVault client machine name, or Enter to continue: []
When you have entered all the hosts, press Enter to continue with configuration.
After enabling remote clients, the setup script displays the following prompt. If you want to administer OpenVault from the named host, accept the default; otherwise enter No.
Will machine vega require administrative access to this server? [Yes] |
After this, the setup script prompts for remote libraries.
If libraries are connected to the named remote host, enter Yes; otherwise accept the default.
Are any libraries controlled by LCPs on vega? [No]
If you answered yes to the previous question, the setup script asks for OpenVault names of libraries on this host:
Do you want to configure a library on vega as “lib1”? [Yes]
The setup script presents a library name lib1, which you may accept.
If you have chosen library names in the configuration worksheet, enter those names. The script continues prompting for remote OpenVault library names.
Press Enter when you have no more remote library names to enter.
| Tip: Use the worksheets to record the names you select. You will be asked to enter them again when configuring the library or drives on a remote OpenVault client host. |
After enabling remote libraries, the setup script prompts for remote drives.
If you plan to have drives connected to the named remote host, enter Yes; otherwise accept the default.
Are any drives controlled by DCPs on vega? [No]
If you answered yes to the previous question, the setup script asks for OpenVault names of drives on this host:
Do you want to configure a drive on vega as “drive1”? [Yes]
The setup script presents a drive name, which you may accept.
If you have chosen drive names in the configuration worksheet, enter those names.
The script continues prompting for remote OpenVault drive names. Press Enter when you have no more remote drive names to enter.
After you configure locally attached drives and libraries, the script asks to import tapes that were discovered in the newly configured libraries. If you have libraries on remote OpenVault client hosts, wait until those libraries are configured, then invoke the import function as described in the section “Importing Media”. If you do not have any remote libraries, you may import media right away.
After configuring the OpenVault server, it is time to configure remote OpenVault clients, in any order. Consult the host worksheet that you generated in “Preparing OpenVault Devices and Hosts”, for the list of OpenVault client hosts.
To configure an OpenVault client host, follow these steps:
Log in to the remote host as root.
Change to the OpenVault directory, and start the setup script:
# cd /usr/OpenVault # ./setup
The setup script outlines the general configuration strategy:
OpenVault Configuration The general strategy for setting up OpenVault is to 1) configure the OpenVault server 2) configure LCP/DCP's on the server machine 3) configure server for local Applications 4) if needed, configure server for remote LCP's, DCP's, and Apps 5) if needed, install and configure LCP/DCP's on remote machines 6) from the server, setup/import media for each libraryThe setup script then determines the name of the OpenVault server host, the OpenVault server port number, and the OpenVault security key that you chose while configuring the OpenVault server.
The script prompts for the name of the OpenVault server host:
What is the name of the OpenVault Server? [vega]
Enter the name. The default presented in this prompt is the hostname of the machine on which you are running setup script.
The script prompts for the port number of the OpenVault server host:
What is the port number OpenVault is using? [44444]
If you chose another port number when you configured the OpenVault server, enter that port number now; otherwise, accept the default.
The script prompts for the security key of the OpenVault server host:
Enter the security key that you chose when you configured the OpenVault server. If you did not select security at that time, accept the default.
What default security key would you like to use? [none]
Note: Specifying the exact values for the OpenVault server's hostname, port number, and security key is critical for proper functioning of all OpenVault components. The setup script then provides the menu options shown Example 2-4:
Example 2-4. OpenVault Configuration Menu Options
OpenVault Configuration Menu Configuration for Machines Running LCPs 11 - Configure a new client LCP Configuration for Machines Running DCPs 21 - Configure a new client DCP Automatic Configuration Option 31 - Autoconfigure OpenVault on this host (setup OpenVault Devices) q - Exit. Which operation would you like to do: [31]Tip: When first configuring an OpenVault client host, it is recommended that you select the Autoconfigure option (option 31). Option 31 detects drives and libraries attached to this host. Selecting other options allows you to configure LCPs and DCPs, but those procedures are not automatic.
Would you like to configure local LCPs and DCPs? [Yes]
If you are ready to configure the libraries and drives on this host, accept the default.
Configure all libraries and drives that you plan to attach to this host.
If you have any drives attached to this host, the setup script prompts for each attached drive in succession. The set of dialogs presented are similar to the dialog when you configure drives on the OpenVault server. The main difference is that the script asks you to enter the OpenVault name for the drive, but does not offer a default name.
It is critical that you enter the OpenVault names for each drive exactly as you entered them (during server configuration when enabling remote drives). Consult your drive worksheet to make certain that the names match. A sample dialog is shown in Example 2-5:
Example 2-5. Drive Configuration on a Client Host
Enter the name for the STK-redwood drive at /dev/rmt/tps3d1,
or Enter to bypass this device [] redwood1
Configuring STK-redwood at /dev/rmt/tps3d1 to be “redwood1”
Starting the DCP for drive redwood1 |
At this point, the offered drive has been configured and the DCP for this drive is started. Use the ov_stat command on the server to show status of the newly configured drive.
The script scans the installed hardware and software to determine which libraries are available for configuration. Each detected library is offered for configuration. The set of dialogs presented are similar to the one when you configure libraries on the OpenVault server. The main difference is that the script asks you to enter the OpenVault name for the library, but does not offer a default name.
It is critical that you enter the OpenVault name for each library exactly as you entered it (during server configuration when enabling remote libraries).
Consult your library worksheet to make certain that the names match. A sample dialog for a SCSI-attached library is shown in Example 2-6.
Example 2-6. Library Configuration on a Client Host
Enter the name for the STK-9714 library at /dev/scsi/sc7d1l0, or Enter to bypass this device [] 9714 Configuring STK9700 at /dev/scsi/sc7d1l0 to be “9714” For the drive at location “first drive from BOTTOM”, enter a drive name for the element address 1030: 9714-bottom-dlt For the drive at location “second drive from BOTTOM”, enter a drive name for the element address 1031: 9714-top-dlt LCP Creation Parameters Confirmation OpenVault Server host name: ursa OpenVault Server port number: 44444 Library name: 9714 LCP name: 9714_lcp Security key: none LCP polling interval: 30 Library control path /dev/scsi/sc7d1l0 Drives in the Library: Name Address 9714-bottom-dlt 1030 9714-top-dlt 1031 Create it now (Y|N)? [] Y LCP successfully created Press enter to continue... Starting the LCP for library 9714If you decide that you do not want to configure a library at this time, press Enter to bypass configuring this library.
The setup script prompts you for OpenVault drive names contained in the library.
Type names exactly as you did when enabling those drives on the OpenVault server. Consult your library worksheet for details. You must match the location description string for each contained drive with the corresponding description string in the library worksheet.
If you have drives in this library that are connected to another host, enter the exact OpenVault name for these drives, even if you have not yet configured the drives on that host. Consult your library worksheet for this library to get this information.
Configuring a non SCSI-attached library on an OpenVault client host follows the same procedure as configuring one on the OpenVault server host.
At this point the library is configured and the LCP is started. To verify current status of the LCP, run the ov_stat command on the OpenVault server.
After you have configured the libraries on the OpenVault server and all OpenVault clients, you need to import media to make it available for application use. Importing media is how the OpenVault server learns about each piece of media. Each tape that applications use must be imported before it can be made available for allocations and mounts. See Chapter 3, “Cartridge Life Cycle”, for more information.
| Caution: If you have media that contain data in a library, or if media are known to certain sensitive applications, take precautions so that other applications do not accidentally modify these media. Refer to the application's documentation for importing media known to that application only. Failure to do so could lead to data loss. |
It is best to invoke the import media function of the setup script only after you have configured all libraries, including libraries on remote OpenVault client hosts.
The import function is available only on the OpenVault server host.
To import media into a library, you must identify a cartridge group for each cartridge. The setup script imports all media found in a library into the same cartridge group. By default, media are imported into the default cartridge group called carts. If you would like to add more cartridge groups, do so now. To import media using multiple cartridge groups, see Chapter 6, “Reconfiguring OpenVault”.
You must also identify a cartridge type for each cartridge; a list is shown in “Selecting Cartridge Types”. The setup script assumes that all media in a library is of the same cartridge type. If this is not true, skip automatic import of media and follow the procedures described in Chapter 3, “Cartridge Life Cycle”.
The import function allows you to pre-allocate all media to an application. If you wish to import media that is pre-allocated to other applications, skip automatic import of media and follow the procedures described in Chapter 3, “Cartridge Life Cycle”.
You may import media that is not pre-allocated. If you do, make sure that OpenVault applications know how to import media. For example, the media mounting application ov_umsh provided with OpenVault knows how to allocate media.
To use the import function, enter these commands as root on the OpenVault server host, and select the “Import Media” option 3, as shown in Example 2-7:
# cd /usr/OpenVault # ./setup OpenVault Configuration Menu Configuration for the OpenVault Server Machine 1 - Manage Libraries, Drives and Applications 2 - Manage Cartridge Groups And Drive Groups 3 - Import Media 4 - Enable remote applications Configuration for Machines Running LCPs 11 - Configure a new client LCP 12 - Modify an existing client LCP 13 - Deconfigure an existing client LCP Configuration for Machines Running DCPs 21 - Configure a new client DCP 22 - Modify an existing client DCP 23 - Deconfigure an existing client DCP q - Exit. Which operation would you like to do: 3 Would you like to import media ? [Yes]The setup script checks for all configured libraries containing media to import, and shows each of the libraries individually.
Would you like import media from the library 9710 [Yes]
Accept the default if you are ready to import media in that library; otherwise, enter No.
The script continues:
Would you like to add ALL cartridge to the SAME Cartridge group [Yes]
If you decide to import all cartridges in this library into the same cartridge group, accept the default. Otherwise, enter No to have the script skip importing media from this library.
Known cartridge types are presented for your inspection, including types that might be unavailable (supported types are denoted with a star):
1. D2-L 2. D2-M 3. D2-S 4. DDS3 5. DDS2 6. DDS1 7. STKredwood * 8. STKtimberline * 9. 3590 * 10. 3490E * 11. 3490 * 12. 3480 * 13. 8mm-160m 14. mammoth 15. DLT-7000 * 16. DLT2000 * 17. DTF 99. MIXED_MEDIA Select the Cartridge type for the cartridges in this library:
Note: Because 3590 cartridges are the same size as 3480 cartridges, they are said to have a 3480 slot type, which is sometimes a source of confusion. Once you select the cartridge type, available cartridge groups are displayed. Enter the cartridge group of which all cartridges in this library should be members.
Cartridge Groups available are: 1. carts Select the Cartridge group for the cartridges in this library:Once you select a cartridge group, the script asks about pre-allocation. If you want to pre-allocate cartridges to an application, accept the default. If not, see “Not Pre-allocating Cartridges”.
Would you like to pre-allocate cartridges to specific application [Yes]
If you answer Yes, you are prompted for an application name, dmf in this example:
Enter name of application for cartridge pre-allocation [ov_umsh] dmf
If the application name you enter does not exist, the setup script creates it for you.
Once the import completes successfully, you see output similar to the following:
Created Application: dmf Cartridge-group-application creation: Application: dmf Group: carts Importing tapes with: Cartridge Type = DLT2000 Cartridge Group = carts Application = dmf This may take a while... Finished importing media from library, 9710
If you do not wish to pre-allocate cartridges, enter No after the following prompt:
Would you like to pre-allocate cartridges to specific application [Yes] |
Cartridges in this library are imported without being pre-allocated to any application. Once the import completes successfully, you see output similar to Example 2-8:
Example 2-8. Importing Media without Pre-allocating Cartridges
Importing tapes with:
Cartridge Type = DLT-7000
Cartridge Group = carts
This may take a while ...
Finished importing media from library, 9730 |
Before doing a custom install, you must determine the types of all OpenVault-managed libraries and drives on all systems.
For drives, see “Determining Attached SCSI Drives”.
For SCSI libraries, see “Determining Attached SCSI Libraries”.
For other libraries, see “Non-SCSI-Attached Libraries”.
Remember to repeat the steps explained in this section for every host with an attached library or drive that is to be managed by OpenVault.
Use the hinv command to determine connected SCSI drives as shown in Example 2-9:
Example 2-9. hinv Drive Output
# hinv | grep Tape | \
awk '/Tape/ {printf "/dev/scsi/sc%dd%dl0\n", $8, $4}' | \
xargs /usr/sbin/scsicontrol -i
/dev/scsi/sc2d1l0: Tape QUANTUM DLT-7000 1E46
/dev/scsi/sc2d2l0: Tape QUANTUM DLT-7000 1E46
/dev/scsi/sc3d2l0: Tape QUANTUM DLT-7000 1E46
/dev/scsi/sc3d3l0: Tape QUANTUM DLT-7000 1E46
/dev/scsi/sc4d6l0: Tape IBM 03590B1A 53F2 |
Then use the output of hinv with the scsicontrol command to determine the type of each attached SCSI drive. For each drive that hinv displays, issue a scsicontrol inquire command as shown in Example 2-10. X is the controller number from the hinv output and Y is the unit number from the hinv output:
Example 2-10. scsicontrol Drive Output
# scsicontrol -i /dev/scsi/scXdYl0 vendor product revision ---------------------------------------- QUANTUM DLT-7000 1E46 QUANTUM DLT-7000 1E46 QUANTUM DLT-7000 1E46 QUANTUM DLT-7000 1E46 IBM 03590B1A 53F2 |
Each line in the scsicontrol output shows the drive's control path, the drive vendor name, the drive product name, and its firmware revision number.
Use the hinv command to determine connected SCSI libraries as shown in Example 2-11:
Example 2-11. hinv Library Output
# hinv | grep Juke | \
awk '/Juke/ {printf "/dev/scsi/sc%dd%dl0\n", $7, $3}' | \
xargs /usr/sbin/scsicontrol -i
/dev/scsi/sc2d3l0: Jukebox STK 9730 1300
/dev/scsi/sc3d1l0: Jukebox STK 9710 1805 |
Then use the output of hinv with the scsicontrol command to determine the type of each attached SCSI library as shown in Example 2-12. For each jukebox that hinv displays, issue a scsicontrol inquire command of the following form, where X is the controller number from the hinv output and Y is the unit number from the hinv output:
Example 2-12. scsicontrol Library Output
# scsicontrol -i /dev/scsi/scXdYl0 vendor product revision ---------------------------------------- STK 9730 1300 STK 9710 1805 |
Each line in the scsicontrol output shows the library's control path, the library vendor name, the library product name, and its firmware revision number.
OpenVault supports several non-SCSI libraries. If you plan to manage this type of library, you must install the appropriate OpenVault.lcp subsystems.
For any library that you plan to manage with OpenVault, configure one and exactly one controlling LCP. Because the above-mentioned libraries are not SCSI-attached, you may designate any OpenVault host system to run the LCP. You must install the appropriate OpenVault.lcp subsystem on that chosen system. For simplification, it might be best to designate the OpenVault server as the LCP host for non-SCSI-attached libraries.
| Note: If you unintentionally install the LCP for a non-SCSI-attached LCP on an OpenVault host, the OpenVault setup script asks if you would like to configure that LCP. Answer this question by entering No. |
This section offers guidelines for selecting OpenVault components to install.
For OpenVault server hosts:
Required
OpenVault.sw.config OpenVault setup scripts OpenVault.sw.core OpenVault core servers OpenVault.sw.admin OpenVault administrative tools OpenVault.sw.libs OpenVault core run-time libraries
Recommended
OpenVault.man.manpages OpenVault manual pages OpenVault.man.relnotes OpenVault release notes OpenVault.docs.adminguide OpenVault Administrator's Guide
Optional
OpenVault.sw.user OpenVault end-user tools OpenVault.dev.examples OpenVault sample source for applications OpenVault.dev.include OpenVault app C/C++ include headers OpenVault.docs.architecture OpenVault architecture specifications OpenVault.docs.developer OpenVault LCP/DCP/app developer guides
As needed
OpenVault.dcp.libs OpenVault run-time libraries for DCPs OpenVault.dcp.XXXX Appropriate DCP susbsystem OpenVault.lcp.libs OpenVault run-time libraries for LCPs OpenVault.lcp.XXXX Appropriate LCP susbsystem
For OpenVault client hosts:
Required
OpenVault.sw.config OpenVault setup scripts OpenVault.sw.libs OpenVault core run-time libraries
Not recommended
OpenVault.sw.core OpenVault core servers
Recommended
OpenVault.man.manpages OpenVault manual pages OpenVault.man.relnotes OpenVault release notes OpenVault.sw.admin OpenVault administrative tools OpenVault.docs.adminguide OpenVault Administrator's Guide
Optional
OpenVault.sw.user OpenVault end-user tools OpenVault.dev.examples OpenVault sample source for applications OpenVault.dev.include OpenVault app C/C++ include headers OpenVault.docs.architecture OpenVault architecture specifications OpenVault.docs.developer OpenVault LCP/DCP/app developer guides
As needed
OpenVault.dcp.libs OpenVault run-time libraries for DCPs OpenVault.dcp.XXXX Appropriate DCP susbsystem OpenVault.lcp.libs OpenVault run-time libraries for LCPs OpenVault.lcp.XXXX Appropriate LCP susbsystem
The OpenVault.dcp.libs and OpenVault.sw.libs subsystems are required on each OpenVault host that contains an OpenVault DCP.
The OpenVault.lcp.libs and OpenVault.sw.libs subsystems are required on each OpenVault host that contains an OpenVault LCP.
The OpenVault.sw.libs subsystem is required on each OpenVault host that contains an OpenVault application, DCP, or LCP.
The installation tool enforces these requirements.