Protection Manager/OSSV new secondary volumes migration

[dscarbrough]

Hello,

We recently installed a new FAS3220.  This system is to be used as an OSSV/secondary replacement for an existing FAS3240 that has too much workload on it. 

Currently, Protection Manager (5.0) is managing all of the OSSV relationships in the environment with the corresponding snapmirrors of this data to the DR site once complete.  In the past, I have had the ability to move OSSV secondaries between controller pairs and let PM handle all of the updating of relationships.  This has also worked very well for us.  But, for some reason, I can't get the new 3220 aggregates (which have been added to the current resource pool with OSSV data) to show up as a destination in the "Migrate Wizard" window when I manage storage.  It will only show me the partner of it's cluster.

FAS3240 OSSV --> FAS3220 (both running 8.1.2P1)

w/ complete bundles (everything licensed/enabled)

I have, as of an hour ago, still been able to add a FAS3140 (also 8.1.2P1) into a resource pool and that DOES show up as a destination possibility.  I cannot figure out what I am missing from the new cluster in order to get this to show up as a destination in the wizard.

I believe I have gone through every prerequisite that I can find for this action to be allowed...but something seems to be missing.

New Aggr's have 20x the space for the volume to be migrated

No vFilers being moved (volume wise)

All aggregates involved are in the same resource pool

snapvault/snapmirror enabled and wide-open with access all

ndmpd on and connected

Storage System diagnose comes back clean

Complete Bundle

Also, I can move the Snapmirror destinations sourced from the opposite site to the FAS3220 with no problem and have done so.  But not the OSSV volumes in the same pool.

Any thoughts here?  I've done this a number of times in the past with older systems, but not with the new FAS3220.

I would appreciate any help on this one!

Thanks,

Dan

[dscarbrough · Accepted solution]

After trying to run it via cli with a dfpm migrate volume command, I determined that I was running into BURT 438914 (or the like) based upon older threads.

I went ahead and temporarily turned off deduplication in the provisioning policy, and the migration now worked properly.

While it's not a fix, it did enable us to move forward with migrations.

[adaikkap]

Hi,

     What is the error message did you get in your dfpm migrate volume command ? You are running version 5.0 which may not have dedupe limits set of some of the new platforms which got released after it.

I recommend you to upgrade to 5.1/5.2 RC1 which has platform dedupe limits updated. You can set the dedupe limits and update the prov policy to include the same.

Use this Bugs online link to update the Dedupe limits.

http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=508580

Here is the Dedupe limits for 8.1.2 running on 3220

32Bit Aggr, 14.4 GB

64bit Aggr 53.9GB

If you are running 5.2 you can set individual limits for 32 and 64bit versions but if you are using only 64bit just set that value.

Regards

adai

Regards

adai