Migrate a symdev/meta within a single VMAX non-distruptively?

To migrate to an existing device would only be timefinder/clone within the array.

The above comment is for thin devices and thick>thin migrations.

I should add that with thick to thick migrations you can use symmigrate to migrate to an exising thick device.

So symmigrate can migrate thick to thick, but not thin to thin. Seems quite an oversight that, but ok thanks.

- Can symmigrate migrate data non-disruptively online to the host?

- Do I need a particular license to use symmigrate?

- I read here that PPME with TimeFinder Clones is a good method https://community.emc.com/thread/145129

(requiring the paid for Clone licese, and also the PPME-SymClone license, though apparently that is free).

- Are there any other methods might be open to us to migrate devices (specifically within an array, as surely this facility should be quite simple for the array to perform)?

Symmigrate can indeed migrate a thin device from one thin pool to another. That was not the question. The question was what can be used to migrate to a new device. If you just want to migrate a thin device to a different pool then symmigrate is designed for that process.

It is a non-disruptive processs and can be used in a tiered environment to even move extents from only one specific pool to another target pool without rebinding the thin device to the target pool. Very handy. The license is included in your enginuity license I believe.

When using thick devices (disk based provisioning) you can use symmigrate to migrate to configured (existing device) or unconfigured space (free space).

rwise,

You stated:

- symmigrate *cannot* migrate a thin device to a new thin device (or to unconfigured space in the pool)

This is correct but I fail to see this as a limitation. If you need to move a thin device you simply migrate it to another pool. I don't see the value in migrating it to a new device ID.

The functionality exists in thick devices becuase they are limited by their physical location within the disk group and device configuration, and being able to migrate to another thick device allows the thick device to change RAID type. With thin devices if you want to change the RAID type associated to a thin device you just migrate it to a pool of the desired RAID type.

let's be more specific, PPME is not free unless you have an active maintenance contract for the regular PowerPath license. If you are using PowerPath without the license (basic failover, which gives you very limited failover functionality) you will need to purchase PPME license.

Hello rwise,

Welcome to EMC Community.

Symmigrate can migrate thick to thick However, migrate to larger space is not supported with any code.

migration from thick to thin and thin to thick is not supported with symmigrate. You can overcome this by using host based migration tool like PPME.

Symmigrate supports thin to thin migrations.

PPME can be used without TF on the array, You can use PPME hostcopy. It is a free license In order to  check if it you have it, run this command:  powermt check_registration. if capabilities were "All" then your PPME license is included. If only Multipathing is listed there then you will need a separate license for hostcopy, again it is for free PPME hostcopy consumes some of the host resources as you offload the migration completely to the host. PPME with TF offloads this to the array so we have an advantage here over PPME Hostcopy. Both techniques will do the migration online

Hope that helps

Mohammed Salem

> This is correct but I fail to see this as a limitation. If you need to move a thin device you simply migrate it to another pool. I don't see the value in migrating it to a new device ID.

I guess a situation that I was thinking of, if not *needed* in anyway whatsoever, would be useful in terms of running a tidy array, was that:

- I create an 8-way meta for an application.

- A month later they need it expanded, in the meantime I have done more allocations

- After 3 or 4 expansions, I end up with a 19-way meta with non-contiguous symdevs spread out a lot.

Again, I *know* that this is not required to do this, but it does occur to me that it would be a nice-to-have option to be able to create 19 contiguous symdevs and then move the data onto this tidy / contiguous meta-device. So do you reckon that this is impossible to do short of using PPME ? I'm still quite surprised if there is not be a way to accomodate this easily to be honest as migrating internally to the array should be really simple (I would have thought).

why do you care about meta members being contiguous or not, they are logical devices (btw Meta will be going away in the near future)

Like Dynamox said, You should not really care about the dev IDs, PPME will allow you to migrate the meta TDEV to a new device/s (it can be  a non-meta device is the size is below 240 GB) .

If your question is about how the symdev IDs are allocated then this a different story. I can send you a KB article if you are interested to hear about it.

@Dynamox, You are right but this DOES NOT apply to the current VMAX family..

Hope that helps

Mohammed Salem

Thanks Mohammed, yes please, that KB article sounds very interesting? As I was saying, I know it's non-important, and I know these are logical id's, but this is just about 'housekeeping' I guess. Yep, our current VMAX are just installed, so will be managing them for the next 4 years from now, so in terms of thousands of devices, housekeeping is 'desirable', even if also by no means 'essential'.

e.g. Someone recently described to me on this forum a system to reserve logical id's (https://community.emc.com/message/816153#816153) by creating some 1000 or so gatekeeper devices so that on adding more drives to the VMAX, some of those can be removed to accomodate the TDAT id's (thus keeping the entire set of TDAT id's contiguous). Again, unimportant, but as a housekeeping exercise, easy to do so why not. So If anyone has a process for what I'm describing (unimportant as it definitely is), it would be great to hear that? Clones seem an option (but we do not have Clone license), or PPME (again, no license, and if I understand that's run from a host and not on the array, is that right?). I still think it's a shame that this is not a simple process implemented in symmigrate to move devices in-array (even if it is non-essential).

Interested to hear more about the future architecture that you are hinting at. Are these things that have been published in whitepapers, or is it a case of "you could tell me, but then you would have to kill me" top secret stuff?