Reorganizing the Contents of Disk Groups

There are several circumstances under which you might want to reorganize the contents of your existing disk groups:

• To group volumes or disks differently as the needs of your organization change. For example, you might want to split disk groups to match the boundaries of separate departments, or to join disk groups when departments are merged.
• To reduce the size of a disk group's configuration database in the event that its private region is nearly full. This is a much simpler solution than the alternative of trying to grow the private region.
• To perform online maintenance and upgrading of fault-tolerant systems that can be split into separate hosts for this purpose, and then rejoined.
• To isolate volumes or disks from a disk group, and process them independently on the same host or on a different host. This allows you to implement off-host processing solutions for the purposes of backup or decision support. This is discussed further in Configuring Off-Host Processing.

You can use either the VERITAS Enterprise Administrator (VEA) or the vxdg command to reorganize your disk groups. For more information about using the graphical user interface, see the VERITAS Enterprise Administrator Getting Started manual and VEA online help. This section describes how to use the vxdg command.

The vxdg command provides the following operations for reorganizing disk groups:

• move---moves a self-contained set of VxVM objects between imported disk groups. This operation fails if it would remove all the disks from the source disk group. Volume states are preserved across the move. The move operation is illustrated in Disk Group Move Operation.

Disk Group Move Operation



Click the thumbnail above to view full-sized image.

• split---removes a self-contained set of VxVM objects from an imported disk group, and moves them to a newly created target disk group. This operation fails if it would remove all the disks from the source disk group, or if an imported disk group exists with the same name as the target disk group. An existing deported disk group is destroyed if it has the same name as the target disk group (as is the case for the vxdg init command). The split operation is illustrated in Disk Group Split Operation.

Disk Group Split Operation



Click the thumbnail above to view full-sized image.

• join---removes all VxVM objects from an imported disk group and moves them to an imported target disk group. The source disk group is removed when the join is complete. The join operation is illustrated in Disk Group Join Operation.

Disk Group Join Operation



Click the thumbnail above to view full-sized image.

These operations are performed on VxVM objects such as disks or top-level volumes, and include all component objects such as sub-volumes, plexes and subdisks. The objects to be moved must be self-contained, meaning that the disks that are moved must not contain any other objects that are not intended for the move.

If you specify one or more disks to be moved, all VxVM objects on the disks are moved. You can use the -o expand option to ensure that vxdg moves all disks on which the specified objects are configured. Take care when doing this as the result may not always be what you expect. You can use the listmove operation with vxdg to help you establish what is the self-contained set of objects that corresponds to a specified set of objects.

If the system crashes or a hardware subsystem fails, VxVM attempts to complete or reverse an incomplete disk group reconfiguration when the system is restarted or the hardware subsystem is repaired, depending on how far the reconfiguration had progressed. If one of the disk groups is no longer available because it has been imported by another host or because it no longer exists, you must recover the disk group manually as described in the section "Recovery from Incomplete Disk Group Moves" in the chapter "Recovery from Hardware Failure" of the VERITAS Volume Manager Troubleshooting Guide.

Limitations of Disk Group Split and Join

The disk group split and join feature has the following limitations:

• Disk groups involved in a move, split or join must be version 90 or greater. See Upgrading a Disk Group for more information on disk group versions.
• The reconfiguration must involve an integral number of physical disks.
• Objects to be moved must not contain open volumes.
• Disks cannot be moved between CDS and non-CDS compatible disk groups.
• Moved volumes are initially disabled following a disk group move, split or join. Use the vxrecover -m and vxvol startall commands to recover and restart the volumes.
• Data change objects (DCOs) and snap objects that have been dissociated by Persistent FastResync cannot be moved between disk groups.
• VERITAS Volume Replicator (VVR) objects cannot be moved between disk groups.
• For a disk group move to succeed, the source disk group must contain at least one disk that can store copies of the configuration database after the move.
• For a disk group split to succeed, both the source and target disk groups must contain at least one disk that can store copies of the configuration database after the split.
• For a disk group move or join to succeed, the configuration database in the target disk group must be able to accommodate information about all the objects in the enlarged disk group.
• Splitting or moving a volume into a different disk group changes the volume's record ID.
• The operation can only be performed on the master node of a cluster if either the source disk group or the target disk group is shared.
• In a cluster environment, disk groups involved in a move or join must both be private or must both be shared.
• When used with objects that have been created using the VERITAS Intelligent Storage Provisioning (ISP) feature, only complete storage pools may be split or moved from a disk group. Individual objects such as application volumes within storage pools may not be split or moved. See the VERITAS Storage Foundation Intelligent Storage Provisioning Administrator's Guide for a description of ISP and storage pools.
• If a cache object or volume set that is to be split or moved uses ISP volumes, the storage pool that contains these volumes must also be specified.

