SMVI SnapMirror Issue

[jeffgarmin]

Hello,

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>

Thanks in advance for your help.

[tucker]

>

When I get the error message in SMVI it says "The Volume <volume> does not have SnapMirror set up correctly

<

Were you using QSM (qtree snap mirror)?  This is not supported in the smvi product.

[jeffgarmin]

Hi Tucker,

Thanks for your reply.  This is very intersting and causing an issue.

I have a 2020 in a remote site that I want to replicate back to my main location.  We just bought a NetApp with some 300TB of space for backup / replication.

That being said, when I set up this new one, I put in Data OnTap 8.0.1 to be able to take advantage of the 64 bit aggregates.

Volumes sitting on a 32bit aggr cannot be replicated to a 64bit aggr unless it's a QSM.

Any ideas?

Best thing I can think of off the top of my head is to schedule my SMVI snaps to occur at the same time that a mirror would get kicked off, though the consistency of my VMs could be questionable.

[tucker]

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

options

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?

[cesar_arribas]

I will try to answer you ...

As it's mentioned before SMVI doesn't support QSM. But what you can do is to use SnapVault instead of Snapmirror.

You have to create a Script with next content:

if %BACKUP_PHASE% == POST_BACKUP goto doSV

goto ende

:doSV

chdir "c:\Program Files\NetApp\ontapi"

apitest.exe GUAFAS02 smviuser qnPmJB2g snapvault-secondary-initiate-incremental-transfer primary-snapshot NAME-OF-PRIMARY-SNAPSHOT secondary-path /vol/VOL_REPLICATION/QTREE

goto ende

:ende

EXIT /b 0

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.

Regards,

[keitha]

Hi Jeff,

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.

Keith

[hadrian]

Hello,

Check this out:

"The host names and IP addresses of the SnapMirror source and destination storage systems must be resolvable for the SMVI server, either through a configured DNS server or through hosts entries."

Make sure full forward / reverse DNS is working for the source / destination storage controller, resolvable using the same names used in the /etc/snapmirror.conf file.

See pg 21 of the VSC Backup and Recovery guide for the rest of the SnapMirror requirements.

Hope this helps,

Hadrian