The process of LUN migration:

1.  ID all source luns and their size

2.  Create new LUNs in the destination pool with similar name (name_tomigrate) and same or larger size

3.  Right click each LUN in Unisphere > Migrate and select the proper destination LUN

The following limitations apply to migration LUNs:

• EMC does not support the migration of a component LUN that is part of an aggregate metaLUN.
• The destination LUN must be a public LUN when it is chosen for migration (this is the normal case).
• No other layered feature can use a destination LUN.
• The destination LUN cannot be in a user-defined storage group.
• Migration and LUN expansion are mutually exclusive operations.

You cannot migrate an expanding LUN, and you cannot expand a migrating LUN.

• The source LUN cannot be a private LUN.
• If a layered application uses the source LUN, you can migrate the source LUN only to a LUN of the same size.
• After a migration completes, the data reported in the inquiry command will still reflect the LUN's original RAID type. The new RAID type is visible through the Unisphere interface. This behavior is as designed and is required to maintain compatibility with some operating systems.
• If the destination LUN is a thin LUN, it may not be fully provisioned after a migration because the thin LUN is enabled for zero detection.
• The maximum number of migrations that can be executing at one time is as follows:

              VNX5100                         8
              VNX5300, VNX5500      16
              VNX5700, VNX7500      24

Hi,

I think I partially answered your question in my previous response. Here is the updated one.

1. LUN Migration : You can "migrate" the data on a LUN in one pool and "move" it completely to a different storage pool. By doing this, you retain the data, the ALU (array lun id) of the LUN and its name. You can however change the SP owner.

No cost/license involved.

2. SnapView Clone : You can clone/copy the data of any LUN using SNAPView Clone functionality. Requires a license.

3. SAN Copy : You can "copy" data within a VNX and across two physically distinct arrays. I've never tried it myself, but if you have an extended fabric, then SANCopy shouldwork fine. I've myself done SANCopy data sync between two distinct VNX arrays in the same data center fabric and it works like a breeze. SANCopy is shipped with every VNX as a part of the base pakage. No License/cost involved.

4.. Mirror View : Never used MirrorView myself, but I know that Cost/License is involved.

Jiawen,

Thanks for the info, what does public LUN means ?

The existing LUN is currently serving as Physical RDM to one of the Windows 2008 File server VMware Virtual Machine.

the target LUN will be attached as Physical RDM to the new File server Windows Server 2012 R2 VM as soon as the LUN copy finished.

So can I do it between two different Physical VNX array or does it have to be within the same VNX array ?

Public LUN is any LUN that is host accessible. It is opposite to private LUN.

MirrowView and SAN copy is for migration between different storage systems.

Ah Ok, thank you for the additional information.

I can confirm that this LUN that I'd like to copy or migrate is not the Private LUN.

A private LUN is one that you can not use for normal operations. It is one of the following:

1. component LUN for a metaLUN

2. Clone private LUN

3. Reserved LUN Pool lun

4. Hot Spare

So what about the Private LUN ? what is that use for if the LUN is not accessible to any server host ?

is that for newly created LUN which hasn't been published to any Storage Group to be presented to any servers ?

Sushant Gulati wrote: 3. SAN Copy : You can "copy" data within a VNX and across two physically distinct arrays.

SANCopy can be used to copy within the same array. Very handy when you don't have SnapView clone license or need to make a copy of a LUN that is a target of an existing SnapView clone session.