14.6 Importing a Disk Group

Importing a disk group where a cluster is involved differs from dealing with standalone systems.

There are a few scenarios to consider when importing disk groups in a cluster:

Importing a disk group from a standalone system to a cluster.
Importing a disk group from a cluster to a standalone system.
Importing a disk group from a cluster to a cluster.

In addition to these scenarios, we must also recognize that as of Tru64 UNIX version 5.0, a completely new version of LSM has been introduced which, among other things, changes the on-disk metadata as well as how logging is done. Due to these differences, importing disk groups from systems running Tru64 UNIX prior to version 5.0 must be handled differently than importing a disk group from systems running Tru64 UNIX version 5.0 or newer.

Importing a disk group is done using the voldg(8) command. This is the same command you would use on the standalone system. Table 14-7 shows the additional voldg command options based on the origin of the disk group we will be importing.

Table 14-7: The voldg(8) Command Import Options
Voldg import command options
from	to	options(s)
Tru64 UNIX version 5.0 or newer	TruCluster Server	-0 shared
Digital UNIX version 3.2 -4.0E Tru64 UNIX version 4.0F-4.0G	TruCluster Server	-0 convert_old -0 shared
TruCluster Server	Tru64 UNIX version 5.0 or newer	-0 private
TruCluster Server	Digital UNIX version 3.2 -4.0E Tru64 UNIX version 4.0D-4.0G	unsupported^[*]
^[]there is a scenario where it can be done, see section 14.5.2.2*

Any disk group except for rootdg can be deported and imported. Although you cannot deport the rootdg, we will show you how to import a rootdg from another system.

14.6.1 Importing a Disk Group from a Standalone System to a Cluster

14.6.1.1 From Tru64 UNIX Version 5.0 or Newer

To import a disk group from a standalone system to a cluster, use the following procedure:

Deport the disk group from LSM on the standalone system.
```
 # volume –g mydg stopall 
```
```
 # voldg deport mydg 
```
Disconnect the storage from the standalone system.
Connect the storage to the cluster.

Scan the SCSI bus on each cluster member.

 [sheridan] # hwmgr -scan scsi -bus 3

 [sheridan] # hwmgr -scan scsi -;bus 3 -member molari

Create the device special files (if necessary).
```
 # dsfmgr -K 
```
Determine the new device names.
```
 # hwmgr –show scsi –bus 3 
```
Rebuild the LSM volume device nodes.
```
 # voldctl enable 
```
Import the disk group.
- If the disk group is not the rootdg (Note: the "-f" switch may also be necessary if not every disk in the disk group is available):
```
 # voldg –o shared –C import mydg 
```
- If the disk group was the rootdg on the original system, you will need to rename the disk group because the cluster already has a rootdg.
  
  Before you can import the root disk group, you must determine the disk group identifier (DGID) of the standalone system's rootdg.
```
 # voldisk list dsk10 | grep group group:       name=rootdg id=999905375.1022.delenn 
```
  Import the disk group with a new disk group name. We'll use "mydg."
```
 # voldg -o shared –n mydg -C import id=999905375.1022.delenn 
```
Recover the volumes for the disk group in the background.
```
 # volrecover -sb -g mydg 
```

14.6.1.2 From Tru64 UNIX Prior to Version 5.0

Save the LSM configuration.

While saving the LSM configuration is always a good idea, it is particularly important if you are moving a disk group from a system running Digital UNIX version 3.2 through 4.0E, or Tru64 UNIX version 4.0F through 4.0G, because you may need to move it back. Once a disk group is imported into LSM on a system running Tru64 UNIX version 5.0 or newer, the metadata is converted to the new format and is no longer compatible with the older format. It is possible to restore the metadata to the older, pre-V5 format provided you have the older format backed up and you did not make subsequent metadata changes (e.g., detaching or moving data plexes).
```
 # volsave -d /MyLSMbackupDirectory 
```
Deport the disk group from LSM on the standalone system.
```
 # volume -g mydg stopall 
```
```
 # voldg deport mydg 
```
Disconnect the storage from the standalone system.
Connect the storage to the cluster.

Scan the SCSI bus on each cluster member.

 [sheridan] # hwmgr -scan scsi -bus 3

 [sheridan] # hwmgr -scan scsi -bus 3 -member molari

