# man vxdg Reformatting page. Wait... done Maintenance Commands vxdg(1M) NAME vxdg - manage Volume Manager disk groups SYNOPSIS vxdg [ -g diskgroup ] [ -kp ] adddisk [ medianame=] accessname... vxdg [ -n newname ] [ -h newhostid ] deport diskgroup... vxdg destroy diskgroup... vxdg flush [ diskgroup...] vxdg [ -g diskgroup ] [ -qa ] free [ medianame...] vxdg [ -Cfst ] [ -n newname ] import diskgroup vxdg [ -T version ] [ -s ] init groupname [ nconfig=config-copies ] [ nlog=log-copies ] [ minor=base-minor ] [ medianame =] accessname... vxdg [ -q ] list [ diskgroup...] vxdg [ -g diskgroup ] [ -f ] reminor [ diskgroup ] new-base-minor vxdg [-g diskgroup ] [-k ] repldisk unassoc-medianame=spare-medianame... vxdg [ -g diskgroup ] [ -k ] rmdisk medianame... vxdg [ -g diskgroup ] [ -q ] spare [ medianame...] vxdg [ -T version ] upgrade diskgroup DESCRIPTION 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, and disk group imports and deports. 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. If the slice number extension in the disk access record name is not included in the accessname, s2 is assumed by default. If any other slice is required then it should be included in the accessname (as in c2t1d0s2). A medianame argument is an administrative name VxVM 3.0 Last change: 11 Dec 1998 1 Maintenance Commands vxdg(1M) used to define a disk within a disk group. KEYWORDS vxdg adddisk Add the specified disk(s) to a disk group (rootdg by default). 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, then it names the disk media record used to define the disk within the disk group. If no medianame component is specified, then the disk media record will have 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. If the -k flag is specified, then 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 will be created to represent the disk. With the -k option, plexes requiring recovery will be flagged as stale. Specifying the -p flag with -k packs contiguous subdisks into one subdisk and aligns them consecu- tively on their respective disks. Use the -p option when adding a root encapsulated disk or it may not boot correctly. In Cluster Volume Manager, adding a disk to a cluster-shared disk group will fail 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. vxdg deport Disable access to the specified disk group. A disk group cannot be deported if any volumes in the disk group are currently open. When a disk group is deported, the host ID stored on all disks in the disk group will be cleared (unless a new host ID is specified with -h), so the disk group will not be reimported automatically when the sys- tem is rebooted. VxVM 3.0 Last change: 11 Dec 1998 2 Maintenance Commands vxdg(1M) A disk group can be renamed on deport by specify- ing 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 the rootdg disk group for a new machine. In Cluster Volume Manager, 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 will fail. vxdg destroy Removes a diskgroup 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. vxdg destroy can be used only on imported disk groups. vxdg flush Rewrite all disk on-disk structures managed by the Volume Manager 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 will rewrite those configura- tion copies and attempt to enable them. vxdg free List 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 speci- fied, by disk media name, then restrict the output 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. The physical device tag is a reference that indi- cates which physical device the disk media is defined on. It appears as a truncated disk access name. If a particular physical device is split into several Volume Manager disk objects, then the VxVM 3.0 Last change: 11 Dec 1998 3 Maintenance Commands vxdg(1M) device tag for each Volume Manager disk object will be the same. Device tags can be compared to identify space that is on the same or on different physical disks. If the -q option is specified, then no header is printed describing output fields. If the -a option is specified, then 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. vxdg import Import a disk group to make the specified disk group available on the local machine. This will make any configuration information stored with the disk group accessible, 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. Normally, a disk group will not be 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. Note: Care must be taken when using the -f flag, since it can cause the same disk group to be imported twice from disjoint sets of disks, caus- ing the disk group to become inconsistent. When a disk group is imported, all disks in the disk group are stamped with the host's host ID. Normally, 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), then 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. A new name can be given to the disk group on import using -n newname. If -n is used with the -t option, then the stored name of the disk group will remain unchanged, but the disk group will be known to the importing host under the new name; VxVM 3.0 Last change: 11 Dec 1998 4 Maintenance Commands vxdg(1M) otherwise, the name change will be permanent. Normally, an imported disk group will be reim- ported automatically when the system is rebooted, if at least some of the disks in the disk group remain accessible and usable. This can be dis- abled 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 rootdg disk group from one host can be imported on a second host, operations can be performed on the second host (such as making repairs to the root volume), and the disk group can be given back to the originating host, which can then be rebooted on the repaired disk group. To do this, identify the disk group ID for the rootdg disk group with vxdisk -s list, and use that disk group to import that rootdg using -C to clear import locks, -t for a temporary name, and -n to specify an alternate name (to avoid collision with the rootdg disk group on the second host). After repair, deport the disk group using -h (described below) to restore the import lock from the first host. In Cluster Volume Manager, use the -s option to import a disk group as cluster-shareable. 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 acces- sible 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 will fail. vxdg init Define 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 VxVM 3.0 Last change: 11 Dec 1998 5 Maintenance Commands vxdg(1M) group's configuration database. At least one of the disks specified must have space allocated for a configuration copy. 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 partic- ular disk, then that medianame will name the disk media record used to reference the disk within the disk group (for operations such as rmdisk and sub- disk creations). If no medianame is specified, then the disk media name defaults to accessname. See vxdisk(1M) for a discussion of definition and initialization of disk access records. The init operation can be used to initialize a root disk group configuration, which is identified by the special name rootdg. If any database loca- tions are listed in the volboot file, then as a special case for initializing rootdg, no disk specifications are allowed. Disks should be ini- tialized and added to the disk group as the first operations after creating rootdg. Some or all disks added to the rootdg disk group should also be added to the volboot bootstrap file (see vxdctl(1M)). The nconfig and nlog operands can be used to con- figure the number of configuration database copies and kernel log copies that are maintained for a disk group. The config-copies and log-copies values are either a decimal number (including 0 or -1) or set to all or default. A value of all or -1 signifies that all configuration or log copies on all disks in the disk group will be maintained. A value of default or 0 (this is also the default value) signifies that the Volume Manager will manage copies that are distributed in a reasonable pattern throughout the disks and controllers 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 scattered approximately evenly through the disk controllers on the system. VxVM 3.0 Last change: 11 Dec 1998 6 Maintenance Commands vxdg(1M) If SCSI disks with multiple disks per target are found, then each such target is treated similarly to a controller (that is, configuration copies are evenly distributed between such targets). With the default policy, one configuration or log copy is maintained for each controller, and one confi- guration or log copy is also maintained for each SCSI target that has multiple disks; if this does not result in allocating at least 4 copies, then additional copies are spread through the controll- ers and targets. Refer to vxdisk(1M) for more information on confi- guration and log copies, and for information on how to create them. Note: If a policy other than all is used, then some disks will not have up-to-date, online confi- guration and log copies. As a result, it is pos- sible that some number of disk failures will 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 suf- ficient spread of locations, that such a scenario is very unlikely to occur. 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, an administrator can choose ranges such that all disk groups in a group of machines can be moved around without causing dev- ice number collisions. Collisions may occur because the Volume Manager 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 per- sistency 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, then the Volume Manager may be forced to temporarily remap some devices. A base volume device minor number can be set for a disk group with the minor operand. Volume device numbers for a disk group will be chosen to have minor numbers starting at this base minor number. Minor numbers can range up to 131071, so if it is presumed that no more than 1000 volumes would ever be created in any one disk group, 131 different ranges of minor numbers are available for dif- ferent disk groups. A reasonably sized range VxVM 3.0 Last change: 11 Dec 1998 7 Maintenance Commands vxdg(1M) 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 com- mand line, then the Volume Manager chooses a ran- dom 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 over- lap any currently allocated volume device numbers. Note: The default policy is likely to ensure that a small number of disk groups can be merged suc- cessfully between a set of machines. However, in cases where disk groups will be merged automati- cally using fail-over mechanisms, the administra- tor should select ranges that are known to avoid overlap. In Cluster Volume Manager, the -s option defines a new disk group which is cluster-shareable while the cluster is active. It is the responsibility of the user to ensure that disks specified as members of a cluster-shareable disk group are phy- sically 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. Trying to create a shared disk group during a cluster reconfiguration will fail. 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 will fail. 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. If a version is specified with the -T option, the diskgroup is initialized with that diskgroup ver- sion. This limits the operations that can be VxVM 3.0 Last change: 11 Dec 1998 8 Maintenance Commands vxdg(1M) performed and features that can be used to those supported by the specified diskgroup version. This makes the diskgroup compatible with releases of VxVM that support that version. If no version is specified, the diskgroup 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. vxdg list List the contents of disk groups. If no diskgroup arguments are specified, then all disk groups are listed in an abbreviated one-line format. If diskgroup arguments are specified, then a longer format is used to indicate the status of the disk group, and of the specified disk group configura- tion. If the -q option is specified, then no header is printed describing output fields. This option has no effect with the long formats generated with diskgroup arguments. In Cluster Volume Manager, if the -s option is specified, all cluster-shared disk groups are listed in a one-line format. If diskgroup argu- ments are specified, -s has no effect. vxdg reminor Change the base minor number for a disk group, and renumber all devices in the disk group to a range starting at that number. If the device for a volume is open, then the old device number will remain in effect until the system is rebooted or until the disk group is deported and re-imported. Also, if you close an open volume, then 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 tem- porary renumbering for a volume device, which will also require a reboot or reimport for the new dev- ice numbering to take effect. A temporary renumbering can happen in the following situa- tions: when two volumes (for example, volumes in two different disk groups) share the same per- manently 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 VxVM 3.0 Last change: 11 Dec 1998 9 Maintenance Commands vxdg(1M) 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 will fail 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 with use of 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, then one of the volumes will be temporarily renumbered on the next reboot. Which volume device will be renumbered should be considered random, except that device numberings in the rootdg 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 will not require use of -f. vxdg repldisk Dissociate the DA record from the DM record named by spare-medianame and reassociate 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 (rootdg by default). However, if the -k flag is specified, then the disk media records for the spare-medianame will be kept, although in a removed state. vxdg rmdisk Remove the specified disk(s) from a disk group (rootdg by default). 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. Normally, the rmdisk operation will fail if sub- disk records point to the named disk media records. However, if the -k flag is specified, then the disk media records will be kept, although in a removed state, and the subdisk records will still point to them. The subdisks, and any plexes VxVM 3.0 Last change: 11 Dec 1998 10 Maintenance Commands vxdg(1M) that refer to them, will be unusable until the disk is re-added using the -k option to the adddisk operation. Any volumes that become unus- able, because all plexes become unusable, will be disabled. vxdg spare List spare space that can be used for relocating subdisks during recovery. If a disk group is specified, limit the output to the indicated disk group, otherwise list spare space from all disk groups. If disks are specified, by disk media name, then restrict the output 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 indi- cates which physical device the disk media is defined on. It appears as a truncated disk access name. If the -q option is specified, then no header is printed describing output fields. vxdg upgrade Upgrades the disk group to the lastest VxVM ver- sion. By default, the diskgroup version is updated to the running version of VxVM. The -T option upgrades the diskgroup to a specified version. The following section lists each diskgroup ver- sion, the features it supports, and the VxVM release that introduced it. 10 Supports only the most basic volume manage- ment features of mirroring and simple strip- ing. This format was introduced in VxVM Release 1.2. Starting with VxVM Release 3.0, diskgroups 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 diskgroup to a later release. 20 Introduced support for RAID-5 Volumes, new- style stripes, recovery checkpointing, disk- group configuration/klog copy limiting, and Dirty Region Logging. This version was intro- duced in VxVM Release 2.0 and is supported by all subsequent releases of VxVM. VxVM 3.0 Last change: 11 Dec 1998 11 Maintenance Commands vxdg(1M) 30 Enabled support for the Oracle Resilvering Interface. This version was introduced in VxVM Release 2.2 and is supported by all sub- sequent releases of VxVM. 40 Support for Hot Relocation. Introduced in VxVM Release 2.3 and is supported by all sub- sequent releases of VxVM. 60 Support for Online Relayout, safe RAID-5 sub- disk moves, Striped Mirrors, and RAID-5 Snapshots. Introduced in Release 3.0. You can determine a disk group version using the vxprint -l command, and the vxdisk list operation prints a long listing of a disk- group. SEE ALSO vxconfigd(1M), vxdctl(1M), vxdisk(1M), vxintro(1M), vxplex(1M), vxprint(1M), vxvol(1M) VxVM 3.0 Last change: 11 Dec 1998 12 #