Network and Storage Protocols
Network and Storage Protocols
Hi guys,
Some volumes have been created too small and added to a DR vfiler. Removing them does not work:
FAS> vfiler remove vfilername /vol/VOL001
Cannot remove resources from hprifil0004. Vfiler is part of the DR
configuration for a remote vfiler.
Are any of you aware of a procedure to get out of this without interferring with the source vFiler? Im thinking if we can fire up the DR vfiler
without invoking CIFS we should be OK to remove the volumes with the command above. Then we should be OK shut it down and add
the correct volumes.
Currently the volumes are showing up as offline:
vfiler stopped, DR backup
ipspace: default-ipspace
IP address: xxxxxxx [unconfigured]
Path: /vol/HPRIFIL0004_ROOT [/etc]
VOL001 [OFFLINE]
VOL002 [OFFLINE]
Solved! See The Solution
Here's one way to do it...it's strictly on the dr side so the source won't be touched.
o Delete the dr vfiler
> vfiler dr delete <vf>@<host>
o Make any volume changes you want.
o Recreate the vfiler using the vfiler root volume
> vfiler create <vf> -r <path_to_root>
o Stop the vfiler
> vfiler stop <vf>
o Resync the vfiler to be a dr vfiler again.
> vfiler dr resync <vf>@<host>
This should resync all of the snapmirror relationships and make it a dr again.
Hope this helps.
Here's one way to do it...it's strictly on the dr side so the source won't be touched.
o Delete the dr vfiler
> vfiler dr delete <vf>@<host>
o Make any volume changes you want.
o Recreate the vfiler using the vfiler root volume
> vfiler create <vf> -r <path_to_root>
o Stop the vfiler
> vfiler stop <vf>
o Resync the vfiler to be a dr vfiler again.
> vfiler dr resync <vf>@<host>
This should resync all of the snapmirror relationships and make it a dr again.
Hope this helps.
Adam,
Thanks a bunch for that. I ll give that a try in the lab. My only concern is that it seems that creating the vFiler will boot it up. Ideally I d like to avoid that but
I guess I can stop it straight away.
Once again, thanks!
Eric
Defintely try it in your lab, but I believe what you will find is that when you use the -r with the root path, it remembers that it was not up when you deleted it so it doesn't activate the IPs when you create it.
FYI
great, even better when I thought it couldnt get any better!
unfortunately my lab testing shows that the vfiler comes up running after having run
vfiler create vf -r /vol/vfiler
halting it is pretty fast but still, its a little bit of a risk. Just thought I d let everybody know. feel free to contradict me
as it would help me 😉
Eric
actually a second test using the following command to recreate the DR vfiler
vfiler dr configure vf@filer
works FINE. Ontap will ask you if you want the DR vfiler to come up when you configure it, so just answer NO and its all good.
All of the above is on 7.3.2 simulator. I need to get this tested in 7.2.5.1 as well.
Eric
When running dr configure or resync, I save a copy of snapmirror.conf first. vfiler dr updates snapmirror.conf to 0-59/3 for 3 minute updates which you might not want, especially when the mirror schedules for those volumes in the vfiler might already be set. So if no new mirrors, it's easier to write back the original snapmirror schedule.
thats correct. we found out the hard way. its easy to fix with snaps of vol0 and ASUPs etc. its a small gotcha worth noting for sure.
Thanks for all the other info, its very useful.
Cheers,
Eric
Also, dr configure will initialize all mirrors from scratch, so if there are any existing mirrors, then I use dr resync instead to not have to re-init. For new vfiler dr setup with several large volumes already mirrored, we manually mirror the remaining volumes in the vfiler then just do the resync to get it running.