Reorganizing the Contents of Disk Groups




	NOTE: You may need an additional license to use this feature.

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 implement off-host processing solutions for the purposes of backup or decision support in a cluster environment. This is discussed further in Chapter 11 “Configuring Off-Host Processing”.

You can use either the VERITAS Volume Manager Storage Administrator (VMSA) or the vxdg command to reorganize your disk groups. For more information about using VMSA, see the VERITAS Volume Manager Storage Administrator Administrator's Guide. 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 Figure 4-1 “Disk Group Move Operation” below.
Figure 4-1 Disk Group Move Operation
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 Figure 4-2 “Disk Group Split Operation” below.
Figure 4-2 Disk Group Split Operation
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 Figure 4-3 “Disk Group Join Operation” below.
Figure 4-3 Disk Group Join Operation

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 are the self-contained set of objects that correspond to a specified set of objects.




	CAUTION: Before moving volumes between disk groups, stop all applications that are accessing the volumes, and unmount all file systems that are configured in the volumes.

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.

The disk group move, 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.
Moved volumes are initially disabled following a disk group move, split or join. If required, use either vxrecover -m or vxvol startall to 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.

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:

# vxdg [-o expand] listmove sourcedg targetdg object...

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

# vxdg listmove dg1 rootdg vol1
disk01 c0t1d0 disk05 c1t96d0 vol1 vol1-01 vol1-02 disk01-01 disk05-01

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

# vxdg listmove dg1 rootdg disk01
vxvm:vxdg: ERROR: vxdg listmove dg1 rootdg failed
vxvm:vxdg: ERROR: disk05 : Disk not moving, but subdisks on it are

Specifying the -o expand option ensures that the list of objects encompasses other disks (in this case, disk05) that contain subdisks from vol1.

# vxdg -o expand listmove dg1 rootdg disk01
disk01 c0t1d0 disk05 c1t96d0 vol1 vol1-01 vol1-02 disk01-01 disk05-01




	CAUTION: If you use the `vxassist` command or the VMSA to create a volume, or to enable Persistent FastResync (DCO logging) on a volume, the DCO log plexes are automatically placed on the same disks as the data plexes of the parent volume. When you move the parent volume (such as a snapshot volume) to a different disk group, this ensures that the DCO log volume automatically accompanies it. If you use the `vxmake` and `vxdco` commands to set up DCO logging, you must ensure that the disks that contain the plexes of the DCO log volume accompany their parent volume during the move. Use the `vxprint` command on a volume to examine the configuration of its associated DCO log volume.

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:

# vxdg [-o expand] [-o override|verify] move sourcedg targetdg \
    object ...

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 a 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 dg1:

# vxprint
Disk group: rootdg
TY NAME     ASSOC     KSTATE   LENGTH   PLOFFS STATE TUTIL0 PUTIL0
dg rootdg   rootdg    -        -        -      -     -      -
dm disk02   c1t97d0   -        17678493 -      -     -      -
dm disk03   c1t112d0  -        17678493 -      -     -      -
dm disk04   c1t114d0  -        17678493 -      -     -      -
dm disk06   c1t98d0   -        17678493 -      -     -      -

Disk group: dg1
TY NAME     ASSOC     KSTATE   LENGTH   PLOFFS STATE TUTIL0 PUTIL0
dg dg1      dg1       -        -        -      -     -      -
dm disk01   c0t1d0    -        17678493 -      -     -      -
dm disk05   c1t96d0   -        17678493 -      -     -      -
dm disk07   c1t99d0   -        17678493 -      -     -      -
dm disk08   c1t100d0  -        17678493 -      -     -      -
v  vol1     fsgen     ENABLED  2048     -      ACTIVE-      -
pl vol1-01  vol1      ENABLED  3591     -      ACTIVE-      -
sd disk01-01vol1-01   ENABLED  3591     0      -     -      -
pl vol1-02  vol1      ENABLED  3591     -      ACTIVE-      -
sd disk05-01vol1-02   ENABLED  3591     0      -     -      -

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

# vxdg -o expand move dg1 rootdg disk01

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

# vxrecover -g targetdg -m [volume ...]
# vxvol -g targetdg startall

The output from vxprint after the move shows that not only disk01 but also volume vol1 and disk05 have moved to rootdg, leaving only disk07 and disk08 in disk group dg1:

# vxprint
Disk group: rootdg
TY NAME     ASSOC     KSTATE   LENGTH   PLOFFS STATE TUTIL0 PUTIL0
dg rootdg   rootdg    -        -        -      -     -      -
dm disk01   c0t1d0    -        17678493 -      -     -      -
dm disk02   c1t97d0   -        17678493 -      -     -      -
dm disk03   c1t112d0  -        17678493 -      -     -      -
dm disk04   c1t114d0  -        17678493 -      -     -      -
dm disk05   c1t96d0   -        17678493 -      -     -      -
dm disk06   c1t98d0   -        17678493 -      -     -      -
v  vol1     fsgen     ENABLED  2048     -      ACTIVE-      -
pl vol1-01  vol1      ENABLED  3591     -      ACTIVE-      -
sd disk01-01vol1-01   ENABLED  3591     0      -     -      -
pl vol1-02  vol1      ENABLED  3591     -      ACTIVE-      -
sd disk05-01vol1-02   ENABLED  3591     0      -     -      -

Disk group: dg1
TY NAME     ASSOC     KSTATE   LENGTH   PLOFFS STATE TUTIL0 PUTIL0
dg dg1      dg1       -        -        -      -     -      -
dm disk07   c1t99d0   -        17678493 -      -     -      -
dm disk08   c1t100d0  -        17678493 -      -     -      -

The following commands would also achieve the same result:

# vxdg move dg1 rootdg disk01 disk05
# vxdg move dg1 rootdg vol1

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:

# vxdg [-o expand] [-o override|verify] split sourcedg targetdg \
    object ...

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:

# vxprint
Disk group: rootdg
TY NAME     ASSOC     KSTATE   LENGTH   PLOFFS STATE TUTIL0 PUTIL0
dg rootdg   rootdg    -        -        -      -     -      -
dm disk01   c0t1d0    -        17678493 -      -     -          -
dm disk02   c1t97d0   -        17678493 -      -     -          -
dm disk03   c1t112d0  -        17678493 -      -     -          -
dm disk04   c1t114d0  -        17678493 -      -     -          -
dm disk05   c1t96d0   -        17678493 -      -     -          -
dm disk06   c1t98d0   -        17678493 -      -     -          -
dm disk07   c1t99d0   -        17678493 -      -     -          -
dm disk08   c1t100d0  -        17678493 -      -     -          -
v  vol1     fsgen     ENABLED  2048     -      ACTIVE-          -
pl vol1-01  vol1      ENABLED  3591     -      ACTIVE-          -
sd disk01-01vol1-01   ENABLED  3591     0      -     -          -
pl vol1-02  vol1      ENABLED  3591     -      ACTIVE-          -
sd disk05-01vol1-02   ENABLED  3591     0      -     -          -

The following command removes disks disk07 and disk08 from rootdg to form a new disk group, dg1:

# vxdg -o expand split rootdg dg1 disk07 disk08

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

# vxrecover -g targetdg -m [volume ...]
# vxvol -g targetdg startall

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

# vxprint
Disk group: rootdg
TY NAME     ASSOC     KSTATE   LENGTH   PLOFFS STATE TUTIL0 PUTIL0
dg rootdg   rootdg    -        -        -      -     -      -
dm disk01   c0t1d0    -        17678493 -      -     -      -
dm disk02   c1t97d0   -        17678493 -      -     -      -
dm disk03   c1t112d0  -        17678493 -      -     -      -
dm disk04   c1t114d0  -        17678493 -      -     -      -
dm disk05   c1t96d0   -        17678493 -      -     -      -
dm disk06   c1t98d0   -        17678493 -      -     -      -
v  vol1     fsgen     ENABLED  2048     -      ACTIVE-      -
pl vol1-01  vol1      ENABLED  3591     -      ACTIVE-      -
sd disk01-01vol1-01   ENABLED  3591     0      -     -      -
pl vol1-02  vol1      ENABLED  3591     -      ACTIVE-      -
sd disk05-01vol1-02   ENABLED  3591     0      -     -      -

