Document ID: 278998

http://support.veritas.com/docs/278998

VERITAS Volume Manager 4.1 persistently labels disk devices. The 'vxdisk list'
command will no longer reflect underlying OS device name changes.
Details:
The vxdisk list command can sometimes be used by external applications/agents to
determine the status of Volume Manager disk devices under Solaris. The assumption
that 'VxVM_Device = OS_Device' is normally considered to be true, unless Enclosure
Based Names are in use.

In VERITAS Volume Manager 4.1, the disk devices are persistently "labeled", and
these associations are stored in the /etc/vx/disk.info file. This can cause
confusion if the Solaris OS device tree decides to rename disk devices as part of
a reconfiguration reboot.

Reasons why a Solaris disk device name may change and the expected changes to OS
device name:
1. Hardware changes resulting in changes to SCSI Controller number, e.g. c2 -> c5
2. Hardware changes resulting in changes to SCSI Target number, e.g. c2t1 -> c2t3
3. Hardware changes resulting in changes to SCSI LUN number, e.g. c2t1d1 -> c2t1d8

Note: It is not the intention of this TechNote to describe the behavior of the
Solaris Device Management subsystem.

If the Solaris device names were to change, vxdisk list may confuse the
relationship between OS device and Volume Manager device name because the change
will not be reflected in vxdisk list output:

Before:
# vxdisk list
DEVICE TYPE DISK GROUP STATUS
c0t0d0s2 auto disk01 rootdg online
c1t1d0s2 auto d1 testdg online
c1t2d0s2 auto d2 testdg online

After the disk target numbers were changed, there is no change in the vxdisk list
output:
# vxdisk list
DEVICE TYPE DISK GROUP STATUS
c0t0d0s2 auto disk01 rootdg online
c1t1d0s2 auto d1 testdg online
c1t2d0s2 auto d2 testdg online

The command vxdisk -e list makes relating the OS device and Volume Manager device
much easier with the addition of the OS_NATIVE_NAME column:

Before:
# vxdisk -e list
DEVICE TYPE DISK GROUP STATUS OS_NATIVE_NAME
c0t0d0s2 auto disk01 rootdg online c0t0d0s2
c1t1d0s2 auto d1 testdg online c1t1d0s2
c1t2d0s2 auto d2 testdg online c1t2d0s2

After the disk target numbers were changed, the change is visible in the vxdisk -e
list output:
# vxdisk -e list
DEVICE TYPE DISK GROUP STATUS OS_NATIVE_NAME
c0t0d0s2 auto disk01 rootdg online c0t0d0s2
c1t1d0s2 auto d1 testdg online c1t2d0s2
c1t2d0s2 auto d2 testdg online c1t1d0s2

This behavior of vxdisk list in VERITAS Volume Manager 4.1 can cause confusion if
a systems administrator were to assume that the DEVICE column in vxdisk list
represents the OS_NATIVE_NAME. These can be different under many circumstances,
especially on systems that have a high frequency of changes made to their storage
subsystems.

How to rebuild the 'DEVICE-> OS_NATIVE_NAME' association when using VERITAS Volume
Manager 4.1

If the Solaris systems administrator wishes to re-associate the VxVM DEVICE and
the OS_NATIVE_NAME, then one of these two processes should be followed:

Recommended process for non-VERITAS Cluster Server environments:

1. Move or remove the /etc/vx/disk.info file
2. Restart vxconfigd using vxconfigd -k or reboot the server

Recommended process for VERITAS Cluster Server environments:

1. For each Cluster Server service group with Volume Manager resources, freeze the
groups:
- /opt/VRTSvcs/bin/hagrp -freeze <service_group>
2. Move or remove the /etc/vx/disk.info file
3. Restart vxconfigd using vxconfigd -k or reboot the server
4. For each Cluster Server service group with Volume Manager resources, unfreeze
the groups:
- /opt/VRTSvcs/bin/hagrp -unfreeze <service_group>

This behavior is new to VERITAS Volume Manager 4.1, and may be deemed unexpected
behavior to an experienced user of the Volume Manager. Even if the Volume Manager
device name does not match its equivalent OS device name, there is no risk of data
loss, nor is there any impact on the ability of Volume Manager to maintain I/O, or
maintain Volume Manager private region contents.

If using vxdisk list to determine the name of an OS device, the command vxdisk -e
list is recommended, and the OS_NATIVE_NAME column should be used to gather the OS
device name.

The feature of "Persistent Native Names" is clearly documented in the VERITAS

Volume Manager 4.1 Administrator's Guide for Solaris, page 90.

Related Documents:

275760: VERITAS Volume Manager (tm) 4.1 Administrator's Guide for Solaris
http://support.veritas.com/docs/275760

Supplemental Material:

System: Ref.# Description

ETrack: 423812 unexpected stale info in the disk.info file after upgrade from
3.2 to 4.1
Products Applied:
Volume Manager for UNIX/Linux 4.1 (Solaris)

Last Updated: September 20 2005 12:39 AM GMT

Expires on: 365 days from publish date
Subscribe Via E-Mail IconSubscribe to receive critical updates about this document

Subjects:
Solaris
Application: Device Management
Volume Manager for UNIX/Linux
Application: Device Management, How To

Languages:
English (US)

Operating Systems:
Solaris

10, 8.0, 9.0

Symantec World Headquarters:

20330 Stevens Creek Blvd. Cupertino, CA 95014
World Wide Web: http://www.symantec.com,
Tech Support Web: http://entsupport.symantec.com,
E-Mail Support: http://seer.entsupport.symantec.com/email_forms,
FTP: ftp://ftp.entsupport.symantec.com or http://ftp.entsupport.symantec.com

THE INFORMATION PROVIDED IN THE SYMANTEC SOFTWARE KNOWLEDGE BASE IS PROVIDED "AS
IS" WITHOUT WARRANTY OF ANY KIND. SYMANTEC SOFTWARE DISCLAIMS ALL WARRANTIES,
EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SYMANTEC SOFTWARE OR ITS SUPPLIERS BE
LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES,EVEN IF SYMANTEC
SOFTWARE OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR
CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.