I can't see how this would be the case as long as you're SnapMirror relationships are volume-based, which vfiler migrate should do by default. But if you are migrating at the qtree level, clients would have to remount.
-- Adam Fox ------------------------ Typed with my thumbs on a very small keyboard.
----- Original Message ----- From: Buerger, Andreas andreas.buerger@wincor-nixdorf.com To: toasters@mathworks.com toasters@mathworks.com Sent: Thu Nov 27 11:14:08 2008 Subject: vfiler migrate - qtree level mounts
Hi,
I want to perform a vfiler migrate in a production evironment this weekend, and regarding that I had a deeper look at the documentation at NOW. I did the migrate procedure some times before but always with non production data, and every time the migration went smooth without any client interuption (just nfs access).
But when I had a deeper look at the documentation I was a little worried about the following chapter, how does a vfiler migration affect clients:
http://now.netapp.com/NOW/knowledge/docs/ontap/rel73_vs/html/ontap/vfile r/provisioning/concept/c_oc_prov_vfiler-dr-how-migrating-affects-clients .html#c_oc_prov_vfiler-dr-how-migrating-affects-clients (same at the 7.2.5 documenation)
# NFS volume-level mounts move transparently. # NFS qtree-level mounts need to be remounted.
I tested that yesterday and and I can't reproduce that qtree level mounts need to be remounted after a vfiler migrate. Nearly every mount in our environment is based on the qtree level, so we would have a big problem if that's true. When I performed vfiler migrations in the past I never had any errors, it was just like a filer reboot or takeover, and I'm pretty sure that I had a lot qtree level mounts on the clients that were affected.
Can anybody explain, why a qtree level mount needs be remounted like the documentation says? And whats the difference for the client if it mounts a complete volume like filer:/vol/volume or a qtree like filer:/vol/volume/qtree?
May be someone can put me on the right way.
Cheers Andreas