vxconfigd - Volume Manager configuration daemon


vxconfigd [ -kfd ] [ -r reset ] [ -m mode ] [ -x debug ] [ -D diag_portal ] [ -R request_portal ]


The Volume Manager configuration daemon, vxconfigd, is responsible for maintaining configurations of disks and disk groups in the VERITAS Volume Manager. vxconfigd takes requests from other utilities for configuration changes, and communicates those changes to the kernel and modifies configuration information stored on disk. vxconfigd is also responsible for initializing the Volume Manager when the system is booted.


If a vxconfigd process is running already, then kill it before any other startup processing. This is useful for recovering from a hung vxconfigd process. Killing the old vxconfigd and starting a new one should not cause any problems for volume or plex devices that are being used by applications or that contain mounted file systems.

Start vxconfigd in the foreground. This is often useful when debugging vxconfigd, or when tracing configuration changes. If this flag is not used, vxconfigd will fork a background daemon process. The foreground process will exit as soon as vxconfigd startup processing completes.

This is equivalent to -mdisable, which starts vxconfigd in disabled mode.

-r reset
Reset all Volume Manager configuration information stored in the kernel as part of startup processing. This will fail if any volume or plex devices are currently in use. This option is primarily useful for testing or debugging.

-m mode
Set the initial operating mode for vxconfigd. Possible values for mode are:

Start fully enabled (default). This will use the volboot file to bootstrap and load in the rootdg disk group. It will then scan all known disks looking for disk groups to import, and will import those disk groups. This will also set up the /dev/vx/dsk and /dev/vx/rdsk directories to define all of the accessible Volume Manager devices. If the volboot file cannot be read or if the rootdg disk group cannot be imported, vxconfigd will be started in disabled mode.

Start in disabled mode. This creates a rendezvous file for utilities that perform various diagnostic or initialization operations. This can be used with the -rreset option as part of a command sequence to completely reinitialize the Volume Manager configuration. Use the vxdctlenable operation to enable vxconfigd.

Handle boot-time startup of the Volume Manager. This starts the rootdg disk group and the root file system volume. This mode is capable of operating before the root file system is remounted to read-write. vxdctlenable should be called later in the boot sequence to trigger vxconfigd to rebuild the /dev/vx/dsk and / dev/vx/rdsk directories.

-x debug
Turn on various parameters used for debugging or other miscellaneous aspects of vxconfigd operation. The debug option argument is a decimal number, which will set a tracing output level, or one of the following strings:

timestamp or mstimestamp
Attach a date and time-of-day timestamp to all messages written by vxconfigd onto the console. If mstimestamp is used, then a millisecond value is also displayed, allowing detailed timing of vxconfigd's operation.

syslog or nosyslog
These options are provided only on systems where vxconfigd is compiled with support for the syslog() library calls (see syslogd(ADM) and syslog(S)). vxconfigd can support use of syslog() to log all of its regular console messages. This support is either available by default (in which case -xnosyslog is required to disable its use), or it can support it as a run-time option (in which case -xsyslog can be used to enable its use).

For UnixWare, -xsyslog must be supplied (default) to vxconfigd to enable use of syslog(). The system can be changed to use this option at boot-time by editing the VxVM startup scripts.

NOTE: If the syslog option is enabled, then all console output will be directed through the syslog() interface. However, both syslog and log (described below) can be used together to get reliable logging, into a private log file, along with distributed logging through syslogd.

log or nolog
As an alternative to the use of syslog(), vxconfigd can directly log all of its console output to a file. This logging is reliable, in that any messages which are output just before a system crash will be available in the log file, presuming that the crash does not result in file system corruption. vxconfigd can be compiled such that logging defaults either to enabled or disabled. If it defaults to disabled, then it can be turned on with -xlog; otherwise, it can be turned off with -xnolog.

For UnixWare, logging is disabled by default. If enabled, the default log file location is / var/vxvm/vxconfigd.log.

Specify an alternate location for the vxconfigd logfile. This option implies -xlog.

This option causes the /var/vxvm/tempdb directory to be removed and recreated. This directory stores configuration information that is cleared on reboots (or cleared for specific disk groups on import and deport operations). If the contents of this directory become corrupt, such as due to a disk I/O failure, then vxconfigd will fail to start up if it is killed and restarted. Such a situation can be cleared by starting vxconfigd with -xcleartempdir. This option has no effect if vxconfigd is not started in enabled mode.

NOTE: It is advisable to kill any running operational utilities (vxvol, vxsd, or vxmend) before using the -xcleartempdir option. Failure to do so may cause those commands to fail, or may cause disasterous but unchecked interactions between those commands and the issuance of new commands. It is okay to use this option while running the Visual Administrator (vxva), or while VxVM background daemons are running (vxrelocd or vxnotify).

