That's correct; Open Replicator is only supported between arrays (not within a given array).
Open Migrator is block-based at the host layer, so you don't have to deal with the overhead of opening/closing all the files or with preserving permissions/acls/etc... and it's free with the purchase of a VMAX. You can also fix partition alignment issues with it (if applicable), because it can migrate partitions/volumes in additional to full disks/LUNs.
Excellent, well at least I know the limitations, thanks guys. Open Migrator does sound quite useful in fact and could be the route to go for my client to be able to migrate to an arbitrarily larger sized LUN without breaking the chargeback billing process (that is standard in every corporate / bank in which I have worked) in the way that striped meta expansion does. I'll hopefully get a chance to test this weekend. Edit: just saw dynamox's note that it requires a reboot - that almost completely negates it's use in the vast majority of the corporate environments in which I work (i.e. change management for downtime on global banking systems is not easy ...). What a huge shame ...
If anyone can think of a brilliant / ingenious other method of doing what ancient HDS technology can do in base functionality (block-based migrate / expand a LUN to another arbitrarily sized larger LUN on the same array, either offline or online), that would also be a great thing to add to my toolkit ? ...
I don’t know if this was covered, but Open Migrator take several reboots to start and complete the migration. The data synchronization itself is an online event but you have to attach the filter driver to the volumes and before you can begin the sync and the host has to be rebooted. Once the sync is complete and you want to commit the migration you have to reboot again. This is then followed up by yet another reboot to detach the filter driver from the volumes. If you want to then uninstall OM, you have to reboot again.
Now, I’ve used OM quite a bit and it’s a good product that definitely has a place and can overcome some configuration issues that other products can’t, like a volume offset issue. The reboots are definitely a check in the negative column though.
While at this stage of the discussion, my question might seem irrelevant and out of context, but just wanted to know what auto-meta does and would that be helpful for the problem being discussed here?
i think auto-meta is not related to this. basically auto-meta is nothing but what the name implies - i.e. some configuration settings that symm can use to 'automatically' create metas. for ex, one can define a setting such that if user tries to create volume >500GB, symm can automatically create meta Lun (composite volume). these settings can also tell the meta configuration used by symm...
Whereas the question here, expanding a stripe meta to any size similar to concatenate meta?
The maximum size for a single symdev is 240 GB. Meta's are required above that size. We can either create meta's manually (by creating the symdevs and forming a meta), or use Auto-Meta to specify a size (say 1 TB) and the VMAX will automatically create the right size of symdevs to form a 1 TB meta, so auto-metas are not related here.
What I am basiaclly interested here is in taking a striped-meta (either single symdev or meta, and either concat, or striped), and then migrating it internally on the box (ideally online, but also offline seems impossible on VMAX) to another, larger sized meta. It's been pointed out to me that HDS could do this 8 years ago (not 5 as I previously thought - and HDS does all this non-disruptively online), so it is incredible to me that VMAX can't take an arbitrarily sized LUN, and then migrate or expand it to an arbitrarily sized LUN in the same box, which seems a very reasonable and straightforward operation that we would want from an array (and particularly Virtually Provisioned arrays where it should not matter how the data is stored on the box), but so far in this thread, it seems to be that the answer is this operation is completely impossible in-box on a VMAX !