C H A P T E R 2

Pre-installation Tasks

This chapter explains the system requirements for the Sun StorEdge QFS software and the tasks you must complete before you begin to install and configure your software.

This chapter contains the following sections:

- Hardware and Software Requirements

- Determining Disk Space Requirements

- Obtaining the Release Files

- Setting Up the Network Management Station

##

Hardware and Software Requirements

This section outlines the hardware and software requirements for the Sun StorEdge QFS software.

### Hardware Requirements

The Sun StorEdge QFS software can be installed either on a Sun server based on UltraSPARC® technology or on a server based on AMD Opteron x64 technology.

If you plan to install the File System Manager browser interface tool, there are additional requirements for the server that you want to use as the web server host. For more information about these requirements, see Verifying Requirements for File System Manager.

### Operating System Requirements

Sun StorEdge QFS software package runs in the following operating system environments:

- Solaris 9 OS 04/03 or later

- Solaris 10 OS

- Red Hat Enterprise 3.0 (UD-4 and UD-6) for x86/x64 platforms - shared client only

- Red Hat Enterprise 4.0 (UD-2) for x64 platforms - shared client only

- SuSE Enterprise Server 8 (service pack 4) for x64 platforms - shared client only

- SuSE Enterprise Server 9 (service pack 2) for x64 platforms - shared client only

Before installation, you should verify the applicability of the hardware, the level of the operating system, and the patch release installed. To install the Sun StorEdge QFS software, you also must ensure that you have root-level access to your system.

Note - The Sun StorEdge QFS software always supports the two most recent versions of the Solaris OS. When a new version of the Solaris OS is released, Sun StorEdge QFS adds support of the new version and drops support of the oldest version. The only exception to this policy occurs when the new Solaris OS version is released right near the time of the Sun StorEdge QFS software release. In this case, three Solaris OS versions may be supported temporarily until the next Sun StorEdge QFS software release.

To Verify the Environment

Repeat these steps for each host on which you want to install the Sun StorEdge QFS software.

1. Verify that your system has a CD-ROM drive or that it can access the release package at the Sun Download Center.

The Sun Download Center is at the following URL:

`http://www.sun.com/software/downloads`

2. Log in to your system as root.

You must have superuser access to install the software.

3. Verify your system's Solaris OS level.

The software relies on properly configured Solaris software at one of the following minimum release levels:

- Solaris 9 OS 04/03 or later

- Solaris 10 OS (for SPARC or x64 platforms)

#### Installing Solaris OS Patches

Sun Microsystems provides Solaris OS patches to customers with a maintenance contract by means of CD-ROM, anonymous FTP, and the Sun Microsystems SunSolve web site (`http://sunsolve.sun.com`).

To install a patch after you install the Sun StorEdge QFS release packages, load the CD-ROM or transfer the patch software to your system. Follow the instructions outlined in the Patch Installation Instructions and Special Install Instructions in the README file included in the patch or jumbo patch cluster.

### Verifying Third-Party Compatibilities

The Sun StorEdge QFS software interoperates with many different hardware and software products from third-party vendors. Depending on your environment, you might need to upgrade other software or firmware before installing or upgrading the Sun StorEdge QFS package. Consult the Sun StorEdge QFS and Sun StorEdge SAM-FS 4.5 Release Notes for information pertaining to library model numbers, firmware levels, and other compatibility information.

### Verifying Sun StorEdge QFS Shared File System Requirements

This section describes the system requirements for a Sun StorEdge QFS shared file system.

#### Metadata Server Requirement

There must be at least one Solaris metadata server. If you want to be able to change the metadata server, there must be at least one other Solaris host that can become the metadata server; these other host systems are known as potential metadata servers. These servers must all be running on the same hardware platform, either SPARC or x64. You cannot mix server hardware platforms. In a Sun Cluster environment, all nodes included in a Sun StorEdge QFS shared file system are potential metadata servers.

The following are configuration recommendations with regard to metadata storage:

- A Sun StorEdge QFS shared file system should have multiple metadata (`mm`) partitions. This spreads out metadata I/O and improves file system throughput.

