cancel
Showing results for 
Search instead for 
Did you mean: 

VxVM Disk UDID is correct. Disk Tag is incorrect.

Gotham_Gerry
Level 4

We recently made a change on our SAN that resulted in all the EMC disk's WWN changing.  Now all my VxVM disks have a correct UDID, but one of the disk tags still references the old disk type and WWN.  For example:

# vxdisk -g datadg -v list datadg01

...

udid:      EMC%5FInvista%5FDISKS%5F60001240000000102071A5C6B99843D8
 ...
Annotations:
 tag      udid_scsi3=EMC%5FInvista%5FDISKS%5F60001240000000102071A5C6B99843D8
 tag      udid_asl=DGC%5FVRAID%5FQPM01104902923%5E3006016041352800DC79A223C758D141

...

The second tag listed is incorrect. That is information from the disk before we made the SAN change.  Will this cause us problems?

The reason I ask is that we've had two servers get a corrupted VxVM configuration some time after the SAN change.  In one case we had corruption and lost a file system.  Not sure if our problems are the result of our SAN change or not.  Is there something we should do to update VxVM when all the disk WWN change?  All I've been doing is a reconfigure reboot, and the disk groups import without error. 

Thanks.

 

1 ACCEPTED SOLUTION

Accepted Solutions

Gaurav_S
Moderator
Moderator
   VIP    Certified

Hi,

Thanks for giving more clarity .. Well, I would expect that VxVM should take care of this automatically as it has already scanned the new tag, it should also get the old one out however because its 5.0, I am little unsure.

One more question, have you ever received an error of UDID_mismatch in the server ? usually while importing diskgroup or in error messages ?

I was thinking that an updateudid command would be worth a try to see if the tags get updated however 5.0 had some reported issues on running updateudid command so I won't recommend it without taking inputs from Symantec support directly, see technote below

http://www.symantec.com/docs/TECH54882

If this tag is kept as it is, I would say max that you will face is UDID_mismatch errors which was reported in 5.0 most (as UDID was introduced in 5.0) & this error mostly use to appear during import operation of diskgroup where import will fail with UDID mismatch error. Refer below article for what is UDID & what is UDID mismatch

http://www.symantec.com/docs/TECH128957

The above article also reads about udid_asl tag,

The second string "udid_asl" (or udid_jbod if the disk is not claimed by any ASL) is a permanent on-disk record of the udid found during the disk initialization (vxdisksetup or vxdisk init).   "udid_asl" is a permanent record on the disk and will change after disk initialization until "vxdisk updateudid" is run.

For better environment, I would recommend for VxVM to be upgraded to latest version.

 

G

 

View solution in original post

6 REPLIES 6

Gaurav_S
Moderator
Moderator
   VIP    Certified

Hello,

Can you share what version of VXVM you are using ? also is this a clustered setup ? which operating system ? what storage array you have & what exactly was the change ?

About tag, tag can be removed using below command:

vxdisk [-g diskgroup] rmtag {disk {site=siteid | name} [name...]|
    {site|name} {disk|{e|encl|enclr}:enclosure} [{disk|{e|encl|enclr}:enclosure}...]}

you wouldn't need a reconfig reboot for this. Also, do you have setup like a campus cluster ?

 

G

 

 

Gotham_Gerry
Level 4

Thank you for responding.  VxVM version is 5.0, running on Solaris 10, no cluster.

The SAN change resulted in all our EMC Symmetrix or Clariion disks changing to type "Invista", and all the WWN changed.  This required a reconfigure reboot, because the OS need to rebuild all its device files to see the disks.  The Volume Managers (ZFS, SVM, Oracle ASM, & VxVM) all were able to locate their disks after the reboot, and all the data is there. 

Apparently the "udid_asl=" tag cannot be removed:

# vxdisk -g dssnadg rmtag udid_asl=DGC%5FVRAID%5FANM00124922932%5F6006016041152800302B8285305AC021

VxVM vxdisk ERROR V-5-1-13909  The rmtag command failed on the following devices with error: tagid is reserved for VM use
disk_107
 

 

Gaurav_S
Moderator
Moderator
   VIP    Certified

Hi,

Thanks for giving more clarity .. Well, I would expect that VxVM should take care of this automatically as it has already scanned the new tag, it should also get the old one out however because its 5.0, I am little unsure.

One more question, have you ever received an error of UDID_mismatch in the server ? usually while importing diskgroup or in error messages ?

I was thinking that an updateudid command would be worth a try to see if the tags get updated however 5.0 had some reported issues on running updateudid command so I won't recommend it without taking inputs from Symantec support directly, see technote below

http://www.symantec.com/docs/TECH54882

If this tag is kept as it is, I would say max that you will face is UDID_mismatch errors which was reported in 5.0 most (as UDID was introduced in 5.0) & this error mostly use to appear during import operation of diskgroup where import will fail with UDID mismatch error. Refer below article for what is UDID & what is UDID mismatch

http://www.symantec.com/docs/TECH128957

The above article also reads about udid_asl tag,

The second string "udid_asl" (or udid_jbod if the disk is not claimed by any ASL) is a permanent on-disk record of the udid found during the disk initialization (vxdisksetup or vxdisk init).   "udid_asl" is a permanent record on the disk and will change after disk initialization until "vxdisk updateudid" is run.

For better environment, I would recommend for VxVM to be upgraded to latest version.

 

G

 

Gotham_Gerry
Level 4

>One more question, have you ever received an error of UDID_mismatch in the server ?

Yes, we are familar with that error, but in this case we have not encountered it.

Thank you for the good information on the udid_asl tag. I did try 'vxdisk updateudid' on one of these disks, and it changed nothing. 

Gaurav_S
Moderator
Moderator
   VIP    Certified

Well, thats interesting, I would assume then this record will change if the disk is initialized again..

as the disk may already be in use, need to be careful while reinitializing the disk using same public & private offset values else there may be risk to data

you can find puboffset & privoffset values from "vxdisk list <disk>" output & then reinitialize the disk using

# vxdisksetup -i <disk> puboffset=<value>  privoffset=<value> pubslice=<value> privslice<value>

 

G

TonyGriffiths
Level 6
Employee Accredited Certified

Hi

If I understood correctly, some of the vendor attributes of a disk changed following a SAN change.

As such the UDID that VxVM built from the original attributes and wrote to the disk is now different to the one that it is now discovered.

In theory the "vxdisk updateudid" should correct this. You should also consider upgrading as you mentioned the version was 5.0

cheers

tony