Create the device special files (if necessary).
```
 # dsfmgr -K 
```
Determine the new device names.
```
 # hwmgr -show scsi -bus 3 
```
Rebuild the LSM volume device nodes.
```
 # voldctl enable 
```
Import the disk group.
- If the disk group is from a V3.2 through V4.0G standalone system and not the rootdg:
```
 # voldg -o shared -o convert_old -fC import mydg lsm:voldg: WARNING: Volume myvol: Temporarily renumbered due to conflict 
```
- If the disk group is from a V3.2 through V4.0G standalone system and is the rootdg, you will need to rename the disk group because the cluster already has a rootdg. Before you can import a disk group you will be renaming, you must determine the disk group identifier (DGID) of the standalone system's rootdg.
```
 # voldisk list dsk10 | grep group group:      name=rootdg id=999905375.1022.delenn 
```
  Import the disk group with a new disk group name. We'll use "mydg."
```
 # voldg -o shared -o convert_old -n mydg -fC import id=999905375.1022.delenn 
```

Start the volume.

 # volprint -Aht myvol Disk group: mydg V   NAME          USETYPE      KSTATE       STATE     LENGTH    READPOL    PREFPLEX PL  NAME          VOLUME       KSTATE       STATE     LENGTH    LAYOUT     NCOL/WID   MODE SD  NAME          PLEX         DISK         DISKOFFS  LENGTH    [COL/]OFF  DEVICE     MODE v   myvol         fsgen        DISABLED  CLEAN 2097152   SELECT     - pl  myvol-01      myvol        DISABLED  CLEAN 2097152   CONCAT     -          RW sd  mydg_01-01    myvol-01     mydg_01      0         2097152   0          dsk10      ENA

 # volume -g mydg startall

For additional information, see the Logical Storage Manager manual or the volume(8), voldisk(8), voldg(8), volrecover(8), and volsave(8) reference pages.

14.6.2 Importing a Disk Group from a Cluster to a Standalone System

14.6.2.1 From TruCluster Server to a V5.0+ Standalone System

The procedure for going from a cluster to a standalone system running Tru64 UNIX version 5.0 or newer is almost the same procedure as described in section 14.6.1.1 the only difference occurs at Step 8. Use the following command:

 # voldg -o private -C import mydg

14.6.2.2 From TruCluster Server to a V3.2 through V4.0G Standalone System

Caution

This procedure will not work if the disk group did not originate on a system that had a volsave performed prior to moving the data to the TruCluster Server environment. This procedure is really a recovery procedure and not to be used to move disk groups back and forth between the pre-V5.0 operating system environments.

If you are moving the disk group back to a standalone system running Digital UNIX version 3.2 through 4.0E, or Tru64 UNIX version 4.0F through 4.0G, you need to restore the metadata from a backup. Replace Steps 5–10 in section 14.6.1.2 with the following procedure:

Scan the SCSI bus on each cluster member.
```
 # scu scan edt 
```

Restore the LSM configuration.

 # volrestore -i -g mydg -d /MyLSMbackupDirectory

Initialize the volumes in the disk group to a CLEAN state (repeat as necessary).
```
 # volume –g mydg init clean myCoolVolume myMultiPlex 
```
Start all of the volumes in the disk group.
```
 # volume –g mydg startall 
```

For additional information, see the Logical Storage Manager Guide or the volume(8), voldg(8), and volrestore(8) reference pages.

14.6.3 Importing a Disk Group from a Cluster to a Cluster

14.6.3.1 From TruCluster Server to TruCluster Server

The procedure for going from a cluster to a cluster running TruCluster Server version 5.0A or newer is almost the same procedure as described in 14.6.1.1; the only difference is at Step 8. Use the following command:

 # voldg –C import mydg

14.6.3.2 From TruCluster Version 1.5 or 1.6 to TruCluster Server

Importing a disk group from a cluster running TruCluster version 1.5 or 1.6 should be done using the clu_migrate_* scripts included in the TCRMIGRATE subset that ships with TruCluster Server version 5.0A (or newer). We will discuss migrating from V1.5 or V1.6 as well as those clu_migrate_* scripts in chapter 26.