vxchg_rootid

NAME

vxchg_rootid - set up VxVM root disk that has been cloned or copied from another operational VxVM root disk

SYNOPSIS

DESCRIPTION

The vxchg_rootid command sets up a VxVM root disk that has been freshly cloned by using the dd command, or by using a hardware-based procedure such as EMC Symmetrix BCV cloning. The disk ID and disk group ID fields in the private region header and the configuration records are changed from their cloned values to ensure that they are unique. The new host name is written to the host ID fields of the private region header and to the /etc/vx/volboot file. Script files in /etc, /usr and /var, that contain hard-coded host name values, are modified to use the new host name (new_host_name).

If no options are specified, values in the /etc/rc.config.d/netconf file are initialized such that when the new root disk is first booted, the "set_parms initial" dialog menu is displayed. This allows you to enter the system host name and network parameters manually.

OPTIONS

-g new_dg

Specifies the name of the disk group for the new root disk. If this option is not used, the new root disk remains in the same disk group as the source disk.

-N

Provides a method of updating a current host for a new release of the HP-UX operating system.

The command attempts to use NFS to mount the root directory of the current root disk from which new_host_name was booted. This assumes that the specified host already exists and is accessible over the network. The root directory is temporarily mounted using the new_host_name:/ syntax. For this to work, the /etc/exports file on the target system must have been edited to contain an entry for /, and the exportfs command must have been run to give root permission to the host on which the vxchg_rootid command is to be invoked.

When the old root file system has been mounted, and the freshly cloned root file system has also been temporarily imported and mounted, system-specific files are copied from the old to the new root file system. The files that are copied include:

-R

Provides a method of obtaining and updating machine-specific information on a remote target host. When the new disk ID and disk group ID fields have been changed on the cloned disk, the command uses remsh to execute appropriate commands to find the new root disk as it is enumerated on the remote host. Once a match has been found, the name and hardware path of the new disk as it exists on the remote host are extracted. The disk name information is used to update the /stand/bootconf file with the correct value. The hardware path information is used with the setboot command to set the boot device in the target host's NVRAM.

The criteria for making the setboot changes are as follows:

• If the -v option was specified, the current primary and alternate boot device values are displayed.
• The hardware path of the new root on the remote host is set as the primary boot path.
• The hardware path of the current primary boot device is set as the alternate boot path.

As successful operation of remsh depends on having permission to access the remote host, vxchg_rootid executes a simple remsh command to test this before any configuration changes have been made. An entry for the host name of the maintenance server and the user running the command (such as root) must exist in the /.rhosts file on the remote host. See the hosts.equiv(4) manual page for further information.

-S

Starts an interactive Bourne shell when the new root file system has been temporarily mounted. This allows manual changes to be made to the configuration before it is booted on the new host. When the changes have been completed, exit the shell to allow the vxchg_rootid command to continue to completion. Immediately before starting the shell, a message is output to indicate the mount point of the temporarily mounted new root file system.

-s script_path

Runs the specified shell script after the new root file system has been temporarily mounted. This allows you to make any automated changes to the configuration files that are required. When the script exits, the vxchg_rootid command continues to completion if a 0 exit status is received, or aborts if a non-zero exit status is received.

If any command arguments are required to the script, place script_path and its arguments in quotes.

To allow operational control from the invoked shell script, the new host name and the temporary mount point of the new root file system are passed to the script as the last two arguments. Thus, the calling sequence for the invoked shell script is:


user_script script_arguments host_name mount_point 

For example, the calling sequence for the script, patch_db, which takes the internal arguments db_path and token would be:


patch_db db_path token newhost temp_mount

-v

Outputs verbose messages, including a time stamp, which indicates the major operations that are being performed.

ARGUMENTS

new_host_name

The host name of that target machine that is to inherit the newly cloned disk as its root disk when accessed via a SAN boot.

new_root_da

The disk access name (CTD name) of the freshly cloned root.

NOTES

The order in which any optional operations are completed is important as it may determine what can be accomplished in a script, or what must be done manually. This is the order of operations that are performed by vxchg_rootid:

1.

Perform sanity checks on the arguments and options specified. These checks include:

• Check that VERITAS Volume Manager is running.
• If the -s option was specified, check that the specified script_path exists.
• Check that the new_root_da argument refers to a real disk.
• Check that the disk group name on the freshly cloned disk is rootdg.
• Check that the rootdg disk group contains one disk.

2.

If the -N option was specified, attempt to mount the current root file system over NFS. If the target host does not grant access, the mount is unsuccessful and the vxchg_rootid command exits without performing any configuration operations.

3.

The main operations of the vxchg_rootid command are accomplished up to the unmounting of the file systems on the new root. These operations include:

• Patching the private region to provide unique disk ID and disk group ID values.
• Temporarily importing the new root disk clone, running fsck, and temporarily mounting the new root file system and all file systems under it.
• Initializing values in the /etc/rc.config.d/netconf file on the new root file system.
• Patching the new host ID into the /etc/vx/volboot file on the new root file system.
• Updating the /stand/bootconf file with the appropriate disk name.
• Updating the host name value in files in the /etc, /usr and /var directories.

4.

If the -N option was specified, system-specific files (listed in the DESCRIPTION section) are copied from the old to the new root file system.

5.

If the -s option was specified, the script file is executed.

6.

If the -S option was specified, start an interactive Bourne shell. This allows the contents of the new root file system and all of its subordinate file systems to be inspected, and any required manual operations to be performed. When the shell exits, the vxchg_rootid command runs to completion.

7.

All temporarily mounted file systems are unmounted.

8.

The new root disk clone is deported.

9.

The host ID value in the new root disk clone's private region is patched with the specified value.

10.

The vxchg_rootid command exits.

When the vxchg_rootid command is executed, messages similar to the following may be displayed on the system console:

These messages are the normal consequence of temporarily importing the cloned rootdg disk group and starting its volumes. The minor device numbers of the indicated volumes are changed, but only for the period that they are temporarily imported.

EXAMPLES

This example shows the vxchg_rootid command being invoked in its simpliest form:

The next example shows the vxchg_rootid command being invoked with the -s option. Note that quoted script arguments are also specified. In this case, the test_script script echoes each of the four arguments:

The next example is similar to the one above, except that the -N, -R and -v options are also specified. (The time stamp is usually placed on the line as each message, but this output has been edited for clarity.)

SEE ALSO

dd(1), remsh(1), setboot(1M), hosts.equiv(4)