Dell Unity™ Family VNX® Series Data Import to Unity All Flash or Hybrid, or UnityVSA™ System User Guide

Restrictions and limitations for NFS-only VDM file import

The following restrictions and limitations relate to an NFS-only VDM file migration from either a VNX1 or VNX2 storage system to a Unity storage system:

• Only Unified VNX (which includes VNX1 and VNX2) storage systems are supported as the source storage system in a VDM file migration.
• The source VNX1 OE is 7.1.x or later, or the source VNX2 OE is 8.1.x or later.
• Upgrading a Unity system when an import session is in progress is not supported.
• Creating an import session when an upgrade session is in progress is not supported.
• Unity supports a VDM import session with at most 500 file systems on the source VDM. UnityVSA supports a VDM import session with at most 32 file systems on the source VDM.
• The target pool size may be larger than the pool size of the source VDM and its migrated file systems.
  • Unity storage systems use a different file system layout than Unified VNX storage systems. Unity storage systems use UFS64 file systems while VNX storage systems use UFS32 file systems.
  • Import of deduplication settings is not supported.
  • A versioning file and fast clone are imported as a normal file. Unity systems with OE versions earlier than 4.5 do not support file level retention (FLR), and the default import setting is to not import such file systems. However, you can override the default, and those file systems are imported as normal target file systems (UFS64). Unity systems with OE version 4.5 and later support both FLR-E and FLR-C.
• Only uxfs-type file systems are imported from the VNX1 or VNX2 source VDM. Import of non-uxfs-type file systems or file systems that are mounted on a Nested Mount File System (NMFS) file system are not supported.
• A file system whose mount path contains more than two slashes is not supported. The target system does not allow file systems with a name containing multiple slashes, for example, /root_vdm_1/a/c.
• Import of a file system that is a replication destination is not supported.
• Import of a checkpoint or checkpoint schedule is not supported.
• If the source replication file system is also the target file system of a VDM import session, failing over the replication session (synchronous or asynchronous) is not allowed until the import is complete.
• Restrictions that are related to Quota migration:
  • Import of group quota or inode quota settings is not supported. (The target system does not support either.)
  • Import of a tree quota whose path contains single quotation marks is not supported. (A VNX1 or VNX2 system can create it but it cannot be queried or modified.)
• A VAAI operation is not allowed on either the source or target systems during and after cutover.
  • A VAAI operation is not allowed on the target system before cutover.
  • A VAAI operation on the source system must finish before cutover.
• Limitations that are related to Host access:
  • After cutover, read access performance degrades until the related file is migrated.
  • After cutover, write access performance degrades until the VDM file migration is completed.
  • After cutover, a host cannot write data when the source file system is in the read-only mounted state.
  • Dell EMC Unity systems running OE 4.4 or earlier do not support FLR, and the default import setting is to not import such file systems. However, you can override the default, and those file systems are imported as normal target file systems (UFS64) without FLR protection. This means that after cutover, locked files can be modified, moved, or deleted on the target Dell EMC Unity system, but not on the source VNX system. This discrepancy can cause the two file systems to be in an inconsistent state.
  • After cutover, for FLR file systems that are being imported from a VNX system, the host cannot set the Retention Period to a time between the source epoch year and 2017 that translates to a future time. The epoch year on Unity systems is permanently set to 2017.
    NOTE: For example, if the source epoch year is 2003, do not set the atime to a time between 2003 and 2017. This is because anytime between 2003 and 2017 translates to a future time that cannot be represented by the source epoch year 2003. The host can do that after the import session commits.
  • After cutover, a host cannot access data when the target system mobility interface cannot access the source file system, which includes the following cases:
    • The network between the source VDM file migration interface and the target mobility interface is disconnected.
    • The source VDM is not in either the loaded or mounted state.
    • The user modifies the source export, which makes the target system mobility interface unable to access the source file system.
