12.4 Moving a VOB on UNIX

This section describes procedures for the following types of VOB moves involving UNIX platforms:

• Moving a VOB to another UNIX VOB server host that has the same architecture (binary data format). This procedure also applies when moving a VOB from one partition to another on a UNIX VOB server host.

• Moving a VOB to another UNIX VOB server host that has a different architecture.

For clarity, the procedures in this section use an example:

• The current location of the VOB storage directory to be moved is /vobstore/libpub.vbs, on a host named sol.

• The VOB tag is /vobs/libpub.

• The new location for the VOB storage directory is /vobstore2/libpub.vbs. The example includes these cases:

• The new location is also on sol.

• The new location is on another host, named ccsvr04.

If the VOB Has Remote Pools

Any of the VOB move procedures described in this section can be used to move a VOB that has remote pools. Before you begin the VOB move procedure, take the following steps to determine whether the VOB has any remote pools, and to ensure that the pools will be accessible after the VOB has been moved.

1. Determine whether the VOB has any remote storage pools.

cleartool lspool -long -invob /proj/libpub | egrep '(^pool|link)'
pool "cdft"
pool "ddft"
pool "sdft"
pool "s_2"
pool storage link target pathname "/net/ccsvr04/ccase_pools/s_2"

The output of lspool shows that this VOB has remote pool, s_2.

2. Verify that the remote pools are accessible on the target host. Moving a VOB storage directory does not move any of its remote storage pools. You must make sure that the VOB's new host can access each remote storage pool using the same global pathname as the VOB's current host:

• If you are moving the VOB to another location on the same host, the validity of remote storage pool global pathnames is assured.

• If you are moving the VOB to a different host, log on to that host and verify that all the remote storage pool global pathnames are valid on that host.

Consolidating Remote Pools

If you are moving a VOB that has remote pools from UNIX to Windows, you must consolidate the remote pools before you move the VOB. You may also want to use this procedure to consolidate a VOB's remote pools after the VOB has been moved to a NAS device (see Moving a VOB to NAS).

1. Log in to the VOB server host as the VOB owner or root.

2. Find the remote pools. Go to the VOB storage directory and determine the locations of all remote pools and the links that point to them. In this example, the UNIX find(1) command shows a single symbolic link to a remote pool.

cd /vobstg/libpub.vbs
find . -type l -exec ls -l {} \;
lrwxrwxrwx 1 root 12 Dec 30 1999
d/ddft_2 ->/net/ccsvr5/pools/libpub/d/ddft_2

3. Replace each remote pool with a local directory. For each remote pool, replace the link with a local copy of the pool. You must preserve file and directory protection and ownership information during this operation. These two UNIX commands would remove the symbolic link d/ddft_2, and then replace it with the contents of the link's target, /net/ccsvr5/pools/libpub/d/ddft_2. (Note that if the target had a different terminal leaf, you would need to ensure that the contents were copied into a local directory named ddft_2.)

# rm d/ddft_2
# cd /net/ccsvr5/pools/libpub/d; tar -cf - ddft_2 | (cd /vobstg/libpub.vbs; tar -xBpf-)

4. Verify that the VOB has no remote pools. Stop and restart ClearCase on the VOB server host; then verify that the VOB has no remote pools by using the lspool command.

cleartool lspool -long -invob /vobs/libpub

The output of lspool should list no link targets.

5. Modify the VOB tag. If the consolidated VOB is not being moved to a new host (for example, if the VOB storage is being moved to a NAS device but the VOB server host remains the same) and has a tag in a Windows region, the tag must be modified to remove the split pool map. Use the ClearCase Administration Console's Registry Regions node. The Properties page for the VOB-tag has a Mount Options tab that allows you to edit the split pool map if you are logged in as a member of the ClearCase administrators group (or another group that has permission to change the tag registry). If you cannot use the ClearCase Administration Console, use cleartool mktag -replace to remove the VOB-tag and re-create it without a split pool map.

6. Verify that users can access the consolidated pools. After you have tested the VOB, you may delete the old remote pool storage.

NOTE: Check and modify your VOB backup procedures after you have consolidated remote pools. Be sure that the newly consolidated pools are backed up with the rest of the VOB and that the old remote pools are no longer being backed up. If you restore backups of the VOB that were made before the pools were consolidated, the remote pools are re-created, and the restored VOB is not usable.

