I am having a little bit of an issue with SnapMirror replication and SMVI 2.0. As far as I can see, everything is set up properly. I can manually update the mirror through FilerView or CLI, the destination NetApp is in the Basic Setup list in SMVI. When I get the error message in SMVI it says "The Volume <volume> does not have SnapMirror set up correctly"
I believe I might know what the issue is, though I don't know why SMVI would care.
I am moving all my SnapMirrors to go to 1 volume and separate Qtrees inside the volume. So the 1 volume I have currently is the target for 3 snapmirrors. Data volume, User volume and vSphere volume all go to their own qtree.
Note that the source and destination is sitting on qtrees and I am doing a qtree level snapmirror.
/vol/remote_mirrors/data - this one works because it is initiated through filerview
/vol/remote_mirrors/users- this one works because it is initiated through filerview
/vol/remote_mirrors/vsphere - does not work with error above but works when manually updated through filerview
This is the error message in the logs
<level>WARN</level> <thread>backup4 a21de51a07fd1bbb7c21dcb64ee3f853</thread> <location>com.netapp.smvi.task.ontap.snapmirror.NaSnapMirrorUpdateAction</location> <msgKeyClass>com.netapp.smvi.SMMsgKey</msgKeyClass> <msgKeyValue>BACKUP_MIRROR_NOT_CONFIGURED</msgKeyValue> - <parameters> <parameter>vSphere</parameter> </parameters> <message>The volume "vSphere" does not have SnapMirror set up correctly.</message>
As mentioned SMVI does not support QSM only VSM. Still you have a couple of options. First you can simply set up a QSM schedule which will take the SMVI snaps across. Second you could use a post SMVI job script to update the QSM relationship.
In either case (or with the SMVI VSM integration for that matter) the SMVI snapshot is never the "top" snapshot. SnapMirror will always have a newer snapshot that it uses for the replication process. If you are worried about VM consistentcy (I wouldn't be really) you can always FlexClone the SMVI snapshot for restores or do a SnapRestore on the Volume at the DR site in the event of a disaster. The SnapRestore option though would force you to re baseline when you reverse the replication though so be careful about that.
I feel like I'm asking a dumb question, but whats stopping you from creating a 32bit aggr on the hq site to replicate from remote site using VSM....unless of course you are space constrained. Since 64bit aggrs cap at 100TB it isn't like you have used all of your disk space in 1 big aggr, and 32-bit and 64-bit aggrs can co-exist (ref 8.0 storage mgmt guide pg 122).
So the issue is....
- Remote site is uning 7.x,hq site is using 8.x
- Remote site is 32bit aggr, hq site is 64bit aggr
- Snapmirror works for qsm 32bit to 64bit but not vsm
- Smvi doesn't support qsm
1. Script it (as Keith said)
2. Create a 32bit aggr on the hq site to use vsm?
3. Use 8.x on the remote site so that it can also be contained in a 64bit aggr and do vsm?
Later you configure a snapvault snap sched with the retention you want in destiny. Leave the script with .bat extension in NetApp\Virtual Storage Console\smvi\server\scripts
When you configure the Backup job you specify that script and that is all. You can also find for SV-SMVI tool which will help you to do it with a simple script, as that tool use the environment variable to identify local and remote path and name of snapshoot, etc..
The only limit with SV-SMVI tool is if you are using a private network for storage NFS and vCenter can't connect to filer using that IP you won't be able to use that tool (We have that problem :-S)
P.D.: You must download NetApp Manageability SDK as apitest.exe is part of that SDK. You can request it into NetApp webpage.