Veritas Volume Manager 5.0 Administrator's Guide (September 2006)

180 Creating and administering disk groups
Handling conflicting configuration copies
Note: Such a disk group may still not be importable by VxVM 4.0 on Linux with a pre-2.6
kernel if it would increase the number of minor numbers on the system that are assigned to
volumes to more than 4079, or if the number of available extended major numbers is
smaller than 15.
You can use the following command to discover the maximum number of volumes that
are supported by VxVM on a Linux host:
# cat /proc/sys/vxvm/vxio/vol_max_volumes
4079
See the vxdg(1M) manual page for more information.
Handling conflicting configuration copies
If an incomplete disk group is imported on several different systems, this can create
inconsistencies in the disk group configuration copies that you may need to resolve
manually. This section and following sections describe how such a condition can occur,
and how to correct it. (When the condition occurs in a cluster that has been split, it is
usually referred to as a serial split brain condition).
Note: The procedures given here require that the version number of the disk group is at
least 110.
Example of a serial split brain condition in a cluster
Note: This section presents an example of how a serial split brain condition might occur
for a shared disk group in a cluster. For more information about shared disk groups in
clusters, see “Administering cluster functionality” on page 387. Conflicts between
configuration copies can also occur for private disk groups in clustered and non-clustered
configurations where the disk groups have been partially imported on different systems.
The procedure in “Correcting conflicting configuration information” on page 184
describes how to correct such problems.
A campus cluster (also known as a stretch cluster or remote mirror configuration)
typically consists of a 2-node cluster where each component (server, switch and storage)
of the cluster exists in a separate building. Figure 4-1 illustrates a 2-node cluster with node
0, a fibre channel switch and disk enclosure enc0 in building A, and node 1, another
switch and enclosure enc1 in building B. The fibre channel connectivity is multiply
redundant to implement redundant-loop access between each node and each enclosure. As
usual, the two nodes are also linked by a redundant private network.