cloned disks not "online aliased"

[Johnny Vergeer]

Greetings all,

My client is experiencing a problem using “volclonedg”. Running “voldisk list” on a target system reveals that some of the cloned disks in a disk group are presented as “online” and not “online aliased” as would be expected. When using a different target system to recover the clone, the same disks will be problematic.

This behavior has been observed on EMC (CLARiiON and Symmetrix) storage and non EMC storage. All the systems in question are running v5.1B (PK4).

Has anyone seen this problem before? Any idea where to start debugging this?

Many

[Michael Schulte zur Sur]

Hi,

there is already pk5 out there but there is only the case that disk erreonously are labeled as online aliased but not like your case. There is however a hint in man volclonedg. Please check it whether it applies to your system.

greetings,

Michael

To ascertain which disks are LSM disk clones, run the voldisk list command.
The output from this command indicates cloned disks with a status of online
aliased.

If LSM has not been made aware of the cloned disks and the autoconfigura-
tion feature is enabled (this is the default; see vold(8) for more informa-
tion), run the voldctl enable command before running voldisk list.

[Han Pilmeyer · Accepted solution]

A disk is identified as "aliased" when the WWID that is recorded in the LSM metadata on the disk differs from the WWID of the LUN. You can check the LSM recorded WWID on the disk with the volprivutil command and the WWID of the disk with "hwmgr -show scsi -full -id ".

Haven't heard of any problems in this area recently.

[Han Pilmeyer]

One more thing... after you create and present the business copy (BCV) to the system, if you do a "hwmgr -scan comp -cluster" followed by a "voldctl enable" after the disks are registered (check with "evmwatch -A" as this is done asynchronously), then you don't need to run "volclonedg" to see if the disks are correctly identified by LSM. This could save you a lot of time as "volclonedg" is usually slow.

When you do any of this sort of testing ALWAYS have a "evmwatch -A" running to see what is happening.

[Johnny Vergeer]

Thanx Michael & Han for the feedback so far.

Using "volprivutil list" to look at the LSM data on disks on the parent system, we found that WWID is set to all zero's on disks that display as "online" only on the target.

Disks that show as "online aliased" on the target have valid WWID data set.

Now to find out how and why the disks on the parent system get into this incorrect state.

/usr/lib/lsm/bin/volprivutil list /dev/rdisk/dsk385h
<...>
public: slice=6 offset=16 len=141415408
private: slice=7 offset=0 len=4096
update: time: 1114484766 seqno: 0.13
headers: 0 248
configs: count=1 len=2993
logs: count=1 len=453
WWID: 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0
tocblks: 0
tocs: 1/4095
Defined regions:
config priv 17- 247[ 231]: copy=01 offset=000000 disabled
config priv 249- 3010[ 2762]: copy=01 offset=000231 disabled
log priv 3011- 3463[ 453]: copy=01 offset=000000 disabled

[Han Pilmeyer]

Are these old disks that have the WWID set to zero in the LSM metadata?

This could be the original probelm that I think Michael was referring to. When support for this was first introduced with V5.1A PK2, the old disks were not always correctly updated. There should be an article about this somewhere. I'll have a look.

[Johnny Vergeer]

Hello Han,

Sorry for the late reply to your questions. I don't have direct access to these systems, so can't play at my own leisure.

From what I can gather from the sysadmins, these are not particularly old disks, and were most probably created under V5.1B.

We have noticed that using "voldisksetup -i" sets the WWID in the LSM metadata to all zero's. Only once "voldiskadd" is executed, does the WWID data get set. It's still a mystery how some of the LSM disks in active disk groups got to have all zero set for WWID. We have however confirmed that this unset WWID value is causing the disk clones to be incorrectly displayed as "online" and not "online aliased" at the target system

Apart from using "volevac" to move data off the affected disk and "re-introducing" the disk to LSM, are there any other ways to re-initialize the disk to LSM and emulate the steps that voldiskadd would do without affecting the data on the actual disks?

Finding an elegant way to write the correct LSM metadata to the disk without having to move the data off the disk would be very helpful.

Best regards
johnny

[Han Pilmeyer]

I'm trying to get you an answer, but I'm "on the road", so I'm not sure how quick I can be...

[Han Pilmeyer]

The reponse I'm getting so far is:

- This is not a known problem. At least it is not so well known that we remember the solution. :-)
- Therefore it would make sense to open a case with HP, so that we can investigate it (assuming this is something that you need to have fixed and you have a support contract)
- The WWID is supposed to be recorded in the meta data when the disk is added to the volume group (voldiskadd is a wrapper to voldisksetup and voldg which normally do that)

[Johnny Vergeer]

For the record, we have found a fairly elegant way to rewrite the LSM metadata to a disk without having to move the data off.

Use "voldg -g -k rmdisk dskXYZ" followed by "voldg -g -k adddisk dskXYZ" will rewrite the LSM metadata, and specifically correct the WWID.

However trying to start the LSM volume gives the following error:
"lsm:volume: ERROR: Volume has no CLEAN or non-volatile ACTIVE plexes"

The workaround for this situation is:

volmend -g -o force off -01
volmend -g on -01
volmend -g fix clean -01

After this, "volume start " works fine.

Any comments on this procedure most welcome.