Veritas InfoScale™ 7.3.1 Troubleshooting Guide - Solaris

To perform the precommit operation

• Use the following command to perform a precommit analysis of the state of the disk group configuration, and to reinstall the disk headers where these have become corrupted:

  # /etc/vx/bin/vxconfigrestore -p [-l directory] \
    {diskgroup | dgid}

  The disk group can be specified either by name or by ID.

  The -l option allows you to specify a directory for the location of the backup configuration files other than the default location, /etc/vx/cbr/bk.

  See Backing up a disk group configuration.

To specify that the disk headers are not to be reinstalled

• Type the following command:

  # /etc/vx/bin/vxconfigrestore -n [-l directory] \
    {diskgroup | dgid}

  At the precommit stage, you can use the vxprint command to examine the configuration that the restored disk group will have. You can choose to proceed to commit the changes and restore the disk group configuration. Alternatively, you can cancel the restoration before any permanent changes have been made.

To abandon restoration at the precommit stage

• Type the following command:

  # /etc/vx/bin/vxconfigrestore -d [-l directory] \
    {diskgroup | dgid}

To perform the commit operation

• To commit the changes that are required to restore the disk group configuration, use the following command:

  # /etc/vx/bin/vxconfigrestore -c [-l directory] \
    {diskgroup | dgid}
  

  Note:

  Between the precommit and commit state, any operation that results in change in diskgroup configuration should not be attempted. This may lead to unexpected behavior. User should either abandon the restoration or commit the operation.

  If no disk headers are reinstalled, the configuration copies in the disks' private regions are updated from the latest binary copy of the configuration that was saved for the disk group.

  If any of the disk headers are reinstalled, a saved copy of the disks' attributes is used to recreate their private and public regions. These disks are also assigned new disk IDs. The VxVM objects within the disk group are then recreated using the backup configuration records for the disk group. This process also has the effect of creating new configuration copies in the disk group.

  Volumes are synchronized in the background. For large volume configurations, it may take some time to perform the synchronization. You can use the vxtask -l list command to monitor the progress of this operation.

  Disks that are in use or whose layout has been changed are excluded from the restoration process.

To make the disk group shared

1. Deport the disk group:

   # vxdg deport dg_name

2. Import the disk group as shared:

   # vxdg -s import dg_name