• Considerations for import

    PDF

    Considerations for import

    Importing VNX file systems with File Level Retention (FLR) enabled

    Dell EMC Unity systems running OE version 4.5 or later support both FLR-E and FLR-C. When importing an FLR-enabled file system from a VNX system to a Dell EMC Unity system, ensure the Dell EMC Unity system is running operating environment (OE) version 4.5 or later.

    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 will be 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 can cause the two file systems to be in an inconsistent state.
    Limitations related to host access and NFS datastores

    After cutover, for FLR-enabled 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 Dell EMC Unity systems is permanently set to 2017.

    For example, if the source epoch year is 2003, do not set the atime to a time between 2003 and 2017. This is because any time 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.

    When performing a VDM import of FLR-enabled file systems to a Unity system, the source VNX Data Mover must be running the DHSM service for the import to succeed. Also, if the source DHSM service authentication is set to None, you do not need to configure the DHSM credentials, username and password, on the Unity system for import. However, if the source DHSM service authentication is set to either Basic or Digest, you must configure those credentials at the Unity system as part of the import configuration. If DHSM is not already configured on the source file system, refer to the VNX system's Unisphere online help or the VNX Command Line Interface Reference for File for information about setting up the DHSM configuration on the source VNX system.

    Unity systems do not support FLR on NFS datastores. Therefore, VNX FLR-enabled file systems cannot be imported to Unity as NFS datastores. They can only be imported as file system objects.

    If the source VNX file system is FLR-enabled, you cannot change the target resource from a file system to an NFS datastore. This action is not allowed.
    Port requirements for DHSM when FLR is enabled

    The default DHSM service port is 5080 on both VNX and Unity systems. However, the VNX Data Mover (the physical Data Mover that hosts the VDM that is being imported) that is configured with the DHSM service can be set to a different port than the default. This port must match on both systems in order for the import of FLR-enabled file systems to succeed. To import FLR-enabled file systems when the source VNX Data Mover is using another port instead of the default, do one of the following before creating the file import:

    • If possible, change the VNX Data Mover that is configured with the DHSM service to use the default port 5080.
    • If the DHSM service port change cannot be made on the VNX system, on the Unity system use the svc_nas service command to change the value of the remoteDhmsPort parameter for the imt facility to reflect the same DHSM service port as that set on the VNX.
      Changing the value of the remoteDhmsPort parameter requires a reboot of the storage processors on the Unity system so that the change takes effect.

    VNX port requirements for data import

    To import data from a VNX system to a Unity system, the Unity system should be able to access the following ports on the VNX system:

    • 22, 443, and 5989 to establish import connections
    • 3205 and 3260 for iSCSI-based LUN import
    • 111, 137, 138, 139, 389, 445, 464, 1020, 1021, 1234, 2049, 2400, 4647, 31491, 38914, and 49152-65535 for NFS VDM import
    • 137, 138, 139, 445, and 12345 for CIFS VDM import
    On the VNX source system, the physical Data Mover that is configured with the DHSM service can be set to a different port than the default port 5080. This port must match on both VNX and Unity systems in order for the import of FLR-enabled file systems to succeed. To import FLR-enabled file systems, if the source VNX Data Mover is not using the default port, do one of the following before creating the file import:
    • If possible, change the VNX Data Mover that is configured with the DHSM service to use the default port 5080.
    • If the DHSM service port change cannot be made on the VNX system, on the Unity system use the svc_nas service command to change the value of the remoteDhmsPort parameter for the imt facility to reflect the same DHSM service port as that set on the VNX. This action requires a reboot of the storage processors so that the change takes effect.

    For more information related to ports on the VNX system, refer to the EMC VNX Series Security Configuration Guide for VNX. For more information related to the svc_nas service command, refer to the Unity Service Commands Technical Notes.

    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 (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 dedupe 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 will be 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.
      • (Does not apply to Unity systems running OE 4.5 or later) 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 will be 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 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.
        For example, if the source epoch year is 2003, do not set the atime to a time between 2003 and 2017. This is because any time 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's 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's mobility interface unable to access the source file system.
    • Protocol restrictions:
      • Import of CIFS and multi-protocol settings and related settings is not supported. For example, 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 (Hyper Text Transfer Protocol), or CEPP (Common Event Publishing Protocol) is not supported.
    • Rollback restrictions and limitations:
      • After rollback, a host may need to remount the NFS file system if interfaces configurations are different between the source VDMs and the target NAS Servers.
      • Only rollback data changes to the source file systems. Rollback of any configuration changes to the NAS server/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 with the exception of 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. Refer to 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).
        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.

    Restrictions and limitations for CIFS-only VDM file import

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

    • Only Unified VNX (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 must be large enough to host 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 dedupe settings is not supported. During the import session, data is un-deduped and un-compressed.
      • 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 will be imported as normal target file systems (UFS64). Unity systems with OE version 4.5 or 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.)
    • 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.
      • (Does not apply to Unity systems running OE 4.5 or later) 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 will be 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 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.
        For example, if the source epoch year is 2003, do not set the atime to a time between 2003 and 2017. This is because any time 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's 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's mobility interface unable to access the source file system.
    • Protocol restrictions:
      • Import of NFS settings and related settings is not supported. For example, LDAP, NIS, local password, group and netgroup files, mount options other than synchronous write, op locks, notify on write, and notify on access.
      • Import of FTP or SFTP (File Transfer Protocol), HTTP (Hyper Text Transfer Protocol), or CEPP (Common Event Publishing Protocol) is not supported.
    • Cancel restrictions and limitations:
      • Only some configuration changes, such as the target VDM's CIFS shares, or local users along with data changes to the source file systems are rolled back to the source VDM.
    • Configuration restrictions and limitations:
      • Import of NTP configuration is not supported.
      • 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.)
      • 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).
        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 during import:
      • Shares
      • Local groups
      • Local users
      • Privileges
      • Home directory
      • Distributed File System (DFS) (only pre-existing DFS shares are synchronized during a cancel operation)
      Those are also the only configuration settings that are synchronized with the source if the migration is canceled.

    Block import restrictions and limitations

    The following restrictions and limitations relate to a block import from a VNX storage system to a Unity storage system:

    It is recommended that features like Snapview and MirrorView/A are stopped during import.
    • The source VNX1 Block OE is 5.32.x or later or the source VNX2 Block OE is 5.33.x or later.
    • You can only import from a VNX storage system to a single Unity storage system at a time. Importing from one VNX to multiple Unity storage systems at the same time is not supported.
    • Deleting a SAN Copy initiator is not supported.
    • Adding a SAN Copy initiator to a new or existing host is not supported.
    • Deleting VNXSancopyHost is not supported.
    • Adding non-import Unity LUNs to VNXSancopyHost is not supported.
    • Removing host access of import LUNs from VNXSancopyHost is not supported.
    • Snapshots are not allowed until the import is complete.
    • Snapshot schedules are not allowed until the import is complete.
    • Changes to the ReplDest property are not allowed until import is complete.
    • Access to hosts other than VNXSancopyHost (initiators) is not allowed until the import is complete.
    • For a LUN in an import session:
      • Do not add a LUN to a CG until the import is complete.
      • Do not remove a LUN from a CG until the import is complete.
      • Do not extend or shrink a LUN until the import is complete.
    • For a CG in an import session:
      • Do not add LUNs to the CG until the import is complete.
      • Do not remove LUNs from the CG until the import is complete.
    • 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.
    • SAN Copy and MirrorView features cannot be configured on the same FC port as the Import feature for block on both the VNX and Unity systems.
    • Avoid configuring MirrorView reserved iSCSI ports for block import iSCSI interfaces.
    • Although hundreds or thousands of LUNs can be created for import, the number of LUNs importing actively is limited to the concurrent SAN Copy sync limits. The concurrent executing sessions limit is based on the VNX model:
      • For VNX5700, VNX7500, VNX7600, and VNX8000 models, the limit is 32.
      • For VNX5500 and VNX5800 models, the limit is 16.
      • For VNX5100, VNX5300, VNX5400, and VNX5600 models, the limit is 8.
    The SAN Copy limits on the source system can be changed. However, it is highly recommended that you configure these limits before a Remote System connection is established between the Unity and VNX systems.