Dell Unity: How To Have A Successful IMT Migration (User Correctable)

The Dell Unity Inband Mobility Tool (IMT) is a great tool for migrating data from your previous VNX array to your new Unity system. However, there are some things which can be donein order to ensure your best chance at a successful migration.

Here are a few pre-conditions to be aware of when considering whether or not, and when, to begin your IMT migration:

• IMT only supports VNX1 or VNX2 storage systems. Older Celerra or VNX systems (VG or NS systems) are unsupported as source systems.
• IMT uses file-based copy protocols (NFS or CIFS) to copy data.
• Special file system on VNX, such as NMFS or WORM file system, are unsupported as source file system.
• Multiprotocol source file system are unsupported; only CIFS OR NFS is copied.
• Disable FTP services on any NAS servers involved in an IMT migration before starting that IMT migration.
• Ensure you have enough space on your destination to host all of the files on your source BEFORE you begin.  Do not rely on automatic extension; pre-configure all space before you start.
• Ensure that if quotas are enabled on the target file system that there is enough quota available for the expanded size of any files. 
• Compressed (deduplication or DHSM) source file system are expanded during migration.  You must consider the expanded size plus overhead when planning how much space to allocate in your target file system.
  • You must also enable file recalls on your source array to account for this.
• When performing a VDM migration, the interface attached to the CIFS server on the VDM being migrated will be cut over to the Unity system. If it is the only interface on the VDM, this leaves the source VDM unreachable. Ensure you have at least one additional interface configured on your source VDM so that other users do not lose connectivity at cutover.

The following items impact when a migration using IMT can be performed:

• Once you begin your migration, you cannot change the source array, such as renaming CIFS servers. Consider the VNX LOCKED DOWN once you start the migration, and keep it locked down until the migration is concluded and cutover is successful.
• You should also consider doing your migration during a LOW I/O PERIOD of the source filesystem, or consider closing access to the source filesystem completely.  Open files may impact their ability to be migrated, and if such a failure occurs, you may not be notified that the file was not transferred.  You can use the MMC to see if there are open files prior to migration.

 

---

Here are some best practices to keep in mind during your initial configuration of IMT:

• IMT CIFS import sessions support only a single CIFS server on the source VDM.  You must re-configure your source VDM such that there is only one CIFS server on it (the source for the migration).
• If your source VDM also has NFS exports, your CIFS import session creation fails. Ensure you completely unexport any NFS exports before beginning a CIFS IMT creation.
• The interfaces on both the VNX and Unity must be up and pingable.  Additionally, all the interfaces involved in the migration must be part of the same VLAN.
• DNS must be configured, and a default gateway must be defined.
• Your source VDM must have a new migration-specific interface created, with a name that begins with "nas_migration_" and that interface must be online and "up."  The interface must be valid and have good communication to the network.
  • The "nas_migration" interface must be on a different DNS domain, or subdomain, than the production CIFS interface. You may have to create a new DNS domain zone.  If you are using dynamic DNS, creating the interface while specifying a new subdomain will automatically create the new zone.
• The source CIFS server must have local users support enabled, and local administrator credentials are required for creating an import session.  You must manually change the local administrator password (it cannot stay at the default).  Finally, the local administrator account must be added to the "Backup Operators" local group on the Data Mover (or a standard local user must be added to both the "Administrators" and "Backup Operators" local groups).
• If your target Unity system is running a code below 4.4.1, Data Reduction will not be automatically enabled when the migration is initiated unless the migration is started from UEMCLI.  This is corrected in 4.4.1 and higher.

---

Here are some best practices surrounding cutover of an IMT migration:

• Failed files can occur for several reasons.  The only way to see failed files is by using the svc_imt tool using UEMCLI.
  • Files which fail to migrate can also be categorized as "dropped/skipped" which would allow the migration to continue (as we mentioned earlier, you would not be notified that dropped or skipped files occurred).  Other file failures cause the migration to stop responding. The migration status shows "MIS_Waiting_For_Resync".
  • Some files are internal to IMT and report failing as well. See notes for more information.
• In the case of a MIS_FAILED state, a "Cancel" must be issued to roll back to VNX.  This may require Dell assistance.
• During the incremental sync portion of a cutover, it may be helpful to open two windows side by side: the C$ share on the VNX, and the Unity active production share, to ensure both are available and that new files written to Unity are immediately copied back to the same location on the VNX.

Review the following articles for more information about these conditions and other issues that you may encounter while performing an IMT migration: 

• Dell Unity: NFS VDM Import/Block Import (IMT) Issues and Resolutions (User Correctable)
• Dell Unity: CIFS VDM Import (IMT) Issues and Resolutions (User Correctable)

Please note if "oplock" is enabled on file system on the source VNX, you want to check out the following KB:

• Dell Unity: Unity Oplocks is disabled by default on a migrated file system and cannot be enabled during IMT (Dell Correctable)