migrate volume that has 2 vfilers to another aggregate and snapvault in protection manager

[dennisvisser]

For a customer I need to move a source volume from aggr1 to aggr3. The volume is about 3,5 TB big and has a snapvault relationship to a nearline storage system.

The volume has 2 vfilers running (qtree based). The snapvault relationship is managed with Protection Manager. Version is 4.0.1 so secondary space management could be an option.

vfiler migrate lookslike no option because the destination is the same storage system.

SSM in protection manager could be an option but one of the requirements is no root volume (vfiler or filer)

Q1a) What will happen when i first do a vfiler destroy, and after the ssm migration I do a vfiler create -r and -b?

First I tested the situation outside Protection Manger with VSM.

problem with vfiler and rename of volume is vfiler change the volume as well. (yes even with cifs terminated)

so the solution then is to first destroy the vfiler and recreate it with the -r and -b option.

In the test enviroment this works as a charm ..... but the problem then is protection manager.

The snapvault relationship in protection manager is id based ... and it is for protection manager a new id.

Only solution then is to recreate the snapvault to the secondary storage system ... so an extra 3,5 TB of space for the baseline.

Here on the community i found the option secondary space management. with is new in 4.0.1 of protection manager.

I tried it now with a volume without vfilers yet.

Q1b) Will it work when i first destroy the vfiler and recreate it with -r and -b?

If client has nfs i could unexport it while migrating

if client has cifs i could unshare it.

Q2a) What if client has luns. Then the option is to unmap the luns? (Q2b or how does SSM check for luns?)

Q3) Anyone who could give me an idication how much time 3,5 TB cost to migrate within the same FAS3140, on fiberchanneldisks.

Because with this option (SSM) all will be down for a while ... the customer probably want to know an indication of downtime although i know it depends on so many factors... but is it 8 hours or is it more like 80 hours ,,,,,

[adaikkap · Accepted solution]

Pls do the following steps.

1. Suspend the dataset,using dfpm dataset suspend <dsid/name> cli.
2. Note the FS id of the volumes being moved.
3. Then using traditional method VSM the volume from aggr1 to aggr3, quiesce and break the mirror.
4. Then resync the snapvault( though i thing this would not be needed as they are in the same filer).
5. After that rewrite the FSID of the migrated volume using ontap cli rewrite fsid.
6. Now do a dfm host disover <filername> on the filer on which volumes are moved from aggr1 to 3.
7. Resume the dataset using dfpm datsaet resume <dsid>

Now things should work fine.

Regards

adai

[dennisvisser]

A few question about your answer:

Then resync the snapvault.--> in protection manager or on the console of the filer?

Rewrite the FSID --> how can i do this? (ontap cli = console of the filer ,,, or dfm command ...)

Thx sofar

[dennisvisser]

ok found the rename of fsid:

console of netapp: vol read_fsid %volumename%

vol rewrite_fsid %volumename%

to change it, volume needs to be restricted.

[adaikkap]

Though you found the answers just for the convenience of others.

Then resync the snapvault.--> in protection manager or on the console of the filer?

In the console of the filer.

Rewrite the FSID --> how can i do this? (ontap cli = console of the filer ,,, or dfm command ...)

Ontap CLI.

Regards

adai

[dennisvisser]

Tested it and works GREAT. THX a lot