• Protocol restrictions:
  • Import of CIFS, multiprotocol settings, and related settings is not supported when performing an NFS-only import. These settings include settings for CIFS server, CIFS share path and options, Kerberos key, CAVA (Common AntiVirus Agent), usermapper, and ntxmap.
  • Import of a VDM using Secure NFS, NFSv4, or pNFS is not supported.
  • Import of FTP or SFTP (File Transfer Protocol), HTTP, or CEPP (Common Event Publishing Protocol) is not supported.
  • The NFS protocol is transparent, but sometimes client access behaviors can be impacted. Client access issues can arise from policy differences between the source VNX system and the target Unity system.
    NOTE: NFSv3 I/O is transparent for SP failover and failback during the incremental copy stage. However, if failover or failback begins as the node is migrated, an error might occur, disrupting client access and resulting in an I/O error. This error is resolved when the node is resynced.

    NFSv3 operations such as CREATE, MKDIR, SYMLINK, MKNOD, REMOVE, RMDIR, RENAME, and LINK might fail with error during migration cutover. For example, before cutover, an operation finishes successfully on the source VNX side. However, the client does not receive the response; after cutover, the client retries the same operation silently after cutover in an under layer.

    For example, if a file has already been removed on the source VNX side before cutover, the silent retry of the REMOVE operation fails with a NFS3ERR_NOENT message. You might see the remove failure even though the file has been removed on the file system. This failure notification occurs because after cutover, the XID cache that is used to detect duplicated requests does not exist on the destination Unity side. The duplicated request cannot be detected during cutover.

• Rollback restrictions and limitations:
  • After rollback, a host might need to remount the NFS file system if the interface configurations are different between the source VDMs and the target NAS Servers.
  • Only rollback data changes to the source file systems are supported. Rollback of any configuration changes to the NAS server and file systems on the target storage system is not supported. For example, if you add an NFS export to a file system, a rollback does not add the new NFS export to the source VNX1 or VNX2 storage system.
• Configuration restrictions and limitations:
  • Import of NTP configuration is not supported.
  • Import of server parameter settings (VNX1 or VNX2 server_param settings except for the IP reflect parameter) is not supported.
  • Import of LDAP configuration with Kerberos authentication (CIFS server is not migrated) is not supported.
  • Import of client certificates, which the LDAP server requires (persona is not supported on the Unity system), is not supported.
  • Import of customized cipher list for LDAP connection (customized cipher list is not supported on the Unity system) is not supported.
  • If multiple LDAP servers are configured with different port numbers that are used by the source VDM, only the server with the port number equal to the first server is migrated.
  • If both NIS and LDAP are configured and taken into effect for the naming service on the source VDM, you must select one of them to take effect on the target NAS server.
  • If local files are configured and taken into effect for the naming service on the source VDM, you can select whether the local files take effect on the target NAS server. The search order of the local files is always higher than NIS or LDAP on the target NAS server.
  • Only enabled network interfaces on the source VDM are imported. Disabled network interfaces on the source VDM are not imported. (The target system does not allow you to enable or disable network interfaces.)
  • Many of the mount options for VNX storage systems are not supported on Unity storage systems. See File system mount options mapping for information about the options that Unity supports.
  • Some of the NFS export options for VNX storage systems are not supported on Unity storage systems. See NFS export options mapping for information about the options that Unity supports.
  • File Level Retention (FLR) file systems can be imported on Unity systems running OE version 4.5 or later. However, Unity systems with OE versions earlier than 4.5 do not support FLR so those file systems are imported as normal file systems (UFS64).
    NOTE: Files can no longer be protected when they are migrated to a non-FLR file system.
  • Distributed Hierarchical Storage Management (DHSM)/(Cloud Tiering Appliance (CTA) may be configured on the source VNX for archiving inactive files to secondary storage. If DHSM/CTA is configured on the source VNX system and a VDM import to Unity is run, all the files on the associated file system are recalled from the secondary storage to the source VNX. Those files are then imported to Unity as normal files (that is, no stub files are imported).
• Only limited configuration changes to the source VDM and the target NAS server are supported. Refer to Change settings of an NFS-only VDM import for information about what changes can be made and when.
• Restoring NDMP backups:
  • The NDMP backup path on VNX is /root_vdm_xx/FSNAME while the same path on Unity is /FSNAME. If any file system of the source VNX VDM is protected by NDMP and already backed up, then after VDM file import, those file systems cannot be restored to Unity using the original path option. A restore using the original path option fails due to an unavailable destination path. Instead, use the alternative path option.