I ran across an issue today that my various sources of troubleshooting (ok, Google) couldn’t help solve – at least not directly. I configured SnapMirror between two disparate systems for a data migration. 16 of the 17 volumes initialized just fine, but I was getting an error on the one volume that had a LUN inside. It was a SnapDrive for Windows LUN, so I knew that just prior to the final cutover I’d have to take a Snapshot via SnapDrive, but I should be able to start the baseline transfer via the standard CLI. Here’s what I was seeing:
ControllerA> snapmirror initialize -S ControllerZ-vif01:vol_server2008 ControllerA:vol_server2008 Transfer started. Monitor progress with 'snapmirror status' or the snapmirror log. Mon May 13 14:21:26 CDT [ControllerA:replication.dst.err:error]: SnapMirror: destination transfer from ControllerZ-vif01:vol_server2008 to vol_server2008 : process was aborted.
I had the opportunity to configure SnapMirror for a client today and it gave me a bit of a headache. I did what I thought was my due diligence: reading the relevant vendor documentation for SnapMirorr for each version of Data ONTAP, 7.3.2 and 8.0.3P3. What I failed to do was read a few lines further than I actually did – I missed a simple piece of syntax that turned a 30 minute WebEx into a 2 hour ordeal. I learned a good lesson about SnapMirror during this engagement, though, and I’d like to share it.
The SnapMirror of these three volumes were actually for a data migration because the source filer is being decommissioned. The general steps required in the engagement today were as follows:
<> Run a cable between what will be the dedicated replication links on each filer
<> Configure each interface with IP settings
<> Ensure SnapMirror is licensed and enabled on each filer
<> Configure /etc/hosts and /etc/snapmirror.allow files on source filer
<> Configure /etc/hosts and /etc/snapmirror.conf files on destination filer
<> Initialize the baseline replicaction