Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Synchronous Snapmirror license required on storage system

2013-03-11
05:35 PM
3,392 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm getting this error during the vFiler migration pre-flight checks:
Conformance Results
=== SEVERITY ===
Error: Synchronous Snapmirror license required on storage system 'na01'(151) for Automated Online Migration.
=== REASON ===
Migration not supported (Error 23509)
=== SUGGESTION ===
No suggested corrective action is available.
Snapmirror is licensed on na01 and snapmirror_sync shows ENABLED
I did a dfm host discover na01 in case it was a stale DFM DB issue - no change
thanks for any tips!
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm testing vfiler migrations as well on 8.2 and getting the same error. I've found a couple of mentions that even though sync and semi sync snapmirror are included in the snapmirror license you need to add a special free one. I found it here:
https://library.netapp.com/ecmdocs/ECMP1217273/html/GUID-EA4A107F-469C-4FB3-8055-8D891CA4044F.html
but the license in the page isn't the right format for 8.2 so I'm going to raise a ticket with support
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
finally got the thing stop reporting a licensing issue.
I had to upgrade DFM/Ops Mgr/OnCommand Unified Manager to 5.3, the Management console to 3.3 and then install separately the plugin for 8.2 from here:
http://support.netapp.com/NOW/download/software/ontap/8.2/dfm_plugin.shtml
Even though the release notes state that 5.3 now supports the licensing changes to ONTAP 8.2 it didn't. Once the plugin was installed and I refreshed the system via Ops Mgr the Management console correctly reported the 8.2 systems' licensing. However it failed on something else, differing disk types ATA to FSAS.
In the end I pre-created the required vols on target system, didn't restrict them and then ran:
vfiler migrate -l root:<p/w> -c secure <source vfiler>@<source filer>
this worked even with an open file and a script constantly writing to a 3GB file @ 120MB/s so as long as the NFS timeouts are long enough (we're NFS shop) there's just a pause rather than and down time