The following sections describe how to use the vxdg command to reorganize disk groups. For more information about the vxdg command, see the vxdg(1M) manual page.

Listing Objects Potentially Affected by a Move

To display the VxVM objects that would be moved for a specified list of objects, use the following command:

The following example lists the objects that would be affected by moving volume vol1 from disk group mydg to newdg:

However, the following command produces an error because only a part of the volume vol1 is configured on the disk mydg01:

Specifying the -o expand option, as shown below, ensures that the list of objects to be moved includes the other disks (in this case, mydg05) that are configured in vol1:

Moving DCO Volumes Between Disk Groups

When you move the parent volume (such as a snapshot volume) to a different disk group, its DCO volume must accompany it. If you use the vxassist addlog, vxmake or vxdco commands to set up a DCO for a volume, you must ensure that the disks that contain the plexes of the DCO volume accompany their parent volume during the move. You can use the vxprint command on a volume to examine the configuration of its associated DCO volume.

If you use the vxassist command or the VERITAS Enterprise Administrator (VEA) to create both a volume and its DCO, or the vxsnap prepare command to add a DCO to a volume, the DCO plexes are automatically placed on different disks from the data plexes of the parent volume. In previous releases, version 0 DCO plexes were placed on the same disks as the data plexes for convenience when performing disk group split and move operations. As version 20 DCOs support dirty region logging (DRL) in addition to Persistent FastResync, it is preferable for the DCO plexes to be separated from the data plexes. This improves the performance of I/O from/to the volume, and provides resilience for the DRL logs.

Examples of Disk Groups That Can and Cannot be Split illustrates some instances in which it is not be possible to split a disk group because of the location of the DCO plexes on the disks of the disk group. For more information about relocating DCO plexes, see Specifying Storage for Version 0 DCO Plexes and Specifying Storage for Version 20 DCO Plexes.

For more information about the layout of DCO volumes and their use with volume snapshots, see and FastResync. For more information about the administration of volume snapshots, see Volume Snapshots and Administering Volume Snapshots.

Examples of Disk Groups That Can and Cannot be Split

Click the thumbnail above to view full-sized image.

Moving Objects Between Disk Groups

To move a self-contained set of VxVM objects from an imported source disk group to an imported target disk group, use the following command:

The -o expand option ensures that the objects that are actually moved include all other disks containing subdisks that are associated with the specified objects or with objects that they contain.

The default behavior of vxdg when moving licensed disks in an EMC array is to perform an EMC disk compatibility check for each disk involved in the move. If the compatibility checks succeed, the move takes place. vxdg then checks again to ensure that the configuration has not changed since it performed the compatibility check. If the configuration has changed, vxdg attempts to perform the entire move again.

The -o override option enables the move to take place without any EMC checking.

The -o verify option returns the access names of the disks that would be moved but does not perform the move.

See Moving Objects Between Disk Groups for information on how to move objects between disk groups in a cluster.

For example, the following output from vxprint shows the contents of disk groups rootdg and mydg:

The following command moves the self-contained set of objects implied by specifying disk mydg01 from disk group mydg to rootdg:

The moved volumes are initially disabled following the move. Use the following commands to recover and restart the volumes in the target disk group:

The output from vxprint after the move shows that not only mydg01 but also volume vol1 and mydg05 have moved to rootdg, leaving only mydg07 and mydg08 in disk group mydg:

The following commands would also achieve the same result:

Splitting Disk Groups

To remove a self-contained set of VxVM objects from an imported source disk group to a new target disk group, use the following command:

For a description of the -o expand, -o override, and -o verify options, see Moving Objects Between Disk Groups.

See Splitting Disk Groups for more information on splitting shared disk groups in clusters.

For example, the following output from vxprint shows the contents of disk group rootdg:

The following command removes disks rootdg07 and rootdg08 from rootdg to form a new disk group, mydg:

The moved volumes are initially disabled following the split. Use the following commands to recover and restart the volumes in the new target disk group:

The output from vxprint after the split shows the new disk group, mydg:

Joining Disk Groups

To remove all VxVM objects from an imported source disk group to an imported target disk group, use the following command:

For a description of the -o override and -o verify options, see Moving Objects Between Disk Groups.

See Joining Disk Groups for information on joining disk groups in a cluster.

For example, the following output from vxprint shows the contents of the disk group rootdg and mydg:

The following command joins disk group mydg to rootdg:

The moved volumes are initially disabled following the join. Use the following commands to recover and restart the volumes in the target disk group:

The output from vxprint after the join shows that disk group mydg has been removed: