|
|
|
|
|
vxdg - manage Veritas Volume Manager disk groups
vxdg [-g diskgroup] [-kp] [-f]
[-o {verify|override}] [-o overridessb}] adddisk
[ medianame=]accessname...
vxdg -g diskgroup [-f] addsite sitename
vxdg [-n newname] [-h newhostid] deport diskgroup...
vxdg [-o coordinator] [-o {verify|override}] destroy diskgroup...
vxdg -g diskgroup [-o force] detachsite sitename
vxdg [-g diskgroup] [-qa] free [ medianame...]
vxdg [-Cfst] [-n newname] [-o clearreserve]
[-o useclonedev={on|off}] [-o updateid]
[-o groupreserve=fencekey [-o verify]]
[-o noreonline] [-o selectcp=diskid]
[-o site=sitename] [-o tag=name] import diskgroup
vxdg [-T version] [-s] [-o coordinator={off|on}] [-o groupreserve=fence_key]
[-o {verify|override}] init groupname
[cds={off|on}] [minor=base-minor] [nconfig=config-copies] [nlog=log-copies]
[medianame=]accessname...
vxdg [-o {verify|override}] join sourcedg targetdg
vxdg [-q] [-o listreserve] list [diskgroup...]
vxdg [-g diskgroup] [-q] listclone
vxdg [-q] listmeta [diskgroup ...]
vxdg [-q] listtag [diskgroup ...]
vxdg [-o expand] listmove sourcedg targetdg object...
vxdg [-o expand] [-o {verify|override}] move
sourcedg targetdg object...
vxdg [-g diskgroup] [-q] nohotuse [ medianame...]
vxdg -g diskgroup [-o overridessb] reattachsite sitename
vxdg [-o {clean|remove}] recover diskgroup
vxdg [-g diskgroup] [-f] reminor
[diskgroup] new-base-minor
vxdg[-g diskgroup] [-k] repldisk
unassoc-medianame=spare-medianame...
vxdg [-g diskgroup] [-k] [-o {verify|override}] rmdisk
medianame...
vxdg -g diskgroup [-f] rmsite sitename
vxdg [-g diskgroup] rmtag name ...
vxdg -g diskgroup set attribute=value...
vxdg -g diskgroup set siteconsistent={on|off}
vxdg -g diskgroup set tagmeta={on|off} tag=name
[nconfig=config-copies] [nlog=log-copies]
vxdg [-g diskgroup] [-f] settag name[=value] ...
vxdg [-g diskgroup] [-q] spare [ medianame...]
vxdg [-Cft] [-o expand] [-o {verify|override}] split
sourcedg targetdg object...
vxdg [-T version] upgrade diskgroup
The vxdg utility performs basic administrative operations on disk groups. Operations include the creation of disk groups, the addition of disks to a disk group, disk group split/join, and disk group imports and deports.
Note
A license is necessary to use the Disk Group Split/Join feature.
The behavior of the vxdg utility depends upon the keyword specified as the first operand.
A diskgroup argument can be either a disk group name or a disk group ID. A groupname argument is a disk group name, not a disk group ID. An accessname argument refers to a system-dependent disk access name (also referred to as a disk device name), as stored in the root configuration by the vxdisk utility. A medianame argument is an administrative name used to define a disk within a disk group.
In releases of Veritas Volume Manager (VxVM) prior to 4.0, a system installed with VxVM was configured with a default disk group, rootdg, that had to contain at least one disk. By default, operations were directed to the rootdg disk group. From release 4.0 onward, VxVM can function without any disk group having been configured. Only when the first disk is placed under VxVM control must a disk group be configured. There is no longer a requirement that you name any disk group rootdg, and any such named disk group has no special properties.
The following sections describe reserved disk group names and the rules that commands use to determine which disk group to use if this is not specified.
The following disk group names are reserved, and cannot be used to name any disk groups that you create:
Specifies the boot disk group. This is an alias for the disk group that contains the volumes that are used to boot the system. VxVm sets bootdg to the appropriate disk group when the root disk is put under VxVM control. Otherwise, bootdg is set to nodg.
Caution: Do not attempt to change the value of bootdg. You may render your system unbootable.
Specifies the default disk group. This is an alias for the disk group name that should be assumed if the -g option is not specified to a command, or if the VXVM_DEFAULTDG environment variable is undefined. By default, defaultdg is set to nodg (that is, no disk group).
Specifies to an operation that no disk group has been defined. For example, if the root disk is not under VxVM control, bootdg is set to nodg.
If you have upgraded your system to VxVM 4.0, you may find it convenient to continue to configure a disk group named rootdg as the default disk group (defaultdg).
Note
There is no requirement that both defaultdg and bootdg refer to the same disk group, nor that either the default disk group or the boot disk group be named rootdg.
It is recommended that you use the -g option to specify a disk group to VxVM commands. If you do not specify the disk group, VxVM uses the following rules in order until it determines a disk group name:
Use the default disk group name that is specified by the environment variable VXVM_DEFAULTDG. This variable can also be set to one of the reserved system-wide disk group names: bootdg, defaultdg, or nodg. See the section System-Wide Reserved Disk Groups above for details. If this variable is undefined, the following rule is applied.
Use the disk group that has been assigned to the system-wide default disk group alias, defaultdg. Use the command vxdctl defaultdg diskgroup to change the name of the default disk group that is assigned to defaultdg. If this alias is undefined, the following rule is applied.
If the operation can be performed without requiring a disk group name (for example, an edit operation on disk access records), do so.
If none of these rules succeeds, the requested operation fails.
Caution: In releases of VxVM prior to 4.0, a subset of commands attempted to deduce the disk group by searching for the object name that was being operated upon by a command. This functionality is no longer supported. Scripts that rely on deducing the disk group from an object name may fail.
Adds the specified disk or disks to a disk group. The disk must not already be part of a disk group. The accessname component to a disk specification argument names a disk access record (essentially a device address specification) used to access the disk. If a medianame component is specified, it names the disk media record used to define the disk within the disk group. If no medianame component is specified, the disk media record is given the same name as the disk access record.
Adding a disk to a disk group causes the disk group's configuration to be copied onto the disk (if the disk has regions for configuration copies). Also, the disk is stamped with the system's host ID, as defined in the volboot file.
The -f option must be specified if the disk already has a disk group tag name set.
If the -k option is specified, the disk media name must represent a disk media record that was previously dissociated from its disk access record with -k rmdisk; otherwise, a new disk media record is created to represent the disk. With the -k option, plexes requiring recovery are flagged as stale.
Specifying the -p option with -k packs contiguous subdisks into one subdisk and aligns them consecutively on their respective disks.
In a cluster environment, adding a disk to a cluster-shared disk group fails if the disk is not physically accessible from all joined nodes in the cluster. If the addition is successful, the disk is stamped with the cluster ID and marked with the shared flag.
Note
EFI disks cannot be added to CDS-compatible disk groups.
The -o overridessb option is used to allow disks with inconsistent configuration copies due to a serial split brain condition to be added back to a disk group.
Prepares the specified disk group for site-based allocation. This operation must be performed at each site for which site-based allocation from a disk group is required. If siteconsistent is set to on, the disk group is also configured for consistency. The operation checks if the existing site-based volumes in the disk group meet the necessary allocation requirements, and fails if any of the volumes does not have a data plex at the site that is being added.
If the -f (force) option is specified, the operation does not fail, but instead mark all such volumes as not being able to participate in site-based allocation.
Displays the currently defined system-wide boot disk group that is aliased by the reserved name, bootdg. The boot disk group contains the volumes that are required to boot a system if its root disk is under VxVM control.
Displays the currently defined system-wide default disk group.
Note
You can use the command vxdctl defaultdg diskgroup to change the currently defined default disk group.
Disables access to the specified disk group. A disk group cannot be deported if any volumes in the disk group are currently open (for example, they are mounted as file systems, or are in use by an application such as a database). When a disk group is deported, the host ID stored on all disks in the disk group are cleared (unless a new host ID is specified with -h), so the disk group is not reimported automatically when the system is rebooted.
A disk group can be renamed on deport by specifying a new disk group name with -n newname. A lock can be assigned to an alternate host by specifying the host ID (see vxdctl(1M)) of the alternate host. This allows the disk group to be auto-imported when the alternate host reboots. For example, the -n and -h options can be combined to export a disk group to be used as a disk group for a new machine.
In a cluster environment, when a cluster-shared disk group is deported, the cluster ID and shared flag stored on all disks in the disk group are cleared, so the disk group is not imported automatically when the cluster is next started.
Trying to deport a shared disk group during a cluster reconfiguration fails.
Removes a disk group from the system. Use this option when a disk group and the information on the disks is no longer needed. This frees up space for use by other disk groups. A disk group cannot be destroyed if any volumes in the disk group are open (for example, they are mounted as file systems, or are in use by an application such as a database). vxdg destroy can be used only on imported disk groups.
The destroy operation clears the disk group name, and makes the disks available for use in other disk groups. However, the disk group ID is not cleared, so the disk group can be imported by specifying this value if the disk group has been accidentally destroyed (assuming that the disks have not already been added to another disk group).
The -o coordinator option is used to specify that the disk group is no longer to be used as the coordinator for the I/O fencing feature of Veritas Cluster Server (VCS).
Caution: Ensure that the coordinator disks are no longer in use before destroying the coordinator disk group.
Simulates site failure by detaching all devices in the specified disk group at the specified site.
Rewrites all disk on-disk structures managed by Veritas Volume Manager (VxVM) for the named disk groups. This rewrites all disk headers, configuration copies, and kernel log copies. Also, if any configuration copies were disabled (for example as a result of I/O failures), this command rewrites those configuration copies, and attempts to enable them.
Lists free space that can be used for allocating subdisks. If a disk group is specified, limit the output to the indicated disk group, otherwise list space from all disk groups. If disks are specified, by disk media name, the output is restricted to the indicated disks. A region of free space is identified by disk media name, a physical device tag, an offset relative to the beginning of the public region for the media, and a length.
If the -q option is specified, no header is printed describing output fields. If the -a option is specified, space on spare disks (which is not really allocatable) is listed in addition to regular free space; otherwise, space on spare disks is not listed.
Imports a disk group to make the specified disk group available on the local machine. This makes accessible any configuration information stored with the disk group, including any disk and volume configurations. The disk group to import is indicated by the diskgroup argument, which can be either an administrative disk group name or a disk group unique ID.
Usually, a disk group is not imported if some disks in the disk group cannot be found by the local host. The -f option can be used to force an import if, for example, one of the disks is currently unusable or inaccessible. A disk group can be imported successfully without specifying the -f option if all the disks are accessible that were visible when the disk group was last imported successfully. As using the -f option to force the import of an incomplete disk group counts as a successful import, an incomplete disk group may be imported subsequently without this option being specified.
Note
Be careful when using the -f option because it can import the same disk group twice from disjointed sets of disks. This can make the disk group inconsistent.
When a disk group is imported, all disks in the disk group are stamped with the host's host ID. Typically, a disk group cannot be imported if any of its disks are stamped with a non-matching host ID. This provides a sanity check in cases where disks can be accessed from more than one host.
If it is certain that a disk is not in use by another host (such as because a disk group was not cleanly deported), the -C option can be used to clear the existing host ID on all disks in the disk group as part of the import. A host ID can also be cleared using vxdisk clearimport.
Attempting to import a disk group with one of the reserved names (such as bootdg or nodg) or with the same name as an existing disk group fails. A new name can be given to the disk group on import using -n newname. If -n is used with the -t option, the stored name of the disk group remains unchanged, but the importing host knows the disk group under the new name; otherwise, the name change is permanent.
Typically, an imported disk group is reimported automatically when the system is rebooted, if at least some of the disks in the disk group remain accessible and usable. This can be disabled using the -t option, which causes the import to be persistent only until the system is rebooted.
As an example of the use of -n and -t, a disk group from one host can be imported on a second host, operations (such as making repairs to the root volume if this is under VxVM control) can be performed on the second host. The repaired disk group can then be returned to the originating host. To do this, identify the disk group ID for the disk group with vxdisk\ -s\ list, and import the disk group using -C to clear import locks, -t for a temporary name, and -n to specify an alternate name (to avoid collision with a similarly named disk group on the second host). After repair, deport the disk group using -h to restore the import lock from the first host.
In a cluster environment, use the -s option to import a disk group as cluster-sharable. This is only valid if the cluster is active on the host where the import takes place. Ensure that all the disks in a shared disk group are physically accessible by all hosts. A host which cannot access all the disks in a shared disk group cannot join the cluster.
The disks in a shared disk group are stamped with the ID of the cluster to which the hosts belong and are marked with the shared flag. When a host joins a cluster, it automatically imports disk groups whose disks are stamped with the cluster ID.
Trying to import a shared disk group during a cluster reconfiguration fails.
If the disks in a deported disk group have recently been scanned by vxconfigd, the -o noreonline option may be specified to avoid having to rescan all the disks to make them online again. This can greatly speed up the importing of a large disk group.
Caution: Only use the noreonline if you know that a re-online has recently been performed on the disks (for example, by running the vxdctl enable or vxdg import commands), and that the configuration of the disks has not changed since that time.
The -o selectcp option is used to specify a disk ID, diskid, for the disk that has the preferred configuration copy. This option is used to force the import of a disk group after a serial split brain error condition has been detected. (Note that this condition can happen for any disk group; not just for private or shared disk groups in a cluster.) To help in choosing a preferred configuration copy, you can use the vxsplitlines script to examine the IDs of the configuration copies on the disks. See the vxsplitlines(1M) manual page and the Veritas Volume Manager Administrator's Guide for more information.
The -o groupreserve=fence_key option specifies the I/O fencing key for a disk group. If the -o verify option is also specified, the import of a private disk group fails if the SCSI-3 PR keys have not been registered on all the paths to the disks. This ensures that a host is not fenced off while importing the disk group, or that two nodes cannot attempt to fence the disk group at the same time.
When importing a private disk group on which I/O fencing is enabled, the -o groupreserve option must be used to specify the I/O fencing key explicitly. The specified I/O fencing key, fence_key, must be no longer than 7 bytes.
When importing a shared disk group on which I/O fencing is enabled, there is no need to specify the key explicitly provided that the appropriate I/O fencing licenses have been installed, and cluster-wide fencing has been enabled. The I/O fencing key is automatically created on import.
The -o clearreserve option can be used to clear pre-existing reservations on the disks that comprise the disk group.
See the description of vxdg init for more information about I/O fencing.
If the udid_mismatch flag is set on a disk to indicate that the UDID does not correspond to that disk, and a disk with the same UDID already exists in the disk group, the disk is normally prevented from being imported to avoid a duplicate disk ID condition.
If udid_mismatch is set, but no disk with the same UDID already exists in the disk group, the disk can be imported but the udid_mismatch flag remains set.
If the -o tag option is specified, only those disks that are tagged with a matching tag name are imported into the disk group. This can result in the partial import of the disk group.
If the -o useclonedev=on option is specified, the import operation only imports devices that have the clone_disk or udid_mismatch flag set. into a disk group. This allows the import of cloned disks; for example, disks that have been created as hardware mirrors or snapshots of existing disks in the disk group. By default, the useclonedev option is set to off, which disallows the import of cloned disks. However, if a disk group contains only cloned disks, it is not necessary to specify the -o useclonedev=on option.
Note
Non-cloned and cloned disks cannot be imported in the same operation. If the disk group is already imported, use the -n option to specify a new disk group name for the clone disk group during the import operation.
If more than one cloned disk that are to be imported have the same unique disk identifier (UDID), the command fails unless the -o tag option is used to specify which disk is to be imported. (The vxdisk settag command can be used to assign a tag name and tag value to individual disks.) This may result in only a subset of the disks associated with the disk group being imported.
The -o updateid option can be used to generate identification values for the clone disks that are being imported.
The -o site option specifies that only devices from the named site are to be imported; devices from other sites are treated as detached. This can be used to simulate the failure of a another site during import. This can be combined with the -o tag option to specify a subset of suitably tagged disks that are to be imported.
Defines a new disk group composed of the indicated disks, identified by disk access names. This involves assigning an internal unique ID to the group, storing a pointer to that group in the root configuration, storing a reference to the group on all of the named disks that have a disk header, and storing a disk group record in the disk group's configuration database. At least one of the disks specified must have space allocated for a configuration copy.
An existing deported disk group may be imported under a different name if it has the same name as that specified for the new disk group.
The init cannot complete if a disk is being used by a disk group, deported or otherwise. If vxdg finds an unneeded disk group on the disk, it can be cleaned with the vxdisk -f init command. vxdg init can then be run again.
If a medianame is specified for use with a particular disk, then that medianame names the disk media record used to reference the disk within the disk group (for operations such as rmdisk and subdisk creations). If no medianame is specified, the disk media name defaults to accessname. See vxdisk(1M) for a discussion of definition and initialization of disk access records.
The following additional attributes may be specified to the init operation:
Specifies whether the disk group being created is compatible with the Cross-platform Data Sharing (CDS) feature. If not specified on the command line, the /etc/default/vxdg file is searched for a definition of this attribute. If no such definition is found, the value cds=on is assumed.
Note
EFI disks cannot be added to CDS-compatible disk groups.
Specifies whether a disk group is the coordinator for the I/O fencing feature of Veritas Cluster Server (VCS). The coordinator disk group must contain exactly 3 disks, and the addition or removal of disks is not permitted while this attribute is set to on.
Caution: Ensure that the coordinator disks are no longer in use before setting the value of this attribute to off.
Specifies a base volume device minor number for a disk group. Volume device numbers for a disk group are chosen to have minor numbers starting at this base minor number. Minor numbers can range up to 16,777,216, so if it is presumed that no more than 1000 volumes would ever be created in any one disk group, 16,777 different ranges of minor numbers are available for different disk groups.
Note
The minor number range for disk groups that support the Cross-platform Data Sharing (CDS) feature is restricted to 65535 for compatibility with other platforms.
A reasonably sized range should be left at the end for temporary device number remappings (in the event that two device numbers still conflict).
If no minor operand is specified on the init command line, then VxVM chooses a random number of at least 1000 that is a multiple of 1000, and yields a usable range of 1000 device numbers. This default number is chosen such that it does not overlap within a range of 1000 of any currently imported disk groups, and does not overlap any currently allocated volume device numbers.
Since disk groups can be moved between systems, it is desirable that device numbers used for volumes be allocated in separate ranges for each disk group. That way, you can choose ranges such that all disk groups in a group of machines can be moved around without causing device number collisions. Collisions may occur because VxVM stores device numbers in disk group configurations, so that the same numbers can be used after a reboot (which is necessary for use with NFS, which requires persistency of device numbers). If two systems use the same device numbers for a set of volumes, and if a disk group from one machine is moved to the other, VxVM may be forced to temporarily remap some devices.
Note
The default policy is likely to ensure that a small number of disk groups can be merged successfully between a set of machines. However, in cases where disk groups are merged automatically using fail-over mechanisms, the administrator should select ranges that are known to avoid overlap.
Trying to create a shared disk group during a cluster reconfiguration fails.
Note
Volumes in shared disk groups must have the same minor number on all nodes in the cluster. If there is a conflict when a node attempts to join the cluster, the join fails. In that case, the administrator should use the reminor operation on the joined node(s) to resolve the conflict. In a cluster where more than one node is joined, the administrator should use a base minor number which does not conflict on any node.
Specifies a base volume device minor number for a disk group. Volume device numbers for a disk group are chosen to have minor numbers starting at this base minor number. Minor numbers can range up to 16,777,216, so if it is presumed that no more than 1000 volumes would ever be created in any one disk group, 16,777 different ranges of minor numbers are available for different disk groups.
Specifies the number of configuration database copies and kernel log copies respectively that are maintained for a disk group.
The config-copies and log-copies values can be a decimal number (including 0 or -1), all or default. A value of all or -1 signifies that all configuration or log copies on all disks in the disk group are to be maintained. A value of default or 0 (this is also the default value) signifies that VxVM is to manage copies that are distributed in a reasonable pattern throughout the disks, controllers and enclosures on the system. Any other number signifies that a particular number of copies should be maintained (or all copies, if that number is larger than the number of available configuration or log copies on all disks).
When a specific number (or default) is requested, configuration copies are distributed across the enclosures on the system. The number of copies in each enclosure is proportional to the number of disks in that enclosure. With the default policy, at least one configuration and log copy is maintained for each enclosure. It is ensured that at least one configuration and log copy is maintained for each host controller connected to an enclosure. If this does not result in allocating at least 4 copies, additional copies are spread uniformly across enclosures.
Refer to vxdisk(1M) for more information on configuration and log copies, and for information on how to create them.
Note
If a policy other than all is used, some disks do not have up-to-date, online configuration and log copies. As a result, it is possible that some number of disk failures can leave a disk group unusable, even if some disks in the disk group remain usable. The default policy allocates a sufficient number of copies, in a sufficient spread of locations, that such a scenario is very unlikely to occur.
The -o groupreserve=fence_key option specifies the I/O fencing key for a disk group. The specified I/O fencing key, fence_key, must be no longer than 7 bytes.
To create the 8-byte SCSI-3 Persistent Reservation key, vxdg adds the character 'A' to the node ID (0 to number of nodes minus 1) of the host within the cluster to form the first byte, and uses the I/O fencing key for the last 7 bytes (padding with NULL characters as appropriate).
Note
The node ID is obtained from the vxfen driver. This driver must have been been installed and configured to allow I/O fencing to be used with disk groups.
See the description of vxdg import for more information about I/O fencing.
If a version is specified with the -T option, the disk group is initialized with that disk group version. This limits the operations that can be performed and features that can be used to those supported by the specified disk group version. This makes the disk group compatible with releases of VxVM that support that version. If no version is specified, the disk group is initialized with the highest versions supported by the release of VxVM currently running on the system. See the vxdg upgrade operation for more information.
In a cluster environment, the -s option defines a new disk group which is cluster-sharable while the cluster is active. It is the responsibility of the user to ensure that disks specified as members of a cluster-sharable disk group are physically accessible from the hosts that make up the cluster.
The disks in a shared disk group are stamped with the ID of the cluster to which the hosts belong and are marked with the shared flag. When a host joins a cluster, it automatically imports disk groups whose disks are stamped with the cluster ID.
Moves all objects from the imported source disk group, sourcedg, to the imported target disk group, targetdg. At the conclusion of the move, sourcedg is removed.
The source disk group and target disk group to be joined must both be either private or shared. If one disk group is private and the other is shared, deport and reimport the private disk group as shared before performing the join.
The -o verify and -o override options modify the default behavior of a move, split or join operation that includes disks from an EMC array. Usually, if the EMC license is present, the EMC disk compatibility check is performed for each disk that is involved in a move. If the compatibility check succeeds, the normal operation takes place. An internal check is made to ensure the configuration has not changed since the compatibility check was performed. If it was changed, the entire process is retried.
If -o verify is specified, the access names of the disks to be moved are returned but the operation does not take place.
If -o override is specified, the operation is performed without any EMC checking.
Lists the contents of disk groups. If no diskgroup arguments are specified, all disk groups are listed in an abbreviated one-line format. If diskgroup arguments are specified, a longer format is used to indicate the status of the disk group, and of the specified disk group configuration.
If the -q option is specified, no header is printed describing output fields. This option has no effect with the long formats generated with diskgroup arguments.
In a cluster environment, if the -s option is specified, all cluster-shared disk groups are listed in a one-line format. If diskgroup arguments are specified, -s has no effect.
You can use the -o listreserve option to discover if I/O fencing has been enabled for a disk group.
If a private disk group has been fenced off due to a reservation conflict, this is indicated by fencedoff being set in the flags field. This flag can be cleared by rebooting the host, or by deporting and then reimporting the disk group.
Displays a list of all objects, including all objects in hierarchies, that would move from the imported source disk group, sourcedg, to the imported target disk group, targetdg, as implied by the specified list of objects. The items in the specified object list must be top-level objects, disk media objects or disk access objects.
This command is used to confirm the validity and object content of a proposed move operation without actually moving any objects.
Displays all disks on which the clone_disk or udid_mismatch flags are set. If the -q option is specified, no header is printed describing output fields. If no disk group is specified using the -g option, the information is shown for all imported disk groups.
Displays the tagmeta values for the configuration database copies and kernel log copies. If the -q option is specified, no header is printed describing output fields. If no disk groups are specified as arguments, the information is shown for all imported disk groups.
Displays the tag names and tag values that are associated with the specified disk groups, or with all disk groups if no disk groups are specified as arguments. If the -q option is specified, no header is printed describing output fields.
Moves the specified objects together with their hierarchies from the imported source disk group, sourcedg, to the imported target disk group, targetdg.
The items in the object list must be top-level objects, disk media objects or disk access objects. The list must define a set of self-contained objects, unless the -o expand option is specified. (Self-contained means that the disks used by the selected objects should not contain any objects that are not selected for the move.) If the -o expand option is specified, the object set is expanded to be self-contained.
The source disk group and target disk group must both be either private or shared. If one disk group is private and the other is shared, deport and reimport the private disk group as shared before performing the move.
See vxdg join for a description of the usage of the -o override and -o verify options.
Lists free space that cannot be used by hot-relocation to replace failed subdisks. If a diskgroup is specified, the output is limited to the indicated diskgroup, otherwise nohotuse space from all disk groups is listed. If disks are specified by disk medianame, the output is restricted to the indicated disks. A region of nohotuse space is identified by disk medianame, a physical device tag, an offset relative to the beginning of the public region for the media, and a length.
The physical device tag is a reference that indicates which physical device the disk media is defined on. It appears as a truncated disk access name.
If the -q option is specified, no header is printed describing output fields.
Reattaches the devices in the specified disk group at the specified site. The -o overridessb option may be used to allow disks with inconsistent configuration copies due to a serial split brain condition to be added back to a disk group. Appropriate recovery procedures are initiated to resynchronize the data at the site.
Attempts to manually recover an incomplete move, split or join operation using either of the disk groups that was involved in the operation.
In the event that the recovery cannot complete the operation, the -o clean option clears the MOVE flags from the tutil0 fields of the objects in the disk group.
The -o remove option removes all objects marked with the MOVE flag from the disk group.
Changes the base minor number for a disk group, and renumbers all devices in the disk group to a range starting at that number. If the device for a volume is open, the old device number remains in effect until the system is rebooted or until the disk group is deported and re-imported. Also, if you close an open volume, the user can execute vxdg\ reminor again to cause the renumbering to take effect without rebooting or reimporting.
A new device number may also overlap with a temporary renumbering for a volume device. This also requires a reboot or reimport for the new device numbering to take effect. A temporary renumbering can happen in the following situations: when two volumes (for example, volumes in two different disk groups) share the same permanently assigned device number, in which case one of the volumes is renumbered temporarily to use an alternate device number; or when the persistent device number for a volume was changed, but the active device number could not be changed to match. The active number may be left unchanged after a persistent device number change either because the volume device was open, or because the new number was in use as the active device number for another volume.
vxdg fails if you try to use a range of numbers that is currently in use as a persistent (not a temporary) device number. You can force use of the number range by using the -f option. With -f, some device renumberings may not take effect until a reboot or a re-import (just as with open volumes). Also, if you force volumes in two disk groups to use the same device number, one of the volumes is temporarily renumbered on the next reboot. Which volume device is renumbered should be considered random. The only exception is when the system is booted from a root disk that is under VxVM control. In this case, the device numbers for the boot disk group take precedence over all others.
The -f option should be used only when swapping the device number ranges used by two or more disk groups. To swap the number ranges for two disk groups, you would use -f when renumbering the first disk group to use the range of the second disk group. Renumbering the second disk group to the first range does not require the use of -f.
Dissociates the DA record from the DM record named by spare-medianame, and reassociates it with the unassociated DM record named by unassoc-medianame. Both unassoc-medianame and spare-medianame must be members of the disk group named by the diskgroup argument. However, if the -k option is specified, the disk media records for the spare-medianame are retained, although in a removed state.
Removes the specified disk or disks from a disk group. The last disk cannot be removed from its disk group. It is not possible to remove the last disk containing a valid disk group configuration or log copy from its disk group.
Typically, the rmdisk operation fails if subdisk records point to the named disk media records. However, if the -k option is specified, the disk media records are kept, although in a removed state, and the subdisk records still point to them. The subdisks, and any plexes that refer to them, remain unusable until the disk is re-added using the -k option to the adddisk operation. Any volumes are disabled that become unusable because all plexes become unusable.
Removes the requirement for consistency from the specified disk group that had been configured for site-based allocation. However, a copy of the data remains present at each site, and this continues to be updated. If the site is detached or offline, the site-consistency requirement cannot be removed unless the -f (force) option is specified.
Removes the specified tag names from the disks in a disk group.
Changes disk group characteristics. Specify changes by entering arguments after the set keyword in the form attribute=value.
The following attributes may be set:
The activation mode of a disk group determines whether applications are permitted to read and write to volumes in the disk group.
The following are the valid activation modes and corresponding read/write capability for non-shared disk groups:
Volumes in the disk group are not available for read or write access.
Volumes in the disk group are available for read access only.
Volumes in the disk group are available for read and write access.
For a shared disk group, the activation mode is on a per-node basis. The following are the valid activation modes and corresponding read/write capability for shared disk groups:
The node has exclusive write access to volumes in the disk group. No other node in the cluster can activate the disk group for write access.
Volumes in the disk group are not available for read or write access.
The node has read access to volumes in the disk group. It has no write access and denies write access to all other nodes in the cluster.
The node has read access to volumes in the disk group, but no write access, However, other nodes can activate the disk group for write access.
The node has write access to volumes in the disk group. Other nodes can activate the disk group for shared write access.
Note
If you use the vxdg command to change the activation mode of a shared disk group, first change the activation mode to off before setting it to any other value.
The related attributes-value pairs, enable_activation=true and default_activation_mode=mode, can be used to enable and define a default activation mode for shared disk groups. These attributes can only be set by adding their definitions to the /etc/default/vxdg defaults file.
The node has write access to volumes in the disk group. Other nodes can activate the disk group for shared write access.
Specifies the alignment value for the disk group. Possible values are 1 (one block) or 8k (8KB). For a disk group to be compatible with the Cross-platform Data Sharing (CDS) feature, the alignment value must be set to 8k.
Specifies whether a disk group is compatible with the Cross-platform Data Sharing feature.
Specifies whether a disk group is the coordinator for the I/O fencing feature of Veritas Cluster Server (VCS). The coordinator disk group must contain exactly 3 disks, and the addition or removal of disks is not permitted while this attribute is set to on. If a disk fails, the attribute may temporarily be set to off to allow the number of disks to be restored to three.
Caution: Ensure that the coordinator disks are no longer in use before setting the value of this attribute to off.
Sets the disk group failure policy in the case that the master node loses connectivity to the configuration and log copies within a shared disk group. This attribute is ignored for private disk groups, and requires that the disk group version is 120 or greater. The following policies may be set:
The master node disables the disk group for all user or kernel-initiated transactions. First write and final close fail.
The master node panics instead of disabling the disk group if a log update fails for a user or kernel-initiated transaction (including first write or final close). If the failure to access the log copies is global, all nodes panic in turn as they become the master node.
Sets the disk group detach policy, which determines the way that unusable disks are detached in a shared disk group. This attribute is ignored for private disk groups. The following policies may be set:
For a shared disk group, if any node in the cluster reports a disk failure, the detach occurs in the entire cluster. An I/O error results if the disk was in the final active plex of a volume.
If a disk fails for a single node only, the I/O failure is confined to that node. If all nodes report a problem with the failed disk, the disk is detached throughout the cluster. An I/O error results if the disk was in the final active plex of a volume.
Specifies the maximum number of VxVM devices that are permitted in a disk group. This value must be a positive integer that is greater than the number of such devices that are currently configured in the disk group.
Specifies the maximum number of VxVM devices that are permitted in a disk group. This value must be a positive integer that is greater than the number of such devices that are currently configured in the disk group.
Specifies the number of configuration database copies and kernel log copies respectively that are maintained for a disk group.
For more information, see the descriptions under the init operation.
If set to on, specifies that the site consistency is to be enforced for a disk group.
If set to off, the site consistency requirement is removed.
Enables (on) or disables (off) the configuration copies and kernel log copies for disks that are tagged with the specified tag name. This ensures that a suitable number of configuration copies and kernel log copies exist on a set of tagged disks in agreement with any policies that have been set for the nconfig and nlog values.
The cds, default_activation_mode and enable_activation attribute values may be defined in the /etc/default/vxdg defaults file. Values that are defined in this file override the built-in default values, and persist across reboots of the system. Attribute values that are defined in the defaults file may themselves be overridden by values specified on the command line.
Sets or updates the tag names and optional tag values for all disks in a disk group. The tag name and tag value are strings of up to 128 characters. The string must not include space or tab characters.
The -f option must be specified if the tag name is already set on the disk.
Note
The tag names site, udid and vdid are reserved, and cannot be used.
Lists spare space that can be used for relocating subdisks during recovery. If a disk group is specified, the output is limited to the indicated disk group, otherwise spare space is listed from all disk groups. If disks are specified, by disk media name, the output is restricted to the indicated disks. A region of spare space is identified by disk media name, a physical device tag, an offset relative to the beginning of the public region for the media, and a length.
The physical device tag is a reference that indicates which physical device the disk media is defined on. It appears as a truncated disk access name.
If the -q option is specified, no header is printed describing output fields.
Moves the specified objects together with their hierarchies from the imported source disk group, sourcedg, to a newly created target disk group, targetdg.
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 may be imported under a different name if it has the same name as the target disk group (as is the case for the vxdg init command).
The items in the object list must be top-level objects, disk media objects or disk access objects. The list must define a set of self-contained objects, unless the -o expand option is specified. (Self-contained means that the disks used by the selected objects should not contain any objects that are not selected for the move.) If the -o expand option is specified, the object set is expanded to be self-contained.
The newly created target disk group is imported as shared if the source disk group is shared; otherwise, it is imported as private. The -C, -f, and -t options are import options for the new disk group. See the description of vxdg import for details of their use.
See vxdg join for a description of the usage of the -o override and -o verify options.
Upgrades the disk group to the latest Veritas Volume Manager version. By default, the disk group version is updated to the running version of VxVM. The -T option upgrades the disk group to a specified version. The following section lists each disk group version, the features it supports, and the Veritas Volume Manager release that introduced it. Note: Some Veritas Volume Manager versions are not available on all supported OS platforms.
Supports only the most basic volume management features of mirroring and simple striping. This format was introduced in VxVM Release 1.2. Starting with VxVM Release 3.0, disk groups of version 10 can be imported, but no operations can be performed on the objects it contains (for example, starting volumes or adding mirrors). The only operation supported is to upgrade the disk group to a later release.
Introduced support for RAID-5 Volumes, new-style stripes, recovery checkpointing, disk group configuration/klog copy limiting, and Dirty Region Logging. This version was introduced in VxVM Release 2.0 and is supported by all subsequent releases of VxVM.
Enabled support for the Oracle Resilvering Interface. This version was introduced in VxVM Release 2.2 and is supported by all subsequent releases of VxVM.
Support for Hot Relocation. Introduced in VxVM Release 2.3 and is supported by all subsequent releases of VxVM.
Support for Online Relayout, safe RAID-5 subdisk moves, Striped Mirrors, and RAID-5 Snapshots. Introduced in Release 3.0.
Non-Persistent FastResync, Veritas Volume Replicator (VVR) enhancements, and Unrelocate. Introduced in Release 3.1.
Veritas Volume Replicator (VVR) Enhancements. Introduced in Release 3.1.1.
Cluster support for Oracle Resilvering, disk group move, split and join, Device Discovery Layer (DDL), layered volume support in clusters, ordered allocation, OS independent Naming support, and Persistent FastResync. Introduced in Release 3.2.
Cross-platform Data Sharing (CDS), Device Discovery Layer (DDL) 2.0, disk group configuration backup and restore, elimination of rootdg as a special disk group, full-sized and space-optimized instant snapshots, Veritas Intelligent Storage Provisioning (ISP), volume sets (Multiple Device support for Veritas File System). Introduced in Release 4.0.
Automatic cluster-wide failback for A/P arrays, DMP co-existence with third-party drivers, migration of volumes to ISP, persistent DMP policies, shared disk group failure policy, support for EFI disks. Introduced in Release 4.1.
Veritas Volume Replicator (VVR) Enhancements. Introduced in Release 5.0.
Data migration, Remote Mirror, coordinator disk groups (used by VCS), linked volumes, snapshot LUN import. Introduced in Release 5.0.
To determine the version of a disk group, use the vxdg list diskgroup command.
Some environments provide guidelines to optimize VxVM's interaction with intelligent storage systems. If these guidelines are present, VxVM follows the guidelines when creating disk groups and adding disks to disk groups. By default, vxdg only allows disk groups to contain disks that conform with these guidelines. The following options change the behavior of vxdg:
Performs the disk group task and ignores any storage-specific guidelines. Overriding the guidelines is not recommended as it can result in incompatible objects, or objects that cannot be administered by VxVM.
Verifies that the specified disk group task can be performed without violating any storage-specific guidelines, but does not perform the task. If any guidelines are violated, vxdg exits with an error message.
Note
These options need a specific license. Without the license, vxdg ignores the specified option.
Refer to the vendor-specific documentation for more information on how intelligent storage systems can interact with VxVM.
In clusters that are configured using Veritas Cluster Server (VCS) as the cluster monitor, the I/O fencing feature uses the underlying hardware disk reservation mechanism to avoid the split brain problem.
Note
The SCSI-3 Persistent Reservation (PR) mechanism is currently supported for disk reservation and I/O fencing. This feature is enabled if the value of the scsi3_pr attribute has been set to on in the volboot file.
See the description of the vxdg import, init and list commands for information about the clearreserve, coordinator, groupreserve and listreserve options that are used with I/O fencing.
To import the disk group, mydg:
To display the free space in the disk group, mydg:
To deport the disk group, mydg:
To import the disk group, mydg, and rename it as newdg:
To move volumes, vol1 and vol2, from the disk group, olddg, to newdg:
vxdg move olddg newdg vol1 vol2
To split volumes, vol3 and vol4, from the disk group, olddg, to form a new disk group, mynewdg:
vxdg split olddg mynewdg vol3 vol4
To merge the contents of the disk groups, olddg with the disk group, testdg:
File containing VxVM configuration information.
Default attribute definitions file for the vxdg command.
vxcdsconvert(1M), vxconfigd(1M), vxdctl(1M), vxdisk(1M), vxintro(1M), vxplex(1M), vxprint(1M), vxvol(1M)