Lun addition followed by a "vxdctl enable" operation can cause data corruption, when Volume Manager's (VxVM) configuration daemon, vxconfigd, is migrating disk-access names (DANAME) with simultaneous active I/O on the devices


Data corruption can occur in any one of the following configurations, when new LUNs are provisioned or removed under VxVM, while IOs are in progress.

1. The VxVM device naming scheme is EBN (enclosure based naming) and persistence=off
2. The VxVM device is configured with single path
3. The VxVM device is controlled by non-VxVM DMP Multipathing Driver (Ex: MPXIO, MPIO et.,) which presents only one logical path to the OS

Error Message

The following "WARNING" messages can be seen

vxio: [ID 914260 kern.notice] NOTICE: VxVM vxio V-5-0-1046 changing UDID for disk <DANAME>

vxio: [ID 718197 kern.notice] NOTICE: VxVM vxio V-5-0-1056 change disk <DANAME> has a non-unique UDID


There is a possibility of change in name of the DA records, when LUNs are removed or added followed by the following commands, since the persistence naming is OFF.

(a) vxdctl enable
(b) vxdisk scandisks
Executing the above commands claims all the devices and builds the attribute list for all the claimed disks. This attribute list is built according to the new names. The new attribute list is used to refresh the in core DA records at a point in the code, where the DA names are not yet updated with new names. Thus the DA refreshes lead to an incorrect device mapping. In this process of updating, at later point of time the change in DA name is recognized and accordingly the device number is updated with correct device number. Thus an intermittent data corruption can be observed if IOs are in progress during this process of DA record updating.


Set disk to persistence naming this problematic vxvm code can be avoided.


Please run the following commands to avoid the problem:
#vxddladm set namingscheme=ebn persistance=yes
Check the following file is created
#cat /etc/vx/
bash-3.00# cat /etc/vx/
EMC%5FSYMMETRIX%5F000190301018%5F60060480000190301018533030304335 c4t60060480000190301018533030304335d0 0x4ec0100 0x2 emc1_00c5 EMC 000190301018
EMC%5FSYMMETRIX%5F000190301018%5F60060480000190301018533030304338 c4t60060480000190301018533030304338d0 0x4ec00b0 0x2 emc1_00c8 EMC 000190301018
EMC%5FSYMMETRIX%5F000190301018%5F60060480000190301018533030323442 c4t60060480000190301018533030323442d0 0x4ec0058 0x2 emc1_024b EMC 000190301018
FUJITSU%5FMAY2073RCSUN72G%5FDISKS%5F500000E011FF7850 c0t0d0 0x4ec0000 0x2 disk_1 Disk DISKS
The file should reflect persistence=yes.
scheme=ebn persistence=yes mode=default lowercase=yes use_avid=yes
This issues can be tracked through Etrack (e2349352 )
This issue is fixed in the following patches:
- 5.1SP1RP2 on Solaris, Linux and AIX
- 5.0.1RP3P2 on HP-UX 11.31
- 5.0MP2RP3P1 on HP-UX 11.23
- 5.0MP3RP5HF1 on Solaris
- 5.0MP4RP1HF7 on Linux
- 5.0MP3RP5HF9 on AIX

Terms of use for this information are found in Legal Notices.



Did this article answer your question or resolve your issue?


Did this article save you the trouble of contacting technical support?


How can we make this article more helpful?

Email Address (Optional)