Disk group: dg1
TY NAME     ASSOC     KSTATE   LENGTH   PLOFFS STATE TUTIL0 PUTIL0
dg dg1      dg1       -        -        -      -     -      -
dm disk07   c1t99d0   -        17678493 -      -     -      -
dm disk08   c1t100d0  -        17678493 -      -     -      -

Joining Disk Groups

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

# vxdg [-o override|verify] join sourcedg targetdg




	NOTE: You cannot specify `rootdg` as the source disk group for a `join` operation.

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 dg1:

# vxprint
Disk group: rootdg
TY NAME     ASSOC     KSTATE   LENGTH   PLOFFS STATE TUTIL0 PUTIL0
dg rootdg   rootdg    -        -        -      -     -      -
dm disk01   c0t1d0    -        17678493 -      -     -      -
dm disk02   c1t97d0   -        17678493 -      -     -      -
dm disk03   c1t112d0  -        17678493 -      -     -      -
dm disk04   c1t114d0  -        17678493 -      -     -      -
dm disk07   c1t99d0   -        17678493 -      -     -      -
dm disk08   c1t100d0  -        17678493 -      -     -      -

Disk group: dg1
TY NAME     ASSOC     KSTATE   LENGTH   PLOFFS STATE TUTIL0 PUTIL0
dg dg1      dg1       -        -        -      -     -      -
dm disk05   c1t96d0   -        17678493 -      -     -      -
dm disk06   c1t98d0   -        17678493 -      -     -      -
v  vol1     fsgen     ENABLED  2048     -      ACTIVE-      -
pl vol1-01  vol1      ENABLED  3591     -      ACTIVE-      -
sd disk01-01vol1-01   ENABLED  3591     0      -     -      -
pl vol1-02  vol1      ENABLED  3591     -      ACTIVE-      -
sd disk05-01vol1-02   ENABLED  3591     0      -     -      -

The following command joins disk group dg1 to rootdg:

# vxdg join dg1 rootdg

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

# vxrecover -g targetdg -m [volume ...]
# vxvol -g targetdg startall

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

# vxprint
Disk group: rootdg
TY NAME     ASSOC     KSTATE   LENGTH   PLOFFS STATE TUTIL0 PUTIL0
dg rootdg   rootdg    -        -        -      -     -          -
dm disk01   c0t1d0    -        17678493 -      -     -          -
dm disk02   c1t97d0   -        17678493 -      -     -          -
dm disk03   c1t112d0  -        17678493 -      -     -          -
dm disk04   c1t114d0  -        17678493 -      -     -          -
dm disk05   c1t96d0   -        17678493 -      -     -          -
dm disk06   c1t98d0   -        17678493 -      -     -          -
dm disk07   c1t99d0   -        17678493 -      -     -          -
dm disk08   c1t100d0  -        17678493 -      -     -          -
v  vol1     fsgen     ENABLED  2048     -      ACTIVE-          -
pl vol1-01  vol1      ENABLED  3591     -      ACTIVE-          -
sd disk01-01vol1-01   ENABLED  3591     0      -     -          -
pl vol1-02  vol1      ENABLED  3591     -      ACTIVE-          -
sd disk05-01vol1-02   ENABLED  3591     0      -     -          -

Reorganizing the Contents of Disk Groups

Technical documentation

» Table of Contents

» Glossary

» Index

Listing Objects Potentially Affected by a Move

Moving Objects Between Disk Groups

Splitting Disk Groups

Joining Disk Groups