Managing a virtual filer

Virtual filer management overview

You manage a virtual filer as you do any filer, including managing disks, with the following exceptions, which are described in greater detail later in this section:

A virtual filer can access only failed filer disks.
Some commands are unavailable.
Some displays differ from normal displays.

Accessing the virtual filer from the takeover filer

You access the virtual filer from the takeover filer in takeover mode with the partner command. You can issue the partner command in two forms:

The partner command without an argument toggles between partner mode, in which you manage the virtual filer, and takeover mode, in which you manage the takeover filer. The prompt changes to the partner mode prompt, which has the form:
virtual_filer/takeover_filer>,

The following example shows the change from takeover mode to partner mode and back:
```
filer1(takeover)> partner

Login from console: filer2

filer2/filer1> Thu Aug 20 16:44:39 GMT [filer1: 
rc]: Login from console: filer2

partner

Logoff from console: filer2

filer1(takeover)> Thu Aug 20 16:44:54 GMT [filer1: 
rc]: Logoff from console: filer2

filer1(takeover)> 
```
The partner command with a filer command as an argument executes the filer command on the virtual filer in partner mode, then returns to takeover mode, as shown in the following example:
```
filer1(takeover)> partner cf status

filer2 has been taken over by filer1.

filer1(takeover)> 

Accessing the virtual filer remotely
```

You can also access the virtual filer using a remote shell program such as rsh without using the partner command.

Using Telnet

With Telnet, you can access directly only the takeover filer. To access the virtual filer, log in to the takeover filer, then use the partner command.

Using a remote shell

To execute a command on the virtual filer using a remote shell, issue the command to that filer, which has the same name as the failed filer.

Virtual filer tape drives inaccessible

You cannot access tape devices on the virtual filer. You must use the tape drives on the takeover filer instead.

Virtual filer commands

Almost all the commands that are available to a normal filer are available on the virtual filer in partner mode. The commands in the following subsections are exceptions.

Unavailable commands

The following commands are not available on a virtual filer:

cf disable

cf enable

cf forcegiveback

cf forcetakeover

cf giveback

cf takeover

date date

halt

ifconfig partner

ifconfig -partner

ifconfig mtusize

license cluster

rdate

reboot

timezone name

Commands with different behaviors

The commands in the following table behave differently in partner mode than they do on a takeover filer.


Command	Difference
ifconfig [interface]	Displays the following: Virtual filer interface mappings based on the failed filer's /etc/rc file. Virtual filer's interface names rather than the takeover filer's interface names that have performed the takeover. Only interfaces that have been configured.
mt	Uses the tape devices on the takeover filer. This is because the failed filer has no access to its tape devices.
netstat -i	Appends a plus sign (+) to shared interfaces. A shared interface is one that has two IP addresses assigned to it: an IP address for the filer in which it physically resides, and an IP address for it's partner filer in the cluster.
shelfchk	Does not distinguish between the takeover filer's disk shelves and the virtual filer's disk shelves. The `shelfchk` command has the same result in partner mode as it does in takeover mode.
sysconfig	When it displays hardware information, the `sysconfig` command displays information only about hardware that is attached to the takeover filer. It does not display information about any hardware that is attached only to the failed filer. For example, the disk adapter information that the `partner sysconfig -r` command displays is about the disk adapters on the takeover filer.
uptime	Displays how long the failed filer has been down and the host name of the takeover filer.
vol status	When it displays hardware information, the `vol status` command displays information only about hardware that is attached to the takeover filer. It does not display information about any hardware that is attached only to the failed filer. For example, the disk adapter information that the `partner vol status -r` command displays is about the disk adapters on the takeover filer.

Backing up and restoring from the virtual filer

You can perform dumps and restores on the virtual filer. However, neither the takeover filer nor the virtual filer can access the tape drives or other peripheral devices on the failed filer.

Performing dumps on a virtual filer

Any dump commands directed to the failed filer's tape drives are executed on the takeover filer's tape drives. Therefore, any dump commands that you execute through the cron command succeed only under the following conditions:

The device names are the same on both filers in the cluster.
The dump commands for the filer and the virtual filer are not scheduled to occur during the same time period--the filer and the virtual filer cannot access the tape drives simultaneously.

Caution: Make sure there that is a tape on which you want the backup to be written in the tape device for each dump. Any tape in the tape device can get overwritten by a dump.

Performing restores on a virtual filer

To perform restores to the virtual filer, follow these steps:


Step	Action
1	Put the restore tape in a drive accessible by the takeover filer.
2	Use the `restore` command in partner mode or as an argument to the `partner` command.

Verifying the link between clustered filers

You can verify the status of the link between clustered filers by entering the following command:

cf status

The following table shows the messages that may be displayed by the cf status command.


Message	Meaning
Cluster enabled, partner_name is up.	The cluster is operating normally.
partner_name_1 has taken over partner_name_2.	One filer in the cluster has taken over the other filer in the cluster.
Interconnect not present.	The system does not recognize the existence of an interconnect device.
Interconnect is down.	The interconnect is unable to access the partner. This may be due to cabling problems or the partner may be down.
Interconnect is up.	The interconnect is active and is able to transmit data to the partner.
X link is down; Y link is up.	The X link (upper cable) is currently down. This condition may occur briefly when a cluster node is booting. If this condition persists, check the cable seating.
X link is up; Y link is down.	The Y link (lower cable) is currently down. This condition may occur briefly when a cluster node is booting. If this condition persists, check the cable seating.

Note: Even if one of the interconnect links (X or Y) is down, cluster communication continues over the link that is up.

Part No. 210-02334
File: clust11.htm
Last updated: 02/24/99 12:16:47