2010-03-11 04:44 AM
When running an offline (!!) migration of a vFiler, the Cutover-Process does not work and quits with error "Online migration is not allowed between a storage system and its partner."
Although the migration mode is set to "Offline", the cutover for a vFiler unit fails with the error "Online migration is not allowed between a storage system and its partner."
The mirror-relationships are established correctly. I have tried this with SAN and NAS provisioning policies, the error occurs on both. I have also tried to stop the vFiler, but with the same results.
I have followed the steps in the "workflow.pdf" to create a scenario for a live-demo to a prospect.
DFM Version is 18.104.22.16853 (4.0)
FAS systems are DataONTAP 7.3.2P2
Please see the screenshots attached.
Thank you in advance for your help!
Solved! SEE THE SOLUTION
2010-03-11 07:59 AM
Hi Matthias, This looks like a burt. Please file a burt with all the details.
If possible, can you disable cf and try cutover ?
Online migration is not possible between a node and its CFO partner (this is because of sync snapmirror limitation). I think this check is wrongly happening for offline migration also. Disabling cf temporarily will make cutover progress and then cf can be reenabled.
2010-03-11 08:00 AM
I think, you are trying to migrate the vFiler unit to the source filer partner. This is not allowed either in 'Offline' or 'Online' migration.
The error seems to be mis-leading, as we are throwing the same error for offline and online migration.
2010-03-11 08:39 AM
Disabling cf worked. But this can not be more than a workaround.
Whats the reason for not supporting a Data Motion between two cluster partners??
And, almost more important, why is it impossible to migrate the data between two different aggregates on the SAME system? THIS is the feature we need for tiered-storage! Migrate data from FC to SATA, from mirrored aggregates to non-mirrored aggregates and so on.
2010-07-13 05:52 AM
The limitation is because data motion uses synchronous snapmirror as the underlying mechanism to synchronise the volumes in the final steps of the cutover, and this is one of the limitations of synch snapmirror. Without a large re-write of the way synchronous snapmirror works this is unlikely to change, and a large rewrite of synchronous snapmirror is probably a few years away.
Having said that, there are other ways of doing what your looking for (Non disruptive volume migration - coming soon), which will allow you to move volumes between aggregates on the same controller, and the good old "snapmover" for moving all the vfilers on a given aggregate from one controller to the other (basically the whole aggregate moves). With a little luck this could all be included in something like provisioning manager, or failing that a relatively simple powershell script.