SnapDrive snapvault archive not working on vFilers?

[mheimberg]

Hi

I have set up a SnapVault relation between to vFilers, replicating the content of a volume with a MS SQL LUN in it.

So far everything is working fine; I see the status in the vfiler, I can run a snapvault update from the secondary:

SecFiler>vfiler context vfiler-test

vfiler-test@SecFiler>snapvault status

Snapvault secondary is ON.
Source                                     Destination                             State          Lag        Status
172.17.1.98:/vol/iscsi_mssql2k5_lab_db/db  vfiler-test:/vol/sv_mssql2k5_lab_db/db  Snapvaulted    01:32:02   Idle

vfiler-test@SecFiler>snapvault update -S 172.17.1.98:/vol/iscsi_mssql2k5_lab_db/db  vfiler-test:/vol/sv_mssql2k5_lab_db/db

....everything is working.

When switching to the MS SQL server I see the LUN as a SnapVault primary by sdcli disk list

Now I would like to replicate the most recent backup by using sdcli snapvault archive:

>sdcli snapvault archive -a sv_daily -DS N: sqlsnap__mssql2k5-lab__recent

I get the output, that the backupset is submitted, but actually nothing happens on the vFilers.

Could it be, that sdcli archive is not working on vFilers because some kind of API is missing there?

THX

Markus

[scottgelb]

It sounds like sdcli may be looking for vfiler0 (similar to dfm where it only works with vfiler0 for snapvault).  Does "sdcli snapvault snap_list" work?  There is updated documentation on SnapVault management of vFilers stating management is only supported from vfiler0.

http://now.netapp.com/NOW/knowledge/docs/ontap/rel733/html/ontap/onlinebk/GUID-B5462BA9-83F7-4F67-8148-DE0167C5DDE7.html 

There are certain limitations when using SnapVault with vFiler  units. These limitations apply to all Data ONTAP  releases that support vFiler units.

The management of SnapVault secondary (creation or  modification of SnapVault relationships and schedules at  the SnapVault secondary) is only supported from the default  vFiler unit (vfiler0). The management of SnapVault  secondary is not supported from a nondefault vFiler context. If the  volume containing the SnapVault destination qtree is owned  by a nondefault vFiler unit, the SnapVault  secondary needs to be managed through the default vFiler unit  (vfiler0).

[mheimberg]

It sounds like sdcli may be looking for vfiler0 (similar to dfm where it only works with vfiler0 for snapvault).  Does "sdcli snapvault snap_list" work? 

Yes, this command, like all the others, works and gives a correct output.

The management of SnapVault secondary (creation or  modification of SnapVault relationships and schedules at  the SnapVault secondary) is only supported from the default  vFiler unit (vfiler0). The management of SnapVault  secondary is not supported from a nondefault vFiler context. If the  volume containing the SnapVault destination qtree is owned  by a nondefault vFiler unit, the SnapVault  secondary needs to be managed through the default vFiler unit  (vfiler0).

The documentation is weired, because my experience shows something else: in vfiler context you can set options snapvault, eg snapvault.access to another network than vFiler0 is connected, you can also initialize a SnapVault from a primary volume owned by a vFiler to a secondary volume also owned by a vFiler and set the snapvault snap sched....and it is all working!

And that is what I am expecting according the often heard "multi-tennancy"-story 🙂

Seems, like one developpers group does not know what the others are doing...or maybe they know that expanding vFilers capabilities are not yet complete and want to avoid support questions...

Markus