I have done a lot of PS engagements like this where we move existing workloads into vFilers. Basically you need a vfiler root volume to create the vfiler...then you assign the volume from vfiler0 to the vfiler itself (no migration, just a move of the volume) but you need to delete all cifs shares and nfs exports first...then recreate them in the vfiler. And then join the vfiler to the domain. There are a lot of things to check and recreate from vfiler0 into the vfiler but worth getting some PS hours if you haven't done it before. Below is a list of considerations from the vFiler labs I created/taught at Insight for MultiStore. A good check list to start with below..
-------
It is possible to migrate an existing physical controller to a vFiler unit. There are many considerations to plan for moving a physical controller into a vFiler. There will be downtime to migrate to a vFiler, but if you plan (and pre-write commands or scripts) for all the considerations below, the downtime can be short. In many cases you may take vfiler0 and create more than one vFiler, and that can be extrapolated from the list below.
There are a lot of small things to migrate from vfiler0 into the vFiler and these considerations also apply when migrating from one physical controller to another physical controller. Below is a checklist of topics without ONTAP commands (anyone doing this work should know the commands or where to find them). A pre-written plan to execute on-site is the key to success when migrating to a vFiler from a physical controller.
• A vFiler needs its own small root volume
• Create a root volume for the vFiler
• iSCSI Nodename and LUN Mappings
• Rename the vfiler0 iscsi nodename and reassign the iscsi nodename on the vFiler to match former vfiler0 for no client change (you can leave it different but need to make changes on the clients if you do).
• Create iGroups in the vFiler
• Map LUNs to iGroups
• Hostname
• Need a new hostname (either for vfiler0 or vFiler depending on which keeps the original hostname). For no host change, often vfiler0 is renamed and the vFiler assumes the name of vfiler0.
• IPSpaces
• Do you need to create a separate network from the default-ipspace?
• IP and Interface, DNS, NIS, LDAP
• You need a new IP (often put a new management IP on vfiler0 and move existing interfaces on vfiler0 to the vFiler).
• Domain Membership, FilerSID, Recreate shares and exports
• We need to rejoin the domain from vFiler using the same netbios name we had in vfiler0, then rejoin with vfiler0 with a new netbios name. Typically vfiler0 rejoins the domain with a new name to free the computer account first.
• SnapMirror Relationships
• Need to manually setup additional volumes and then create the dr vfiler manually ,then resync it. Use vfiler0 for the relationship, so this typically involves a new IP address since the new vFiler typically assumes the physical filer address and you have a new hostname and IP for vfiler0 which will be the source of the mirror for vfiler dr. You could use the vfiler IP for snapmirror, but not if using vfiler dr.
• If Operations Manager use vfiler0 for relationships and update snapmirror.access.
• NDMP Backups
• If any backups are set to run against vfiler0 and it’s ip changes, change the backup software to authenticate to vfiler0’s new IP/name. NDMP works for copying but does not work for backup to tape from a vFiler. NDMP backups for the data will need to re-authenticate to vfiler0.
• SnapVault Relationships
• Operations Manager uses vfiler0 (hosting filer) for SnapVault relationships. Modify / restart vaults from vFiler0 between source and target instead of direct vfiler to vfiler.
• Set snapvault.access and ndmpd.preferred_interfaces on vfiler0.
• VSCAN
• If any vscanners are set to run against vfiler0 and its ip changes, change the vscan software to authenticate to vfiler0’s new IP/name. Unless you want to vscan from the vFiler (most often vscan is centralized for all vFilers at vfiler0).
• Netbios Aliasing
• If any netbios aliases are used by vfiler0, they need to be moved to the vFiler. NOTE: this might be an issue if you leave resources on vfiler0 that also need the alias. The same alias can’t be in more than one filer (virtual or physical). If all resources move to the vFiler, we can move it from vfiler0, but if not, users may be impacted.
• AutoHome directories
• If any autohome directories are setup for any volumes moving from vfiler0 to the vFiler, they must be removed from vfiler0 and setup again in the vFiler.
• Local User Accounts
• Create local user accounts in vfiler0 in the vFiler. There is a method to export and import registry entries for users.
• Local Groups
• Check for local groups from the windows mmc and/or /etc/lclgroups.cfg. Make entries in the new vfiler for any groups needed in the vfiler.
• Domain User Accounts
• Always check to see if domain user accounts are used in vfiler0 so they can be added to the vFiler.
• SNMP
• Match SNMP settings if any snmp monitors are used (OpsManager, etc.)
• Quotas
• If any quotas are set on volumes moving from vfiler0 to the vFiler, the /etc/quotas entries need to be removed from /etc/quotas on vfiler0 and created in /etc/quotas on the vFiler, then “quota on volname” in the vFiler for the volume.
• User Mappings
• Copy usermap.cfg entries needed in vfiler1 from vfiler0 (modify / copy / delete as needed for each vfiler)
• CIFS, NFS, iSCSI Options
• List all options from vfiler0 and match on the vFiler
• Fpolicy settings
• Need to run fpolicy setup in the vFiler
• Widelinks
• /etc/symlink.translations (move from the physical controller to the vFiler).
• SSH, RSH setup
• Both of these need to be enabled and configured in the vFiler.
• Volume Names
• Volume names must be the same on the source and destination for migrate, dr and data motion.
