VERITAS Volume Manager 3.5 Release Notes (August 2003)

VERITAS Volume Manager™ HP-UX 11i v2 Release Notes
Patches and Fixes in This Version
Chapter 134
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.