Ok, I'm not sure if this was the best solution, but I did a snapvault stop on the secondary, moved the volume to a new aggregate and then issued a snapvault start. This started a new baseline snapshot. The volume was a small one so the baseline snapshot didn't hurt much. The old snapshots are still there.
But I'd like to know how could move a snavault destantion volume/qtree, without stopping first the snapvault relationship and without the need to start a new baseline snapshot.
I'm not sure that we have a snapmirror license, at least we don't use it yet. Is there no command get the same result with snapvault commands. We have much larger volumes/qtrees with 8+ TB. If I have to move one of these volumes to a different aggregate on the source side, I'll also have to move it on the destination side. But I don't see an easy way to do this yet.
"snapvault start -S -r" will reestablish the vault without rebaselining...the -r to restart updates... the vol move method should work fine but copying the volume works too since vol move is doing the same thing in the background but less commands for vol move and automates a lot of the steps.
I have found the same problem when trying to move snapvaulted volumes. The "vol move" doesn't seem to want to work with snapmirror (or snapvaulted) volumes so you have to do the process manually. Now I am not a NetApp Engineer so this may not be 100% correct, but it has worked for me using OnTap 8.1 on a number of volumes.
1. First thing is to disable any external process that might try to update the volume during the move. (i.e. Protection Manager or custom backup scripts)
2. Create the new volume (I also assign volume options, your options may be different)
vol create volname_new aggr size
vol options volname_new guarantee none
vol options volname_new nosnap on
vol options volname_new nosnapdir on
vol options volname_new fractional_reserve 0
vol options volname_new try_first volume_grow
3. Before I do anything I enable Dedup and Compression.
sis on /vol/volname_new
sis config -C true -I true /vol/volname_new
sis start -s -d -f /vol/volname_new
sis status /vol/volname_new
4. Copy the entire contents of the volume including ALL snapshots (because having a snapvaulted volume would be useless without the snapshots)
vol restrict volname_new
vol copy start -S volname volname_new
5. Swap the names of the old and new volumes
vol online volname_new
vol rename volname volname_old
vol rename volname_new volname
vol offline volname_old
So at this point you now you have a new volume with the exact same information in it as the old volume (which is now offline).
Because the new volume has the old name and all of the snapshots have the same name you Protection Manager will still be able to restore any information.
Also snapshots which were "snapvaulted snapshots" are present, so any snapvaulting should proceed flawlessly. (It is my understanding that the special snapshots "snapvault" or "snapmirror" contain extra meta data which points them back to their partner)
Be just to be sure I normally initiate a manual snapvault update:
snapvault update /vol/volname/qtree
And then enable and run a manual Protection Manager Job or run whatever custom script I use for backups.
Same here - after 'vol move' from one aggr to the other any attempts to start snapvault 'snapvault start' result in the error:
Transfer aborted: the qtree is not the source for the replication destination.
That KB that was quoted to you by the support was not on the subject - conversion from traditional to flex volume. No wonder they where eager to close the case 🙂
My workaround was to create new volume on the new aggregate and run 'snapvault start -S' to do baseline transfer. Looks like the presence of the old SV snapshots in the volume that was moved had something to do with it.