- A Sun StorEdge QFS shared file system should use a separate, private metadata network so that typical user traffic does not interfere with metadata traffic. A switch-based (not hub-based) network is recommended for this.

#### Operating System and Hardware Requirements

Ensure that your configuration meets the following operating system and hardware requirements:

- The host systems to be configured in the Sun StorEdge QFS shared file system must be connected by a network.

- All metadata servers and potential metadata servers must have the same processor type.

- The client systems can be installed on the Solaris OS or on one of the following OSs:

- Red Hat Enterprise 3.0, AS, ES, and WS for x86/x64 platforms

- SuSE Enterprise Server 8 for x64 platforms

- Online data storage devices must be directly accessible to all hosts. All online metadata storage devices must be directly accessible to all potential metadata server hosts.

#### Sun StorEdge QFS Release Levels

Ensure that your configuration meets the following Sun StorEdge QFS requirements:

- Each host to be configured in the Sun StorEdge QFS shared file system must have a Sun StorEdge QFS software package installed upon it.

- All Sun StorEdge QFS software installed on the systems in the Sun StorEdge QFS shared file system must be at the same release level. This ensures that all systems in a Sun StorEdge QFS shared file system have identical over-the-wire protocol versions. If these levels do not match, the system generates the following message when mounting is attempted:

    SAM-FS: client client package version x mismatch, should be y.

The system writes the preceding message to the metadata server's `/var/adm/messages` file.

- When applying patches or upgrading the software for a Sun StorEdge QFS shared file system, make sure to apply the same patch to all hosts that have access to the shared file system. Unexpected results might occur if not all host systems are running the same patch level.

### Verifying Requirements for a Sun Cluster Environment

If you plan to configure a Sun StorEdge QFS file system in a Sun Cluster environment, verify the following:

1. Verify your hardware.

Ensure that you have between two and eight UltraSPARC or AMD x64 hosts to use as a cluster.

Note - You cannot mix hardware architectures in a shared Sun StorEdge QFS Sun Cluster environment. All of the nodes must be either SPARC or AMD x64.

2. Verify your software.

Ensure that you have the following minimum software levels installed on each cluster node:

- Solaris 9 OS 04/03 or later, or Solaris 10 OS

- Sun Cluster 3.1 4/04

Note - For AMD x64 configurations only Solaris 10 OS is supported with Sun Cluster 3.1 U4 08/05.

Each node must have the same Sun Cluster software level and Sun Cluster patch collection. You must install Sun StorEdge QFS software packages on each node in the cluster that will host a Sun StorEdge QFS file system.

3. Ensure that you are familiar with how disks are used in a Sun Cluster environment.

In a Sun Cluster environment, the disk space used by the Sun StorEdge QFS file system must be configured on storage that is highly available and redundant. Ensure that you have a good understanding of the concepts in the Sun Cluster System Administration Guide for Solaris OS.

You should also be familiar with Sun Cluster operations. For information on Sun Cluster operations, see the following manuals:

- Sun Cluster Concepts Guide for Solaris OS

- Sun Cluster Software Installation Guide for Solaris OS

- Sun Cluster Data Services Planning and Administration Guide for Solaris OS

4. Verify your disk space.

Verifying Disk Space explains how much disk space to allow for the various directories that the file systems need.

5. Verify that you have the correct kinds of disk devices.

The types of disk devices you can use depend on the kind of file system you are configuring and whether you are using a volume manager, as follows:

- If you are going to configure a Sun StorEdge QFS shared file system, use raw device identification (DID) devices. In the `scdidadm`(1M) command output, these appear as `/dev/did/*` devices. The Sun Cluster nodes that share the file system must have access to each DID device through a host bus adapter (HBA) direct connection. All devices must be accessible to the file system from all nodes in the Sun Cluster environment that mount the Sun StorEdge QFS shared file system. For more information about DID devices, see the `did`(7) man page.

When you specify these devices in your `mcf` file, use the `/dev/did` devices from the `scdidadm`(1M) output. For more information about using `scdidadm`(1M), see Example: Verifying Devices and Device Redundancy.

