VERITAS Volume Manager 3.5 Release Notes (August 2002)

Chapter 1
VERITAS Volume Manager™ Release Notes
Patches and Fixes in This Version
25
accessible to the host. If the administrator or system software wants to privately use the same disk group
from another host, the host that already has the disk group imported (importing host) must deport (give up
access to) the disk group. Once deported, the disk group can be imported by another host.
If two hosts are allowed to access a disk group concurrently without proper synchronization, such as that
provided by the Oracle Parallel Server, the configuration of the disk group, and possibly the contents of
volumes, can be corrupted. Similar corruption can also occur if a file system or database on a raw disk
partition is accessed concurrently by two hosts, so this is not a problem limited to Volume Manager.
Import Lock When a host in a non-clustered environment imports a disk group, an import lock is written on
all disks in that disk group. The import lock is cleared when the host deports the disk group. The presence of
the import lock prevents other hosts from importing the disk group until the importing host has deported the
disk group.
Specifically, when a host imports a disk group, the import normally fails if any disks within the disk group
appear to be locked by another host. This allows automatic re-importing of disk groups after a reboot
(autoimporting) and prevents imports by another host, even while the first host is shut down. If the importing
host is shut down without deporting the disk group, the disk group can only be imported by another host by
clearing the host ID lock first (discussed later).
The import lock contains a host ID (in Volume Manager, this is the host name) reference to identify the
importing host and enforce the lock. Problems can therefore arise if two hosts have the same host ID.
NOTE Since Volume Manager uses the host name as the host ID (by default), it is advisable to change
the host name of one machine if another machine shares its host name. To change the host
name, use the vxdctl hostid new_hostname command.
Failover The import locking scheme works well in an environment where disk groups are not normally
shifted from one system to another. However, consider a setup where two hosts, Node A and Node B, can
access the drives of a disk group. The disk group is first imported by Node A, but the administrator wants to
access the disk group from Node B if Node A crashes. This kind of scenario (failover) can be used to provide
manual high availability to data, where the failure of one node does not prevent access to data. Failover can
be combined with a “high availability” monitor to provide automatic high availability to data: when Node B
detects that Node A has crashed or shut down, Node B imports (fails over) the disk group to provide access to
the volumes.
Volume Manager can support failover, but it relies on the administrator or on an external high-availability
monitor to ensure that the first system is shut down or unavailable before the disk group is imported to
another system. For details on how to clear locks and force an import, see the vxdg(1M) manual page and the
section on moving disk groups between systems in the VERITAS Volume Manager Administrator’s Guide.
Corruption of Disk Group Configuration If vxdg import is used with -C (clears locks) and/or -f (forces
import) to import a disk group that is still in use from another host, disk group configuration corruption is
likely to occur. Volume content corruption is also likely if a file system or database is started on the imported
volumes before the other host crashes or shuts down.
If this kind of corruption occurs, you must probably rebuild your configuration from scratch and reload all
volumes in the disk group from a backup. To backup and rebuild the configuration, if nothing has changed,
use vxprint -mspvd and store the output which can be fed to vxmake to restore the layouts. There are
typically numerous configuration copies for each disk group, but corruption nearly always affects all
configuration copies, so redundancy does not help in this case.
Disk group configuration corruption usually shows up as missing or duplicate records in the configuration
databases. This can result in a variety of vxconfigd error messages, including errors such as: