vfiler Migration fails: maximum of 4 volumes for Automated Online Migration

[fletch2007]

Am I forced to do an offline migration for this 7 volume vfiler?

thanks

=== SEVERITY ===

Error:    Attention: Failed to select a resource.

=== ACTION ===

Select a destination resource for migrating

=== REASON ===

Storage system : 'irt-na03.'(119):

     - Destination storage system 'irt-na03.'(119) can contain maximum of 4 volumes for Automated Online Migration. But the migrating vFiler unit 'str-vf-02'(1838) has 7 migrating volumes for Automated Online Migration

     - Volumes by same name as 'strdata', 'strweb2' already exist on the storage system 'irt-na03.'(119).

=== SUGGESTION ===

Suggestions related to storage system 'irt-na03.'(119):

     - Choose/Add a storage system, which can contain minimum of 7 volumes per vFiler unit.

     - Destroy the volumes on the storage system and refresh host information either by executing 'dfm host discover' CLI or navigate to 'Hosts > Storage Systems' page in Management Console and press 'Refresh' button.

[adaikkap]

What is the hardware model of irt-na03 ?

Is it a FAS 20X0 or FAS 3050 ? then yes, only maximum 4 volumes are supported for vfiler migration including the root volume of the vfiler.

Refer Section 7.2 Table six of TR 3814.

http://media.netapp.com/documents/tr-3814.pdf

Regards

adai

[fletch2007]

the destination is a 3270 (we are using a testpoint supplied by netapp support to bypass the model check).

Apparently it is defaulting to a low max volume value for migrations!

How can I persuade NMC & DFM to use the correct higher value for the 3270 destination?

This is the last vfiler I need to migrate - so any help is much appreciated

thanks

[adaikkap]

Hi Flecth,

     I think, you got the root cause.Raise a case with NGS, to get around this issue.

This is becasue of the bypass model check testpoint.

Regards

adai

[adaikkap]

Hi Fletch,

     Is this also true ?

>   - Volumes by same name as 'strdata', 'strweb2' already exist on the storage system 'irt-na03.'(119).

In which case you may have to address this too to successfully complete the migration.

Regards

adai

[fletch2007]

Ok, I've re-engaged with support to update the testpoint to workaround the max volume issue

yes, we can resolve the volume name conflicts separately on our own

thanks

[joshuah]

Are there updated flexvol limits for the new platforms out now?  I.e. the 3240, 3270, 6210??  Did the limit increase or are we still stuck at 4, 8, 20?

Thanks

[scottgelb]

20 for 6200, 8 for other platforms. No increase. But less limits on 8.1. Bigger to smaller controller and sas to sata is allowed for example.

Sent from my iPhone 4S

[arndt]

The limit is 4 for the 2xxx platforms…8 is only for the 3xxx platforms. What type of systems are involved in this setup?

Mike

[scottgelb]

Thank you for clarifying...I left out 2040 for 8.1.   With a 2040 on 8.1 it stays at 4 volumes max.  No increases or changes from 7.3 to 8.1 in volume limits but a change being more flexible to go between platforms and disks like I mentioned.

[adaikkap]

Do keep in mind, the ontap release between 7.3 and 8.1 includes 8.0 which does not support datamotion.

Regards

adai

[sinhaa]

Hello fletch,

     There are Storage System hard limits based on models for the number of volumes that can be supported for Online migrations. E.g. If you have a FAS2050 then it can only support 4 a vfiler with only 4 volumes for online migration. A higher model like a FAS3170 has limit as 8 volumes, FAS6070 has 20 volume limit. I'm sure this must be documented in the User Manuals for Provisioning Manager. Isn't it?

The restriction is set as per what is the destination filer model. Suppose if your source filer(f1) is a FAS3170 ( 8 volumes supported) and you choose a destination(f2) which is a FAS2050 ( supports only 4 volumes) then you can have at max only 4 volumes in your vfiler ( which includes the root of the vfiler as well) for Online migration.

warm regards,

Abhishek

[adaikkap]

Hi Abishek,

     Isnt higher platform to lower platform supported only starting from 8.1 ? Correct me if I am wrong.

Regards

adai

[scottgelb]

Only 8.1. Not 7.3. A nice change. Hopefully vol limits increase.

Sent from my iPhone 4S

[fletch2007]

Ok, we took delivery of a new 3250 running 8.1.2 7-mode - for some reason the forum is not showing me the option to create a NEW post, so I'll reply to this thread from 2011.