Note - Starting with version 4U4 the Sun StorEdge QFS software supports using multi-owner disksets in Solaris Volume Manager for Sun Cluster to obtain redundancy. In versions previous to 4U4, you should not use a volume manager with a Sun StorEdge QFS shared file system in a Sun Cluster environment. Data corruption can result.

- If you are going to configure a Sun StorEdge QFS highly available file system, you must use highly available devices. You can use either raw devices or devices managed by a volume manager.

If you want to configure a Sun StorEdge QFS highly available file system using raw devices, use Sun Cluster global devices. Use the output from the `scdidadm`(1M) command to determine the names of the global devices and substitute `global` for `did` when specifying the devices in the `mcf`(1) file. Global devices are accessible from all nodes in a Sun Cluster environment, even if these devices are not physically attached to all nodes. If all nodes that have a hardware connection to the disk lose their connections, the remaining nodes cannot access the disk. File systems created on global devices are not necessarily highly available.

If you want to use a volume manager, use one of the following:

- For shared Sun StorEdge QFS configurations:
  Solaris Volume Manager for Sun Cluster. Such devices are located in `/dev/md`.

- For stand-alone Sun StorEdge QFS configurations:

- Solstice DiskSuite volume manager. Such devices are located in `/dev/md`.

- VERITAS Volume Manager (VxVM). Such devices are located in `/dev/vx`.

Use `scsetup`(1M) to register volume-managed devices with the Sun Cluster framework prior to configuring your file system.

Note - If you use a volume manager, use it only to provide redundancy. For performance reasons, do not use it to concatenate storage on separate devices; this causes the Sun StorEdge QFS highly available file system to distribute I/O inefficiently across the component devices.

If you are unsure about your devices, issue the `scdidadm`(1M) command with its
`-L` option to determine which devices in your Sun Cluster environment are highly available. This command lists the paths of the devices in the DID configuration file. In the output from the `scdidadm`(1M) command, look for devices that have two or more DID devices listed with the exact same DID device number. Such devices are highly available in a Sun Cluster environment and can also be configured as global devices for a file system, even if they directly connect only to a single node.

I/O requests issued to global devices from a node other than the direct attached node are issued over the Sun Cluster interconnect. These single-node, global devices cease to be available when all nodes that have direct access to the device are unavailable.

6. Verify device redundancy.

There are two types of redundancy to consider in a Sun Cluster environment: storage redundancy and data path redundancy. The implications of these are as follows:

- Storage redundancy is achieved by maintenance of extra disk copies of data using mirroring or RAID-1, or parity across several disks using RAID-5 to allow reconstruction of data after a disk failure. When supported by the hardware, these disk configurations enable you to configure the raw devices in a Sun Cluster environment without a volume manager. These raw devices are accessible from multiple nodes, so you can issue the `format`(1M) command from any node to obtain information on the disks.

Storage redundancy can also be achieved by using software to support mirroring or RAID. This method, however, is not generally suitable for concurrent access from multiple hosts. Sun Cluster software supports mirroring of disk volumes (RAID-1 only) through its multi-owner diskset feature with Sun StorEdge QFS software and Solaris Volume Manager. This requires Sun Cluster software version 3.1 8/05 or later, Sun StorEdge QFS software version 4U4 or later, and the Solaris Volume Manager patch for the Solaris 10 OS, which is pending release. No other software redundancy is supported.

- Data path redundancy is achieved with multiple HBAs, which are configured from a single node. If your environment includes multiple HBAs for redundancy, be aware that the Sun StorEdge QFS file systems require multipathing software like Sun StorEdge Traffic Manager software (MPxIO) to enable data path redundancy. For more information, see the Sun StorEdge Traffic Manager Software Installation and Configuration Guide, or see the `scsi_vhci`(7D) man page.

To determine redundancy, consult the hardware documentation for your disk controllers and disk devices. You need to know whether the disk controller or disk devices that are reported by `scdidadm`(1M) are on redundant storage. For information, see the storage controller vendor's documentation set and view the current controller configuration.

After the set of highly available devices has been determined, check for device redundancy. All devices must employ mirroring (RAID-1) or striping (RAID-5) to ensure continued operation in the event of a failure, as follows:

