Upgrade V6210 to Data ONTAP 8.1RC3

[#1]

We are planning on upgrading our V6210 which has two controllers in an active active setup to 8.1 RC3.  They are currently running 8.0.2P2 7-mode.  These are running multiple vfilers on each controller.  We should be able to move all the vfilers to one controller, and then update the other controller.  Will there be any issues once the other conttroller is upgraded to the new version of ONTAP to be able to migrate the vfilers to the newly upgraded controller while the other is still at the older version?  I am trying to determine how much downtime if any will be required for my vfilers during the upgrade process.

[#2]

Following the NDU process (use upgrade advisor) you run cf takeover then giveback on each node (with a takeover -n after one node is upgraded to halt the lower system).  All vFilers stay running.  When a node takes over another node the partner runs an instance on that node along with all its vFilers.  Just make sure all network interfaces have working partner interfaces and you are good to go.  Also make sure all hosts have timeouts set properly (iSCSI, FCP - no fcp in vfilers though, NFS).  CIFS will be terminated since not persistent with an Non-disruptive upgrade.

Run through upgrade advisor and review the plan... I also wonder why you are going to an RC release instead of staying on GA (8.0.2P6 for example)?

[#3]

We need to attach to an IBM XIV GEN3.  The first supported version of ONTAP is 8.1 RC3, so we don't have much choice at this point.

[#4]

Good reason to do the upgrade... when we hear about an RC release a feature is the key reason to upgrade but wanted to make sure.  If you want to swap vFiler volumes between the XIV once connected, a trick is to vfiler migrate vFilers between controllers... you can't use data motion (guaranteed migrate in 120 seconds) but a fairly quick migration still with minimal outage using vFiler migrate...we have done this at v-series customers to move to new back-end arrays... basically all vfilers on nodeA move to B and vice-versa moving one at a time back and forth to get volumes moved intact with the vfiler and migrating between back-end disk.  Works well for non-vseries when adding newer disk too.

[#5]

IBM was suggesting we temporarily break multipathing and zone one fiber connection from each controller to each SAN.  One to the XIV GEN2(Current Storage) and One to the XIV GEN3(New Storage).  Setup a new volume on the GEN3 and then setup a SyncMirror to sync the volumes.  Once sync is complete cutover to the new volume.  Does this sound like the proper approach to migrating data?

[#6]

syncmirror on the back-end fc loop is a way to do it then break it after... a good idea.  I haven't tried it with v-series but should work well and you can split the aggr after... just need to make sure you have some aggregate reserve for the aggregate snapshot used.  This won't have disruption but might be worth adding an HBA if you want to keep the active/passive resiliency during the cutover.

[#7]

Sounds Good.  Thanks