VPLEX encapsulation and mirror device could be considered to be a migration method for you.

The following is consideration of plan.

The existing source array and planned target array are supported with VPLEX code, you could take ESM as reference.

You need downtime to implement VPLEX system and re-cable the host-VPLEX-array connection.

Capture the existing ESX LUNs from existing array as one leg of VPLEX mirror device, and the other leg on your new array.

Set Sync between two leg.

You could break one leg on source ,destroy mirror dev and remove VPLEX after Sync completion.

Eddy, while VPLEX might be a feasible way to do the migration. I still doubt if your action plan will work. Because you will remove VPLEX after sync completion, then you might have the same resignature issue to mount the storage volumes to ESXi hosts. The metadata in the signature might be different because previously it was identified as VPLEX volume not the Storage Volume.

As I know, VPLEX would not change any metadata on captured LUN as long as using 1:1 encapsulation.

Eddy

Yeah, you are right. Device presented by VPLEX is entitled with a “inVista” device.

Do you what is ESX resignature made up with?

Thanks,

Eddy

Eddy,

here is some background information for signature.

When a storage device contains a VMFS datastore copy, you can mount the datastore with the existing signature

or assign a new signature.

Each VMFS datastore created in a storage disk has a unique UUID that is stored in the file system superblock.

When the storage disk is replicated or snapshotted, the resulting disk copy is identical, byte-for-byte, with the

original disk. As a result, if the original storage disk contains a VMFS datastore with UUID X, the disk copy

appears to contain an identical VMFS datastore, or a VMFS datastore copy, with exactly the same UUID X.

ESXi can detect the VMFS datastore copy and display it in the vSphere Client. You can mount the datastore

copy with its original UUID or change the UUID, thus resignaturing the datastore.

In brief, signature is built in VMFS level. It has nothing to do with the invista Device label, so It seems VPLEX might handle the migration job seemlessly if these VMFS is already awared by ESX hosts on DR site. 

JingYi and Alex,

http://one.emc.com/clearspace/docs/DOC-36425, hope you could access this PG of Encapsulating ESX volumes in VPLEX.

I think signature would not be modified, even VPLEX change device type from CX device to inVista device.

Thanks,

Eddy

The thing is if you decommision the VPLEX and remount the storage volumes directly to ESX cluster, will ESX host think these volumes are original VPLEX volumes or Cloned VPLEX volumes? If the former, these volumes can be seen by all hosts without resignature.

The difference is in VPLEX migration solution, ESX Hosts on DR side already know and communicate to the DataStore. While for other replication solution, The DR volumes have not been presented to hosts yet.

How does ESX determine the UUID?

I think UUID would not be a problem, if device type is not a part of UUID calculation or validation.

Thoughts?

Eddy

I am a bit confused with it.

SCSI ID is address of a physical device, LUN is a logic device and identified with LUN ID.

Txtee, could you provide more information about it?

Thanks,

Eddy