- If you are configuring a Sun StorEdge QFS shared file system, you have the option of obtaining redundancy through multi-owner disksets in Solaris Volume Manager for the Sun Cluster environment. This support was added in version 4U4 of the Sun StorEdge QFS software. If you are using an earlier version of the software, the redundancy must be supported in the disk device hardware. Do not use a volume manager to obtain redundancy.

- If you are configuring a Sun StorEdge QFS highly available file system, you can use either the Solstice DiskSuite volume manager or the VERITAS Volume Manager to obtain mirroring (RAID-1) or striping (RAID-5).

For more information about volume sizing and redundancy configurations, see the Solaris Volume Manager Administration Guide or your VERITAS Volume Manager documentation.

#### Example: Verifying Devices and Device Redundancy

This example shows how to use output from the `scdidadm`(1M) command to find the devices in the Sun Cluster environment, determine which devices are highly available, and then determine which devices are redundant.

##### Determining High Availability

CODE EXAMPLE 2-1 shows the `scdidadm`(1M) Sun Cluster command. This example uses the `-L` option for this command to list paths of the devices in the DID configuration file for all nodes. In the output from the `scdidadm`(1M) command, look for output that shows a device that is visible from two or more nodes and that has the same World Wide Name. These are global devices.

CODE EXAMPLE 2-1 uses Sun StorEdge T3 arrays in a RAID-5 configuration. The output shows that you can use devices 4 through 9 for configuring the disk cache for a file system.

CODE EXAMPLE 2-1 `scdidadm` (1M) Command Example
    ash# scdidadm -L
    1        ash:/dev/rdsk/c0t6d0        /dev/did/rdsk/d1
    2        ash:/dev/rdsk/c1t1d0        /dev/did/rdsk/d2
    3        ash:/dev/rdsk/c1t0d0        /dev/did/rdsk/d3
    4        elm:/dev/rdsk/c6t50020F2300004921d1 /dev/did/rdsk/d4
    4        ash:/dev/rdsk/c5t50020F2300004921d1 /dev/did/rdsk/d4
    5        elm:/dev/rdsk/c6t50020F2300004921d0 /dev/did/rdsk/d5
    5        ash:/dev/rdsk/c5t50020F2300004921d0 /dev/did/rdsk/d5
    6        elm:/dev/rdsk/c6t50020F23000049CBd1 /dev/did/rdsk/d6
    6        ash:/dev/rdsk/c5t50020F23000049CBd1 /dev/did/rdsk/d6
    7        elm:/dev/rdsk/c6t50020F23000049CBd0 /dev/did/rdsk/d7
    7        ash:/dev/rdsk/c5t50020F23000049CBd0 /dev/did/rdsk/d7
    8        elm:/dev/rdsk/c6t50020F23000055A8d0 /dev/did/rdsk/d8
    8        ash:/dev/rdsk/c5t50020F23000055A8d0 /dev/did/rdsk/d8
    9        elm:/dev/rdsk/c6t50020F23000078F1d0 /dev/did/rdsk/d9
    9        ash:/dev/rdsk/c5t50020F23000078F1d0 /dev/did/rdsk/d9
    10       elm:/dev/rdsk/c0t6d0        /dev/did/rdsk/d10
    11       elm:/dev/rdsk/c1t1d0        /dev/did/rdsk/d11
    12       elm:/dev/rdsk/c1t0d0        /dev/did/rdsk/d12
         # The preceding output indicates that both ash and elm can access disks 4, 5, 6, 7, 8, and 9.
         # These disks are highly available.
    ash# format /dev/did/rdsk/d5s2
    selecting /dev/did/rdsk/d5s2
    [disk formatted]
    FORMAT MENU:
            disk       - select a disk
            type       - select (define) a disk type
            partition  - select (define) a partition table
            current    - describe the current disk
            format     - format and analyze the disk
            repair     - repair a defective sector
            label      - write label to the disk
            analyze    - surface analysis
            defect     - defect list management
            backup     - search for backup labels
            verify     - read and display labels
            save       - save new disk/partition definitions
            inquiry    - show vendor, product and revision
            volname    - set 8-character volume name
            !<cmd>     - execute <cmd>, then return
            quit
    format> verify
    Primary label contents:
    Volume name = <        >
    ascii name  = <SUN-T300-0118 cyl 34530 alt 2 hd 192 sec 64>
    pcyl        = 34532
    ncyl        = 34530
    acyl        =    2
    nhead       =  192
    nsect       =   64
    Part      Tag    Flag     Cylinders         Size            Blocks
      0        usr    wm       0 - 17264      101.16GB    (17265/0/0) 212152320
      1        usr    wm   17265 - 34529      101.16GB    (17265/0/0) 212152320
      2     backup    wu       0 - 34529      202.32GB    (34530/0/0) 424304640
      3 unassigned    wu       0                0         (0/0/0)             0
      4 unassigned    wu       0                0         (0/0/0)             0
      5 unassigned    wu       0                0         (0/0/0)             0
      6 unassigned    wu       0                0         (0/0/0)             0
      7 unassigned    wu       0                0         (0/0/0)             0

