Error Message

Potential error message with 5.1 SP1 RP3 and 6.0.1 onwards:

# /usr/sbin/vxdg -g datadg adddisk emc0_00e5=emc0_00e5
VxVM vxdg ERROR V-5-1-0 Disk Group datadg has only cloned disks and tyring to add standard disk to diskgroup. Mix of standard and cloned disks in a diskgroup is not allowed. Please follow the vxdg (1M) man page.

SRDF example

The Primary server hosts the SRDF-R1 devices, and the secondary server hosts the SRDF-R2 devices. The on-disk UDID content is then replicated from the Primary SRDF-R1 devices to the corresponding SRDF-R2 devices on the Secondary server.
 

Figure 3.0


 

Primary (source) server:

# vxdisk -eo alldgs list | grep srdf
emc0_008d    auto:cdsdisk   -            (datadg)    online               c1t5006048C5368E5A0d223s2 lun srdf-r1
emc0_008e    auto:cdsdisk   -            (datadg)    online               c1t5006048C5368E580d268s2 lun srdf-r1

# ./vxudidlist.sh | egrep 'emc0_008d|emc0_008e‘
emc0_008d dgname:datadg EMC%5FSYMMETRIX%5F000290300822%5F220008D000 EMC%5FSYMMETRIX%5F000290300822%5F220008D000  match
emc0_008e dgname:datadg EMC%5FSYMMETRIX%5F000290300822%5F220008E000 EMC%5FSYMMETRIX%5F000290300822%5F220008E000  match

 

Secondary (target) server:

 
# vxdisk -eo alldgs list | grep srdf
emc1_0073    auto:cdsdisk   -            (datadg)    online udid_mismatch c1t5006048C536979A0d66s2 lun WD srdf-r2
emc1_0074    auto:cdsdisk   -            (datadg)    online udid_mismatch c1t5006048C536979A0d67s2 lun WD srdf-r2

 

# ./vxudidlist.sh | egrep 'emc1_0073|emc1_0074‘
emc1_0073 dgname:datadg online EMC%5FSYMMETRIX%5F000290301414%5F1400073000 EMC%5FSYMMETRIX%5F000290300822%5F220008D000  mismatch
emc1_0074 dgname:datadg online EMC%5FSYMMETRIX%5F000290301414%5F1400074000 EMC%5FSYMMETRIX%5F000290300822%5F220008E000  mismatch

 

To increase data integrity, additional VxVM code enhancements were introduced in VxVM 5.1 SP1 RP3, and 6.0.1. A disk group must now consist of just standard (data) disks, or clone/replicated disk types (a single lun class). 

Figure 2 - LUN classes overview


Prior to the above mentioned VxVM versions, VxVM was not validating whether the disk group consisted solely of clone devices, or standard data disks, allowing for a disk group to have a mixture of LUN classes, leading to potential data corruption, or loss.

Going forward, unless the disk group consists of just a single LUN class, LUNs from different LUN classes cannot be assigned to the same disk group using the vxdg -g adddisk = command.

VxVM refers to two UDID values:

• The UDID value returned by the DDL (Device Discovery Layer) which is the correct (true) UDID value of the LUN
• The UDID written on-disk can be from a different source.

Standard disks would normally not report a UDID mismatch state, as the two UDID values would be aligned (match each other).
Clone devices would normally report a UDID mismatch condition, as the clone will inherit the on-disk UDID from the corresponding source disk.

Replicated (secondary) devices will report a UDID mismatch condition, as the secondary target disk will inherit the on-disk UDID from the corresponding source (primary) disk.

 

The UDID related content can be reported using the following vxudidlist.sh script:
 

#!/bin/ksh# vxudidlist.sh - Compare UDID values until upgrading to 6.x which has the "vxdisk -o udid list" commandecho "Check excludes disks reported in online invalid|error|LVM|ZFS states"echo "DA_NAME DGNAME DDL_UID PRIV_UDID CHECK"for disk in `vxdisk -q list | egrep -v 'online invalid|error|LVM|ZFS' | awk '{ print $1 }'`docontent=`vxdisk -v list $disk |egrep '(Device|group|udid)' |awk '{ print $2 }' |sed "s/name=/dgname:/g" |sed "s/udid_asl=//g" |tr -s "n" " "`echo "$content" | awk '{ if ($3==$4) print $0,"match" ; else print $0,"mismatch" }'done# END OF SCRIPT - S.N.Dummer - Jan 2013

VCS engineering has created a preonline trigger which is solely responsible for updating the on-disk UDID-based content for the primary (read-write enabled) replicated devices. When migrating the replication roles between a pair of devices, it is critical that the UDID be updated on-disk, prior to importing the disk group.

To achieve this task, the preonline trigger is called when the corresponding VCS ServiceGroup (SG) is failed over to the alternate system. The migration of the actual replication roles is the responsibility of the applicable VCS replication agent calling the underlying hardware storage commands.

This preonline trigger will ensure that the UDID value from the DDL (Device Discovery Layer) replaces the UDID value retained on disk. This aligns the two UDID values.

Please contact Veritas Support if you feel your environment would warrant the implementation of the VCS preonline trigger.

 

Applies To

Cross platform issue

This document attempts to explain how Veritas Cluster Server (VCS) can be used in conjunction with hardware-based replicated solutions, such as EMC SRDF, HDS TrueCopy and IBM GlobalMirror, where the Veritas Volume Manager (VxVM) UDID (Unique Disk Identifier) related disk content needs to be updated at the appropriate time, prior to importing the VxVM managed disk group. VCS provides several replication agents that offer support for application failover and recovery. The VCS-supported agents provide an interface into the array support and intelligence surrounding the replicated states between the storage arrays that are attached to the VCS servers. The appropriate VCS agent ensures that the servers have the required replicated resources online and have exclusive access to the configured devices. The Veritas Volume Manager (VxVM) managed device content, such as the diskid, dgid and on-disk UDID (Unique Disk Identifier) is replicated from the source (primary) to the target (secondary) replicated device. This results in an intentional "udid_mismatch" state on the target devices.


Figure 1

Note: The UDID value stored in the DDL (Device Discovery Layer) will remain unique for both the primary and secondary disk types.

As the replicated roles are migrated from the original primary that is hosting the source replicated devices, to the secondary server that is hosting the target replicated devices, the replicated devices associated with the secondary server are promoted to a read-write (rw) state on the newly-promoted primary server.

The newly-promoted replicated devices will have an intentional "udid_mismatch" state, as per design. As a consequence, this can lead to issues involving the addition of newly-initialized devices on the new primary server, as VxVM believes the newly promoted disks are "clone" devices. The newly-initialized disk itself will not report a "udid_mismatch" state, as the UDID value from the DDL were aligned with the on-disk value when the disk was initialized, using the "vxdisksetup" CLI interface. The newly-initialized device will be classed as a "standard" (std) data disk. Due to VxVM code enhancements to safeguard against potential data loss, VxVM will no longer permit a mixture of different LUN types within the same disk group.

ETrack: 2815517 ETrack: 3132040