V-5-1-10978 - Diskgroup import failed with error message "import failed: No valid log copies in disk group"

Article: 100002601
Last Published: 2023-11-16
Ratings: 1 1
Product(s): InfoScale & Storage Foundation

Problem

Diskgroup fails to import with message: No valid log copies in disk group

 

Error Message

VxVM vxdg ERROR V-5-1-10978 Disk group testdg: import failed: No valid log copies in disk group.

 

Cause

The following conditions trigger/contributed to the diskgroup import failure:

-Diskgroup had a mix of disks with non-UDID_mismatch  and UDID_mismatch flags set
-Log copies were enabled only on those disks which had UDID_mismatch set

 

The following command can be used to check if the diskarray hardware-generated udid and on-disk udid match each other.

# vxdisk -v list hds9500-alua0_84
Device:    hds9500-alua0_84
devicetag: hds9500-alua0_84
type:      auto
clusterid: alawrac
disk:      name=cvmdgH11 id=1166620242.322.alaw1
group:     name=cvmdg id=1166620276.324.alaw1
info:      format=cdsdisk,privoffset=256,pubslice=2,privslice=2
flags:     online ready private autoconfig shared autoimport imported
pubpaths:  block=/dev/vx/dmp/hds9500-alua0_84s2 char=/dev/vx/rdmp/hds9500-alua0_84s2
guid:      {7f2a122e-1dd2-11b2-8947-0003bae2eb47}
udid:      HITACHI%5FDF600F%5FD600101C%5F0054         
<<< diskarray hardware-generated UDID
site:      -
version:   3.1
iosize:    min=512 (bytes) max=2048 (blocks)
public:    slice=2 offset=2304 len=20887296 disk_offset=0
private:   slice=2 offset=256 len=2048 disk_offset=0
update:    time=1320116885 seqno=0.253
ssb:       actual_seqno=0.2
headers:   0 240
configs:   count=1 len=1280
logs:      count=1 len=192
Defined regions:
 config   priv 000048-000239[000192]: copy=01 offset=000000 enabled
 config   priv 000256-001343[001088]: copy=01 offset=000192 enabled
 log      priv 001344-001535[000192]: copy=01 offset=000000 enabled
 lockrgn  priv 001536-001679[000144]: part=00 offset=000000
Annotations:
 tag      udid_asl=HITACHI%5FDF600F%5FD600101C%5F0054       
<<< on-disk UDID
Multipathing information:
numpaths:   2
c3t50060E80004372C0d0s2 state=enabled type=primary
c3t50060E80004372C1d0s2 state=enabled type=primary

Command to check if hardware-generated UDID is consistent with on-disk UDID.

# vxdisk -q list | cut -f1 -d' ' | xargs -i vxdisk -v list {} | egrep '^Device|^disk:|^udid:|udid_asl' | sed 's/^udid: *//' | sed 's/.*udid_asl=//' | uniq -c

For example,

 # vxdisk -q list | cut -f1 -d' ' | xargs -i vxdisk -v list {} | egrep '^Device|^disk:|^udid:|udid_asl' | sed 's/^udid: *//' | sed 's/.*udid_asl=//' | uniq -c
   1 Device:    hds9500-alua0_84
   1 disk:      name=cvmdgH11 id=1166620242.322.alaw1
   2 HITACHI%5FDF600F%5FD600101C%5F0054
           <<< udid and udid_asl are the same

   1 Device:    hds9500-alua0_86
   1 disk:      name= id=1166619742.80.alaw2

   1 HITACHI%5FDF600F%5FD600101C%5F0056         <<< hardware-generated udid
   1 HITACHI%5FDF600F%5FD600888D%5F0096         <<< is dfferent from the on-disk udid (udid_asl)
 

Solution

The following commands should be executed after an array migration on deported diskgroups and prior to (re)importing.  For all disks  whose UDID is mis-matched, execute updateudid and turn off clone as follows:

# vxdisk updateudid  <disk>   

After executing the above command it will mark disk as clone disk but in reality disk may not be a real clone so this command will reset the clone flag.
 

# vxdisk set <disk> clone=off        

After setting the clone flag off, import should work.
 

# vxdg -Cf import <diskgroup>

 

 

Was this content helpful?