Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

unable to add new disk on diskgroups copied by array based copying

Created: 12 Dec 2012 • Updated: 07 Mar 2013 | 4 comments
This issue has been solved. See solution.

i have some disks copied via array base solution

so after the disks are fully sync-ed. the master and slave relation are split. the disks are imported on the destination host.

vxdisk list didn;t show any udid_mismatch or clone_disk 

but when i add a new empty disk, i couldn' add it into the diskgroup. i forgot the exact error but it was related to clone_disk. i deported the diskgroup, updated udid and set clone=off on all the disks. import the diskgroup again and i was able to add a new disk to the disk group. i am on 5.1SP1RP2 at least.

now is this a bug  which have been fixed already? or it is udid_mismatch and clone needs to be turned off everytime we use the array base copying? 

thanks in advance. sorry for not able to show any errors.

Comments 4 CommentsJump to latest comment

TonyGriffiths's picture

Hi

If I understood correctly, this looks like normal behavior.

When yoru source disks were initialised, some unique attributes of the LUN were obtained and made into a unique string (UDID) which is then stamped on the disk in the private region.

The lun was then cloned to the new target disk, so all the disk content (including the UDID) was copied to the new LUN. VxVM has detected that the attributes of the new LUN do not match those written to the disk.

If the source disks and target disks were both accessible to the host, then the udid_mismatch would be flagged and you will have to take appropriate steps to import the DG as regular import would fail.

In the above case, only the target devices are visible, so VXVM allows the regular import to succeed though the disks are "clones". Later you try to add a regular (non-cloned) device into the DG and VxVM fails the operation as it does not allow a mix of non-clone and cloned devices.

Your steps to update the UDID on the disks and set clone off have made the disks into non-cloned devices and the operation will now succeed

cheers

tony

IdaWong's picture

hi tony, 

Thank you for the reply. I appreciate this.

I am afraid I still don't get it. Would you expect in my case to see "udid_mismatch" and clone_disk in vxdisk list output on the target host then? and why not?

Regards,

ida 

TonyGriffiths's picture

Hi

If the clone disk group and the source disk group are both accesible to the same host, then VxVM will flag a udid_mismatch and you will have to take the appropriate steps to import the disk group. A regular import will fail due to the mismatch

If only the clone disk group is accessible to the host, then VxVM allows a regular DG import to proceed, though it is aware that there is a UDID conflict, but does not flag it. This is the scenario that you have. The disk group is made up of devices that have been copied from source disks. The UDID constructed for the source disks is has been copied to the clone devices as part of the cloning operation.

Hope this helps

tony

SOLUTION
pradeepV's picture

I have a situation with SF5.1RP3 upgraded from 5.0MP1+RP5. The Diskgroups have only cloned disks and the no flags set on the devices. No source disks visible to hosts. When I tried to add new devices it wouldn't let me do it with error message:

ERR VxVM vxdg ERROR V-5-1-0 Disk Group sdg 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.

None of the vxdg/vxdisk commands to update the UDID seem to work when its already imported and I am stuck at the only option of an outage to deport/import the DG to update UDID. Are there any option to update UDID without taking an outage so that we can add new storage in such situations ?