Relocate OSSV Secondary to new Vol/QTree

[ Edited ]

I have a situation where we have a FAS3240 configured as an OSSV secondary to 20 or so remote Windows file servers running OSSV.  Everything is generally running well, with the exception that the existing secondary/destination paths are both obscurely named and limited to around 1TB of data.  I presume this is a historical thing, based on previous OnTAP limits.  For example, I have:

SERVERA:E:/ -> FAS3240:/vol/vol1/SERVERA_E__

SERVERB:E:/ -> FAS3240:/vol/vol1/SERVERB_E__

SERVERC:E:/ -> FAS3240:/vol/vol2/SERVERC_E__

SERVERD:E:/ -> FAS3240:/vol/vol2/SERVERD_E__


The desire is to both get some better naming involved (overall across all vol/qtree/shares) and co-locate everything into a single Volume allowing for better DeDupe/Compression at the destination. 

So something like:





How can I do this without either re-baselining (600GB across 10mbit WAN is not great), or resorting to LREP.  Also, the replication is being handled by DFM (4.0.1D5), if that matters at all.

NetApp support has pointed me here: but this seems very much related to a Primary/Secondary SV vs a Windows/Secondary OSSV relationship.  I've been trying the steps in simulators and on a lab unit, and am not having much luck. 

Any suggestions?


Re: Relocate OSSV Secondary to new Vol/QTree

Hi Avram

The KB is OK. But there is also a detailed description in the OSSV Manual.

I've done this for OSSV a couple of times and it works, without rebaselining the relationship.

Where did your sim test exactly fail?


Re: Relocate OSSV Secondary to new Vol/QTree


Thanks for the reply, it at least lets me know I'll find a way.  I have to be honest, I'm new to NetApp in the last 6 months, and I've done a little button mashing to get to where I have gotten.  Some of the issues I've had were:

* As I'm on a single unit, without a Pri/Sec, the sequence of commands in the KB article are uncertain to me.  It is not clear if the Pri is also the Sec in my use case, or if it the Pri specifically refers to the Windows OSSV host. 

