Preparing the destination filer

When to use this section

Perform the Storage checks and actions that follow and the Network checks and actions whenever you intend to replicate a vFiler, whether you are moving the vFiler or preparing a disaster-recovery vFiler.

Storage checks and actions

Perform the following checks, and the accompanying actions if necessary, before moving (migrating) a vFiler or setting up a disaster-recovery vFiler. Photocopy the worksheet that follows this section and fill out the storage items as you go along.

Note
The storage checks are not necessary if you are going to use disk ownership technology to migrate the vFiler.

Step	Action
1	Check that the destination filer has enough storage space to hold the source vFiler's volumes. On the source filer, use the `vfiler status -r` command to see what volumes the vFiler is using. Then use the `df` command on each of those volumes to check how much space is being used. The destination volumes must have at least that much free space; run `df` on the destination filer to check. Fill in the `df` results on the worksheet. Note If the source and destination filers use different-sized disks and have different block sizes, you will need to adjust the `df` numbers accordingly.
2	If...	Then...
	There is enough space on the destination volumes	Continue with Step 3.
	There is not enough space	a. If necessary, install new disk shelves. b. Use the `vol add` command to add new disks to the destination volumes.
3	Check to see if the destination filer has the same volume structure as the source. The volumes to be used by the destination vFiler must have the same path names as those used by the source vFiler.
4	If...	Then...
	The destination filer has volumes whose path names match those used by the source vFiler	Continue with Step 5.
	The destination filer does not have matching volume path names	Use the `vol create` command on the destination filer to create volumes whose names match those being used by the source vFiler, or `vol rename` to rename a volume.
5	Check to see if there are qtrees in the destination volumes whose names match those of qtrees in the source volumes. The migration process uses SnapMirror, which will replicate qtree names from the source to the destination volume, so these names should not already exist on the destination.
6	If...	Then...
	There are qtrees in the destination volumes whose names match those of qtrees in the source volumes	Delete the matching qtrees in the destination volumes. To remove a qtree, delete it from a client as you would a directory or folder.
	There are no matching qtree names in the destination volumes	Continue with Step 7.
7	Check to see if quotas are being enforced from the hosting filer. Quotas enforced from the vFiler will be copied to the new vFiler, but quotas enforced from the hosting filer will not. To see where quotas are being enforced from, enter the command `quota report` from the hosting filer.
8	If...	Then...
	The output of the `quota report` command shows that quotas for qtrees used by the vFiler are being enforced from the hosting filer	a. Print out a copy of the filer's quota file: /vol/vol0/etc/quotas. b. Copy the relevant entries into the destination filer's /vol/vol0/etc/quotas file.
	No quotas for qtrees used by the vFiler are being enforced from the hosting filer	Continue with Step 9.
9	Continue with Network checks and actions.

Network checks and actions

Step	Action
1	Check to see if the destination vFiler can take over the source vFiler's IP addresses. Use the command `ifconfig -a` on the source vFiler and on the destination filer to display information about all their network interfaces. You can reuse the source IP addresses and aliases on the destination vFiler if the destination vFiler will be on the same subnet as the source vFiler.
2	If...	Then...
	The source and destination filers are on the same subnet Note This is the default case assumed by the `vfiler migrate` command.	Continue with Step 3.
	They are on different subnets	a. Obtain as many new IP addresses for the destination vFiler as are in use on the source vFiler. Note You might need to replicate subnet-separation arrangements that exist on the source vFiler. For example the source vFiler might use one IP address for a service network and another for an administration network. b. Make a note of the new IP addresses on the worksheet. The `vfiler` `dr configure` command will prompt you for these addresses; see Creating the disaster-recovery vFiler. The `vfiler migrate` command will also prompt you for these addresses, but you might then need to run `setup` on the destination vFiler. See If you have moved the vFiler to a different subnet or Windows domain.
3	Check whether the source vFiler uses the default IPspace. Use the command `ipspace list` on the source vFiler to display information about IPspaces and the interfaces assigned to them. For more information about IPspaces, see Chapter 3.
4	If...	Then...
	`ipspace list` reports `default-ipspace`	Continue with Step 5.
	`ipspace list` reports something other than `default-ipspace`	a. Use the command `ipspace create` ipspacename to create a corresponding IPspace with the same name on the destination filer. b. Use the command `ipspace assign` ipspacename interfacename to assign physical interfaces to the IPspace. These interfaces must all be attached to the same physical network.
5	Check to see if the destination vFiler will have access to the same NIS servers as the source. Note You can skip this check if the source and destination vFilers are on the same subnet. Use the command `nis info` on the source vFiler to see what NIS servers are available to it. (The `ypwhich` command shows which server the filer is currently bound to.)
6	If...	Then...
	The destination vFiler can use the same NIS servers as the source vFiler Note This is the default case assumed by the `vfiler migrate` command.	Continue with Step 7.
	The destination vFiler cannot use same NIS servers	a. Find out which NIS servers are available to the destination filer. b. Make a note of the IP addresses of those servers on the worksheet. The `vfiler` `dr configure` command will prompt you for these addresses; see Creating the disaster-recovery vFiler. The `vfiler migrate` command will not prompt you for these addresses. If you move a vFiler to a different subnet, you might need to run `setup` on the destination vFiler. See If you have moved the vFiler to a different subnet or Windows domain.
7	Check to see if the destination vFiler will have access to the same DNS servers as the source. Note You can skip this check if the source and destination vFilers are on the same subnet. Use the command `dns info` on the source vFiler to see what DNS servers are available to it.
8	If...	Then...
	The destination vFiler can use the same DNS servers as the source vFiler Note This is the default case assumed by the `vfiler migrate` command.	Continue with Step 9.
	The destination vFiler cannot use the same DNS servers	a. Find out which DNS servers are available to the destination filer. b. Make a note of the IP addresses of those servers on the worksheet. The vFiler `dr configure` command will prompt you for these addresses; see Creating the disaster-recovery vFiler. The `vfiler migrate` command will not prompt you for these addresses. If you move a vFiler to a different subnet, you might need to run `setup` on the destination vFiler. See If you have moved the vFiler to a different subnet or Windows domain.
9	Check to see if the destination vFiler will have access to the same WINS servers and the same Windows security network as the source.
10	If...	Then...
	The destination vFiler can use the same WINS servers and Windows security network as the source vFiler	Continue with Step 11.
	The destination vFiler cannot use the same WINS servers and Windows security network	a. Find out the name and type (Windows NT 4 or Windows 2000) of the domain the destination vFiler will be in. b. Make a note of this information on the worksheet. When you activate the disaster-recovery vFiler, you will need to configure it into the new domain. See Activating the disaster-recovery vFiler. If you move a vFiler into a different domain, you will need to configure it into the new domain. See If you have moved the vFiler to a different subnet or Windows domain.
11	Check to see if the destination vFiler can use the same trusted host for vFiler administration as the source vFiler.
12	If...	Then...
	The destination vFiler can use the same trusted host as the source vFiler	You are done.
	The destination vFiler cannot use the same trusted host	a. Find out the name of the new trusted host. b. Make a note of this information on the worksheet. You will need to configure the new trusted-host information after configuring the disaster-recovery vFiler, or after moving the vFiler. See Creating the disaster-recovery vFiler or If you have moved the vFiler to a different subnet or Windows domain.