I am trying a test vfiler migration from our 3270 (8.1 7-mode) to the 3250.

Its failing on this check (below)

Is is the 32->64bit or the FC to SAS or 3270->3250, or something else?

Successful non-disruptive vFiler migration from the 3270 to 3250 will make a BIG difference in planning (downtime) and customer impact

thanks

Conformance Results

=== SEVERITY ===

Error:    Failed to select a resource.

=== ACTION ===

Select a destination resource for migrating

=== REASON ===

Storage system : 'cci-na01'(5040):

     - There are no aggregates with enough space and reliability/label match for all the volumes in the vFiler unit.

Storage capacity configurations and reliability requirements of volumes in the vFiler unit:

Volume 'stride-vf-04:/stride4'(5036): Used space: 1.45 MB Current size: 50.0 GB (volume guarantee)

Block type: 32-bit

Disk type: FCAL

Aggregates, their capacities and configurations:

Storage system 'cci-na01'(5040):

Aggregate 'cci-na01:aggr0'(5041): Used space: 237 GB Total capacity: 24.5 TB Committed size: 227 GB

Block type: 64-bit

Disk type: SAS

Configuration: Double disk failure protection

=== SUGGESTION ===

Suggestions related to storage system 'cci-na01'(5040):

     - Add more resources to the resource pool or select a different storage system.

[scottgelb]

Data motion for vfilers requires the same volume type. 32 to 32 or 64 to 64. 32 To 54 bit isn't allowed.

You can do a vFiler migrate though. It doesn't guarantee 120 second cutover but with mirrors close up to date it can be done since migrate doesn't require same aggr bit type source and dest. You also need to clean up snapshots manually and set fs_size_fixed to off for all volumes on the 3250 target. Plan for a possible short outage, but migrate will work the near the same without the restriction.

Sent from my iPhone 5

[fletch2007]

Thanks Scott -

With the 32->64bit check passed (by going 64->64bit), my test data motion is now failing on "Failed to discover the destination vFiler unit."

Job Started.

Successfully provisioned flexible volume 'cci-na01:/stride4'(5194) of size 25.0 GB with space guarantee set to 'volume' on aggregate 'cci-na01:aggr0'(5041).

Online Migration initiated, waiting for baseline transfer to complete...

An error occured: cci-na01: Failed to discover the destination vFiler unit.

Clearing the destination IP bindings of vFiler unit stride-vf-04

Destroyed the provisioned volume 'cci-na01:/stride4'(5194) on 'cci-na01'(5040).

Job completed with errors.

on the console of the destination (cci-na01) - I see:

Sun Jun 17 08:51:38 PDT [cci-na01:ndmp.authentication.accept:info]: ndmpd(authtype+password) allowed for version = 4, sessionId = 35482, from src ip = 11.65.64.19, dst ip = 12.25.124.84, src port = 3938, dst port = 10000 

Sun Jun 17 08:51:38 PDT [cci-na01:ndmp.connection.close:info]: ndmpd session closed successfully for version = 4, sessionId = 35482, from src ip = 11.65.64.19, dst ip = 12.25.124.84, src port = 3938, dst port = 10000 

Sun Jun 17 08:51:42 PDT [api_mpool_05:warning]: registry: Unexpected error in rollback in regx_commit - Error: No such file or directory (name=options.files.snapmirror.conf.cci-na01:stride4)

Sun Jun 17 08:51:43 PDT [cci-na01:wafl.vvol.offline:info]: Volume 'stride4' has been set temporarily offline 

Sun Jun 17 08:51:43 PDT [cci-na01:wafl.vvol.destroyed:info]: Volume stride4 destroyed. 

Any ideas how to resolve?

thanks!

[scottgelb]

Doesn't make sense when it creates the vFiler for migration... did the target have a vfiler of the same name before the migration?  But more could be a bug and should have a case to make sure.

[fletch2007]

Scott - turns out you posted the solution in this thread

https://communities.netapp.com/thread/17394

dfm option set discovervfilers=yes

For some reason this was disabled !

"Failed to discover the destination vFiler unit." turned out to be the most relevant error I've seen in a long while!

Now onto testing migration to ip-spaces - fun!

thanks!

[scottgelb · Accepted solution]

Very good...you know you have been working too long when you forget your own answers   I thought this option was enabled by default though but all good.

For IPspaces, you need to create new vFilers or recreate existing ones since there is no moving a vFiler between IPspaces nor can you rename an IPspace without destroying/recreating.