##### Analyzing the Output From the Commands

The `scdidadm`(1M) command in this example lists device /dev/rdsk/c6t50020F2300004921d0, which is DID device /dev/did/rdsk/d5 or global device /dev/global/rdsk/d5. This device has a two partitions (`0` and `1`), each of which yields 212152320 blocks for use by a Sun StorEdge QFS highly available file system as `/dev/global/rdsk/d5s0` and `/dev/global/rdsk/d5s1`.

You need to issue the `scdidadm`(1M) and `format`(1M) commands for all devices to be configured for use by the Sun StorEdge QFS highly available file system.

- If you want to configure a Sun StorEdge QFS shared file system on a cluster, you must use highly available, redundant devices.

- If you want to configure a Sun StorEdge QFS highly available file system and the `scdidadm`(1M) command output indicates that the devices you want to use are JBOD (just a bunch of disks) or dual-port SCSI disk devices, you need to use a volume manager that is supported in a Sun Cluster environment to obtain redundancy. The options available and capabilities provided by such a volume manager are beyond the scope of this manual.

Version 4U4 of the software added support for multi-owner disksets in Solaris Volume Manager for the Sun Cluster environment to obtain redundancy with shared Sun StorEdge QFS file systems. If you are using an earlier version of the software, you cannot use a volume manager to construct redundant devices to support a Sun StorEdge QFS shared file system.

For more information about configuring devices that are on redundant storage, see your Sun Cluster software installation documentation.

#### Performance Considerations

For optimal file system performance, the metadata and file data should be accessible through multiple interconnects and multiple disk controllers. In addition, plan to write file data to separate, redundant, highly available disk devices.

Plan to write your file system's metadata to RAID-1 disks. You can write file data to either RAID-1 or RAID-5 disks.

If are configuring a Sun StorEdge QFS highly available file system and you are using a volume manager, the best performance is realized when the file system is striping data over all controllers and disks, rather than when the volume manager performs the striping. You should use a volume manager only to provide redundancy.

### Verifying Requirements for File System Manager

Perform this verification if you want to use the File System Manager browser interface to configure, control, monitor, or reconfigure a Sun StorEdge QFS environment through a web server.

You can install the File System Manager software in one of the following configurations:

- As a standalone management station to manage one or more Sun StorEdge QFS hosts.

- As additional software on the Sun StorEdge QFS host.

After the File System Manager software is installed, you can invoke File System Manager from any machine on the network that is allowed access to its web server.

If you plan to use File System Manager, the host upon which you are configuring the File System Manager software must meet the requirements described in the following subsections:

- Hardware Requirements

- Browser Requirements

- Operating System Requirements

- Web Software Requirements

#### Hardware Requirements

The minimum hardware requirements for the File System Manager software are as follows:

- SPARC 400 MHz (or more) CPU or x64 AMD CPU

- 1 gigabyte of memory

- One 20-gigabyte disk

- One 10/100/1000Base-T Ethernet port

#### Browser Requirements

Ensure that your installation meets the following browser requirements:

- One of the following browsers, at the minimum level indicated, must be installed on any client system that needs to access File System Manager:

- Netscape 7.x / Mozilla 1.2.1 on the Solaris OS or Microsoft Windows 98, SE, ME, 2000 or XP operating system