* At this point, by making some assumptions I managed to get past it not wanting to let me do a QSM of the original location (I believe that was telling me it wasn't possible with that type of source - I assume because it was not properly converted from SV or because it was showing as a VSM relationship in System Manager and not a QSM, and it was a limitation on a OSSV -> QT -> VSM -> QSM type of cascade

* Currently, I got the data to QSM to the new location.  When I try to update the OSSV relationship, it tells me it did so, but when I try an actual replication, I get "Transfer aborted: the qtree is not the source for the replication destination."

I'm going to clean up my mess, start fresh with a new test and take some better notes.  I'm also going to check for the OSSV manual, I know I've been through the Best Practices one, but as there are many, I suspect I'm just not looking in the one most appropriate to this.  If you have a document and page number or a sample of what you've done, I'd be appreciative, but don't think I won't go getting off my duff to try to find the answer on my own   I'll be back tomorrow.....


Re: Relocate OSSV Secondary to new Vol/QTree

Looks like page 159 of the Installation and Administration Guide at  I get it at a high level, will need to give it a try.  However, and I may be over thinking it, this refers to relocating the volume in their original states, to new aggregates as I understand it.  So in my case, isntead of ending up with my 4 QTree destinations in a new common volume, I'd still end up with 2 destination volumes, with 2 QTree's each, just on a new aggregate.  For now, I'd settle for that, as it would clean up some old disk.  I'll give it a shot and see if it works just as well if I'm going to a net new volume. My assumption is that it is doing a VSM vs a QSM, and I won't be able to merge two volumes.  Knock on wood....

Re: Relocate OSSV Secondary to new Vol/QTree

Hi Avram

PRI is in this case always the OSSV client. SEC is always the NetApp System.

You can get everything in ONE volume, just do not forget to "start" the relationship again (snapvault start -S ...." this is the key to success...

Hope this helps,


Re: Relocate OSSV Secondary to new Vol/QTree


So I've given it a retry, with the advice you provided and tried to use the two documents to try to get a better triangulation on what either or both wanted, and try a few different things.

I'm near the end but what i have is:

NW-FAS2020A*> snapmirror status

Snapmirror is on.

Source                                     Destination                                State          Lag        Status

NW-WSUS1:C:/                               NW-FAS2020A:/vol/VOL_OSSV_01/NW-WSUS1_C__  Broken-off     01:03:55   Idle

NW-FAS2020A:/vol/VOL_OSSV_01/NW-WSUS1_C__  NW-FAS2020A:/vol/VOL_OSSV_02/NW-WSUS1_C__  Broken-off     00:44:36   Idle

The first line showed up after doing the "Before executing the recipe, enter the following commands:" from the KB article, to convert the SnapVault path to a SnapMirror, which makes sense.  Then after creating the QSM of the original VOL (VOL_OSSV_01) to the new VOL (VOL_OSSV_02), I get the second one.  Both documentation tells me I want to quiesce then break the SnapMirror, which ends up with me in a Broken-off state.

If I then try to convert the new path to a SnapVault:

NW-FAS2020A*> snapvault convert /vol/VOL_OSSV_02/NW-WSUS1_C__

Error converting qtree: destination is not in snapmirrored state

If I trye to either modify or start the SnapVault relationship, I get errors that I wasn't neccesarily expecting, but upon reading, they do make sense.

NW-FAS2020A*> snapvault modify -S NW-WSUS1:C:/ NW-FAS2020A:/vol/VOL_OSSV_02/NW-WSUS1_C__

The qtree /vol/VOL_OSSV_02/NW-WSUS1_C__ is not configured in snapvault.

Configure first with the 'snapvault start' command.

NW-FAS2020A*> snapvault start -S NW-WSUS1:C:/ NW-FAS2020A:/vol/VOL_OSSV_02/NW-WSUS1_C__

Qtree /vol/VOL_OSSV_02/NW-WSUS1_C__ already exists and is not a replica.

So it seems like I am very close.  Just need to get over this last hump.  Any suggestions?

Thanks in advance.

Re: Relocate OSSV Secondary to new Vol/QTree

With a little button mashing, I was able to get the VOL_OSSV_01 and VOL_OSSV_02 QSM resynced, which then allowed me to do the snapvault convert.  I was then able to do the snapvault modify, and a snapvault status show it on the secondary properly. 

NW-FAS2020A> snapvault update -w NW-FAS2020A:/vol/VOL_OSSV_02/NW-WSUS1_C__

Thu Nov 22 06:50:12 GMT [replication.dst.err:error]: SnapVault: destination transfer from NW-WSUS1:C:/ to /vol/VOL_OSSV_02/NW-WSUS1_C__ : the qtree is not the source for the replication destination.

Transfer aborted: the qtree is not the source for the replication destination.

This is I guess where I'm stuck for tonight. 

Re: Relocate OSSV Secondary to new Vol/QTree

Looks like it needs one last "snapvault start -S" to get the thing properly registered in Ontap... Then the "snapvault update" should work again.

Re: Relocate OSSV Secondary to new Vol/QTree

I had tried a number of snapvault <options> after that, I was never able to get beyond the "qtree is not the source".  OnTAP support came back and told me that it was not possible, and unfortunately closed my ticket.  Looks like I'm buying hard drives and doing LREP's  

Re: Relocate OSSV Secondary to new Vol/QTree


As you're new to NetApp and it can be a bit overwhelming if you're diving into SnapVault and OSSV, check out the Data ONTAP 8.1 7-mode simulator. (Search the communities site for "simulator")  You can install the simulators on your laptop or a spare PC and use them to experiment with OSSV, SnapVault, SnapMirror or just about anything else.  The simulators do about 95% of what a real NetApp controller can do.

As an example, I've got VMware workstation on my laptop. I'm running two 8.1 7-mode simulators, OnCommand 5.1 (a.k.a DFM) and a Linux client running OSSV.  I use this to experiment with Protection Manager, OSSV backups, complex SM/SV relationships and doing customer demos.  Its a fantastic learning tool that avoids the risk of a live production system.