unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (HP-UX-11.11)
Page:
Section:
Apropos / Subsearch:
optional field



 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



 NAME
      vxintro - introduction to the VERITAS Volume Manager utilities

 SYNOPSIS
      vxassist, vxclustadm, vxconfigd, vxdco, vxdctl, vxdg, vxdisk,
      vxdiskadd, vxdiskadm, vxedit, vxevac, vxinfo, vxinstall, vxiod, vxmake,
      vxmend, vxmirror, vxnotify, vxpfto, vxplex, vxprint, vxr5check,
      vxreattch, vxrecover, vxrelayout, vxrelocd, vxresize, vxrlink, vxrvg,
      vxsd, vxsparecheck, vxstat, vxtask, vxtrace, vxvmconvert, vxvol

 DESCRIPTION
      The VERITAS Volume Manager (VxVM) utilities provide a shell-level
      interface for use by system administrators and high-level applications
      and scripts to query and manipulate objects managed through VxVM.

 GLOSSARY
      concatenated plex
		A plex whose subdisks are associated at specific offsets
		within the address range of the plex, and extend into the
		plex address range for the length of the subdisk.  This
		layout allows regions of one or more disks to create a plex,
		rather than a single big region.

      data change map
		The data change map (DCM) is a bit-map which represents
		regions in the volume.	When a write to a region occurs, the
		corresponding bit in the DCM is turned on.  It is used by
		VVR for both log overflow protection and automatic secondary
		synchronization.

      data volume
		A volume being used as a child of an RVG. For a primary RVG,
		a data volume contains the primary copy of that volume data.
		For a secondary RVG, a data volume contains a copy of the
		corresponding remote primary data volume data. Secondary
		data volumes are only writable with updates from the
		primary.  The secondary RVG must contain a data volume
		corresponding to each primary data volume.

      disk	Disks exist as two entities.  One is the physical disk on
		which all data is ultimately stored and which exhibits all
		the behaviors of the underlying technology.  The other is
		the VERITAS Volume Manager presentation of disks which,
		while mapping one-to-one with the physical disks, are just
		presentations of units from which allocations of storage are
		made.  As an example, a physical disk presents the image of
		a device with a definable geometry with a definable number
		of cylinders, heads, and so forth, whereas a VERITAS Volume
		Manager disk (VM disk) is simply a unit of allocation with a
		name and a size.




				    - 1 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      disk access record
		A configuration record that defines a pathway to a disk.
		The disk access records most commonly name a particular
		controller number, target ID, and logical unit number.	The
		list of all disk access records stored in a system is used
		to find all disks attached to the system.  Disk access
		records do not identify particular physical disks.

		Disk access records are identified by their disk access
		names (also known as DA names).

		Through the use of disk IDs, VxVM allows disks to be moved
		between controllers, or to different locations on a
		controller.  When a disk is moved, a different disk access
		record is used when accessing the disk, although the disk
		media record continues to track the actual physical disk.

		On some systems, VxVM builds a list of disk access records
		automatically, based on the list of all devices attached to
		the system.  On these systems, it is not necessary to define
		disk access records explicitly.	 On other systems, disk
		access records must be defined explicitly with the vxdisk
		define operation.  Specialty disks (such as RAM disks or
		floppy disks) are likely to require explicit vxdisk define
		operations on all systems.

      disk group
		A group of disks that share a common configuration.  A
		configuration consists of a set of records describing
		objects (including disks, volumes, plexes, and subdisks)
		that are associated with one particular disk group.  Each
		disk group has an administrator-assigned name that can be
		used by the administrator to reference that disk group.
		Each disk group has an internally defined unique disk group
		ID, which is used to differentiate two disk groups with the
		same administrator-assigned name.

		Disk groups provide a method to partition the configuration
		database, so that the database size is not too large and so
		that database modifications do not affect too many drives.
		They also allow VxVM to operate with groups of physical disk
		media that can be moved between systems.

		Disks and disk groups have a circular relationship: disk
		groups are formed from disks, and disk group configurations
		are stored on disks.  All disks in a disk group are stamped
		with a disk group ID, which is a unique identifier for
		naming disk groups.  Some or all disks in a disk group also
		store copies of the configuration database of the disk
		group.




				    - 2 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      disk group configuration
		A disk group configuration is a small database that contains
		all volume, plex, subdisk, and disk media records.  These
		configurations are replicated onto some or all disks in the
		disk group, usually with one copy on each disk.	 Because
		these databases are stored within disk groups, record
		associations cannot span disk groups.  Thus, a subdisk
		defined on a disk in one disk group cannot be associated
		with a volume in another disk group.

      disk header
		A block stored in a private region of a disk and that
		defines several properties of the disk.	 The disk header
		defines the size of the private region, the location and
		size of the public region, the unique disk ID for the disk,
		the disk group ID and disk group name (if the disk is
		currently associated with a disk group), and the host ID for
		a host that has exclusive use of the disk.

      disk ID	A 64-byte universally unique identifier that is assigned to
		a physical disk when its private region is initialized with
		the vxdisk init operation.  The disk ID is stored in the
		disk media record so that the physical disk can be related
		to the disk media record at system startup.

      disk media record
		A reference to a physical disk This record can be thought of
		as a physical disk identifier for the disk Disk media
		records are configuration records that provide a name with
		up to 31 characters (known as the disk media name or DM
		name), which you can use to reference a particular disk,
		independent of its location on the system's various disk
		controllers.  Disk media records reference particular
		physical disks through a disk ID, which is a unique
		identifier that is assigned to a disk when it is initialized
		for use with VxVM.

		Operations are provided to set or remove the disk ID stored
		in a disk media record.	 Such operations have the effect of
		removing or replacing disks, with any associated subdisks
		being removed or replaced along with the disk.

      host ID	A name, usually assigned by the administrator, that
		identifies a particular host.  Host IDs are used to assign
		ownership to particular physical disks.	 When a disk is part
		of a disk group that is in active use by a particular host,
		the disk is stamped with that host's host ID.  If another
		system attempts to access the disk, it detects that the disk
		has a non-matching host ID and disallows access until the
		first system discontinues use of the disk.  To allow for
		system failures that do not clear the host ID, the vxdisk



				    - 3 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



		clearimport operation can be used to clear the host ID
		stored on a disk.

		If a disk is a member of a disk group and has a host ID that
		matches a particular host, then that host imports the disk
		group as part of system startup.

      kernel log
		A log kept in the private region on the disk and that is
		written by the VERITAS Volume Manager kernel.  The log
		contains records describing the state of volumes in the disk
		group.	This log provides a mechanism for the kernel to
		persistently register state changes so that vxconfigd can be
		guaranteed to detect the state changes even in the event of
		a system failure.

      layered volume
		A virtual volume that is used and managed directly by VxVM,
		not by a user.	Note that currently a layered volume
		provides storage for only one upper-level volume.

		Layered volumes allow VxVM to implement the following
		features:

		+  Striped mirrors and concatenated mirrors are new types of
		   volume layouts that are less likely to fail and that
		   provide faster recovery times because there is less data
		   to recover (one column or part of a column versus the
		   whole volume).

		+  Online relayout lets you change the volume layout while
		   the volume is online.  See the vxassist(1M) and
		   vxrelayout(1M) manual pages for more information.

		+  RAID-5 subdisk moves and RAID-5 snapshots (see
		   vxassist(1M)).

      plex	A copy of a volume's logical data address space, also called
		a mirror.  A volume can have up to 32 plexes associated with
		it.  Each plex is, at least conceptually, a copy of the
		volume that is maintained consistently in the presence of
		volume I/O and reconfigurations.  Plexes represent the
		primary means of configuring storage for a volume.  Plexes
		can have a striped, concatenated, or RAID-5 organization
		(layout).

      plex consistency
		If the plexes of a volume contain different data, then the
		plexes are said to be inconsistent.  This is only a problem
		if VxVM is unaware of the inconsistencies, as the volume can
		return differing results for consecutive reads.	 Plex



				    - 4 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



		inconsistency is a serious compromise of data integrity.
		This inconsistency can be caused by write operations that
		start around the time of a system failure, if parts of the
		write complete on one plex but not the other.  Plexes can
		also be inconsistent after creation of a mirrored volume, if
		the plexes are not first synchronized to contain the same
		data.  An important part of VERITAS Volume Manager operation
		is ensuring that consistent data is returned to any
		application that reads a volume.  This may require that plex
		consistency of a volume be ``recovered'' by copying data
		between plexes so that they have the same contents.
		Alternatively, the volume can be put into a state such that
		reads from one plex are automatically written back to the
		other plexes, thus making the data consistent for that
		volume offset.

      private region
		Disks used by VxVM contain two special regions: a private
		region and a public region.

		The private region of a disk contains various on-disk
		structures that are used by VxVM for various internal
		purposes.  Each private region begins with a disk header
		which identifies the disk and its disk group.  Private
		regions can also contain copies of a disk group's
		configuration, and copies of the disk group's kernel log.

      public region
		The public region of a disk is the space reserved for
		allocating subdisks.  Subdisks are defined with offsets that
		are relative to the beginning of the public region of a
		particular disk.  Only one contiguous region of disk can
		form the public region for a particular disk.

      RLINK	(remote link) A representation of a communications link to a
		RVG hierarchy at a remote replication site, which contains
		information about the link.  An RLINK is a primary RLINK if
		its parent RVG is the primary RVG containing writable
		primary data volumes. Alternatively, a RLINK is a secondary
		RLINK if its parent RVG contains read-only data volumes (one
		for each data volume that the primary RVG contains). The
		vxrlink(1M) command is used to replicate a volume or volumes
		to any number of remote sites. The primary RVG has one RLINK
		record associated with it for each secondary site. A
		secondary RVG has only one RLINK record associated with it,
		which represents and contains information about the
		connection with the corresponding primary RLINK.

      root disk group
		Each system requires one special disk group, named rootdg,
		which is generally the default for most utilities.  In



				    - 5 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



		addition to defining the regular disk group information, the
		configuration for the root disk group (rootdg) contains
		local information that is specific to a disk group and that
		is not intended to be movable between systems.

      RVG	(replicated volume group) A virtual device that
		hierarchically contains one or more data volume records, a
		log volume record called a Storage Replicator Log (SRL), and
		one (or more for primary RVGs) RLINK records. It must be
		associated as a parent of the data volume records in order
		for those data volumes to be replicated to other sites which
		may be located across a LAN or WAN. In order to actively
		replicate a data volume, an RVG must have at least one data
		volume child (the volume to be replicated), exactly one SRL
		volume child (a volume to SRL data volume writes before they
		are transmitted to RLINKs), and at least one RLINK child
		(which represents a connection to an RVG hierarchy at a
		remote replication site). An RVG can be either a primary or
		a secondary, depending on whether its data volumes are
		considered to contain the primary copies of data or whether
		the data volumes are considered to be read-only copies of
		the data. Secondary RVGs contain one SRL volume, one RLINK,
		and the same number of data volumes as the primary RVG
		contains.

      SRL volume
		(storage replicator log volume) A volume being used as a
		child of an RVG. The SRL volume contains temporary copies of
		data intended to be written from (primary) or to (secondary)
		sibling data volumes. The SRL volume also contains meta
		data, such as connection information, about the RVG and
		RLINK with which the SRL volume is associated. The primary
		SRL volume is used to log SRL data while either in
		asynchronous mode, or during network outages while in
		synchronous mode. A secondary RVG must also have an SRL
		volume associated with it.

      striped plex
		A plex that scatters data evenly across each of its
		associated subdisks.  A plex has a characteristic number of
		stripe columns (consisting of associated subdisks) and a
		characteristic stripe unit size.  The stripe unit size
		defines how data with a particular address is allocated to
		one of the associated subdisks.	 Given a stripe unit size of
		64 blocks and two stripe columns, the first group of 64
		blocks is allocated to the first subdisk, the second group
		of 64 blocks is allocated to the second subdisk, the third
		group to the first subdisk, and so on.

      subdisk	A region of storage allocated on a disk for use with a
		volume.	 Subdisks are associated to volumes through plexes.



				    - 6 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



		One or more subdisks are laid out to form plexes based on
		the plex layout (striped, concatenated, or RAID-5). Subdisks
		are defined relative to disk media records.

      volboot file
		The volboot file is a special file (usually stored in
		/etc/vx/volboot) that is used to bootstrap the root disk
		group and to define a system's host ID.	 In addition to a
		host ID, the volboot file contains a list of disk access
		records.  On system startup, this list of disks is scanned
		to find a disk that is a member of the rootdg disk group and
		that is stamped with this system's host ID.  When such a
		disk is found, its configuration is read and is used to get
		a more complete list of disk access records that are used as
		a second-stage bootstrap of the root disk group, and to
		locate all other disk groups.

      volume	A virtual disk device that looks to applications and file
		systems like a regular disk device.  Volumes present block
		and raw device interfaces that are compatible in their use
		with disk devices.  However, a volume is a virtual device
		that can be mirrored, spanned across disk drives, moved to
		use different storage, and striped using administrative
		commands.  The configuration of a volume can be changed,
		using VERITAS Volume Manager utilities, without causing
		disruption to applications or file systems that are using
		the volume.

 CONVENTIONS
      VxVM employs certain conventions to provide a degree of similarity
      between various operations.  The conventions are used in the following
      areas:

	   +  Disk Group Selection



	   +  Standard Length Numbers



	   +  Command Syntax

 Disk Group Selection
      Most commands operate upon only one disk group per invocation.  Each
      disk group has a separate configuration from every other disk group
      and it is possible for two disk groups to contain two objects that
      have the same name.  This can happen, in particular, if a disk group
      is moved from one system to another.  However, most utilities make no
      attempt to ensure that names between disk groups are unique, so name
      collisions can occur.



				    - 7 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      System administrators who try to avoid name collisions should be able
      to use most of the utilities without having to specify disk groups
      except when creating objects.  Administrators cannot use single-
      command invocations that reference objects in more than one disk
      group, but disk groups are selected automatically, based on objects
      specified in the command.

      The standard rules that most commands use for selecting the disk group
      for a command are as follows:

      +	 Given a particular set of object names specified on the command,
	 look for the disk group of each object.  If all objects are in the
	 same disk group, use that disk group.	If any named object is not
	 unique between all disk groups, and if one of those object names is
	 not in the rootdg disk group, then fail.



      +	 To force use of a particular disk group, use -g diskgroup to
	 indicate the group.  Non-unique names do not cause errors when a
	 disk group is specified explicitly.  The diskgroup specification is
	 either a disk group ID or a disk group name.



      +	 A special case is provided for the rootdg disk group.	Any set of
	 objects in the rootdg disk group can be specified without
	 specifying -g rootdg, even if the given object name is used in
	 another disk group.

	 If a set of object names is given on the command line, and if some
	 are unique but some are not unique, then the command still fails
	 according to the rules listed above.

 Standard Length Numbers
      Many basic properties of objects that are managed by VxVM require
      specification of lengths, either as a pure object length or as an
      offset relative to some other object.

      VxVM supports volume lengths up to 2^63-1 disk sectors when using
      VERITAS-specific ioctl calls.  However, system calls such as seek,
      lseek, read and write are limited to a maximum offset that is
      determined by the operating system. For a system that supports large
      files, this is usually 2^63-1 bytes. Otherwise, the maximum offset
      value is usually 2^31-1 bytes (1 byte less than 2 terabytes).

      VxVM provides a uniform syntax for representing large numbers, and
      uses suffixes to provide convenient multipliers.	Numbers can be
      specified in decimal, octal, or hexadecimal.  For convenience, numbers
      can be specified as a sum of several numbers.




				    - 8 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      A hexadecimal (base 16) number is introduced using a prefix of 0x.
      For example, 0xfff is the same as decimal 4095.  An octal (base 8)
      number is introduced using a prefix of 0.	 For example, 0177777 is the
      same as decimal 65535.

      A number can be followed by a single-character suffix to indicate a
      multiplier for the number.  A length number with no suffix character
      represents a count of standard disk sectors.  The length of a standard
      disk sector can vary between systems; it is typically 512 bytes or
      1024 bytes.  On systems where disks can have different sector sizes,
      one of the sector sizes is chosen as the ``standard'' size.  Supported
      suffix characters are:

	   b	(Blocks) Multiply the length by 1024 bytes.

	   g	(Gigabytes) Multiply the length by 1,073,741,824 (1024M)
		bytes.

	   k	(Kilobytes) Multiply the length by 1024 bytes.

	   m	(Megabytes) Multiply the length by 1,048,576 (1024K) bytes.

	   s	(Sectors) Multiply the length by the standard sector size.
		This is the default unit if no suffix is specified.

      Numbers are represented internally as an integer number of sectors.
      As a result, if the standard disk sector size is larger than 512
      bytes, numbers can be specified that need to be rounded to a sector.
      Rounding is always done to the next lowest, not the nearest, multiple
      of the sector size.

      Because the letter b is a valid hexadecimal character, there is a
      special case for the b suffix where a single blank character can
      separate a number from the b suffix character.  Use of a blank within
      a number, when invoking commands from the shell, usually requires
      quoting the number.  For example:

	   vxassist make vol01 "0x1000 b"


      Numbers can be added or subtracted by separating two or more numbers
      by a plus or minus sign, respectively.  A plus sign is optional. The
      following is an example:

	   1023g+1023m+1023k+1


      In output, VxVM reports lengths in sectors, with no suffix character.

      Case is ignored in length specification.	Hexadecimal numbers and
      suffix characters can be specified using any reasonable combination of



				    - 9 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      uppercase and lowercase letters.

 Utility Syntax
      Most utilities in VxVM provide more than one operation, with
      operations grouped into utilities primarily by object type.  Utilities
      that provide multiple operations are typically invoked with the
      following form:

	   utility_name [ options ] keyword [ operands ]


      utility_name is the name of the VERITAS Volume Manager command and
      keyword specifies the specific operation to perform.  Any options that
      are introduced in the standard -letter form precede the operation
      keyword.	This is in keeping with standard System V UNIX utility
      syntax, which provides for a set of options as the first arguments to
      a command, followed by any non-option operands.  The keyword is
      considered an operand under standard System V syntax.

      All VM utilities provide an extended usage message that lists all the
      options and operation keywords supported by the utility.	Most VM
      utilities alsodisplay a usage message if you enter an invalid option.
      For utilities that are keyword-based, you can display this extended
      usage message the keyword help or a question mark (?).  Utilities that
      use operands for something other than operation selection provide a
      reserved option of -H to display the extended usage information.

 RECORD TYPES
      Disk group configurations contain eight types of records:

	   +  Disk Access Records



	   +  Disk Group Records



	   +  Disk Media Records



	   +  Plex Records



	   +  RLINK Records







				   - 10 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



	   +  RVG Records



	   +  Subdisk Records



	   +  Volume Records

      Disk access records are specific to the root disk group and are stored
      in configurations only because there is no other convenient place to
      store them; otherwise, they are logically separate from all disk
      groups.  Because they are specific and meaningful to the local system
      only, the logical place for their storage is the rootdg since that is
      the only disk group guaranteed to exist on the system.

 Disk Access Records
      Disk access records define an address, or access path, that can be
      used to access a disk.  The list of all disk access records defines
      the list of all disk addresses that VxVM can use to locate physical
      disks.  Disk access records do not define specific physical disks,
      since physical disks can be moved on a system.  When a physical disk
      is moved, a different disk access record may be necessary to locate
      it.

      Disk access records are stored in the rootdg disk group configuration.
      Unlike all other record types, the names of disk access records can
      conflict with the names of other records.	 For example, a specialty
      disk (such as a RAM disk) can use the same name for both the disk
      access record and the disk media record that points to it.  It is
      typically advisable to use different names for the access and media
      records, to avoid additional confusion if disks are moved.

      Disk access records can be defined explicitly.  Some (sometimes all)
      disk access records may be configured automatically by VxVM, based on
      available information in the operating system.  Such automatically-
      configured disks are not stored persistently in the on-disk root disk
      group configuration, but are instead regenerated every time VxVM
      starts up.

      Disk access records have the following fundamental attributes:

      disk access name
		The name of the disk access record is typically a disk
		address.  Disk access names are usually of the form c#t#d#,
		indicating use of the entire disk on controller c#, with
		SCSI target ID t#, and logical unit d#.

		VxVM 3.2 introduced an alternative enclosure-based naming
		scheme, which uses disk access names of the form



				   - 11 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



		enclosurename_disk# where enclosurename is the logical
		enclosure name, and disk# is the number of the disk in the
		enclosure. For example, enc0_0 refers to the first disk in
		the enclosure enc0.

		Other systems are likely to have different conventions for
		disk access name.

      type	Each disk access record has a type, which identifies key
		characteristics of VxVM's interaction with the disk.
		Available types are: simple, and nopriv.  See vxdisk(1M) for
		more information on disk types.	 Typically, most or all of
		the disks are of type simple.  It may be desirable to create
		specialty disks (such as RAM disks) with type nopriv.

      If the physical disk represented by the disk access record is
      associated with a disk media record, then the following fields are
      defined:

      disk group name
		The name of the disk group containing the disk media record.

      disk media name
		The name of the disk media record that points to the
		physical disk.

      Additional attributes can be added, arbitrarily, by disk types.  See
      vxdisk(1M) for a list of additional attributes defined by the standard
      disk types.

 Disk Group Records
      Disk group records define several different types of names for a disk
      group.  The different types of names are:

      alias name
		This is the standard name that the system uses when
		referencing the disk group.  References to the disk group
		name usually mean the alias name.  Volume directories are
		structured into subdirectories based on the disk group alias
		name.  Typically, the disk group's alias name and real name
		are identical.	A local alias can be useful for gaining
		access to a disk group with a name that conflicts with other
		disk groups in the system, or that conflicts with records in
		the rootdg disk group.

      disk group ID
		A 64-byte identifier that represents the unique ID of the
		disk group.  All disk groups on all systems should have a
		different disk group ID, even if they have the same real
		name.  This identifier is stored in the disk headers of all
		disks in the disk group.  It is used to ensure that VxVM



				   - 12 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



		does not confuse two disk groups which were created with the
		same name.

      real name This is the name of the disk group, as defined on disk.
		This name is stored in the disk group configuration, and is
		also stored in the disk headers of all disks in the disk
		group.

 Disk Media Records
      Disk media records define a specific disk within a disk group.  The
      name of a disk media record (the disk media name) is assigned when a
      disk is first added to a disk group (using the vxdg adddisk
      operation).  Disk media records can be assigned to specific physical
      disks by associating the disk media record with the current disk
      access record for the physical disk.

      Disk media records have the following fundamental attributes:

      disk access name
		The disk access name that is currently used to access the
		physical disk referenced by the disk ID.  If the disk ID is
		defined, but no physical disk with that ID could be found,
		the disk access name is clear.	A disk where the physical
		disk could not be found is considered to be in the NODAREC,
		or inaccessible, state.	 A disk can become inaccessible
		either because the indicated disk is not currently attached
		to the system, or because I/O failures on the physical disk
		prevented VxVM from identifying or using the physical disk.

      disk ID	A 64-byte unique identifier representing the physical disk
		to which the media record is associated.  This can be
		cleared to indicate that the disk is considered in the
		removed state.	A removed disk has no current association
		with any physical disk.

      A disk media record that has an active association with a physical
      disk (both the disk ID and the disk access name attributes are
      defined), inherits several properties from the underlying physical
      disk.  These attributes are taken from the disk header, which is
      stored in the private region of the disk.	 These inherited attributes
      are:

      atomic I/O size
		This is the fundamental I/O size for the disk, in bytes,
		also known as the sector size.	All I/O operations to this
		disk must be multiples of this size.  VxVM requires that all
		disks have the same sector size.  On most systems, this size
		is 1024 bytes.

      private length
		The length of the region of the physical disk that is



				   - 13 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



		reserved for storing private VERITAS Volume Manager
		information.

      public length
		The length of the region of the physical disk that is
		available for subdisk allocations.

 Plex Records
      Plex records define the characteristics of a particular plex of a
      volume.  A plex can be in either an associated state or a dissociated
      state.  In the dissociated state, the plex is not a part of a volume.
      A dissociated plex cannot be accessed in any way.	 An associated plex
      can be accessed through the volume.

      Plexes have the following fundamental attributes:

      comment	An administrator-assigned string of up to 40 characters that
		can be set and changed using the vxedit utility. VxVM does
		not interpret the comment field. The comment cannot contain
		newline characters.

      condition flags
		Various condition flags are defined for the plex that define
		state which is recognized automatically, rather than managed
		by the volume usage type.  Defined flags are:

		IOFAIL	  The plex was detached as a result of an I/O
			  failure detected during normal volume I/O.  The
			  plex is out-of-date with respect to the volume,
			  and in need of complete recovery.  However, this
			  condition also indicates a likelihood that one of
			  the disks in the system should be replaced.

		NODAREC	  No physical disk could be found corresponding to
			  the disk ID in the disk media record for one of
			  the subdisks associated with the plex.  The plex
			  cannot be used until the condition is fixed or the
			  affected subdisk is dissociated.

		RECOVER	  A disk for one of the disk media records was
			  replaced or was reattached too late to prevent the
			  plex from becoming out-of-date with respect to the
			  volume.  The plex requires complete recovery from
			  another plex in the volume to synchronize the plex
			  with the correct contents of the volume.

		REMOVED	  One of the disk media records was put into the
			  removed state through explicit administrative
			  action.  The plex cannot be used until the disk is
			  replaced or the affected subdisk is dissociated.




				   - 14 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      contiguous length
		The offset of the first block in the plex address space that
		is not backed by a subdisk.  If the plex has no holes, the
		contiguous length matches the plex length.  If the
		contiguous length is equal to or greater than the length of
		the associated volume, the plex is considered complete,
		otherwise it is sparse.

      I/O mode	Each plex is in read-write, read-only, or write-only mode.
		This mode affects read and write operations directed to the
		volume, if the plex is enabled.	 For read-write and read-
		only modes, volume read operations can be directed to the
		plex.  For read-write and write-only modes, volume write
		operations are directed to the plex.

		Plexes are normally in read-write mode.	 Write-only mode is
		used to recover a plex that failed, and whose contents have
		thus become out-of-date with respect to the volume.  It is
		also used when attaching a new plex to a volume.  In write-
		only mode, writes to the volume update the plex, causing
		written regions to be up-to-date.  Typically, a set of
		special copy operations is used to update the remainder of
		the plex.

      layout	The organization of associated subdisks with respect to the
		plex address space.  The layout is striped, concatenated, or
		RAID-5.

      length	The length of a plex is the offset of the last subdisk in
		the plex plus the length of that subdisk.  In other words,
		the length of the plex is defined by the last block in the
		plex address space that is backed by a subdisk.	 This value
		may or may not relate to the length of the volume, depending
		on whether the plex is completely contiguously allocated.

      log subdisk
		Each plex can have at most one associated log subdisk.	A
		log subdisk is used with the dirty region logging feature to
		improve the time required to recover consistency of a volume
		after a system failure.

      plex kernel state
		Each plex is either enabled, disabled, or detached.  When
		enabled, normal read and write operations from the volume
		can be directed to the plex.  When disabled, no I/O
		operations are applied to the plex.  When detached, normal
		volume I/O are not directed to the plex.

		I/O failures encountered during normal volume I/O may move
		the enabled state for a plex directly from enabled to
		detached.  See the description of volume exception policies



				   - 15 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



		(earlier in this manual page) for more information.

      subdisks	Each plex has zero or more associated subdisks.	 Subdisks
		are associated at offsets relative to the beginning of the
		plex address space.  Subdisks for concatenated plexes may
		not cover the entire length of the plex, in which case they
		leave holes in the plex.  A plex that is not as long as the
		volume to which it is associated is considered to have a
		hole extending from the end of the plex to the end of the
		volume.	 A plex with a hole is considered incomplete, and is
		sometimes called sparse.

      usage-type state
		Volume usage types maintain a private state field related to
		the the operations that have been performed on the plex, or
		to failure conditions that have been encountered.  This
		state field contains a string of up to 14 characters.

      volatile state
		A plex is considered to have ``volatile'' contents if the
		disk for any of the plex's subdisks is considered to be
		volatile.  The contents of a volatile disk are not presumed
		to survive a system reboot.  The contents of a volatile plex
		are always considered out-of-date after a recovery and in
		need of complete recovery from another plex.

 RLINK Records
      RLINK records define the characteristics of a particular RLINK of an
      RVG.  An RLINK can be in either an associated or dissociated state. In
      the dissociated state, the RLINK is not part of any RVG. An associated
      RLINK can be accessed through the RVG.

      RLINK have the following fundamental attributes:

      usage type
		RLINK are treated internally as if they have a usage-type of
		gen, but this distinction is largely irrelevant and exists
		merely to be compatible with pre-existing VERITAS Volume
		Manager code.

      rlink kernel state
		Each primary RLINK is either enabled, disabled or detached.
		When enabled, normal write operations are forwarded to the
		remote RLINK. When disabled, no I/O operations on the RLINK
		are allowed. When detached, normal RVG I/O are not directed
		to the RLINK, but certain ioctls can be issued against the
		RLINK. An enabled RLINK can also be either connected or
		disconnected, depending on whether the network connection
		between the RLINKs on the primary and secondary nodes is
		currently open or not.




				   - 16 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      usage-type state
		RLINKs are treated as having a gen usage-type, and its
		usage-type state is a private state field indicating the
		state of operations that have been performed on the RLINK,
		or failure conditions that have been encountered.  This
		state field contains a string of up to 14 characters.

      synchronous
		A field that indicates whether the RLINK should operate in
		synchronous or asynchronous mode. In synchronous mode, a
		write request to a replicated volume does not complete until
		the data has been recorded on the SRL and reached the
		secondary node. In asynchronous mode, a write request
		completes as soon as the data is recorded on the SRL. The
		field may have one of three values:

		off	  mode is asynchronous

		override  mode is synchronous, but automatically switches to
			  asynchronous if the rlink becomes inactive due to
			  a disconnection or administrative action

		fail	  mode is synchronous. If synchronous=fail is set
			  and an administrator detaches the Primary RLINK,
			  writes to the RVG are not failed. However, if an
			  RLINK becomes inactive for any other reason,
			  including an administrative detach of the
			  Secondary RLINK, subsequent write requests are
			  failed with an EIO error.

      local_host
		RLINKs have a host_name attribute that contains the name of
		the local host machine. Needed to support private networks.

      remote_host
		RLINKs have a remote_host attribute that contains the name
		of the remote host machine from (primary) or to (secondary)
		which replication takes place.

      remote_dg RLINKs have a remote_rlink attribute that contains the name
		of the diskgroup on the remote machine.

      remote_rlink
		RLINKs have a remote_rlink attribute that contains the name
		of the RLINK counterpart on the remote machine.

      comment	An administrator-assigned string of up to 40 characters that
		can be set and changed using the vxedit utility. VxVM does
		not interpret the comment field. The comment cannot contain
		newline characters.




				   - 17 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      latencyprot
		A field that indicates whether latency protection is enabled
		for the RLINK.	Latency protection prevents a RLINK from
		having more than a preset number of outstanding requests.
		All requests which have not been written to the remote data
		volume are counted as outstanding. If latency protection is
		enabled, then when the number of outstanding requests
		reaches latency_high_mark, throttling is enabled. This
		causes all new write requests to stall until throttling is
		disabled. Throttling is not disabled until the number of
		outstanding requests is reduced to latency_low_mark.  The
		field may have one of three values:

		off	  latency protection is disabled

		override  latency protection is enabled, but is
			  automatically disabled if the RLINK becomes
			  inactive due to a disconnection or administrative
			  action

		fail	  latency protection is enabled. If the RLINK
			  becomes inactive for any reason, and the
			  latency_high_mark is reached, subsequent write
			  requests are failed with an EIO error.

      srlprot	A field that indicates whether SRL protection is enabled for
		the RLINK. SRL protection prevents an RLINK from overflowing
		the SRL, which causes the RLINK to disconnect. If the RLINK
		has SRL protection enabled, and the next write request would
		cause the RLINK to overflow the SRL, then throttling is
		enabled. This causes all new write requests to stall until
		throttling is disabled.	 Throttling is not disabled until a
		predetermined amount of space is available on the SRL. The
		exception to this is when the autodcm mode is set, in which
		case, DCM protection is enabled as soon as the SRL overflows
		and incoming write requests are not stalled.  The field may
		have one of five values:

		off	  SRL protection is disabled

		override  SRL protection is enabled, but will automatically
			  be disabled if the RLINK becomes inactive due to a
			  disconnection or administrative action

		fail	  SRL protection is enabled. If the RLINK becomes
			  inactive for any reason, and SRL overflow is
			  imminent, subsequent write requests are failed
			  with an EIO error.

		autodcm	  SRL protection is enabled. This is the default
			  option for srlprot.  If an RLINK begins to



				   - 18 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



			  overflow the SRL, DCM protection is activated.

		dcm	  SRL protection is enabled. This differs from the
			  "autodcm" protection in that the DCM protection is
			  activated only when the RLINKs disconnect.  When
			  the RLINKs are connected, incoming writes are
			  throttled as described above.


      Note: When DCM protection is activated, the DCMs are used to record
      the regions that change on the data volumes. The vxrvg command can be
      used to resynchronize the images when the RLINKs are connected.  It
      should be noted that using DCM to resynchronize an image makes the
      image inconsistent until the resynchronization completes.

      latency_high_mark
		Maximum number of outstanding requests when latency
		protection is enabled.

      latency_low_mark
		After latency throttling is enabled, the number of
		outstanding requests must drop to this before it is
		disabled.

 RVG Records
      RVG records define the characteristics of particular RVG devices. The
      name of an RVG record defines the node name used for files in the
      /dev/vx/dsk and /dev/vx/rdsk directories. The block device for a
      particular RVG (which is unused in the current implementation) has the
      path:

	   /dev/vx/dsk/groupname/rvg


      where groupname is the name assigned by the administrator to the disk
      group containing the RVG. Note that the block device for a child data
      volume, not the RVG itself, can be used as an argument to the mount
      command (see mount(2)). The raw device for an RVG, typically used for
      issuing I/O control operations (see ioctl(2)), has the path:

	   /dev/vx/rdsk/groupname/rvg


      For convenience, RVGs assigned to the root disk group are accessible
      under the rootdg subdirectories of /dev/vx/dsk and /dev/vx/rdsk, but
      are also under /dev/vx/dsk/rvg and /dev/vx/rdsk/rvg.  Accesses to a
      data volume associated with a primary RVG device are internally
      directed to the RVG so that replication can take place. The RVG device
      nodes do not support the read(2) and write(2) system calls.





				   - 19 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      RVGs have the following fundamental attributes:

      usage type
		RVGs are treated internally as if they have a usage-type of
		gen, but this distinction is largely irrelevant and exists
		merely to be compatible with pre-existing VERITAS Volume
		Manager code.

      rvg kernel state
		Each primary RVG is either enabled, disabled or detached.
		When enabled, normal read and write operations are allowed
		on the child data volumes (assuming the underlying data
		volumes themselves are enabled) and those accesses are
		reflected to the data volumes as well as to any active
		RLINKs.	 When disabled, no access to the data volumes or any
		of its associated RLINKs is allowed. When detached, some
		ioctls can be used by utilities to operate on the RVG.

      usage-type state
		RVGs are treated as having a gen usage-type, and its usage-
		type state is a private state field indicating the state of
		operations that have been performed on the RVG, or failure
		conditions that have been encountered. This state field
		contains a string of up to 14 characters.

      datavols	List of data volumes associated with the RVG.

      srl	Each RVG has one associated SRL volume.

      rlink	Each primary RVG has between zero and thirty-two associated
		RLINK. Each secondary RVG can have no more than one
		associated RLINK.

      comment	An administrator-assigned string of up to 40 characters that
		can be set and changed using the vxedit utility. VxVM does
		not interpret the comment field. The comment cannot contain
		newline characters.

      user|group|mode
		These attributes are the user, group and file permission
		modes used for the RVG device nodes. The user and group are
		normally root. The mode usually allows read and write
		permission to the owner, and no access by other users.

 Subdisk Records
      Subdisk records define a region of disk, allocated from a disk's
      public region.  Subdisks have very little state associated with them,
      other than the configuration state that defines which region of disk
      the subdisk occupies.  Subdisks cannot overlap each other, either in
      their associations with plexes, or in their arrangement on disk public
      regions.



				   - 20 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      Subdisks have the following fundamental attributes:

      comment	An administrator-assigned string of up to 40 characters that
		can be set and changed using the vxedit utility. VxVM does
		not interpret the comment field. The comment cannot contain
		newline characters.

      disk media name
		The name of the disk media record that the subdisk is
		defined on.

      disk offset
		The offset, from the beginning of the disk's public region,
		to the start of the subdisk.

      length	The length of the subdisk.

      plex offset
		For associated subdisks, this is the offset (from the
		beginning of the plex) of the subdisk association.  For
		subdisks associated with striped plexes, the plex offset
		defines relative ordering of subdisks in the plex, rather
		than actual offsets within the plex address space.

 Volume Records
      Volume records define the characteristics of particular volume
      devices.	The name of a volume record defines the node name used for
      files in the /dev/vx/dsk and /dev/vx/rdsk directories.  The block
      device for a particular volume (which can be used as an argument to
      the mount command (see mount(1M)) has the path:

	   /dev/vx/dsk/groupname/volume


      where groupname is the name assigned by the administrator to the disk
      group containing the volume.  The raw device for a volume, typically
      used for application I/O and for issuing I/O control operations (see
      ioctl(2)), has the path:

	   /dev/vx/rdsk/groupname/volume


      For convenience, volumes assigned to the root disk group are
      accessible under the rootdg subdirectories of /dev/vx/dsk and
      /dev/vx/rdsk, but are also under /dev/vx/dsk/volume and
      /dev/vx/rdsk/volume.

      Reads to a volume device are directed to one of the read-write or
      read-only plexes associated with the volume.  Writes to the volume are
      directed to all of the enabled read-write and write-only plexes
      associated with the volume.



				   - 21 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      During a write operation, two plexes of a volume may become out of
      sync with each other, due to the fact that writes directed to two
      disks can complete at different times.  This is not normally a
      problem.	However, if the system were to crash or lose power during a
      write operation, the two plexes could have different contents.

      Most applications and file systems are not written with the
      presumption that two separate reads of a device can return different
      contents without an intervening write operation.	Since plexes with
      different contents could cause such a situation where two read
      operations of a block return different contents, VxVM expends
      considerable effort to ensure that this is avoided.

      Volumes have the following fundamental attributes:

      comment	An administrator-assigned string of up to 40 characters that
		can be set and changed using the vxedit utility.  VxVM does
		not interpret the comment field.  The comment cannot contain
		newline characters.

      exception policy
		There are several modes that can be set on the volume, by
		utilities according to the usage type of the volume.  These
		modes affect operation of a volume in the presence of I/O
		failures.  Currently only one of these policies, called
		GEN_DET_SPARSE is ever used.  This policy tracks complete
		and incomplete plexes in a volume (an incomplete plex does
		not have a backing subdisk for all blocks in the volume).
		If an unrecoverable error occurs on an incomplete plex, the
		plex is detached (disabled from receiving regular volume I/O
		requests).  If an unrecoverable error occurs on a complete
		plex, the plex is detached unless it is the last complete
		plex.  If the plex is the last complete read-write plex, any
		incomplete plexes that overlap with the error are detached
		but the plex with the error remains attached.

		This default policy is chosen to ensure that an I/O that
		fails on one plex is not directed to that plex again unless
		that plex is the last complete plex remaining attached to
		the volume.  In that case, the policy ensures that the
		volume returns the error consistently, even in the presence
		of incomplete plexes.

      length	Each volume has a length, which defines the limiting offset
		of read and write operations.  The length is assigned by the
		administrator, and may or may not match the lengths of the
		associated plexes.

      log type	A policy to use for logging changes to the volume, which can
		be assigned by the administrator.  Policies that can be
		specified are:



				   - 22 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



		none	  Do not perform any special actions when writing to
			  the volume.  Just write the requested data to all
			  read-write or write-only plexes.

		dirty-region-log
			  A volume is divided into regions. A bitmap where
			  each bit corresponds to a region is maintained.
			  When a write to a particular region occurs, the
			  respective bit is set to on. When the system is
			  restarted after a crash, this region bitmap is
			  used to limit the amount of data copying that is
			  required to recover plex consistency for the
			  volume.  The region changes are logged to special
			  log subdisks associated with each of the plexes
			  associated with the volume.  Use of dirty region
			  logging can greatly speed recovery of a volume,
			  but it also degrades performance of the volume
			  under normal operation.

		dcm	  A bit-map representing regions of a volume that is
			  used to track changes to that volume. it is used
			  by VVR for srl overflow protection and automatic
			  secondary synchronization.

      plexes	Each volume has between zero and 32 associated plexes.

      primary_datavol
		A name field. This field is only used with secondary
		volumes. The value indicates the name of the data volume on
		the primary to which this data volume corresponds.

      read policy
		A configurable policy for switching between plexes for
		volume reads.  When a volume has more than one enabled
		associated plex, VxVM can distribute reads between the
		plexes to distribute the I/O load and thus increase total
		possible bandwidth of reads through the volume.	 The read
		policy can be set by the administrator.	 Possible policies
		are:

		preferred plex
			  This read policy specifies a particular named plex
			  that is used to satisfy read requests.  In the
			  event that a read request cannot be satisfied by
			  the preferred plex, this policy changes to round-
			  robin.

		round-robin
			  For every other read operation, distribute the
			  operation across all of the available plexes.
			  Given three plexes, this switches between each of



				   - 23 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



			  the three plexes, so each plex gets one third of
			  the read requests.

		select	  This read policy is the default policy, and
			  adjusts to use an appropriate read policy based on
			  the set of plexes associated with the volume.	 If
			  exactly one enabled read-write striped plex is
			  associated with the volume, then that plex is
			  chosen automatically as the preferred plex;
			  otherwise, the round-robin policy is used.  If a
			  volume has one striped plex and one non-striped
			  plex, preferring the striped plex often yields
			  better throughput.

      read/write-back recover mode
		This is a mode that applies to the volume, which is managed
		by utilities as part of plex consistency recovery.  When
		this mode is enabled, each read operation recovers plex
		consistency for the region covered by the read.	 Plex
		consistency is recovered by reading data from blocks of one
		plex and writing that data to all other writable plexes.
		This ensures that a future read operation covering the same
		range of blocks reads the same data.

      start options
		This is a string that is organized as a set of usage-type
		options to apply when starting (enabling) a volume.  See
		vxvol(1M) for details.

      usage type
		Each volume has a usage type that defines a particular class
		of rules for operating on the volume. The usage type is
		typically based on the expected content of the volume.
		Several VERITAS Volume Manager utilities can apply
		extensions or limitations that apply to volumes with a
		particular usage type.	Several basic usage types are
		included with VxVM: fsgen, for use with volumes that contain
		file systems; gen, for use with volumes that are used as
		swap devices or for other applications that do not use file
		systems; raid5, for use with RAID-5 volumes; and special
		root and swap usage types, which are specifically for use
		with the root file system volume and the primary swap
		device.

      usage-type state
		Usage types maintain a private state field related to the
		volume that relate to operations that have been performed on
		the volume, or to failure conditions that have been
		encountered.  This state field contains a string of up to 14
		characters.




				   - 24 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      user|group|mode
		These attributes are the user, group, and file permission
		modes used for the volume device nodes.	 The user and group
		are normally root.  The mode usually allows read and write
		permission to the owner, and no access by other users.

      volume kernel state
		Each volume is either enabled, disabled, or detached.  When
		enabled, normal read and write operations are allowed on the
		volume, and any file system residing on the volume can be
		mounted, or used in the usual way.  When disabled, no access
		to the volume or any of its associated plexes is allowed.

      write-back-on-read-failure mode
		This is a mode that applies to the volume, which can be
		enabled or disabled by the administrator using vxedit.	If
		this mode is enabled, then a read failure for a plex causes
		data to be read from an alternate plex and then written back
		to the plex that got the read failure.	This usually fixes
		the error.  Only if the writeback fails is the plex detached
		for having an unrecoverable I/O failure.

      writecopy mode
		This is a mode that applies to the volume, which can be
		enabled or disabled by the administrator using vxedit.	This
		mode takes affect only if dirty region logging or RAID-5
		logging is in effect.  When the operating system hands off a
		write request to the volume driver, the operating system may
		continue to change the memory that is being written to disk.
		VxVM cannot detect that the memory is changing, so it can
		inadvertently leave plexes with inconsistent contents.	This
		is not normally a problem, because the operating system
		ensures that any such modified memory is rewritten to the
		volume before the volume is closed (such as by a clean
		system shutdown).  However, if the system crashes, plexes
		may be inconsistent.  Since the logging feature prevents
		recovery of the entire volume, it may not ensure that plexes
		are entirely consistent.

		Turning on the writecopy mode (which is normally set by
		default) often causes VxVM to copy the data for a write
		request to a new section of memory before writing it to
		disk.  Because the write is done from the copied memory, it
		cannot change and so the data written to each plex is
		guaranteed to be the same if the write completes.

		See the vxedit(1M) manual page for more information.

 VOLUME USAGE TYPES
      The usage type of a volume represents a class of rules for operating
      on a volume.  Each usage type is defined by a set of executables under



				   - 25 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      the directory /etc/vx/type/usage_type, where usage_type is the name
      given to the usage type.	The required executables are: vxinfo,
      vxmake, vxmend, vxplex, vxsd, and vxvol.	These executables are
      invoked by VERITAS Volume Manager administrative utilities with the
      same names.  The executables under /etc/vx/type should not, normally,
      be executed directly.

      Five usage types are provided with VxVM: gen, fsgen, root, swap, and
      raid5.  It is possible for third-party products to install additional
      usage types.

      The usage types provided with VxVM store state information in the RVG,
      RLINK, volume, and plex usage-type state fields.

      The state fields defined for RVGs are:

      EMPTY	The RVG is not yet initialized. This is the initial state
		for RVGs created by vxmake.

      CLEAN	The RVG has been stopped and contains consistent data.

      ACTIVE	The RVG has been started and is running normally, or was
		running when the system was stopped. If the system stops in
		this state, then the RVG may require RLINK recovery.

      FAIL	Some problem has been detected with the RVG. It is disabled.

      The state fields defined for RLINKs are:

      UNASSOC	The RLINK is not fully initialized. This is the initial
		state for RLINKs created by vxmake, or which are not
		currently associated with an RVG.

      STALE	The RLINK is associated with an RVG, but it is not actively
		taking part in replication.  RLINK requires a full resync
		before it is up to date, unless the RVG is EMPTY.

      ACTIVE	The RLINK is associated and actively replicating normally,
		or was when the system was stopped.

      PAUSING	The RLINK is transitioning to the PAUSE state, or was doing
		so when the system was stopped. If the system stops in this
		state, then the RLINK must be reattached to put it back into
		the proper PAUSE state.

      PAUSE	The RLINK is paused. If it is a primary (secondary) RLINK
		and was paused by the pause command, vxrlink pause, then it
		is said to be primary-paused (secondary-paused).  A
		secondary RLINK can also enter the secondary-paused state if
		an error is detected with a secondary log or data volume.




				   - 26 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      RESTORING Temporary state while RLINK is being restored (see
		vxrlink(1M) restore sub-command).

      RECOVER	Temporary state while RLINK is being recovered with the
		vxrecover utility, which calls vxrlink recover. This state
		indicates that recovery is still needed.

      FAIL	Some problem has been detected with the RLINK. It is
		disabled.

      The state fields defined for volumes are:

      ACTIVE	The volume has been started and is running normally, or was
		running normally when the system was stopped.  If the system
		crashes in this state, then the volume may require plex
		consistency recovery.

      CLEAN	The volume has been stopped and the contents for all plexes
		are consistent.

      EMPTY	The volume is not yet initialized.  This is the initial
		state for volumes created by vxmake.

      NEEDSYNC	The volume requires recovery.  This is typically set after a
		system failure to indicate that the plexes in the volume may
		be inconsistent, so that they require recovery (see the
		resync operation in vxvol(1M)).

      SYNC	Plex consistency recovery is currently being done on the
		volume.	 vxvol resync sets this state when it starts to
		recovery plex consistency on a volume that was in the
		NEEDSYNC state.

      The state fields defined for plexes are:

      ACTIVE	The plex is running normally on a started volume.  The plex
		condition flags (NODAREC, REMOVED, RECOVER, and IOFAIL) may
		apply if the system is rebooted and the volume restarted.

      CLEAN	The plex was running normally when the volume was stopped.
		The plex is enabled without requiring recovery when the
		volume is started.

      DCOSNP	This state indicates that a data change object (DCO) plex
		attached to a volume can be used by a snapshot plex to
		create a DCO volume during a snapshot operation.

      EMPTY	The plex is not yet initialized.  This state is set when the
		volume state is also EMPTY.





				   - 27 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      OFFLINE	The plex was disabled by the vxmend off operation.  See
		vxmend(1M) for more information.

      SNAPATT	This is a snapshot plex that is being attached by the
		vxassist snapstart operation.  When the attach is complete,
		the state for the plex is changed to SNAPDONE.	If the
		system fails before the attach completes, the plex and all
		of its subdisks are removed.

      SNAPDIS	This is a snapshot plex created by vxplex snapstart that is
		fully attached.	 A plex in this state can be turned into a
		snapshot volume with vxplex snapshot.  See vxplex(1M) for
		more information.  If the system fails before the attach
		completes, the plex is dissociated from the volume.

      SNAPDONE	This is a snapshot plex created by vxassist snapstart that
		is fully attached.  A plex in this state can be turned into
		a snapshot volume with vxassist snapshot.  See vxassist(1M)
		for more information.  If the system fails before the attach
		completes, the plex and all of its subdisks are removed.

      SNAPTMP	This is a snapshot plex being attached by the vxplex
		snapstart operation.  When the attach is complete, the state
		for the plex is changed to SNAPDIS.  If the system fails
		before the attach completes, the plex is dissociated from
		the volume.

      STALE	The plex was detached, either by vxplex det or by an I/O
		failure.  vxvol start changes the state for a plex to STALE
		if any of the plex condition flags are set.  STALE plexes
		are reattached automatically, when starting a volume, by
		calling vxplex att.

      TEMP	This is a plex that is being associated and attached to a
		volume with vxplex att.	 If the system fails before the
		attach completes, the plex is dissociated from the volume.

      TEMPRM	This is a plex that is being associated and attached to a
		volume with vxplex att.	 If the system fails before the
		attach completes, the plex is dissociated from the volume
		and removed.  Any subdisks in the plex are kept.

      TEMPRMSD	This is a plex that is being associated and attached to a
		volume with vxplex att.	 If the system fails before the
		attach completes, the plex and its subdisks are dissociated
		from the volume and removed.

 EXIT CODES
      The majority of VERITAS Volume Manager utilities use a common set of
      exit codes, which can be used by shell scripts or other types of
      programs to react to specific problems detected by the utilities.	 The



				   - 28 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      number for each distinct exit code is described below.

      0		The utility is not reporting any error through the exit
		code.

      1		Some command line arguments to the utility were invalid.

      2		A syntax error occurred in a command or description, or a
		specified record name is too long or contains invalid
		characters.  This code is returned only by utilities that
		implement a command or description language.  This code may
		also be returned for errors in search patterns.

      3		The volume daemon does not appear to be running.

      4		An unexpected error was encountered while communicating with
		the volume daemon.

      5		An unexpected error was returned by a system call or by the
		C library.  This can also indicate that the utility ran out
		of memory.

      6		The status for a commit was lost because the volume daemon
		was killed and restarted during the commit of a transaction,
		but after restart the volume daemon did not know whether the
		commit succeeded or failed.

      7		The utility encountered an error that it should not have
		encountered.  This generally implies a condition that the
		utility should have tested for but did not, or a condition
		that results from the volume daemon returning a value that
		did not make sense.

      8		The time required to complete a transaction exceeded 60
		seconds, causing the transaction locks to be lost.  As most
		utilities reattempt the transaction at least once if a
		timeout occurs, this usually implies that a transaction
		timed out two or more times.

      9		No disk group could be identified for an operation.  This
		results either from naming a disk group that does not exist,
		or from supplying names on a command line that are in
		different disk groups or in multiple disk groups.

      10	A change made to the database by another process caused the
		utility to stop.  This code is also returned by a usage-
		type-dependent utility if it is given a record that is
		associated with a different usage type.	 If this situation
		occurs when the usage-type-dependent utility is called from
		a switchout utility, then the database was changed after the
		switchout utility determined the proper usage type to



				   - 29 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



		invoke.

      11	A requested subdisk, plex, or volume record was not found in
		the configuration database.  This may also mean that a
		record was an inappropriate type.

      12	A name used to create a new configuration record matches the
		name of an existing record.

      13	A subdisk, plex, or volume is locked against concurrent
		access.	 This code is used for inter-transaction locks
		associated with usage type utilities.  The code is also used
		for the dissociated plex or subdisk lock convention, which
		writes a non-blank string to the tutil[0] field in a plex or
		subdisk structure to indicate that the record is being used.

      14	No usage type could be determined for a utility that
		requires a usage type.

      15	An unknown or invalid usage type was specified.

      16	A plex or subdisk is associated, but the operation requires
		a dissociated record.

      17	A plex or subdisk is dissociated, but the operation requires
		an associated record.  This code can also be used to
		indicate that a subdisk or plex is not associated with a
		specific plex or volume.

      18	A plex or subdisk was not dissociated because it was the
		last record associated with a volume or plex.

      19	Association of a plex or subdisk would surpass the maximum
		number that can be associated to a volume or plex.

      20	A specified operation is invalid within the parameters
		specified.  For example, this code is returned when an
		attempt is made to split a subdisk on a striped plex, or to
		use a split size that is greater than the size of the plex.

      21	An I/O error was encountered that caused the utility to
		abort an operation.

      22	A volume involved in an operation did not have any
		associated plexes, although at least one was required.

      23	A plex involved in an operation did not have any associated
		subdisks, although at least one was required.

      24	A volume could not be started by the vxvol start operation,
		because the configuration of the volume and its plexes



				   - 30 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



		prevented the operation.

      25	A specified volume was already started.

      26	A specified volume was not started.  For example, this code
		is returned by the vxvol stop operation if the operation is
		given a volume that is not started.

      27	A volume or plex involved in an operation is in the detached
		state, thus preventing a successful operation.

      28	A volume or plex involved in an operation is in the disabled
		state, thus preventing a successful operation.

      29	A volume or plex involved in an operation is in the enabled
		state, thus preventing a successful operation.

      30	An unknown error condition was encountered.  This code may
		be used, for example, when the volume daemon returns an
		unrecognized error number.

      31	An operation failed because a volume device was open or
		mounted, or because a subdisk was associated with an open or
		mounted volume or plex.

      32	A problem occurred with multipath coordination.

      33	An object was already reserved for use by the operating
		system.

      35	An error occurred while communicating with a remote host.

      65	An array-related API failed.

      66	An array-specific guideline was violated.

      Exit codes greater than 32 are reserved for use by usage types.  Codes
      greater than 64 can be reserved for use by specific utilities.

 SEE ALSO
      mount(1M), vxassist(1M), vxclustadm(1M), vxconfigd(1M), vxdctl(1M),
      vxdco(1M), vxdg(1M), vxdisk(1M), vxdiskadd(1M), vxdiskadm(1M),
      vxdisksetup(1M), vxdmpadm(1M), vxedit(1M), vxevac(1M), vxinfo(1M),
      vxinstall(1M), vxiod(1M), vxlicinst(1), vxlicrep(1), vxmake(1M),
      vxmend(1M), vxmirror(1M), vxnotify(1M), vxplex(1M), vxprint(1M),
      vxr5check(1M), vxreattach(1M), vxrecover(1M), vxrelayout(1M),
      vxrelocd(1M), vxresize(1M), vxrlink(1M), vxrvg(1M), vxsd(1M),
      vxsparecheck(1M), vxstat(1M), vxtask(1M), vxtrace(1M),
      vxvmconvert(1M), vxvol(1M), ioctl(2), vol_pattern(4), vxmake(4)





				   - 31 -	  Formatted:  August 2, 2006






 vxintro(1M)			  VxVM 3.5			 vxintro(1M)
				 1 Jun 2002



      For information about other aspects of VxVM, see:

      vxio(7), vxinfo(7)

      VERITAS Volume Manager Administrator's Guide

















































				   - 32 -	  Formatted:  August 2, 2006