- Internet Explorer 5.5 on Microsoft Windows 98, SE, ME, 2000, or XP operating system

- You must enable JavaScript technology in your browser. In Mozilla, for example, click through the following menus to get to a panel showing whether JavaScript technology is enabled: `Edit`, `Preferences`, `Advanced`, and `Scripts & Plugins`.

#### Operating System Requirements

Make sure that one of the following minimum levels of the Solaris OS is installed on the web server:

- Solaris 9 OS 04/03

- Solaris 10 OS

#### Web Software Requirements

The File System Manager installation packages include revisions of the following software at the minimum levels indicated:

- Java 2 Standard Edition version 1.4.2

- JavaHelp 2.0

- JATO 2.1.2 or greater

- TomCat version 4.0.5

During the installation procedure, you will be asked to answer questions about what you currently have installed. Based on your answers, the installation software can install the correct revisions for you if the compatible revisions of these software packages are not present.

##

Determining Disk Space Requirements

This section describes how to estimate the size of disk cache needed for creation and management of files and directories in your file system.

### Planning Your File System and Verifying Disk Cache

The Sun StorEdge QFS software requires a certain amount of disk cache (file system devices) in order for it to create and manage data files and directories. An `ma`-type file system requires at least two disk devices or partitions, one for file data and one for metadata. An `ms`-type file system only requires one partition, on which both data and metadata is saved. Multiple disk devices or partitions increase I/O performance. See the Sun StorEdge QFS Configuration and Administration Guide for a detailed description of the two file system types.

The disk devices or partitions do not require any special formatting. You might see better performance if you configure multiple devices across multiple interfaces (HBAs) and disk controllers.

| Caution - Make sure that the disks and partitions that you plan to use are not currently in use and do not contain any existing data. Any existing data will be lost when you create the Sun StorEdge QFS file system.

The disks must be connected to the server through a Fibre Channel or SCSI controller. You can specify individual disk partitions for a disk, or you can use the entire disk as a disk cache. The software supports disk arrays, including those under the control of volume management software, such as Solstice DiskSuite, Solaris Volume Manager, and other volume management software products.

Before creating your first file system, you should familiarize yourself with Sun StorEdge QFS file system layout possibilities. Describing all the aspects of Sun StorEdge QFS file systems is beyond the scope of this manual. For information on volume management, file system layout, and other aspects of file system design, see the Sun StorEdge QFS Configuration and Administration Guide.

Note - EFI labels are required on all shared disks if you are using a Sun StorEdge QFS shared file system configuration that contains both the Solaris 10 OS on x64 platforms and the Solaris 9 or Solaris 10 OS on SPARC platforms. See Configuring EFI Labels for Shared x64 and SPARC Volumes for information on relabeling disks.

To Estimate Disk Cache Requirements

1. Estimate the minimum disk cache requirements for Sun StorEdge QFS software (`ma` file systems).

- Disk cache = largest file (in bytes) + amount of space needed for working files

- Metadata cache

Use the following information to estimate the metadata cache requirements. The metadata cache must have enough space to contain the following data:

- Two copies of the superblock (16 Kbytes each)

- Reservation maps for metadata space plus data space
  ((metadata + file data)/DAU/32,000) * 4 Kbytes

- Inode space
  (number of files + number of directories) * 512 bytes

- Indirect blocks - a minimum of 16 Kbytes each

- Directory data space
  (number of directories * 16 Kbytes)

2. Enter the `format`(1M) command to verify that you have sufficient disk cache space.

Use the `format`(1M) command if you are installing a Sun StorEdge QFS file system on a single server or if you are installing a Sun StorEdge QFS file system as a local file system on a Sun Cluster node.

The `format`(1M) command shows how the disks are partitioned and the size of each partition.

### Verifying Disk Space

The software requires a disk cache consisting of RAID devices, a JBOD (just a bunch of disks) collection, or both. It also requires a certain amount of disk space in the
`/` (root), `/opt`, and `/var` directories. The actual amount needed varies depending on the packages you install. TABLE 2-1 shows the minimum amount of disk space required in these various directories.

