Datamotion (vFiler migration) fails btw 32 bit and 64 bit?

[fletch2007]

I'm running v 3.1 of NMC - is this fixed in a newer version?

Looks like its failing since one of the source volumes in 32 bit and the destination aggr is 64 bit?

Source is 8.1RC2, Destination is 8.1GA (RC3)  - is there a command to upgrade the 32 bit volume in place to make the datamotion pass its checks?

thanks

=== SEVERITY ===

Error:    Failed to select a resource.

=== ACTION ===

Select a destination resource for migrating

=== REASON ===

Storage system : 'irt-na04.abc.edu'(120):

     - 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 'dev65-vf-01:/devapp1'(4271): Used space: 539 MB Current size: 50.0 GB (volume guarantee)

Block type: 32-bit

Disk type: FCAL

Volume 'dev65-vf-01:/devlogs'(4283): Used space: 10.0 MB Current size: 100 GB (volume guarantee)

Block type: 64-bit

Disk type: SAS

Aggregates, their capacities and configurations:

Storage system 'irt-na04.abc.edu'(120):

Aggregate 'irt-na04:aggr2'(3889): Used space: 13.9 TB Total capacity: 19.8 TB Committed size: 12.3 TB

Block type: 64-bit

Disk type: SAS

Configuration: Double disk failure protection

=== SUGGESTION ===

Suggestions related to storage system 'irt-na04.abc.edu'(120):

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

[scottgelb]

ONTAP 8.1 supports 32 to 64 bit SnapMirror, however Data Motion for vFilers does not support that method.

There is no way to convert in place unless you grow over the 16TB limit...but if you add enough disks to the aggregate to go over 16TB it will convert with 8.1.

The only way I can think to run Data Motion is to add disks to the source first to allow conversion to 64-bit then do the data motion.

The other option is to run vfiler migrate from the command line which has the same result (and uses snapmirror which can be 32 to 64) but does not guarantee the 120 second migration like data motion...but can be very close to that (or much longer depending on the async mirror update times).

[fletch2007]

What about this workaround (32->64 bit aggr and volume convert without adding disk) suggested by Robin back in Feb?

Is this safe under 8.1RC2?

thanks

robin.mesotten at gmail Feb 9, 2012, 8:58 AM Post #5 of 5 (209 views) Permalink

Re: Force 64bit aggr migration [In reply to] There is a way... But not supported.. 🙂 The only supported way is by adding disks... Commands below were executed in diag mode (priv set diag) ontap8-s*> vol create test aggr32b_to_upgrade 100g Creation of volume 'test' with size 100g on containing aggregate 'aggr32b_to_upgrade' has completed. ontap8-s*> df -h Filesystem               total       used      avail capacity  Mounted on /vol/test/                95GB      536MB       94GB       1%  /vol/test/ /vol/test/.snapshot     5120MB        0TB     5120MB       0% /vol/test/.snapshot ontap8-s*> aggr 64bit-upgrade start aggr32b_to_upgrade -mode check Checking for additional space required to upgrade all writable 32-bit volumes in aggregate aggr32b_to_upgrade (Ctrl-C to interrupt)...... Upgrading a volume to 64-bit consumes additional free space in the volume. The following table shows the space usage after each volume is upgraded to 64-bit: Volume Name             Total          Used           Available      Capacity -----------             -----          ----           ---------      -------- test                   100GB          5657MB         94GB           5% ontap8-s*> aggr 64bit-upgrade start aggr32b_to_upgrade -mode grow-all Checking for additional space required to upgrade all writable 32-bit volumes in aggregate aggr32b_to_upgrade (Ctrl-C to interrupt)...... Started 64-bit upgrade on aggregate aggr32b_to_upgrade and all contained writable volumes ontap8-s*> Fri Dec 16 13:58:59 GMT [ontap8-s:wafl.scan.64bit.upgrade.start:notice]: The 64-bit upgrade scanner has started running on aggregate aggr32b_to_upgrade. Fri Dec 16 13:58:59 GMT [ontap8-s:wafl.scan.start:info]: Starting 64bit upgrade on aggregate aggr32b_to_upgrade. Fri Dec 16 13:59:00 GMT [ontap8-s:wafl.scan.64bit.upgrade.start:notice]: The 64-bit upgrade scanner has started running on volume test. Fri Dec 16 13:59:00 GMT [ontap8-s:wafl.scan.start:info]: Starting 64bit upgrade on volume test. Fri Dec 16 13:59:01 GMT [ontap8-s:wafl.scan.64bit.upgrade.completed:notice]: The 64-bit upgrade scanner has completed running on aggregate aggr32b_to_upgrade. Fri Dec 16 13:59:01 GMT [ontap8-s:wafl.scan.64bit.upgrade.completed:notice]: The 64-bit upgrade scanner has completed running on volume test. ontap8-s*> aggr status aggr32b_to_upgrade            Aggr State           Status            Options aggr32b_to_upgrade online          raid_dp, aggr                                 64-bit                 Volumes: test                 Plex /aggr32b_to_upgrade/plex0: online, normal, active                     RAID group /aggr32b_to_upgrade/plex0/rg0: normal, block checksums

[scottgelb]

I have this workaround too but it never made it as a supported QA feature... it exists, but I'd check with support before running anything like this.  It wasn't made available as a feature for a reason but don't know the reason....had to be some issues for it to be in diag mode only.  We saw the same with SnapMirror Compression which was in some early 7 code but not published or documented until later..the same with a-sis.

[fletch2007]

I heard back from netapp support today that while snapmirror is supported from 32 -> 64 bit aggrs,

there is an internal BUG currently preventing datamotion from being supported 32 -> 64 bit

So as a workaround What I want to test next:

datamotion 32 bit vfiler with live VM -> 32 bit aggr on standby cluster, then live upgrade the aggr and volumes to 64bit under 8.1 GA (this is supported by netapp)

The steps are outlined in this thread (aggr 64bit-upgrade start aggr32b_to_upgrade -mode grow-all)

If this works, then the plan will be to

1) tear down the standby 64 bit aggrs and on the standby 8.1 GA cluster

2) recreate them < 16Tb as 32 bit aggrs

3) datamotion all vFilers from current prod  8.1RC2 cluster (32 bit to 32 bit)

4) live upgrade the 32bit aggrs to 64bit (> 16Tb)

5) upgrade the 8.1RC2 cluster to 8.1GA

6) re-establish snapmirrors back

thanks

[scottgelb]

Very good. Did support say the live 32 to 64 bit upgrade is supported in place without adding disks?

Sent from my iPhone 4S

[aborzenkov]

Who talks about “without adding disks”? ☺

“live upgrade the 32bit aggrs to 64bit (> 16Tb)”

[scottgelb]

the post above has the hidden workaround to grow in place without growing over 16TB but not sure if that bug was fixed yet...don't think so but if support mentioned it or not.

[fletch2007]

No - I did not ask support about the 64 bit upgrade without adding disk

but since we have the luxury of a standby cluster, I'm planning to test the secret commands without risk.

Then do the supported workaround dance

I'll tear down my 64 bit aggrs, build up the smaller (< 16Tb) 32 bit aggrs etc

Its fun waking up in the morning with a potentially way to jump through these hoops to use the latest best features