Veritas Volume Manager (VxVM) 5.1 SP1 RP2 P2 HF4 (Solaris) addresses multiple "vxdg import" issues for diskgroups created with a dg version less than 140, including fixes for cloned related diskgroups

Problem

Veritas Volume Manager (VxVM) 5.1 SP1 RP2 P2 HF4 (Solaris) addresses multiple "vxdg import" issues for diskgroups created with a dg version less than 140, including fixes for cloned related diskgroups.

Without 5.1 SP1 RP2 P2 HF4/HF5 it may not be possible to import cloned diskgroups or diskgroup with a dg version less than 140.

Multiple vxdg import code fixes are included in 5.0 MP3 RP5 HF7 and 5.1 SP1 RP2 P2 HF4 & HF5 for Solaris

Error Message

# vxdg -C import datadg
VxVM vxdg ERROR V-5-1-10978 Disk group datadg: import failed:
Disk group version doesn't support feature; see the vxdg upgrade command

or

# vxdg import oracledg

VxVM vxdg ERROR V-5-1-10978 Disk group oracledg: import failed:
Disk group has no valid configuration copies

Cause

5.1SP1RP2 introduced a code regression surrounding the diskgroup import process, reference e2165394.


Etrack 2165394

CLONE: dg imported by selecting wrong disks. After destroying original dg, when try to import clone devices without useclonedev option with dgname, then it import dg with original disks.

S.D.R.F content

SYMPTOM:

If the cloned copy of a diskgroup and a destroyed diskgroup exists on the system, an import operation imports destroyed diskgroup instead of cloned one. For example, consider a system with diskgroup dg containing disk disk1. Disk disk01 is cloned to disk02. When diskgroup dg containing disk01 is destroyed and diskgroup dg is imported, VXVM should import dg with cloned disk i.e. disk02. However, it imports the diskgroup dg with disk01.


DESCRIPTION: After destroying a diskgroup, if the cloned copy of the same diskgroup exists on the system, the following disk group import operation wrongly identifies the disks to be import and hence destroyed diskgroup gets imported.


RESOLUTION:

The diskgroup import code is modified to identify the correct diskgroup when a cloned copy of the destroyed diskgroup exists.

5.0 MP3 RP5 HF7 and 5.1 SP1 RP2 P2 HF4 & HF5 addresses the code regression introduced with the fix of e2165394 through e2553729.

Etrack 2553729 (2640671)

dg ver 140 disk attribute clone_disk is reported following a vxdg deport and import operation

S.D.R.F content

SYMPTOM:

Following symptoms can be seen during 'Upgrade' of VxVM (Veritas Volume Manager):

i) 'clone_disk' flag is seen on non-clone disks in STATUS field when 'vxdisk -e list' is executed after upgrade to 5.1SP1 from lower versions of VxVM.

eg: DEVICE TYPE DISK GROUP STATUS
emc0_0054 auto:cdsdisk emc0_0054 50MP3dg online clone_disk
emc0_0055 auto:cdsdisk emc0_0055 50MP3dg online clone_disk

ii) Clone disk groups (dg) whose versions are less than 140 do not get imported after upgrade to VxVM versions 5.0MP3RP5HF1 or 5.1SP1RP2.

e.g.: # vxdg -C import <dgname>
VxVM vxdg ERROR V-5-1-10978 Disk group <dgname>: import failed:
Disk group version doesn't support feature; see the vxdg upgrade command


DESCRIPTION:

While uprading VxVM


i) After upgrade to 5.1SP1 or higher versions: If a dg which is created on lower versions is deported and imported back on 5.1SP1 after the upgrade, then "clone_disk" flags gets set on non-cloned disks because of the design change in UDID (unique disk identifier) of the disks.

ii) After upgrade to 5.0MP3RP5HF1 or 5.1SP1RP2: Import of clone dg with versions less than 140 fails.


RESOLUTION:

Code changes are made to ensure that:
i) clone_disk flag does not get set for non-clone disks after the upgrade.
ii) Clone disk groups with versions less than 140 get imported after the upgrade.

Solution

The issue is addressed by applying VxVM 5.1 SP1 RP2 P2 HF4 & HF5 for which can be obtained from Veritas support.
5.1 SP1 RP2 P2 HF5 is recommended as this includes improved vxdg import messaging.

Veritas is advising customer to apply this hot-fix if encountering vxdg import related issues.

Etrack incident 2098267 which involves diskgroup auto-import issue with cloned devices is fixed in 5.1SP1 RP2.  The autoimport issue surrounding cloned devices is NOT encountered in 5.1SP1 RP2.   This fix is not ported back to the 5.0MP3 branch yet, the latest patch 5.0MP3 RP5 HF7 as of today (April 2012) still doesn't have the fix.

Applies To

Solaris