Convert BCV to 2-way meta

just like you mentioned, unmask/unmap your meta, dissolve it, then convert hypers to 2-way standards, and then meta them together.

Thanks, I'm wondering once i dissolve all devices will be BCV devices , do i need to change to unprotected before changing to 2-way mirror because i dont want 2-way-bcv mirror.

is your current BCV a 2-way-bcv mirror ..or an unprotected BCV. I am confused about the final state of your 34G devices ..do you want them to be BCV or Standard ?

it is unprotected BCV , i want 2-way Meta (4-member meta=34GB)

if you are going from unprocted BCV to 2-way mirror standard ..here is your article how to do it:

emc112327

Actually device is unprotected i want to convert to STD 2-way meta.
i guess i need to delete and recreate the device or i should take one more BCV for creating the Standard.
thanks anyways dynamox .

did you take a look at the article, it explains how to convert an unprotect bcv to 2-way mirror, you dont' have to delete anything. First you convert unprotected bcv to 2-way-bcv-mir and then to 2-way-mir.

how does symm select the hypers while converting from bcv to 2-way-bcv? is there any algorithm that it uses to do this?

i am particularly asking about the hyper selection because we do not wish to run into performance issues due to lun layout like we ran earlier.
i was not sure what issue was that exactly but emc came back saying some luns have been laid out incorrectly so we need to perform bin file update.

We currently have a TB of one way BCVs on our arrays. not sure if there is free space left. so it seems that we need to have 1 TB of free space on the array to get 1TB of 2-way BCVs after the operation. is that correct?

can we remove half of the BCVs using symcli and then ask sym cli to use that space? so i can hope to get half a TB of 2-way BCVs at the end..

Hi Kiran,

The SYMCLI (using the SymmWin program on the Service Processor) creates the requested M2's from available disk "free space".

Increasing the protection does not affect any existing Symm Vol # / hyper. It does NOT delete any volumes.

However, the CLI change will fail if there is insufficient (or suitably located) disk free space for the requested mirrors.

Regards,
Michael.

Sorry Kiran,

Your last post came in just as I replied to your earlier posting. The SYMCLI relies on SymmWin to build a suitable upgrade bin file. The SymmWin program uses it's own internal algorithm to select the "best" possible backend layout.

However, it is only a computer program and is same cases a "non-artifical" intelligence is needed .

This is particularly true if the activity is complex AND you need to optimize for performance. I am not sure what "went wrong" last time but again if 1/2 TB of disk is to be reorganized I think that the local team should be involved.

Again they might just look at the planned change and be satisfied that the SYMCLI will do a good job OR they may build the upgrade bin manually and suggest that EMC implement it.

I hope this helps.

Regards,
Michael.

Hi Kiran,

Yes. In theory this is 100% fine.

You simply delete the unwanted volumes (1/2 TB of unprotected BCV's) and these will return to the "free space pool".

Then the SYMCLI should be able to add mirrors to the remaining 1/2 TB of (still existing) unprotected BCV's.

However (in practice) the SYMCLI may not be able to "mirror up" all of the 1/2TB of BCV's since the physical location of the 'free space" will determine whether the SymmWin program can create the requested mirror. For example, SymmWin (understandably) cannot create an M2 if the M1 is located on the same physical disk or connected to the same DA/DF processor.

I suggest, for a configuration change of this size, that you involve your local Account Team. The local CE and RTS can look at the running bin file and confirm that your planned change will be successful i.e. you can tell them which BCV's are "unwanted" AND OR they may suggest which BCV's should be deleted to create the best "backend" layout, etc.

Best Regards,
Michael.