Do you have new data going for the DeDupe LUNS? Or if using current data, you could just enable DeDuplication on one of the existing LUNs, that would create the dedup container, then just add LUNs where needed.

And yes, you can't change allocation owner, need to do migrations for that, for VMware that is invisible.

sk

It will be new data that will populate the DeDuped LUN. In that case, everything looks correct in the process explained?

Yes, looks good.

sk

Additionally, when I create the new destination LUN for migration would I first need to assign the LUN to a storage group? Or is this step not needed as the destination LUN assumes the source LUNs properties?

That is not needed, it will totally take the place of the original LUN, including name, number and associations.

Hi,

I wanted to provide you some information and comment on some things.

Most importantly - what version of Flare are you on?  If you are on .051, do not enable dedupe with ESX.  Upgrade to .052 first.  There is a bug with .051, dedupe, and ESX that can cause LUNs to go offline.

Here is a blog post I wrote on dedupe: VNX, Dedupe, and You | raid-zero.com

And here is the EMC documentation on it - well worth a few reads before you enable it: http://www.emc.com/collateral/white-papers/h12209-vnx-deduplication-compression-wp.pdf

First you talk about allocation owner and LUN migrations. You never want to change the default owner manually on a storage pool LUN in order to move to another SP.  This will cause performance problems.  The proper procedure is:

1. Create a new LUN of the same size on the opposite SP.  It does not need to be in a storage group.
2. LUN migrate original LUN to new LUN (the new LUN will "become" the old LUN at the end of the migration including name and LUN ID)
3. Look at LUN properties - the allocation owner will be the new SP but the default and current owner will be the old SP.  Change the default owner to the new SP (this is the only time this is acceptable) and then trespass the LUN (which will correct the current owner).
4. Check LUN properties again and all ownership should match to the new SP

Just LUN migrating to a new SP is not enough - you need to correct the default owner and trespass afterwards.

Second I wanted to mention that you can also enable dedupe on an existing LUN and wanted to talk about this because it will probably be relevant to you at some point.  You are correct about the SP ownership, however this is done automatically when a LUN is deduplicated.  The first LUN selected for dedupe will be LUN migrated automatically into the invisible dedupe container on whatever SP it happens to be on.  So in your example, you are choosing the LUN on SP A for dedupe first.  This means that so long as something is deduped in that pool, every deduped LUN will be owned (not should be owned) by SP A.

If you enable dedupe on a 2nd LUN which is currently owned by SP B, it will also be LUN migrated into the dedupe container on SP A!  Once this process completes, the LUN will be in the state it would have been after step #2 above, so you will need to go in and adjust ownership via step #3 and check it via step #4, just as if you would have done a LUN migration yourself.

Finally, you could use sVmotion to affect LUN ownership, but in this case you would need to create a usable datastore on the other SP add to storage group, attach in vSphere, sVmotion, detach the original LUN safely, remove it from the storage group, and destroy it.  Much easier to just LUN migrate, and as Sami says it is never noticed by vSphere.

You may know most or all of this, but wanted to provide you this info since you say you are new to EMC.  Welcome aboard!