Trying to find a solution to an issue I'm having with a client and vFiler DR configurations.
Is it possible to use the nifty "/-" wildcard when setting up the SnapMirror relationships between the two sites for the DR vFiler?
Reason being - primary site utilizes a 64-bit aggregate, destination utilizes a 32-bit aggregate. I know that you can use the /- wildcard to do QSM when no qtree exists (thus how you are able to replicate from one aggregate type to another as is in this case).
It seems that vfiler dr config does not like trying to utilize SnapMirror in this way. Tried it a couple of times and unless I'm doing something wrong, it's not working at all.
I've presented options to the client:
Replicating the DR vFiler to another array at the remote location temporarily until we're able to upgrade properly to 64-bith aggregate (they have two, one for CIFS only which should be the intended target and another for NFS / block, with the block filer being 64-bit and have successfully tested vFiler DR replication to).
Since source vFiler is not yet in use, create qtrees and use SQM between the two filers (makes this an oddity since we're not really using qtrees anywhere else).
Utilize the method of upgrading filer to ONTAP 8.1, converting to 64-bit aggregate, reverting to ONTAP 8.0.2P4. This was just recently done on the source filer, however we could afford to do so since it was not in production use (desired DR vFiler target IS in production use). Process works well, however in order to revert, you must delete all snapshots and this would not be a desired option, and, in deleting snapshots, all SnapMirror replication targets become stale and have to be recreated. So in this, what happens when the client needs to keep the snapshots? Vault them? Break SM relationships and just keep stale volumes until retention period wears off?
Filers are 3210's so upgrading to 8.1 and leaving it there is not an opting since they both have FlashCache (aware of commands to run from loader prompt to disable when using ONTAP 8.1 for aggregate conversion purposes).
So, situation is quite tricky. Reaching out to all NetApp geniuses for assistance / advice.
i think putting /etc for vfiler root (qtree path) is the way to go an utilise qsm until the other boxes are upgraded and then change them to vsm afterwards, not sure which replication technology the vfiler dr commands use qsm or vsm but you can alyways initialise them manually, I dont think it will be block replication for qsm paths
Are you trying to setup permanent DR relationship or just one off migration?
For a single migration run I guess it could be possible to use volume-to-qtree QSM (/- => dest:/vol/new/qtree) and then use “vfiler create -r /vol/new/qtree” to recreate vFiler on destination. Keep in mind, that you may not have any qtree inside this source volume – it will not be replicated.