Veritas Volume Manager Known Issues: Installation and Upgrade Issues
Veritas Volume Manager Known Issues: Installation and Upgrade Issues
Veritas Volume Manager Known Issues: Installation and Upgrade Issues
See the following sections for information about known problems and issues in this release of
VxVM.
This release does not include the libvxpurple.so array support library (ASL) to support Sun
StorEdge T3 and T3+ arrays. Any existing version of the libvxpurple.so ASL is removed
when VxVM is upgraded to 5.0. Any T3 and T3+ arrays must be configured in autotrespass
mode, and treated as JBODs of type A/P.
If an array is of type A/A-A, A/P or A/PF, and a suitable ASL is not available, the array must be
claimed as an JBOD of type A/P. This is to prevent path delays and I/O failures arising. As
JBODs are assumed to be type A/A by default, and neither T3 nor T3+ arrays are of this type,
you must create appropriate JBOD entries for such arrays.
1. Stop all applications, such as databases, from accessing VxVM volumes that are
configured on the array, and unmount all VxFS file systems and checkpoints that are
configured on the array.
4. If you have not already done so, upgrade the Storage Foundation or VxVM software to
5.0. Device discovery will be performed during the upgrade, and the array will be
claimed as an A/P JBOD.
If you have already upgraded your system to 5.0, run the following command to perform
device discovery:
# vxdctl enable
5. Verify that the array has been added with the policy set to APdisk:
# vxddladm listjbod
VID PID Opcode Page Code Page Offset SNO length Policy
============================================================
SUN T300 18 -1 36 12 APdisk
6. Check that the correct devices are listed for the array:
# vxdisk list
DEVICE TYPE DISK GROUP STATUS
APdisk_0 auto:cdsdisk - - online invalid
APdisk_1 auto:cdsdisk - - online invalid
APdisk_2 auto:cdsdisk - - online invalid
...
If you are planning to initialize disks, check to see if any of the disks were previously under
VxVM control. If so, and if they were used on the same host system, the disk groups they
represent are imported automatically during the installation process if the proper removal
procedures were not followed. An attempt during installation to initialize or encapsulate disks
that were previously under VxVM control fails. After installation, if you no longer want to use
those disk groups, use the destroy option of the vxdg command to remove those disk groups.
Alternately, you can use vxdiskunsetup to remove the disks from VxVM control. Be aware that
these options can result in data loss if used incorrectly.
In earlier releases of VxVM, some users minimized the allocation of disks to the disk group,
rootdg, by associating rootdg with a small disk partition that was characterized as a simple
disk. This procedure would have been achieved by using the command, vxdctl add disk,
which is no longer supported in VxVM 4.0 and later releases.
If you created one of these simple disks, you will need to carry out a procedure similar to the one
described in the following example.
Assuming that the simple disk is defined to be on c1t21d0s7, you would see the following entry
in /etc/vx/volboot:
After upgrading to VxVM 5.0, you must reboot the system. After rebooting, execute the
command, vxdisk list, and you will see that c1t21d0s7 is not listed. This is because
vxconfigd now ignores disk entries in /etc/vx/volboot.
# vxdctl enable
# vxprint -th
[137838]
Interruption of an upgrade
If the installation software is interrupted on the local system during certain upgrade situations,
Veritas Volume Manager configurations may be lost after a reboot. If this happens, the entire
Veritas Volume Manager package must be reinstalled and a recover must be done manually by
recreating the disks, disk groups, and volumes and restoring the data from backup. [13033]
When running vxinstall on a system with a SENA array that is enabled with enclosure naming,
you may see a message similar to the following:
You can safely ignore this message. [Sun Bug ID 4955989, i138955]
An alert with the text message "SymCLI command line tools are not installed
properly" will be generated in each of the following two cases when SYMCLI is either absent
or not installed properly on the host on which a VAIL package is installed.
Case 1. When host comes up after a reboot and SYMCLI is either absent or not installed
properly.
Case 2. When a rescan of Symmetrix provider is initiated and SYMCLI is either found to be
absent or found to be not installed properly but SYMCLI installation was proper before rescan of
Symmetrix provider was initiated.
In either of Case 1 or Case 2 one should ignore the alert message on the host on which VAIL
package is installed if there is no EMC Symmetrix array being managed on that host. [Sun Bug
ID 6211778, 297830]
Veritas Volume Manager does not currently support remote package and patch installation across
different architectures. For example, installation of a package from a SPARC system to a x86
system is not supported.
LiveUpgrade
LiveUpgrade does not currently work on a system that has its root disk encapsulated.
Utility issues
On disks that are initialized by VxVM as CDS disks (the default format), the CDS information
occupies the first sector of that disk, and there is no fdisk partition information. Attempting to
create an fdisk partition (for example, by using the fdisk or format commands) erases the CDS
information, and can cause data corruption.
The Global Device Naming (GDN) option to the vxddladm command should only be used with
the Storage Foundation Volume Server software. [608621]
There is no option in the vxddladm command to display the current naming scheme. The naming
scheme that is in operation can be deduced from the output to the vxdisk list command.
[611320]
The vxdiskadm operation displays error V-5-1-9764 if a vendor and product ID combination are
specified to exclude devices from multipathing. This error is harmless and can be ignored. The
error is not seen if controller or device names are specified instead. [587435]
A disk group is disabled if the vxdg init command is used to create it from a set of disks that
have pre-existing private regions that differ in size. This may occur if the disks previously
belonged to disk groups in older releases of VxVM.
The workaround is to reinitialize the disks before creating the disk group (for example, by using
the vxdisk -f init command), or to use the vxdg adddisk command to add the disks to the
disk group after it has been created. [592180]
VxVM supports volume lengths up to 256TB. However, any 32-bit legacy applications that use
system calls such as seek, lseek, read and write are limited to a maximum offset that is
determined by the operating system. This value is usually 231-1 bytes (1 byte less than 2
terabytes).
Resizing volumes with detached remote plexes
If a volume in a Remote Mirror configuration has detached plexes at a remote site, you can use
the following procedure to resize it:
vxassist has no built-in protection to prevent you from shrinking the swap volume without first
shrinking what the system sees as available swap space. If it is necessary to shrink the swap
volume, the operation must be done in single user mode and the system must be rebooted
immediately. Failing to take these precautions can result in unknown system behavior or lock-up.
[6154]
The vxassist command does not add a mirror and a log when processing a command such as
the following:
# vxassist mirror volume layout=log ...
The mirror is added, but the log is silently omitted. To add a log and a mirror, add them in two
separate vxassist invocations, as follows:
[13488]
The old_layout attribute is no longer supported when the vxdisksetup command is used to
make a disk into a VxVM controlled disk. Use the noreserve attribute instead. [121258]
The vxvol and vxmend commands do not handle layered volumes very well. When vxmend is
executed on the top level volume to change the state of a volume, it is executed only on the top
level volume; the change is not propagated to the lower level volumes. As a result, the volume
states can become inconsistent and a subsequent vxvol init command might fail.
The vxvol command exhibits the same problem. When a vxvol init command is executed on
the top level volume, the change is not propagated to the volumes corresponding to its
subvolumes.
Workaround:
When executing the vxvol or vxmend command on a layered volume, first issue the command to
the lower level volumes in a bottom-up fashion; then execute the command on the top-level
volume.
In this example, a volume, vol, has two subvolumes, vol-L01 and vol-L02. The state of the
volumes is first set to empty, and then the initialization commands are executed:
[134932]
Due to the current implementation of a resize of layered volumes, it is recommended that you do
not grow or shrink layered volumes (for example; stripe-mirror, concat-mirror) while
resynchronization is ongoing. Note that this limitation does not apply to ISP layered volumes.
Internally, VxVM converts the layout of layered volumes and updates the configuration database
before it does the actual resize. This causes any ongoing operation, such as a resynchronization,
to fail.
If the system reboots before the grow or shrink of a layered volume completes, the volume is
left with an intermediate layout. In this case, you have to use vxassist convert to restore the
volume to its original layout.
After a layered volume is resized, the volume names, the plex names and the subdisk names
associated with the subvolumes, are changed.
With the introduction of SMF support in Solaris 10, startup script messages are no longer seen
on the console.
These messages can be viewed (cat or vi) in SMF log files found at:
/var/svc/log
/etc/svc/volatile
#/var/svc/log: ls
system-vxvm-vxvm-startup2:default.log
system-vxvm-vxvm-sysboot:default.log
milestone-multi-user-server:default.log
milestone-multi-user:default.log
milestone-name-services:default.log
milestone-single-user:default.log
#/etc/svc/volatile
system-vxvm-vxvm-startup2:default.log
system-vxvm-vxvm-sysboot:default.log
[269949]
When vxio detects a bad disk block on a disk, it will display a warning message indicating that
an uncorrectable write error has been encountered. [272176]
It is recommended that you do not edit the /etc/vx/disks.exclude file directly. Some scripts
like vxdiskadm fail with an error message if a long device name is specified in this file. You
should instead use option 17 or 18 of the vxdiskadm command to suppress or unsuppress devices
from VxVM's view. [Sun Bug ID 6228464, 311275]
Unable to boot system without bootdg link to the boot disk group
One possible cause for the error that the symbolic link between bootdg and the boot disk group
under /dev/vx/dsk or /dev/vx/rdsk is missing.
1. Make sure that your system does not have a link under /dev/vx/dsk and /dev/vx/rdsk
2. Boot the system from an installation disk or from a network boot server.
3. Mount the root (/) file system on a suitable mount point. In this example c0t0d0s0 is the
slice that corresponds to the root file system on the boot disk.
4. Create the link. This example assumes that the boot disk group is called rootdg:
# cd /mnt/dev/vx/dsk
# ln -s rootdg bootdg
# cd /mnt/dev/vx/rdsk
# ln -s rootdg bootdg
# cd
# umount /mnt
# init 0
Solaris 10 update 3 systems panic and fail to boot SAN boot device, when mpxio_disable is set
to 'yes' in /kernel/drv/fp.conf. [Sun Bug ID CR 6525123]
Sun cautions the user on disabling MPxIO on FC disks that have critical file systems needed for
booting. Sun also recommends that you update to the following OS level and patches:
Solaris 10 update 3
Latest kernel level patch - 118855-36 or later
Latest qlc driver patch - 119131-33 or later
Patch 120993-01
Latest firmware array
# bootadm update-archive
#touch /reconfigure
# vi /a/etc/vfstab
# /sbin/bootadm update-archive -R /a
# sync
# umount /a
# reboot
Patch Issues
If you use the patchrm command to remove the VxVM patch (122058-06), the vxconfigd
daemon dumps core when it is restarted, and the following error message is displayed:
Any volume is open, such as if the root disk is encapsulated, or a file system on a VxVM
volume is mounted.
Any process is accessing VxVM drivers that cannot be unloaded. In this case, a
workaround is to use the pkill vx and ps -ef | grep -i vx commands to make sure that all
vx* processes other than vxconfigd are stopped before removing the VxVM patch.
The error is harmless, and the patch is removed correctly. VxVM functions normally if the
system is rebooted. [796270]
Device issues
Under Solaris 10 when converting a multipathed disk that is smaller than 1TB from a VTOC
label to an EFI label, you must issue a format -e command for each path. For example, if a node
has two paths, c1t2d0s2 and c2tsd0s2, you need to apply the format -e command to each of
the two paths. [269566]
The default disk layout on the Solaris x64 platform differs from that on the Solaris SPARC
platform as follows:
On a Solaris SPARC system, the start of the Solaris partition, which may contain a
primary boot executable and boot block in addition to the VTOC and any disk slices, is
located in cylinder 0. The whole disk is accessed using the device c#t#d#s2.
On a Solaris x64 system, an FDISK partition, which may contain a master boot record
(MBR) is located in cylinder 0, and the start of the Solaris partition is located in cylinder
1. The device c#t#d#s2 references the entire Solaris partition, but not the FDISK
partition. The whole disk may be accessed using the device c#t#d#p0.
Before a disk with a sun partition label from a Solaris SPARC system can be used on a Solaris
x64 system, it is necessary to use the fdisk command to rewrite its partition layout and VTOC,
so destroying any data on the disk. However, a CDS disk group can be imported on a Solaris x64
system without needing to run the fdisk command. The layout of the partition table for CDS
disks is the same on all supported platforms, and does not include an FDISK partition, or a
Solaris partition and VTOC.
As on the Solaris SPARC platform, you can use the VERITAS Enterprise Administrator (VEA)
GUI, the Web GUI, or the vxdiskadm, vxdiskadd or vxdisk commands to initialize a new disk
with one of the following formats: auto:cdsdisk, auto:simple, auto:sliced, nopriv, simple
or sliced.
After removing a disk from its disk group, you can use the vxdiskunsetup -C command to clear
the VxVM configuration on the disk:
# vxdiskunsetup -C daname
If the vxdisk list command shows that a disk is in the error state, use the following
commands to reinitialize the disk with the default layout for a Solaris x64 system, and remove
the disk from the VxVM configuration:
# fdisk -B -n /dev/rdsk/danamep0
# vxdisk rm danames2
# vxdisk scandisks
Note that the partition 0 device (for example, c2t4d7p0) is specified to the fdisk command, but
the Solaris partition device (for example, c2t4d7s2) is specified to the vxdisk rm command.
The vxdisk list command should now show the disk's type as auto:none and its state as
online invalid. If the disk is still not shown as being in the online state, use the following
command to clear the first 512 blocks on the disk before rerunning the fdisk and vxdisk
commands:
Disks with insufficient space for the allocation of an on-disk database copy cannot be
encapsulated. The database requires at least the same space as is allocated for other disks in the
same disk group. The default required size is 32MB. To work around this, relocate the data on
the last partition of the disk to a volume on a different disk, and free the space by reducing the
partition size to 0.
The space for the database must be allocated from the beginning or the end of the disk, with the
exception of the root disk. The root disk can be encapsulated by carving out space from the swap
partition if there is no space at the beginning or at the end of the disk. This is done by creating a
subdisk for the private partition in the space obtained from the swap partition.
Workaround:
The problem of insufficient space on a disk to store private VxVM information has no
workaround. VxVM requires a small region of private storage for proper disk identification. The
number of VxVM objects that can be configured in a disk group is almost directly proportional
to the size of the private region. The default private region size is 32MB. If this size is
overridden, it is recommended that it be made no smaller than 1MB.
The Solaris 10 64-bit kernel Operating System provides support for disks larger than 1 terabyte.
Disks of this size are formatted with the Extensible Firmware Interface (EFI) disk label rather
than the VTOC disk label. EFI formatted disks are supported with Veritas Volume Manager on
Solaris 10 only.
[303294, 834313, Sun Bug ID 6226760]
Under Solaris 10, stale device entries in the /dev/[r]dsk directories can cause the VxVM
configuration daemon, vxconfigd, to consume a large amount of CPU time. Remove the stale
entries by entering the following sequence of commands:
# devfsadm -C
# touch /reconfigure
# init 6
When new disks are added to a Solaris configuration, these disks should be labeled before they
are used with VxVM. VxVM can discover unlabeled disks, but it cannot read their disk
geometry, nor can it initialize them. A console message similar to the following is displayed for
each unlabeled disk:
WARNING: /pci@1e,600000/SUNW,qlc@3,1/fp@0,0/ssd@w22110002ac000266,0 (ssd18):
Corrupt label; wrong magic number
When VxVM discovers unlabeled disks, the disk configuration information is added to DMP. If
DMP attempts to open the unlabeled device, the open fails, and the paths are disabled. If the
system is subsequently rebooted with the unlabeled disks, DMP disabled path messages are also
displayed for the unlabeled disks.
To prevent unnecessary delay occurring at boot time, it is recommended that you use the format
command to label new disks before having VxVM discover and initialize them. [544797]
The vxddladm addsupport command could cause your system to hang when using a Sun SCSI
Enclosure Service (SES) Driver. This situation can be caused by stale entries in /dev/es. A stale
entry is a device link in /dev/es, for which no corresponding device is connected to the system.
In some circumstances, installing VxVM can cause a system to hang because the vxddladm
addsupport command is also run.
If your system hangs, perform the following workaround
# devfsadm -C
[115323, 140441]
For a workaround to Sun Bug ID 4164338, use the procedure described in ''Upgrading disk
controller firmware'' in the ''Administering Dynamic Multipathing (DMP)" chapter of the Veritas
Volume Manager Administrator's Guide.
If the host-side switch port is disabled and enabled on a Brocade switch, the event source
daemon (vxesd) dies if the latest Solaris patches for the SUNWfchba, SUNWfchbr and SUNWfchbx
packages have not been applied to the system. Install the latest recommended Patch Cluster.
[534392]
When Hitachi DF400, DF500, HDS9200, HDS9500 or HDS9700 arrays are configured as
Active/Active mode arrays, performance is degraded. The correct ASL must be installed that
allows these arrays to be claimed as A/PG-type arrays. [73154]
Do not run the vxrelayout and vxassist commands to relayout a volume that is part of root
disk. This action may corrupt the layout of the root disk so that you cannot boot from it. On an
encapsulated root disk, a relayout can cause an upgrade to fail. [103991]
Failure to add a disk from a T3 array
On a T3 array, VxVM may display the following failure when trying to add a disk (typically
from vxinstall or vxdisksetup):
This can happen in cases where the T3 disk was re-partitioned (or re-formatted) prior to one or
more disks being added. [105173]
If you attempt to boot a cluster with I/O fencing (PGR) enabled, HDS9200 disks will show up in
error state on the slaves. This error does not appear if I/O fencing is disabled. [131926]
Fujitsu and Hitachi disks in V480 and V880 internal disk enclosures may not be automatically
recognized as JBOD disks. This could potentially cause data corruption if multipathing is not
configured correctly. After installing any Sun-qualified FC disks as FRU replacements, use the
procedure described in "Adding Unsupported Disk Arrays to the DISKS Category" in the
"Administering Disks" chapter of the Veritas Volume Manager Administrator's Guide to add
each such disk to the JBOD category. It is important that both the vendor ID and product ID are
specified for each such disk to avoid conflicts with similar disks in other arrays. For Fujitsu
disks, the number of characters in the serial number must also be specified. [Sun Bug ID
4900508, i133579]
If the model number of your JNI card is one of FCE-1063, FCE2-1063, FCE-6410, FCE2-6410,
or FCE2-6412, you may experience error messages of the form:
Oct 22 00:16:16 ds13un jnic: [ID 847178 kern.notice] jnic1: Memory port parity
error detected
Oct 22 00:16:16 ds13un jnic: [ID 229844 kern.notice] jnic1: Link Down
Oct 22 00:16:16 ds13un jnic: [ID 744007 kern.notice] jnic1: Target0: Port
0000EF (WWN 500060E802778702:500060E802778702) offline.
Oct 22 00:16:18 ds13un jnic: [ID 236572 kern.notice] jnic1: Target0: Port
0000EF (WWN 500060E802778702:500060E802778702) online.
Workaround: Add the following parameter to the JNI configuration file (jnic.conf):
FcEnableContextSwitch = 1;
The Sun StorEdge Traffic Manager (SSTM) boot support feature that is available through SAN
4.3 or later is not supported. Booting from fabric devices under SSTM or boot encapsulation of
fabric devices under SSTM is also not supported.
[Sun Bug ID 4912232, 4909641, 4912667].
If a 3510 array disk that is larger than 512GB is initialized to be a CDS disk, the value that is
returned by a SCSI mode sense command for the number of sectors per track may be incorrect.
This can cause the sector count to be miscalculated and some disk space to be lost. [272241]
After installing the Storage Foundation software, errors such as the following may be displayed
on the console.
When using HDS with True Copy enabled, the primary devices (P-VOL) and their mirrors (S-
VOL devices) are both seen in vxdisk list output. The P-VOL devices are available for import
but the S-VOL devices are not available for import. Do not try to use S-VOL devices even
though they appear in the vxdisk list output. [300979]
Veritas Volume Manager does not ignore USB devices attached to your system, resulting in an
error. When VxVM encounters an USB device, the status field for the device displays an error.
View the device details to verify the error. This USB device should be ignored and cannot be
used due to the error status.[803949]
#vxdisk list
Device: c2t0d0s2
devicetag: c2t0d0
type: auto
guid: -
udid:AMI%5FVirtual%20Floppy%5FOTHER%5FDISKS%5Fvmgalaxy13%5F%2Fdev
%2Frdsk%2Fc2t0d0s2
site: -
Multipathing information:
numpaths: 1
c2t0d0s2 state=enabled
Hot-relocation issues
Except for rootvol and swapvol, the hot-relocation feature does not guarantee the same layout
of data or performance after relocation. It is therefore possible that a single subdisk that existed
before relocation may be split into two or more subdisks on separate disks after relocation (if
there is not enough contiguous space on a single disk to accommodate that subdisk). [14894]
When a disk failure occurs, the hot-relocation feature notifies the system administrator of the
failure and any relocation attempts through electronic mail messages. The messages typically
include information about the device offset and disk access name affected by the failure.
However, if a disk fails completely or a disk is turned off, the disk access name and device offset
information is not included in the mail messages. This is because VxVM no longer has access to
this information. [14895]
DMP issues
Fabric Monitoring
The new Fabric Monitoring feature controls whether the Event Source daemon (vxesd) uses the
Storage Networking Industry Association (SNIA) HBA API. This API allows DMP to improve
the performance of failover by collecting information about the SAN topology and by
monitoring fabric events. Note that the vendor-provided ASL must also support the use of the
SNIA HBA API.
Fabric monitoring may be turned on or off by using the following vxddladm commands:
The current setting of monitor_fabric can be displayed by using the following command:
[784343]
The dmp_health_time and dmp_path_age tunables control how DMP handles intermittently
failing paths. The default values in VxVM 5.0 of dmp_health_time and dmp_path_age are 60
and 300 seconds respectively. The value of dmp_health_time represents the minimum time in
seconds for which a path must stay healthy. If a path changes state between enabled and disabled
on a shorter time scale than this, DMP marks the path as intermittently failing and disables I/O
on the path. I/O is not re-enabled on an intermittently failing path until dmp_path_age seconds
have elapsed without further outage.
The minimum configurable value of dmp_path_age is 0, which prevents DMP from detecting
intermittently failing paths.
Disabling the switch ports on the secondary paths to an A/P array can cause I/O failures on the
primary path. This is because a fabric reconfiguration can take some time to stabilize depending
on the complexity of the SAN fabric. Running the vxdisk scandisks command returns the
primary paths to the enabled state. [607996]
Mirroring a volume by using option 6 to the vxdiskadm command fails if the device discovery
layer chooses a secondary path to a device in an A/PF array. There is no known workaround for
this issue. [603164]
Disabling MPxIO
MPxIO is enabled by default, which may prevent DMP from providing multipathing support. To
ensure that multipathing through DMP is enabled, MPxIO must be disabled. See Enabling the
DMP feature.
The slave nodes in a CVM cluster only have access to I/O objects. If non-I/O related information
(for example, volume tags) are to be made available on a slave node, a command must to be
shipped to the Storage Agent on the master node for execution. The results are then
communicated back to the slave node.
The domain controller mode of VEA allows all nodes of a CVM cluster to be placed in the same
domain with a central authentication server. This allows commands to be executed on any node
within the domain if the executing process has sufficient rights.
Provided domain controller mode is configured, non-I/O related information is accessible via
VEA on any node in a CVM cluster.
However, even if domain controller mode is enabled in a CVM cluster, ISP commands must be
run on the master node. ISP commands that are run on a slave node are not redirected to the
Storage Agent on the master node. Such commands fail if they require access to non-I/O related
information that is unavailable on a slave node. [603213]
In a cluster with a shared IBM System Storage DS4800 disk storage system that is under a very
heavy I/O load, opening the primary paths of a LUN or joining a node may take a long time. For
example, it can take up to 15 minutes for a node to join a single-node cluster where
approximately 90 LUNS are present. This behavior occurs even if the node that is opening the
LUN is not involved in the I/O activity, and even if is not busy in any other way. [616166]
Failure to detach a bad plex
If the cluster detach policy is set to global, and a non-mirrored volume experiences a disk media
failure, the disk is not shown as failed and the volume is not disabled. However, I/O requests fail.
[521182]
A cluster node should not be rejoined to a cluster if both the primary and secondary paths are
enabled to an A/PF array, but all the other nodes are using only the secondary paths. This is
because the joining node does not have any knowledge of the cluster configuration before the
join takes place, and it attempts to use the primary path for I/O. As a result, the other cluster
nodes can experience I/O failures and leave the cluster.
Workaround
1. Before joining the node to the cluster, disconnect the cable that corresponds to the
primary path between the node and the A/PF array.
2. Check that the node has joined the cluster by using the following command:
# vxclustadm nidmap
The output from this command should show an entry for the node.
3. Reconnect the cable that corresponds to the primary path between the node and the array.
# vxdisk scandisks
[579536]
If a node leaves the cluster while a plex is being attached to a volume, the volume can remain in
the SYNC state indefinitely. To avoid this, after the plex attach completes, resynchronize the
volume manually with the following command:
RAID-5 volumes
The use of file systems other than Veritas Storage Foundation Cluster File System (SFCFS) on
volumes in cluster-shareable disk groups can cause system deadlocks.
If the vxconfigd program is stopped on both the master and slave nodes and then restarted on
the slaves first, VxVM output and VEA displays are not reliable until the vxconfigd program is
started on the master and the slave is reconnected (which can take about 30 seconds). In
particular, shared disk groups are marked disabled and no information about them is available
during this time. The vxconfigd program must therefore be started on the master first.
When a node terminates from the cluster, open volume devices in shared disk groups on which
I/O is not active are not removed until the volumes are closed. If this node later joins the cluster
as the master while these volumes are still open, the presence of these volumes does not cause a
problem. However, if the node tries to rejoin the cluster as a slave, this can fail with the
following error message:
A new automatic site reattachment daemon, vxsited, has been implemented to provide
automatic reattachment of sites. vxsited uses the vxnotify mechanism to monitor storage
coming back online on a site after a previous failure, and to restore redundancy of mirrors across
sites.
If the hot-relocation daemon, vxrelocd, is running, vxsited attempts to reattach the site, and
allows vxrelocd to try to use the available disks in the disk group to relocate the failed subdisks.
If vxrelocd succeeds in relocating the failed subdisks, it starts the recovery of the plexes at the
site. When all the plexes have been recovered, the plexes are put into the ACTIVE state, and the
state of the site is set to ACTIVE.
If vxrelocd is not running, vxsited reattaches a site only when all the disks at that site become
accessible. After reattachment succeeds, vxsited sets the site state to ACTIVE, and initiates
recovery of the plexes. When all the plexes have been recovered, the plexes are put into the
ACTIVE state.
Note vxsited does not try to reattach a site that you have explicitly detached by using the
vxdg detachsite command.
The automatic site reattachment feature is enabled by default. The vxsited daemon uses email
to notify root of any attempts to reattach sites and to initiate recovery of plexes at those sites. To
send mail to other users, add the user name to the line that starts vxsited in the
/lib/svc/method/vxvm-recover startup script and run the svcadm refresh vxvm/vxvm-
recover command.
If you do not want a site to be recovered automatically, kill the vxsited daemon, and prevent it
from restarting. To kill the daemon, run the following command from the command line:
# ps -afe
Locate the process table entry for vxsited, and kill it by specifying its process ID:
# kill -9 PID
If there is no entry in the process table for vxsited, the automatic site reattachment feature is
disabled.
To prevent the automatic site reattachment feature from being restarted, comment out the line
that starts vxsited in the /lib/svc/method/vxvm-recover startup script and run the svcadm
refresh vxvm/vxvm-recover command.
The vxvol command cannot be used to set site consistency on a volume unless sites and site
consistency have first been set up for the disk group. [530484]
Adding a remote mirror to a new site for a site-consistent volume does not also create a DRL log
plex or a DCO plex at that site. The workaround is to use the vxassist addlog command to add
a DRL log plex, or the vxsnap command to add a version 20 DCO plex at the specified site
(site=sitename). [533208]
It is not possible to replace a failed disk while its site is detached. You must first reattach the site
and recover the disk group by running these commands:
# vxrecover -g diskgroup
The vxdiskadm command gives an error when replacing disk on which the site tag had been
set. Before replacing such a failed disk, use the following commands to set the correct site name
on the replacement disk:
[536853, 536881]
Snapshot and snapback issues
It is recommended that you do not use snapshots of the root volume as a bootable volume. A
snapshot can be taken to preserve the data of the root volume, but the snapshot will not be
bootable. The data from the snapshot would have to be restored to the original root volume
before the system could be booted with the preserved data.
When taking a snapshot of a file system in an SFCFS cluster, the following warning message
might appear:
Workaround: No action is required. This behavior is normal and is not the result of an error
condition.
Normally, a file system would have no work to do when a snapshot is taken. However, if a CFS
file system is not mounted, it is likely that the fsck of the snapshot will take longer than is
usually necessary, depending on the I/O activity at the time of the snapshot.
Workaround:
When taking a snapshot of a SFCFS file system, you should ensure that at least one of the
volumes defined in the command line is mounted on the CVM master.
VxVM vxassist ERROR V-5-1-10127 getting associations of subdisk subdisk: Record not in disk
group
The command succeeds if I/O is suspended while the snapshot is created. [606613]
To create application volumes successfully, the appropriate licenses must be present on your
system. For example, you need a full Veritas Volume Manager license to use the instant snapshot
feature. Vendors of disk arrays may also provide capabilities that require special licenses for
certain features of their hardware. [Sun Bug ID 4948093, i137185]
If an ISP volume is created with the RAID-5 capability, the parameters ncols and nmaxcols
refer only to the number of data columns, and do not include the parity column. For this reason,
the number of columns that are created in such a volume is always one more than the number
specified. [Sun Bug ID 4976891]
Using allocator type volumes may cause the Storage Agent to terminate. Workaround: Restart
the Storage Agent by executing the following command:
/opt/VRTSobc/pal33/bin/vxpal -a StorageAgent -x
[930615]
Localization issues
You must uninstall the old version of the language packages before installing the Storage
Foundation 5.0 language packages, VRTSmulic and VRTSmuvmp. [625958]
Miscellaneous issues
Disk drives configured to use a write-back cache, or disk arrays configured with volatile write-
back cache, exhibit data integrity problems. The problems occur after a power failure, SCSI bus
reset, or other event in which the disk has cached data, but has not yet written it to non-volatile
storage. Contact your disk drive or disk array manufacturer to determine whether your system
disk drives use a write-back cache, and if the configuration can be changed to disable write-back-
caching.
If a disk that failed while a disk group was imported returns to life after the group has been
deported, the disk group is auto-imported the next time the system boots. This contradicts the
normal rule that only disk groups that are (non-temporarily) imported at the time of a crash are
auto-imported.
If it is important that a disk group not be auto-imported when the system is rebooted, the disk
group should be imported temporarily when the intention is to deport the disk group (for
example, in HA configurations). Use the -t flag to vxdg import. [13741]
During very fast boots on a system with many volumes, vxconfigd may not be able to auto-
import all of the disk groups by the time vxrecover -s is run to start the volumes. As a result,
some volumes may not be started when an application starts after reboot.
Workaround: Check the state of the volumes before starting the application, or place a sleep
(sleep sec) before the last invocation of vxrecover. [14450]
The vxrecover command starts a volume only if it has at least one plex that is in the ACTIVE or
CLEAN state and is not marked STALE, IOFAIL, REMOVED, or NODAREC. If such a plex is
not found, VxVM assumes that the volume no longer contains valid up-to-date data, so the
volume is not started automatically. A plex can be marked STALE or IOFAIL as a result of a
disk failure or an I/O failure. In such cases, to force the volume to start, use the following
command:
However, try to determine what caused the problem before you run this command. It is likely
that the volume contents need to be restored from backup, and it is also possible that the disk
needs to be replaced. [14915]
On machines with very small amounts of memory (32 megabytes or less), under heavy I/O stress
conditions against high memory usage volumes (such as RAID-5 volumes), a situation occurs
where the system can no longer allocate pages of physical memory.
The Sun Online:BackupTM facility does not accept the long device path names for volumes. A
limitation of Online: Backup is that it does not accept device paths longer than 24 characters.
Workaround: Use symbolic links to the longer /dev/vx/dsk/volname paths from a shorter
path name.
The following messages may get displayed on the console during a system reboot or during
VxVM initialization when you are running vxinstall:
These messages are informational only, and can be safely ignored if you are not a Veritas
Volume Replicator user.
Solaris Issues
The default maximum number of inodes in a UFS file system depends on the size of the file
system. Once a UFS file system has been created, you cannot change the number of inodes
without re-creating the file system. On a system with a large number of LUNs, the root file
system can run out of inodes. This causes errors to be seen both from the operating system and
from Veritas Volume Manager. As a general rule, the number of inodes that DMP creates for
every LUN is 16 times the number of separate paths to the device. For example, 8,000 LUNs
connected over 2 paths would require 256,000 additional inodes. [538039]
The versions of the kernel drivers for VxVM are incompatible with some versions of the Solaris
operating system. Multiple kernel modules are installed and properly maintained by the
installation and upgrade software. It is possible for a mismatch to occur (for example, if the
administrator moves the kernel driver files). If a mismatch occurs, the VxVM kernel prints a
warning message on the console similar to the following message:
If this message is displayed, the system must be booted for recovery (as explained in the Veritas
Volume Manager Troubleshooting Guide) and the correct kernel modules installed. To install the
correct kernel module versions, cd to the kernel/drv directory of the mounted root file system.
To list the VxVM kernel modules, use the following command:
The release-specific versions of the kernel modules are stored as module.OS_release, where OS
and release are the result of running the uname -s and uname -r commands on the system,
respectively.
For example, on a misconfigured system running Solaris 2.6, the listing for vxio* may be similar
to the following:
-rw-r--r-- 1 root other 1682424 ... vxio
The size of the vxio kernel module that is in use matches the vxio.SunOS_5.8 version. To
correct the problem, copy the SunOS_5.6 versions to the in-use module name:
# cp vxio.SunOS_5.6 vxio
During encapsulation, VxVM does not consider a partition to be a swap partition unless its
partition tag (as shown by prtvtoc) is swap or 3. Any partition used as a swap partition but not
tagged as such is encapsulated as a file system. In the vfstab file, a note is made that the
partition has been encapsulated, but the vfstab entry is not translated, and thus, the partition is
not added as a swap area as part of the boot process. All partitions that are to be used as swap
devices must be marked with the swap tag to be properly encapsulated. [13388]
Since the disk label is stored in block 0 of the disk, block 0 must not be used (that is, no
application should write any information in block 0). Special protection has been built into
VxVM to protect block 0 from being overwritten.
On Solaris, slice 2 of a non-EFI disk is the full disk by default. When finding connected disks,
VxVM checks slice 2 of a disk. Slice 2 on a disk must always be defined as the full disk slice
with a tag of 0x05.
However, the swap devices are correctly added with no ill effects on the system. To avoid seeing
this message, shorten the names of swap volumes (other than swapvol) from swapvoln to swapn.
Note Refer to the Veritas Storage Foundation Installation Guide for information on how to
set up and start the VEA server and client.
On Microsoft Windows systems, existing volume tags are not displayed when adding a new
volume tag. [602953]
Configurations with more than 10240 LUNs can cause the Storage Agent to dump core in the
directory /var/vx/isis. [584092]
Workaround
VEA fails to create a disk group that contains a duplicate disk ID, and gives no other options.
[Sun Bug ID 4923820]
When a user tries to print the volume layout view from VEA, the print is not clear.
Workaround: Upgrade the printer device driver to 0.3.1282.1 and install Service Pack 3. Upgrade
to the latest version of VEA and print again. [286476]
If the VEA is started without rebooting after a language package installation, the VEA does not
display localized messages and most of the GUI is displayed in English, regardless of the
operating system locale setting. Additionally, the install_lp command does not prompt the
user to reboot after installing a language package.
Workaround: After installing a language package using the install_lp command, reboot the
system. [993374]
The Create Disk Group wizard shows internal disks as being available for the creation of a
shared disk group. [574717]
All Active Alerts view
The All Active Alerts view shows an incorrect number of active alerts. [601167]
An incorrect error message such as the following may be displayed when importing a disk group:
An error such as the following may be seen when attempting to create a volume set that a
includes a newly created volume:
Error: 0xcfff0021 Facility: 0xfff Severity: 0x3 Error number: 0x21 Object Not Found.
The maximum size for a volume is shown as 0 gigabytes if less than 1 gigabyte of storage is
available in the disk group. [573897]
The add map operation for allocator volume does not return the operation result, due to which
the Web GUI framework displays a no result message on the result page.
Workaround: To check the status of the operation, look for text similar to the following in the log
file /var/vx/isis/command.log.
Output:
Exit Code:0
ndcomirs=1
Output:
Exit Code:0
The value associated with Exit Code: indicates the result of the operation. If it is zero then the
operation was executed successfully. If it is a non-zero value, then the operation has failed.
[971985]
All disk groups have a version number associated with them. Each VxVM release supports a
specific set of disk group versions and can import and perform tasks on disk groups with those
versions. Some new features and tasks work only on disk groups with the current disk group
version, so you need to upgrade existing disk groups before you can perform the tasks. The
following table summarizes the disk group versions that correspond to each VxVM release from
2.0 forward:
If you want to take advantage of the new features in this release, you must upgrade the Veritas
Cluster Volume Manager (CVM) protocol Version (70), and upgrade to the latest disk group
version (140).
You can also determine the version by using the vxprint(1M) command with
the -l option.
For shared disk groups, the latest disk group version is only supported by the latest cluster
protocol version. To see the current cluster protocol version, type:
# vxdctl support
To upgrade the protocol version for the entire cluster, enter the following command on the
master node:
# vxdctl upgrade
See the "Administering Cluster Functionality" chapter of the Veritas Volume Manager
Administrator's Guide.
The Scan Disks By Controller View does not list the available controllers. [566619]
Note: A volume is not startable if one plex is in the CLEAN state and some plexes are in the
ACTIVE state. Thus, several vxmend fix operations are normally used in conjunction to set all
plexes in a volume to STALE and then to set one plex to CLEAN. A volume start operation will
then enable the CLEAN plex and recover the STALE plexes by copying data from the one
CLEAN plex.
EMPTY: indicates that you have not yet defined which plex has the good data (CLEAN), and
which plex does not have the good data (STALE).
CLEAN: is normal and indicates that the plex has a copy of the data that represents the volume.
CLEAN also means that the volume is not started and is not currently able to handle I/O (by the
admin’s control).
ACTIVE: is the same as CLEAN, but the colume is or was currently started, and the colume is or
was able to perform I/O.
SNAPDONE: is the same as ACTIVE or CLEAN, but is a plex that has been synchronized with
the volume as a result of a “vxassist snapstart” operation. After a reboot or a manual start of the
volume, a plex in the SNAPDONE state is removed along with its subdisks.
STALE: indicates that VxVM has reason to believe that the data in the plex is not synchronized
with the data in the CLEAN plexes. This state is usually caused by taking the plex offline or by a
disk failure.
SNAPATT: indicates that the object is a snapshot that is currently being synchronized but does
not yet have a complete copy of the data.
OFFLINE: indicates that the administrator has issued the “vxmend off” command on the plex.
When the admin brings the plex back online using the “vxmend on” command, the plex changes
to the STALE state.
TEMP: the TEMP state flags (TEMP, TEMPRM, TEMPRMSD) usually indicate that the data was
never a copy of the volume’s data, and you should not use these plexes. These temporary states
indicate that the plex is currently involved in a synchronization operation with the volume.
NODEVICE: indicates that the disk drive below the plex has failed.
REMOVED: has the same meaning as NODEVICE, but the system admin has requested that the
device appear as failed.
IOFAIL: is similar to NODEVICE, but it indicates that an unrecoverable failure occurred on the
device, and VxVM has not yet verified whether the disk is actually bad. Note: I/O to both the
public and the private regions must fail to change the state from IOFAIL to NODEVICE.
Volume States
EMPTY, CLEAN, and ACTIVE: have the same meanings as they do for plexes.
NEEDSYNC: is the same as SYNC, but the internal read thread has not been started. This state
exists so that volumes that use the same disk are not synchronized at the same time, and head
thrashing is avoided.
SYNC: indicates that the plexes are involved in read-writeback or RAID-5 parity
synchronization:
- Each time that a read occurs from a plex, it is written back to all the other plexes that are in the
ACTIVE state.
- An internal read thread is started to read the entire volume (or, after a system crash, only the
dirty regions if dirty region logging (DRL) is being used), forcing the data to be synchronized
completely. On a RAID-5 volume, the presence of a RAID-5 log speeds up a SYNC operation.
NODEVICE: indicates that none of the plexes have currently accessible disk devices underneath
the volume.
Kernel States
Kernel states represent VxVM’s ability to transfer I/O to the volume or plex.
ENABLED: The object can transfer both system I/O and user I/O
DETACHED: The object can transfer system I/O, but not user I/O (maintenance mode)
DISABLED: No I/O can be transferred.
init_type:
zero: sets all plexes to a value of 0, which means that all bytes are null
active: sets all plexes to active and enables the volume and its plexes
clean: If you know that one of the plexes has the correct data, you can select that particular plex
to represent the data of the volume. In this case, all other plexes will copy their content from the
clean plex when the volume is started.
enable: use this option to temporarily enable the volume so that data can be loaded onto it to
make the plexes consistent.
- This command ignores problems with the volume and starts the volume
- Only use this command on nonredundant volumes. If used on nonredundant volumes, data
can be corrupted, unless all mirrors have the same data.
vxmend offon
When analyzing plexes, you can temporarily take plexes offline while validating the data in
another plex.
- To take a plex offline, use the command:
vxmend –g diskgroup off plex
- To take the plex out of the offline state, use:
vxmend –g diskgroup on plex
To recover:
1) Set all plexes to STALE (vxmend fix stale vol01-01)
2) Set the good plex to CLEAN (vxmend fix clean vol01-01)
3) Run “vxrecover –s vol01”
To resolve:
1) Take all but one plex offline and set that plex to CLEAN (vxmend off vol01-02; vxmend fix
clean vol01-01)
2) Run “vxrecover –s”
3) Verify data on the volume
4) Run “vxvol stop”
5) Repeat for each plex until you identify the plex with the good data
The first 2 are well documented elsewhere, but the last one is
not. It is actually very simple and would lend itself well to
scripting.
The Process:
9.) For FC disks you need to change the boot alias to reflect the new WWN.
View and save the aliases:
# eeprom nvramrc 2> /dev/null | sed -e "1s/nvramrc=//p" -e 1d
Use vxeeprom to remove, then re-add the alias for the bootdisk
# vxeeprom devunalias <dm_name>
# vxeeprom devalias vx-<root or mirror> /dev/dsk/c#t#d#
You should be back in action, "vxtask list" should list the plex
attach tasks.
++++++++++++++++++++++++
1) Unmount the file system and/or kill the application(s) to stop all
i/o to the volume.
CLI:
# vxedit -rf rm <vol_name>
CLI:
# vxdg -g <dg> rmdisk <dm_name> (for each disk)
5) Add the disk/s to the new disk group using the original disk
media name/s.
GUI:
bring up a view of the ssa
highlight the appropriate disk
commands -> volume_manager -> add_disk
a pop-up window appears. This is where you change the
default name to be the original dm_name.
CLI:
(if dg already exists)
# vxdg -g <dg> adddisk <dm_name>=<ctd>
(if you need to create one)
# vxdg init <dg> <dm_name>=<ctd>
7) Start the volume (you may need to change it's state "vxmend"
or force start it).
GUI:
highlight the volume
adv_ops -> volume -> start_volumes -> start
CLI:
# vxvol -f start <vol_name>
+++++++++++++++++++++++++
VxVM Plex STATES and State Transition
Commands
Plex State Transition Flowchart
plex/volume
DISABLED EMPTY The volume is iether sparse (volume
lager
than plex contiguous space) or the the
state
is just incorrect. see SRDB ID: 20563
vxvol -f start <vol>
For LOGGING plexs
plex DISABLED STALE vxplex dis <logplex>
vxedit -rf rm <logplex>
root@hpeos003[] ll /etc/vxvmconf
total 66
root@hpeos003[]
VxVM_DG_Config_Backup_File: ora1
vol chkpt1
tutil0="
tutil1="
tutil2="
kstate=ENABLED
r_all=GEN_DET_SPARSE
r_some=GEN_DET_SPARSE
w_all=GEN_DET_SPARSE
w_some=GEN_DET_SPARSE
lasterr=0
use_type=fsgen
fstype="
comment="
putil0="
putil1="
putil2="
state="ACTIVE
writeback=on
writecopy=off
specify_writecopy=off
logging=off
has_logs=off
root@hpeos003[]
We need to use the dgcfgrestore command when we have initialized disks without the
ability to store the configuration database or when we have a single-disk disk group.
In most cases, we have disk groups of more than one disk. In such situations, if we lose a
physical disk, we don't need to use the dgcfgrestore command. As soon as we add the
repaired disk back into the disk group, the configuration information stored on every disk in
the disk group will be copied to the new disk. Here's an example where I have lost the disk
ora_disk3 (=c4t12d0). The first time I try to perform IO to the disk and the IO times out,
we will see errors appear in syslog of the following form:
If you look closely at the errors, you can deduce where the problem lies; 31/0x4c000 is the
major/minor number of the disk that failed, and we can see errors relating to the names of
subdisks. A message is usually sent to the root user as well:
root@hpeos003[]
volume archive in disk group ora1. No replacement was made and the
data2
archive
failures.
dbvol
logvol
disks. These volumes are now unusable and the data on them is
unavailable. These volumes must have their data restored.
The disk will now be flagged as being offline and disabled. A FAILED disk is a disk on
which VxVM cannot read its private or public region. A FAILING disk is where VxVM can
still read the private region of the disk. Affected plexes are marked with a state of IOFAIL.
If possible, subdisks will be relocated to spare disks (more on that later):
root@hpeos003[]
We can query the status of the disk as well as the state of volumes to see which volumes
are still online and active.
Device: c4t12d0
devicetag: c4t12d0
type: simple
Multipathing information:
numpaths: 1
c4t12d0 state=disabled
root@hpeos003[]
root@hpeos003[]
dm ora_disk3 - - - - NODEVICE - -
root@hpeos003[]
Volumes that are still ENABLED are said to be redundant, i.e., they have redundancy
(mirroring, RAID 5) built into their configuration. Volumes that are DISABLED are said to be
non-redundant. When we recover from this situation, any non-redundant volumes will have
data missing from them, which we will have to recover using a previous backup. The
recovery process we are about to go through is similar, in theory, to recovering LVM
structures, i.e., we recover the structure of the disk group (the private region).
Recovering the data is either the job of mirroring/RAID 5 or a job for our backup tapes.
1. Replace the failed disk with a new one. The new disk need not be attached at the
same hardware path but should be the same size and specification as the original
disk. We will the initialize the disk:
2.
3.
4.
root@hpeos003[]
5. Attach the new disk into the disk group using the original disk media name.
6.
7.
8.
root@hpeos003[] vxdg -g ora1 -k adddisk ora_disk3=c4t12d0
root@hpeos003[]
root@hpeos003[]
root@hpeos003[]
This can take some time to complete depending on the number of volumes that need
recovering as well as the use of DRL for mirroring.
root@hpeos003[]
The state of RECOVER means that VxVM knows the data in that plex needs
recovering. Because we have no other plexes from which to recover this volume, we
have no choice but to force-start the volume in order to start a process of recovering
the data from some form of backup tape.
root@hpeos003[]
14. Recover the data for non-redundant volumes. Because we have lost a large chunk of
data from the volume, it is likely we will need to recover the entire volume from
backup tapes. If the volume contained a filesystem, we will need to fix the filesystem
(run the fsck command), mount this filesystem, and then recover that data from
tape.
If this was a FAILING disk, the process of recovery may be slightly different:
1. Establish that the disk is producing intermittent faults. This is a tricky one to
diagnose. If you are seeing multiple SCSI lbolt errors or if you see NO_HW listed in
an ioscan command, it may be that a cable/connector is malfunctioning. On a SAN,
it may be that a switch port is malfunctioning. In this situation, hardware
troubleshooting comes to the fore. This can be time consuming and costly if we need
to replace components. If it is simply a loose cable, then we can simply force HP-UX
to rescan for devices, i.e., run ioscan -fnC disk.
2. Force VxVM to reread the private area of all disks: vxdctl enable.
3. Reattach the device to the disk media record: vxreattach.
6. Recover non-redundant volumes. This can involve fixing the filesystems (running the
fsck command) and possibly recovering corrupt data files from backup tapes.
If this is happening on a regular (or mostly regular) basis, I would consider having a
hardware engineer perform some diagnostic testing on the device and try to schedule some
planned down time in order to replace the device.
Associated with these kernel states, we have Volume and Plex states (see Table 7-5).
Together, the Kernel and the Volume/Plex states should give us some idea as to what
actions to take next.
Simply knowing these states is not enough to be able to perform credible recovery of a
failed disk. We need to understand and be able to react to different combinations of kernel
and volume/plex states (see Table 7-6). Here are some common combinations and an
appropriate Next Step. These Next Steps should not be viewed in isolation. Some of them
are appropriate for redundant volumes (e.g., vxrecover), while others are appropriate for
non-redundant volumes (e.g., vxvol -f start):
# vxdctl enable
# vxreattach
# vxrecover
Table 7-6. Kernel/Volume States and the Next Step
Kernel/Volume or Plex State Next Step
# vxdisk init
# vxdg -k adddisk
# vxrecover
# vxvol -f start
DISABLED/IOFAIL # vxrecover
DETTACHED/IOFAIL
DISABLED/STALE # vxrecover
DISABLED/ACTIVE # vxrecover -s
DISABLED/OFFLINE # vxmend on
DISABLED/REMOVED # vxdg -k adddisk
The use of the vxmend command is discussed in the Veritas literature. The vxmend command
can change the state of volumes and plexes depending on what is required, e.g., changing
the state of a STALE plex to CLEAN via the vxmend fix CLEAN command. This can be useful
but also very dangerous. When synchronizing a volume, we will want to synchronize from a
CLEAN plex to all STALE plexes. Deciding which plex has the good data can be quite difficult.
We would need some underlying application utility to analyze the data in the volume, which
is not trivial. If such a situation is possible, then we could do the following:
vxprivutil list
List Disk Private Region vxprivutil list
/dev/rdsk/c0t0d0s2
Disk Group Commands
Operation Command Example
Plex Commands
Operation Command Example
Subdisk commands
Operation Command Example
Volume Commands
Operation Command Example
Summary of plex states
State Description Comments
IOFAIL The plex is detached from the The only way to fix this is to
volume replace the failed disk but
veritas can still read the private
region on the disk
NODEVICE No disk access recorded The disk can not be read at all
Disk device for the plex is The disk has been manually
REMOVED
removed removed
Changing state of plexes
From To How