Background:

# man vxconfigd

vxconfigd - Veritas Volume Manager configuration daemon

vxconfigd [-dfk] [-Ddiag_portal]  [-I  inquiry_portal]  [-m mode] [-r reset] [-Rrequest_portal] [-x arg]

The Veritas  Volume  Manager  (VxVM)  configuration  daemon, vxconfigd,  maintains disk configurations and disk groups inVxVM.  vxconfigd takes requests  from  other  utilities  for configuration changes, and communicates those changes to the kernel and  modifies  configuration  information  stored  on disk.   vxconfigd  also  initializes VxVM when the system is booted Using the -m mode we can set the initial  operating  mode  for  vxconfigd. These modes are:

boot -  Handles boot-time startup of  VxVM.  If the  root disk is encapsulated, the boot disk group (of which the root disk  must be  a  member)  is  imported,  and  any required volumes on the  root  disk  are started.    Boot  mode  is  capable  of operating before the root file system is remounted  to read-write.

disable  - Starts vxconfigd in disabled mode.  disable creates a rendezvous file for utilities that perform various diagnostic or initialization  operations.  disable can be used with the -r reset option as part of  a  command  sequence  to  completely reinitialize Veritas Volume Manager configuration.  Use  the  vxdctl  enable operation to enable vxconfigd.

enable - Starts vxconfigd fully enabled (default).enable uses the volboot file to bootstrap and load in the  boot  diskgroup  if  the  root  disk is under VxVM control.  It then scans all known  disks for  disk  groups  to import and imports those disk groups.  enable also sets  up entries    in    the   /dev/vx/dsk   and/dev/vx/rdsk directories to  define  all of the accessible Veritas Volume Manager devices.  If the volboot file cannot  be read,  or  if the boot disk group cannot be imported, vxconfigd  starts  in  disabled mode.

-x syslog  By default, vxconfigd redirects console messages  to  syslog() when  it  is  first started.  

-k  -   If a vxconfigd  process  is  already  running,  -k kills  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 usually does not cause problems for volume devices that are being used by applications, or that contain mounted file systems.
 

Note: issuing the vxconfigd -k command to kill and restart the Volume Manager daemon can cause Cluster Server to attempt to failover to another node in the cluster. Prevent Cluster Server from taking action if a Volume Manager resource does fault due to vxconfigd not being available. This should be done for all service groups that contain Volume Manager objects:

---------------------------------------------------------------------------------------

#man vxdctl
   
vxdctl - control the volume configuration daemon

vxdctl debug level [pathname]

# vxdcl enable  

The primary purpose for  using  this  operation  when  in enabled  mode  is  to  rebuild  the  volume device nodes. This operation causes  vxconfigd  to  scan or  any  disks that were newly added since vxconfigd was last started.  In this manner, disks  can be  dynamically  configured to the system and then recognized by VxVM.

-----------------------------------------------------------------------------------------

After a normal bootup sequence the vxconfigd and vxdctl status are:

# ps -edf  | grep vxconfigd
   root282768      1   0   Mar11      -  0:29 vxconfigd -x syslog -m boot
 
# vxdctl mode
mode: enabled

This indicates the vxconfigd was started with -m boot as part of the initial boot sequence  under normal bootup sequence  and # vxdctl enable was called later in the boot sequence


On occasions, the vxconfigd  daemon may have been killed and restarted using the "-k" option

# ps -edf  |  grep vxconfigd    
   root282745      1   0   Mar12      -  10:29 vxconfigd -k

# vxdctl mode
mode: enabled

This is also regards as a normal/safe mode of operation.

----------------------------------------------------------------------------------------------

Issue:

Under certain condition , its possible the vxconfigd will hang or no response and  the process is stopped using

# pkill vxconfigd                  or

# kill -9

and manually restarted as follows to match the original vxconfigd flags

# vxconfigd -x syslog -m boot


Rechecking  the status of vxconfigd and vxdctl we have

# ps -edf  |  grep vxconfigd    
   root282645      1   0   Mar14      -  14:29 vxconfigd -x syslog -m boot

#vxdctl mode
mode: boot

If you fail to notice mode=boot  ( since vxdctl enable has not been executed) , system will appear to function correctly but will come across issues when you create newvolumes. For example:

# vxassist -g testdg make testvol 500m

Returns no warning/error messages and the volume is created and can be seen in vxprint output  BUT will not create any device files in/dev/vx/rdsk/ and /dev/vx//dsk directories


# ls -lrt  /dev/vx/*dsk/testdg
 

crw------- 1root root 75, 23002 Mar 26 09:26 /dev/vx/rdsk/test/vol1

crw------- 1root root 75, 23001 Mar 26 09:26 /dev/vx/rdsk/test/vol2

crw------- 1root root 75, 23000 Mar 26 09:26 /dev/vx/rdsk/sec/vol3

brw------- 1root root 75, 23002 Mar 26 09:26 /dev/vx/rdsk/test/vol1

brw------- 1root root 75, 23001 Mar 26 09:26 /dev/vx/rdsk/test/vol2

brw------- 1root root 75, 23000 Mar 26 09:26 /dev/vx/rdsk/sec/vol3

But running we can see a new minor number has been allocated to the new testvol

minor=23003

we can see the next minor has been allocated to the new volume but yet it does not appear in the device directories and therefore you can access the volume.

# mkfs -t vxfs/dev/vx/rdsk/testdg/testvol

UX:vxfs mkfs:ERROR: V-3-20002: Cannot access /dev/vx/rdsk/testdg/testvol: No such file or directory

 

1 Run

and the missing device files are created automatically

OR

2. Add device files manually for both rdsk and dsk

# mknod  <-character or block device>

 

In both case you can check they exist: