topic Re: QSM Snapmirror - 32bit --> 64bit aggregate migration in ONTAP Discussions

QSM Snapmirror - 32bit --> 64bit aggregate migration

JLundfelt — Thu, 05 Jun 2025 06:28:41 GMT

Hey guys,

I am being tasked with migrating about 20 volumes from existing 32-bit aggregates to 64-bit aggregates, and as I understand it, cannot use NMC in any capacity whether it be migration / protection manager, or secondary space manager due to the transition from 32-bit to 64-bit. Anyways, I am looking for the best way to create qtrees on the source, create the target volume, and initialize the snapmirror relationship. I have found a few docs-

https://communities.netapp.com/docs/DOC-6246

http://blog.hernanjlarrea.com.ar/index.php/migrating-vsm-snapmirror-to-qsm/

But they imply VSM, or creating new volumes. Anyone have any thoughts on how best to do this? How can I create a qtree on a volume, if its CIFS data in the root?

Thanks,

Jon

Re: QSM Snapmirror - 32bit --> 64bit aggregate migration

mikhail — Thu, 26 Apr 2012 06:37:16 GMT

Hi Jon,

You do not need to create qtrees on source, you can simple use QSM for non-qtree data, see quote from man pages below.

There is a special path that can be used to SnapMirror all the data in a volume which does not reside in a qtree. This path can only be used as a SnapMirror source, never a SnapMirror destination. The path is specified as:

/vol/vol1/-

Re: QSM Snapmirror - 32bit --> 64bit aggregate migration

ERIC_TSYS — Thu, 26 Apr 2012 11:58:12 GMT

what versions of Ontap are you dealing with? If you make sure the destination is on 8.1 you have the choice to do volume snapmirror too

https://library.netapp.com/ecmdocs/ECMP1120690/html/frameset.html

Support for volume SnapMirror replication between 32-bit and 64-bit volumes

Starting with Data ONTAP 8.1, you can replicate volumes by using SnapMirror technology between 32-bit and 64-bit volumes. For both synchronous and asynchronous volume replication, the SnapMirror source and destination volumes can be either 32-bit or 64-bit.

Eric

Re: QSM Snapmirror - 32bit --> 64bit aggregate migration

JLundfelt — Thu, 26 Apr 2012 17:04:13 GMT

Thanks, we are running NetApp Release 8.0.3RC1 7-Mode, and I am struggling to understand how to create a qtree in a volume, where all the data already exists in the root of the volume. What is the procedure to setup a QSM relationship on a pre-existing CIFS volume where there isn't already a qtree?

Re: QSM Snapmirror - 32bit --> 64bit aggregate migration

JLundfelt — Thu, 26 Apr 2012 17:10:00 GMT

I'm also curious how to snapmirror vol0 to a new 64-bit aggregate? Is there any docs on that? these threads seem to contradict each other-

https://communities.netapp.com/thread/2985

https://communities.netapp.com/thread/15895

Thanks,

Jon

Re: QSM Snapmirror - 32bit --> 64bit aggregate migration

scottgelb — Thu, 26 Apr 2012 17:19:19 GMT

We usually just Ndmpcopy etc, remove the restore_symboltable file l, mark new volume as root and reboot. Works on any volume type. Or if 8.1 you can snapmirror to 64 bit the source then break. Mark as root and reboot.

Re: QSM Snapmirror - 32bit --> 64bit aggregate migration

JLundfelt — Fri, 27 Apr 2012 20:40:18 GMT

I can't seem to establish a snapmirror relationship in preparation to moving my root vol, 'vol0'-

PS C:\Windows> Invoke-NaSnapmirrorInitialize -Destination "irv-gdc-san1a:vol0_1" -Source "irv-gdc-san1a:vol/vol0/"

Invoke-NaSnapmirrorInitialize : Invalid source vol/vol0/: The argument must be a volume name or a qtree path. Please specify either "volname" or "/vol/volname

/qtreename".

At line:1 char:30

+ Invoke-NaSnapmirrorInitialize <<<< -Destination "irv-gdc-san1a:vol0_1" -Source "irv-gdc-san1a:vol/vol0/"

+ CategoryInfo : InvalidOperation: (irv-gdc-san1a:NaController) [Invoke-NaSnapmirrorInitialize], ESNAPMIRRORPARSERERROR

+ FullyQualifiedErrorId : ApiException,DataONTAP.PowerShell.SDK.Cmdlets.Snapmirror.InvokeNaSnapmirrorInitialize

PS C:\Windows> Invoke-NaSnapmirrorInitialize -Destination "irv-gdc-san1a:vol0_1/-" -Source "irv-gdc-san1a:vol/vol0/-"

Invoke-NaSnapmirrorInitialize : Invalid destination vol0_1/-: The argument must be a volume name or a qtree path. Please specify either "volname" or "/vol/vol

name/qtreename".

At line:1 char:30

+ Invoke-NaSnapmirrorInitialize <<<< -Destination "irv-gdc-san1a:vol0_1/-" -Source "irv-gdc-san1a:vol/vol0/-"

+ CategoryInfo : InvalidOperation: (irv-gdc-san1a:NaController) [Invoke-NaSnapmirrorInitialize], ESNAPMIRRORPARSERERROR

+ FullyQualifiedErrorId : ApiException,DataONTAP.PowerShell.SDK.Cmdlets.Snapmirror.InvokeNaSnapmirrorInitialize

Any thoughts?

Thanks,

Jon

Re: QSM Snapmirror - 32bit --> 64bit aggregate migration

mikhail — Fri, 27 Apr 2012 21:31:54 GMT

As I can see you have wrong syntax on both attempts, I'm not familiar with PowerShell toolkit but to initialize transfer from cli command it should be like that

snapmirror initialize -S hostname:/vol/vol_data/- hostname:/vol/new_vol_data/qtree

but it should be understood that data on the destination system will be put in qtree and you have to live with it, but I think that will not work for vol0 as it's files should be in /etc on the root volume (I have always used ndmpcopy to move vol0 and never tried QSM). I think this solution is perfectly fine for file services, and change almost nothing except that you should slightly change shares and exports. Another options is to use ndmpcopy, volcopy or 8.1 as was mentioned below.

Re: QSM Snapmirror - 32bit --> 64bit aggregate migration

aborzenkov — Sat, 28 Apr 2012 02:57:10 GMT

1. Source should be "irv-gdc-san1a:/vol/vol0/-" (notice leading slash in qtree name)

2. Destination must be qtree. You can’t QSM non-qtree data onto non-qtree data on on a whole volume

For root volume migration ndmpcopy is more than enough.

Re: QSM Snapmirror - 32bit --> 64bit aggregate migration

ERIC_TSYS — Sat, 28 Apr 2012 09:32:44 GMT

have a look here: https://forums.netapp.com/thread/8657

Also, by looking at the power shell thingy, which I dont know much about, it seems like you put destination and source second. The CLI

syntax is the opposite

snapmirror initialize -S source destination

Maybe thats why thats playing up? Also, if you are looking to move the ROOT volume then you dont want to do a QSM, do a VSM.

I prefer snapmirror to ndmcopy and vol copy because you can set up a baseline and update it as you need. just update it before cutting over.

cheers,

Eric