If the VOB Is Exported for Non-ClearCase Access

Any of the VOB move procedures described in this section can be used to move a VOB that has been exported for non-ClearCase access. Before you begin the VOB move procedure, stop any export views that export this VOB. After the move is complete, restart the export views.

See Setting Up an Export View for Non-ClearCase Access for more information on export views.

Moving a VOB Between UNIX Hosts (Same Architecture)

Use the following procedure to move a VOB from one disk partition to another on a UNIX VOB server host, or between one UNIX VOB server host and another one with the same architecture.

1. Log on to the VOB server host as root.

2. Lock the VOB.

3. Stop ClearCase on the VOB server host:

4. Copy the VOB storage directory. The procedure you use depends on whether you're moving the VOB within the same disk partition or to another disk partition.

1. If you are moving the VOB to another disk partition, use tar or a similar command to copy the entire VOB storage directory tree, but not any remote storage pools, to the new location.

• To the same host on a different disk partition:

# cd /vobstore

# tar -cf - libpub.vbs | ( cd /vobstore2 ; tar -xBpf - )




• To a different host:

# cd /vobstore

# tar -cf - libpub.vbs | rsh ccsvr04 'cd /vobstore2 ; tar -xBpf -'




NOTE: The -B option to the tar command may not be supported on all architectures. Also, the rsh command may have a different name, such as remsh, on some platforms. Refer to the reference pages for your operating system.

1. If you are moving the VOB storage directory within the same disk partition, use a simple mv command to relocate the VOB storage directory to the new location.

5. Restart ClearCase if you have copied the VOB storage directory to a new location on the same VOB server host.

6. Replace the VOB object and tag with new ones that reference the new VOB storage directory. Use the ClearCase Administration Console or the following commands (this example applies to the destination on server sol):

cleartool register -vob -replace /net/sol/vobstore2/libpub.vbs
cleartool mktag -vob -replace -tag /vobs/libpub /net/sol/vobstore2/libpub.vbs

NOTE: If you are registering a UCM project VOB, you must supply the -ucmproject option to the register command.

7. Unlock the VOB.

8. Verify that all clients can access the VOB at the new location.

Moving a VOB Between UNIX Hosts (Different Architectures)

Use the following procedure to move a VOB from one UNIX VOB server host to another UNIX VOB server host that has a different architecture. The procedure is similar to the one described in Moving a VOB Between UNIX Hosts (Same Architecture), but includes the additional steps required to dump the VOB database before it is moved and reformat it on the target host.

1. Log on to the VOB server host as the VOB owner or root.

2. Dump the VOB's database to ASCII dump files using the cleartool reformatvob command. You do not need to lock the VOB beforehand; the reformatvob command does this automatically.

# cleartool reformatvob -dump /vobstore/libpub.vbs

reformatvob -dump marks the VOB database as invalid. It will be unusable by clients until it is processed by a reformatvob -load command.

3. Copy the VOB storage directory. First, make sure that the parent directory of the target location exists and is writable. Then, copy the VOB storage directory to the new host.

# cd /vobstore
# tar -cf - libpub.vbs | rsh ccsvr04 'cd /src/vobstore ; tar -xBpf -'

NOTE: The -B option to the tar commands may not be supported on all architectures. Also, the rsh command may have a different name, such as remsh, on some platforms. Refer to the Platform-Specific Guide in online help for more information or check the reference pages for your operating system.

4. Terminate the old VOB's server processes. You may either stop and re-start ClearCase on the VOB server host, or search the process table for the vob_server and vobrpc_server processes that service the old VOB. Use ps -ax or ps -ef, and search for the VOB storage directory name (libpub.vbs in our example); then use kill to terminate any such processes.

5. Log on to the new VOB server host as the VOB owner or root.

6. Re-create the VOB database from the dump files:

# cleartool reformatvob -load /src/vobstore/libpub.vbs

7. Replace the VOB object and tag with new ones that reference the new VOB storage directory. Use the ClearCase Administration Console, or the following commands (this example applies to the destination on server sol):

cleartool register -vob -replace /net/sol/vobstore2/libpub.vbs
cleartool mktag -vob -replace -tag /vobs/libpub /net/sol/vobstore2/libpub.vbs

NOTE: If you are registering a UCM project VOB, you must supply the -ucmproject option to the register command.

8. Unlock the VOB.

9. Verify that all clients can access the VOB at the new location.