12-23-2013 10:12 AM
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.
Solved! Go to Solution.
12-23-2013 07:40 PM
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
12-23-2013 10:33 AM
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
12-23-2013 11:37 AM
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
12-23-2013 07:40 PM
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
12-30-2013 11:55 AM
>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.
01-03-2014 10:04 PM
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
01-17-2014 08:07 AM
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