TABLE 2-1 Minimum Disk Space Requirements
Directory | Sun StorEdge QFS Minimums | File System Manager Minimum
--- | --- | ---
`/`(root) directory | 2 Mbytes | 25 Mbytes
`/opt` directory | 8 Mbytes | 5 Mbytes
`/var` directory | 1 Mbyte | 2 Mbytes
`/usr` directory | 2 Mbytes | 7 Mbytes
`/tmp` directory | 0 Mbytes | 200 Mbytes

Note - To see minimum disk space requirements for the Sun StorEdge SAM-FS Software, see the Sun StorEdge SAM-FS Installation and Upgrade Guide.

To Verify Disk Space

The following procedure shows how to verify whether there is enough disk space on your system to accommodate the `SUNWsamfsu` and `SUNWsamfsr` software installation packages.

1. Enter the following command to verify that there are at least 2 Mbytes available in the `avail` column for the `/` directory.

    # df -k /Filesystem        kbytes  used    avail capacity   Mounted on
    /dev/dsk/c0t1dos0 76767   19826   49271    29%     /

2. Enter the following command to verify that there are at least 8 Mbytes in the `avail` column for the `/opt` directory.

    # df -k /opt
    Filesystem        kbytes  used    avail capacity   Mounted on
    /dev/dsk/c0t1dos4 192423  59006  114177    35%     /opt

3. Verify that there is at least 1 Mbyte available in the `/var` directory.

A quantity of 30 Mbytes or more is recommended to allow for the growth of log files and other system files.

4. If there is not enough room for the software under each directory, repartition the disk to make more space available to each file system.

To repartition a disk, see your Sun Solaris system administration documentation.

##

Obtaining the Release Files

Make sure that you have a copy of the release software. You can obtain the Sun StorEdge QFS software from the Sun Download Center or on a CD-ROM. Contact your authorized service provider (ASP) or your Sun sales representative if you have questions on obtaining the software.

After the release, upgrade patches are available from the following URL:

`http://sunsolve.sun.com`

| Caution - If you have not read the Sun StorEdge QFS and Sun StorEdge SAM-FS 4.5 Release Notes, please do so before continuing. You can access the Sun StorEdge QFS and Sun StorEdge SAM-FS 4.5 Release Notesfor this release at any time from one of the documentation web sites described in this manual's preface.

### To Obtain the Software From the Sun Download Center

1. Enter the following URL in your browser:

`http://www.sun.com/software/download/sys_admin.html`

2. Click the Sun StorEdge QFS software package you want to download.

3. Follow the instructions on the web site for downloading the software.

### Software Licensing

You must agree to all binary and right-to-use (RTU) software license agreements before installing Sun StorEdge QFS software. Beginning with version 4, update 3, of the software, all media kits and software license options are delivered online, and license keys are no longer required.

##

Setting Up the Network Management Station

Read this section if you want to monitor your configuration through Simple Network Management Protocol (SNMP) software.

You can configure the Sun StorEdge QFS software to notify you when potential problems occur in its environment. The SNMP software manages information exchange between network devices such as servers, automated libraries, and drives. When the Sun StorEdge QFS software detects potential problems in its environment, it sends information to a management station, which enables you to monitor the system remotely.

The management stations you can use include the following:

- Sun Storage Automated Diagnostic Environment (StorADE)

- Sun Management Center (Sun MC)

- Sun Remote Server (SRS)

- Sun Remote Services Net Connect

If you want to enable SNMP traps, make sure that the management station software is installed and operating correctly before installing the Sun StorEdge QFS software. Refer to the documentation that came with your management station software for information on installation and use.

The types of problems, or events, that the Sun StorEdge QFS software can detect are defined in the Sun StorEdge QFS Management Information Base (MIB). The events include errors in configuration, `tapealert`(1M) events, and other atypical system activity. For complete information on the MIB, see `/opt/SUNWsamfs/mibs/SUN-SAM-MIB.mib` after the packages are installed.

The Sun StorEdge QFS software supports the TRAP SNMP (V2c) protocol. The software does not support `GET-REQUEST`, `GETNEXT-REQUEST`, and `SET_REQUEST`.

Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.