cancel
Showing results for 
Search instead for 
Did you mean: 

LUN Consolidation in an VxVM environment?

Magesh
Level 3
I have a question with regard to consolidating two LUNs (which has VxVM data in it) into one LUN. Is this possible?

Consider the below scenario:

I have four LUNs, each of size 2GB. I have created a diskgroup dg1 by using two physical LUNs and another diskgroup dg2 using the remaining two. I also have created vol1 on dg1 and vol2 on dg2 and created VxFS fileysyetems on them. Now, I want to consolidate these 4 LUNs into two LUNs each of size 5GB each. Assuming I have a migration tool which can move block data as per my requirement, can VxVM update the private regions accordingly and update its configuration database as well.

I also need to know what would happen, if there are two private regions in the same disk. Would VxVM identify them and then consolidate them into one? Or will VxVM would know only the first private region and ignore any other private regions?

I am not quite knowledgeable with respect to VxVM internals, so if anyone can point me to some documents which could help me understand, it would be great!

Thanks
Magesh
4 REPLIES 4

Eric_Gao
Level 4
Hi Magesh,

Sorry I didn't get your point.  Say you have lun1,2,3,4  and you want to "consolidate" lun1 lun2 to lun5,   lun3, lun4 to lun6,  is that your requirement?

But how can you do that?   A lun, from vxvm point of view, is a physical disk,  how can vxvm merge two disks into one disk?

Is there any trick you need to do from storage side?   I would assume it is impossible without storage guys being involved.

Eric

Magesh
Level 3
Hi Eric,
Thanks for your reply. I guess I didnt get across my point clearly.

Yes, my requirement is to consolidate lun1 lun2 to lun5 and lun3, lun4 to lun6. And yes, we very much need a block-migration tool to move the data from lun1 and lun2 to lun4 etc.

Assuming thats done, and lun5 now has lun1, lun2 data in the same order, so it would contain, private region of lun1 and then public region of lun1, followed by private region of lun2 and public region of lun2. Now all this is being done without the knowledge of VxVM at the back end storage.

Once all this is completed, and we try to refresh vxvm config database, how will VxVM behave? Will VxVM update its configuration database to reflect the new configuration?

I know its a bit confusing, but since we havent tried it, I am putting this to the forum for any possible solution.

Thanks
Magesh

Gaurav_S
Moderator
Moderator
   VIP    Certified
Hello Magesh,

Even I am not sure how this should work.... VXVM is capable of handling the Dynamic LUN expansions but how this will be taken... no idea...

Even if I think a bit hard, I don't think VXVM can keep 2 diff private regions on same disk (supposing you merged them from Storage), VXVM will still keep the record of first private region only...

yet, once you have merged from storage, you need to run something like "vxdisk resize" command because if I assume correctly for VXVM it is nothing but resize of original LUN..

hope this helps..

Gaurav

sunshine_2
Level 4
Hi Magesh,

so what i can understand is that you want to merge two disk groups into one..if this is true you can accomplish this by doing this,

#  vxdg [-o {verify|override}] join sourcedg targetdg

here is the explanation from the vxdg manpage look under JOIN, MOVE, SPLIT

join Moves all objects from the imported source disk
group, sourcedg, to the imported target disk
group, targetdg. At the conclusion of the move,
sourcedg is removed.

The source disk group and target disk group to be
joined must both be either private or shared. If
one disk group is private and the other is shared,
deport and reimport the private disk group as
shared before performing the join.

The -o verify and -o override options modify the
default behavior of a move, split or join opera-
tion that includes disks from an EMC array. Usu-
ally, if the EMC license is present, the EMC disk
compatibility check is performed for each disk
that is involved in a move. If the compatibility
check succeeds, the normal operation takes place.
An internal check is made to ensure the configura-
tion has not changed since the compatibility check
was performed. If it was changed, the entire pro-
cess is retried.

If -o verify is specified, the access names of the
disks to be moved are returned but the operation
does not take place.

If -o override is specified, the operation is per-
formed without any EMC checking.