This vxconfigd invocation will not communicate configuration changes to the kernel. It is typically used as a demonstration mode of operation for vxconfigd. In most aspects, a stubbed vxconfigd will act like a regular vxconfigd, except that disk devices can be regular files and volume and plex device nodes are not created. A stubbed vxconfigd can run concurrently with a regular vxconfigd, or concurrently with any other stubbed vxconfigd processes, as long as different rendezvous, volboot, and disk files are used for each concurrent process.

Other Volume Manager utilities can detect when they are connected to a vxconfigd that is running in stubbed mode. When a utility detects a stubbed-mode vxconfigd, it will normally stub out any direct use of volume or plex devices, itself. This allows regular utilities to be used for making configuration changes in a testing environment that runs without any communication with the kernel or creation of real volume or plex devices.

Specify the pathname to use for the volboot file. This is primarily of use with the stub debug option. The volboot file contains an initial list of disks that are used to locate the root disk group. It also contains a host ID that is stored on disks in imported disk groups to define ownership of disks as a sanity check for disks that might be accessible from more than one host.

Specify a directory pathname to prefix for any disk device accessed by vxconfigd. For example, with devprefix=/tmp, any access to a raw disk device named c2b0t1d0s0 would actually be directed to the file /tmp/dev/rdsk/c2b0t1d0s0. In stubbed-mode, vxconfigd can operate with such files being regular files. vxconfigd only requires entries in the prefixdir /dev/rdsk directory in stubbed mode.

Log all possible tracing information in the given file.

Flush tracefile data to disk, with fsync(S), to ensure that the last entry will be included in the file, even if the system crashes.

Normally, vxconfigd will automatically configure disk devices that can be found by inspecting kernel disk drivers. These auto_configured disk devices are not stored in persistent configurations, but are regenerated from kernel tables after every reboot. Invoking vxconfigd with -xnoautoconfig prevents the automatic configuration of disk devices, forcing the Volume Manager to use only those disk devices configured explicitly using vxdisk define or vxdisk init.

Specify the pathname to use for the vfstab file. Normally, /etc/vfstab is used.

-D diag_portal
Specify a rendezvous file pathname for diagnostic operation connections to vxconfigd. By default, /etc/vx/vold_diag is used. The diagnostic portal exists in both the enabled and disabled operating modes.

-R request_portal
Specify a rendezvous file pathname for regular configuration and query requests. By default, this is /etc/vx/vold_request. The regular request portal exists only when vxconfigd is operating in enabled mode.


If errors are encountered, vxconfigd writes diagnostic messages to the standard error output. Some serious errors will cause vxconfigd to exit. If an error is encountered when importing the rootdg disk group during a normal startup, vxconfigd will enter disabled mode. The error messages appendix of the VERITAS Volume Manager System Administrator Guide should be consulted for a description of the diagnostics and the suggested course of action.

Defined exit codes for vxconfigd are:

The requested startup mode completed successfully. This is returned if -f is not used to startup vxconfigd as a foreground process. If vxconfigd is started as a foreground process, then it will exit with a zero status if vxdctlstop is used to cause vxconfigd to exit.

The command line usage is incorrect.

Enabled-mode operation was requested, but an error caused vxconfigd to enter disabled mode instead. This is also returned for boot-mode operation if startup failed. However, with boot-mode operation, the background vxconfigd process exits as well.

The -k option was specified, but the existing vxconfigd could not be killed.

A system error was encountered that vxconfigd cannot recover from. The specific operation that failed is printed on the standard error output.

The background vxconfigd process was killed by a signal before startup completed. The specific signal is printed on the standard error output.

A serious inconsistency was found in the kernel, preventing sane operation. This can also happen because of version mismatch between the kernel and vxconfigd.

The -rresest option was specified, but the Volume Manager kernel cannot be reset. Usually this means that a volume is open or mounted.

An interprocess communications failure (usually a STREAMS failure). Has made it impossible for vxconfigd to take requests from other utilities.

Volumes that must be started early by vxconfigd could not be started. The reasons, and possible recovery solutions, are printed to the standard error output. For UnixWare, the early- started volumes is the root file system, if it is defined on a volume.


Directory containing block device nodes for volumes.

Directory containing raw device nodes for volumes.

File containing miscellaneous boot information (see vxdctl(ADM)).

Directory containing miscellaneous temporary files. Files in this directory are recreated after reboot.


syslogd(ADM), vxdctl(ADM), vxintro(ADM), vxmend(ADM), vxnotify(ADM), vxrelocd(ADM), vxsd(ADM), vxvol(ADM), fsync(S), syslog(S), syslog.conf(4bsd)

Copyright © 2005 The SCO Group, Inc. All rights reserved.