Dell Unity™ Family VNX® Series Data Import

to Unity All Flash or Hybrid, or UnityVSA™

System User Guide
Version 5.x

Part Number: 302-003-062

May 2023
Rev. 08
Notes, cautions, and warnings

NOTE: A NOTE indicates important information that helps you make better use of your product.

CAUTION: A CAUTION indicates either potential damage to hardware or loss of data and tells you how to avoid
the problem.

WARNING: A WARNING indicates a potential for property damage, personal injury, or death.

© 2016 - 2023 Dell Inc. or its subsidiaries. All rights reserved. Dell Technologies, Dell, and other trademarks are trademarks of Dell Inc. or its
subsidiaries. Other trademarks may be trademarks of their respective owners.
 1
Introduction
Topics:
• About this document
• Additional resources
• About import

About this document

This document provides information that you can use to configure and manage VNX imports (migrations) on the Unity system.
Along with relevant concepts and instructions to configure VNX imports using the Unisphere GUI, this document also includes
information about the CLI commands that are associated with configuring VNX imports.
NOTE: For more information about other Unisphere features or CLI commands, refer to the Unisphere online help and
Unisphere Command Line Interface User Guide.

Additional resources
As part of an improvement effort, revisions of the software and hardware are periodically released. Therefore, some functions
described in this document might not be supported by all versions of the software or hardware currently in use. The product
release notes provide the most up-to-date information on product features. Contact your technical support professional if a
product does not function properly or does not function as described in this document.

Where to get help

Support, product, and licensing information can be obtained as described below.

Product information
For product and feature documentation or release notes, go to Unity Technical Documentation at: https://www.dell.com/
unitydocs.

Troubleshooting
For information about products, software updates, licensing, and service, go to Support (registration required) at: https://
www.dell.com/support. After logging in, locate the appropriate product page.

About import
The Import feature allows you to migrate a VDM, or a LUN or a consistency group (CG) of LUNs, with its configuration and
data from an existing source VNX storage system to a target Unity storage system. This feature provides a built-in capability
for NFS-only VDM imports with minimal or no disruption to clients. It also provides a built-in capability for CIFS-only VDM and
block-based imports. However, cutting over of a CIFS-only VDM or a block import session can be a disruptive process. Finally,
this feature enables you to perform multiprotocol migrations from VNX source storage to destination Unity systems.
For a block-based import, after the cutover completes, host I/O operations are switched to the target system and the import
process completes automatically. For a file-based virtual data mover (VDM) import, after cutover completes, the import process
does an incremental copy automatically but you must complete the import manually.

Introduction 3
An import is always conducted from the Unity storage system. The target system makes a remote call to the VNX storage
system and instigates a pull (for file-based import) or push (for block-based import) of the source storage resources to the
target system.

4 Introduction
 2
Import workflow
Topics:
• Configure import

Configure import
You can manually import a VDM from a VNX storage system to a Unity storage system.
When you import a VDM, all its associated file-based storage, network, and file systems are migrated.
You can also import multiple concurrent block import sessions for LUNs, or Consistency Group (CG) of LUNs, from the VNX
system to the Unity system.
VDM import operations support only:
● Import of VDM with only NFSV3 protocol enabled (VDMs with NFSV4 protocol enabled not supported)
● Import of VDM with only CIFS protocol enabled
Using the Unisphere CLI, you can also preserve stub files as stub files when you import from the source VNX with CIFS
enabled. Preserving stub files in this state reduces the migration workload. For more information, see Preserving stub files.
● Import of a VDM with multiprotocol file systems, or with both NFS and CIFS file systems exported and shared
The following limitations apply to multiprotocol migration:
● The migration of VDMs that use Secure NFS, NFSv4, or pNFS is not supported.
● The import of CIFS and multiprotocol settings and related settings is not supported as shown in the following list:
○ Common AntiVirus Agent (CAVA)
○ Common Event Publishing Agent (CEPA)
○ Continuous availability states
○ SMB registry
○ File filtering
○ Kerberos keys
○ Usermapper
NOTE: Unlike CIFS migration, multiprotocol migration supports ntxmap imports.

NFS-only VDM import

The configuration and identity information that can be imported along with the data as part of an NFS-only VDM import include:
● Networking:
○ IP address configuration
○ Routing configuration
○ VLAN configuration
● Name Services:
○ DNS
○ LDAP
○ Local files
○ NIS
● NFS server identity:
○ NFS exports
● Data:
○ File systems (including quota configuration)

Import workflow 5
 ○ Security or permissions for NFSv3
NOTE: When the domain configuration is disabled for the source VDM, only the first DNS domain that is configured on
the physical Data Mover which is hosting the VDM is imported. If the intended DNS domain for the source VDM is not the
first DNS domain on the physical Data Mover, the wrong DNS configuration is imported. To avoid importing the wrong DNS
domain, enable the Name Service configuration on the source VDM by using the server_nsdomains CLI command on
the source VNX. Use this command to enable and set the DNS, LDAP, or NIS configuration on the source VDM to ensure
proper import to the Unity system.
Source VNX VDM Servers, and their respective file systems (UFS32-based file systems), are migrated to the new UFS64-based
file systems format on the target Unity system. In addition, all file systems are migrated as Thin. File systems cannot be
migrated individually, only as part of the VDM server migration.
For a file system that VMware uses as an NFS datastore, you must specify the file systems to be imported as a VMware NFS
datastore. Only one NFS export at file system root directory should exist on the VNX for those source file systems. Otherwise,
both create session and resume session operations fail because VMware NFS datastore in Unity only supports this export
configuration.
The target file system is a normal file system by default. If you specify one file system to be imported as a VMware NFS
datastore, the target file system is a VMware NFS datastore, which enables virtualization-specific optimization such as
asyncmtime. A source file system that is specified as file level retention (FLR) enabled cannot be imported as a VMware
datastore file system.
All VNX systems are configured by default with the code page 8859-1 for the NFSv3 clients. This code page is used to translate
the file name from 8859-1 (network format) to UTF-8 (disk format). This code page can be changed to UTF-8 or 8859-15.
Code page 8859-15, which includes the most used western European characters, is an extension of the 8859-1 code page.
When a VDM from a VNX system is imported to a Unity system through NFS, the Unity system browses the VNX files using a
UTF-8 NFS client. This process can cause some problems with the file name when it includes non-ASCII characters. The NFS
import has to browse the VNX files through an 8859-1 NFS client, to preserve the extended characters of filenames of the
source VNX. All Unity systems (OE 4.2 and earlier) are configured to support only NFSv3 clients configured for UTF-8. The
code page on these Unity systems cannot be changed. With Unity OE 4.3 and later, the code page of the Unity system can
be changed through the svc_nas {<NAS_server_name> | all} -param -facility vdm -modify codepage
-value <value> service command to match it with the code page used on the VNX system. Matching the code pages allows
a code page translation for the file names that are seen from NFSv3 clients, and to reproduce the behavior of the VNX system
on the Unity system.
NOTE: Do not change the default code page in Unity systems for either NFSv4 or SMB clients. NFSv4 clients support only
UTF-8. SMB clients support only Unicode.

Prerequisites for NFS-only VDM import

Import of a VDM and its related file systems from a VNX storage system to a Unity storage system requires the following
prerequisites:
● Time is synchronized between the VNX and Unity storage systems. The time difference must be within five seconds. Use
the same NTP server on the VNX Data Mover that hosts the source VDM, and the target Unity SPs. See Configuring Time
Services on VNX for information about NTP.
NOTE: The NTP server used must have a stratum number of 5 or less.
● One or more pools must be created and available on the target Unity system to perform a VDM import operation. The pools
that are selected should be large enough to hold the source VDM and all its file systems that are migrated.
NOTE: Compressed data is uncompressed, and deduplicated data is undeduplicated, for migration. Ensure that the
target pool has enough capacity to handle these changes in data size. Check on the source VNX for the amount of
space savings that compression and deduplication provide for the data. Then determine the amount of space that is
required for the uncompressed and undeduplicated data.
● Before creating an import connection, you must configure mobility interface IP address for each SP (A and B) of the target
system. (When creating an import session, you select the mobility interface IP address of either SPA or SPB to use as the
target import interface. This interface is used to migrate the VNX CIFS server and file systems.)
● Before creating the VDM import session, you must do the following:
○ Create a migration interface on the source Data Mover (for IPv4, use server_ifconfig <server_name>
-create -Device <device> -name <nas_migration_interface_name> -protocol IP <ipv4>
<ipnetmask> <ip–broadcast> ; for IPv6, use server_ifconfig <server_name> -create -Device
<device> -name <nas_migration_interface_name> -protocol IP6 <ipv6/PrefixLength>) and
attach the interface to the source VDM to be migrated (using nas_server -vdm <vdm_name> -attach

6 Import workflow
 <nas_migration_interface_name>). The interface added on the source VDM to perform migration must be
named with the prefix "nas_migraiton_" so that the interface can be clearly identified by the migration process. This
interface is used only for the VDM import operation and must not be used as a production interface. After each VDM
import session is committed, this interface can be reused by attaching it to the next VDM, and so on.
○ Verify that the physical Data Mover on which the source VDM is located has at least one IP interface configured
that is not attached to the VDM being migrated. This IP interface ensures that the source Data Mover can provide
uninterrupted Name Services for the remaining file servers. If this additional interface is not present, the VDM import
session fails.
○ Ensure the code page that is used on the target Unity system matches the code page that is used on the source VNX
system.
● For a source VNX system with two Control Stations, the home directory of a user with the Administrator role, which is used
in configuring the import connection, must exist on the primary Control Station of the VNX. For more information, see VNX
system with two Control Stations.
● Before starting a VDM import, create an import connection between the source VNX system and the target Unity system.
NOTE: If the naming services server (DNS, NIS, or LDAP) configured on the Data Mover of the source VNX cannot be
connected using the network interface that is attached to the VDM to be migrated, attach another interface to the VDM.
This additional interface ensures that the VDM can connect to the naming services server. Otherwise, the target NAS
server cannot connect to the naming services server. If the naming services server configured on the Data Mover of the
source VNX can only be connected using the network interface that is attached to the VDM to be migrated, create another
network interface on the Data Mover. This additional network interface ensures that the Data Mover can connect to the
naming services server. Otherwise, other clients of the Data Mover cannot connect to the naming services server.

CIFS-only VDM import

You must include the configuration and identity information that can be imported along with the data as part of a CIFS-only
VDM.
NOTE: For SMB operations, SMB1 must be enabled for the initial copy to start. SMB1 is a requirement for all CIFS-based
migrations. You can disable SMB1 after the migration is finished.
The required configuration and identity information includes the following:
● Networking:
○ IP address configuration
○ Routing configuration
○ VLAN configuration
● Name Services:
○ DNS
● CIFS server identity:
○ Name
○ Active Directory (AD) account
○ CIFS shares
○ Local group
○ Local users
● VDM settings:
○ Parameters
○ Quota
● Data:
○ File systems
○ File security (Access Control List (ACL) preservation)
○ Timestamps (create date and last modification date are not modified during import)
NOTE: When the domain configuration is disabled for the source VDM, the domain name of the SMB server is used to
search the corresponding DNS configuration. If the configuration cannot be found, the migration cannot start. Enable the
domain configuration for the VDM by using the server_nsdomains CLI command. Use this command to enable and set
the DNS, LDAP, or NIS configuration on the source VDM to ensure proper import to the Unity system.
Source VNX VDM Servers, along with their respective file systems (UFS32-based file systems), are migrated to the new
UFS64-based file systems format on the target Unity system. In addition, all file systems are migrated as Thin and maintained as
Thin on the target Unity system. File systems cannot be migrated individually, only as part of the VDM server migration.

Import workflow 7
Prerequisites for CIFS-only VDM import
Import of a CIFS-only VDM and its related file systems from a VNX storage system to a Unity storage system requires the
following prerequisites:
● Time is synchronized between the VNX and Unity storage systems. The time difference must be within five seconds. Use
the same NTP server on the VNX Data Mover that hosts the source VDM, and the target Unity SPs. See Configuring Time
Services on VNX for information about NTP.
NOTE: The NTP server used must have a stratum number of 5 or less.
● One or more pools must be created and available on the target Unity system to perform a VDM import operation. The pools
that are selected should be large enough to hold the source VDM and all its file systems that are migrated.
NOTE: Compressed data is uncompressed, and deduplicated data is undeduplicated, for migration. Ensure that the
target pool has enough capacity to handle these changes in data size. Check on the source VNX for the amount of
space savings compression and deduplication provide for the data, and then determine how much space would be
required for the uncompressed and undeduplicated data.
● Before creating the VDM import session, you must do the following:
○ Create a migration interface on the source Data Mover (for IPv4, use server_ifconfig <server_name>
-create -Device <device> -name <nas_migration_interface_name> -protocol IP <ipv4>
<ipnetmask> <ip–broadcast> ; for IPv6, use server_ifconfig <server_name> -create -Device
<device> -name <nas_migration_interface_name> -protocol IP6 <ipv6/PrefixLength>) and
attach the interface to the source VDM to be migrated (using nas_server -vdm <vdm_name> -attach
<nas_migration_interface_name>). The interface added on the source VDM to perform migration must be
named with the prefix "nas_migraiton_" so that the interface can be clearly identified by the migration process. This
interface is used only for the VDM import operation and must not be used as a production interface. After each VDM
import session is committed, this interface can be reused by attaching it to the next VDM, and so on.
○ Verify the following:
￭ The physical Data Mover on which the source VDM is located has at least one IP interface configured that is not
attached to the VDM being migrated. This IP interface ensures that the source Data Mover can provide uninterrupted
Name Services for the remaining file servers. If this additional interface is not present, the VDM import session fails.
￭ (For a source VDM with an AD joined CIFS server only) The migration interface has been added to the source CIFS
server and has a prefix for a DNS domain that is different from the production interface. To add this interface when
in a DNS zone, use the following command format: server_cifs <vdm_name> -add
compname=<compname>,domain=<domainname>,interface=<nas_migration_interface>,dns=<spe
cific_prefix.domainname>. This command creates an additional zone in the DNS server for hosting the
migration IP address. This action ensures that the migration interface will not be used for production. For more
information about CLI commands that are related to the source system, see the VNX Command Line Interface
Reference for File.
￭ A single CIFS server is configured on the source VDM.
￭ C$ share is available on the source Data Mover that hosts the VDM and is not disabled or set to Read-only. The C$
share must be available, otherwise the import cannot start. If it was disabled or Read-only on the source, change the
corresponding parameters to enable it:

server_param <source_server> -facility cifs -modify admin.shareC_NotCreated

-value 0

server_param <source_server> -facility cifs -modify admin.shareC_RO -value 0

NOTE: You must stop and start the service that is associated with the CIFS facility for changes to
admin.shareC_NotCreated to take effect.
￭ No NFS exports are configured on the source VDM file systems.
￭ Local CIFS users are enabled on the source CIFS server. (For AD joined CIFS servers only) If local users are not
enabled, you can enable local users on the source CIFS server by entering server_cifs <vdmname> -add
compname=<computername>,domain=<domainname>,local_users. See Configuring and Managing CIFS on
VNX for more information about enabling local user support on VNX.
￭ A local user that is a member to the local administrator group of the source CIFS server must exist on the source
CIFS server. This user must have backup and restore privileges (by default, being a member of the administrators
local group would be enough). See Configuring and Managing CIFS on VNX for information about local user and group
accounts.
￭ Credentials, username, and password, of the remote local CIFS user to use for the import.

8 Import workflow
 ￭ The extended acl feature is enabled on the source Data Mover that hosts the VDM (parameter cifs.acl.extacl should
have bits 2, 3, and 4 set, decimal value 28). Use the following command to view the settings:

server_param <source_datamover> -facility cifs -info acl.extacl

If necessary, use the following command to change the setting:

server_param <source_datamover> -facility cifs -modify acl.extacl -value 28

￭ Unknown SID feature has been enabled on the source Data Mover that hosts the VDM (parameter
cifs.acl.mappingErrorAction must be set to 0x0b, decimal value 11). Use the following command to view the settings:

server_param <source_datamover> -facility cifs -info acl.mappingErrorAction

If necessary, use the following command to change the setting:

server_param <source_datamover> -facility cifs -modify acl.mappingErrorAction

-value 11

￭ NT security is enabled on the source. Share and UNIX security level is not supported. This option is in the mount
options of the file systems. If necessary, change the mount option of the file systems.
￭ The source VDM is not utf8-based.
￭ The source CIFS server is not a Windows NT 4.0 like CIFS server.
￭ DNS is configured for the windows domain in the case of a domain joined CIFS server.
￭ Other VDMs from the source can reach DNS and domain controller (DC) after cutover.
￭ DNS and DCs are reachable on the destination after cutover.
● For a source VNX system with two Control Stations, the home directory of a user with the Administrator role, which is used
in configuring the import connection, must exist on the primary Control Station of the VNX. For more information, see VNX
system with two Control Stations.
● Before creating an import connection, you must configure a mobility interface IP address for each SP (A and B) of the target
system. (When creating an import session, you select the mobility interface IP address of either SPA or SPB to use as the
target import interface. This interface is used to migrate the VNX CIFS server and file systems.)
● Before you conduct a VDM import, an import connection must be created between the source VNX system and the target
Unity system.
○ If the naming services server (DNS) configured on the Data Mover of the source VNX cannot be connected using the
network interface that is attached to the source VDM, attach another interface to the VDM. This additional interface
ensures that the source VDM can connect to the naming services server.
○ If the naming services server can only be connected using the network interface that is attached to the source VDM,
create another network interface on the Data Mover. This additional network interface ensures that the Data Mover can
connect to the naming services server and other clients of the Data Mover.

Multiprotocol VDM import

Beginning with Unity OE 5.1, you can perform a multiprotocol migration session only if the source VNX VDM and the Unity VDM
support multiprotocol access.
When configuring a multiprotocol import session, you must specify qualifiers for both the CIFS and NFS parts of the migration.

NOTE: Access policies might affect client access after the migration is complete.

For CIFS/SMB, you must create a network interface and add it to the source VDM to migrate.
NOTE: For SMB operations, SMB1 must be enabled for the initial copy to start. SMB1 is a requirement for all CIFS-based
migrations. You can disable SMB1 after the migration is finished.
All file systems are migrated as Thin and maintained as Thin on the target Unity system. File systems cannot be migrated
individually, only as part of the VDM server migration.
The following conditions apply to VNX to Unity migration:
● If the source VDM has an NFS export and an enabled CIFS server, you can use multiprotocol migration to migrate the VDM
to Unity.
You can migrate that VDM even if it does not have a CIFS share.

Import workflow 9
● If the source VDM only has an NFS export and the CIFS server is disabled, you can use NFS migration to migrate this VDM
to Unity.
● If the source VDM has a CIFS share and the CIFS server that is enabled, you can use CIFS migration to migrate this VDM to
Unity.

Prerequisites for multiprotocol VDM imports

Importing both NFS and CIFS VDMs and their related file systems from a VNX storage system to a Unity storage system
requires the following prerequisites:
● Time is synchronized between the VNX and Unity storage systems. The time difference must be within five seconds. Use
the same NTP server on the VNX Data Mover that hosts the source VDM, and the target Unity SPs. See Configuring Time
Services on VNX for information about NTP.
NOTE: The NTP server used must have a stratum number of 5 or less.
● One or more pools must be created and available on the target Unity system to perform a VDM import operation. The pools
that are selected should be large enough to hold the source VDM and all its file systems that are migrated.
NOTE: Compressed data is uncompressed, and deduplicated data is undeduplicated for migration. Ensure that the
target pool has enough capacity to handle these changes in data size. Check on the source VNX for the amount of
space savings that compression and deduplication provide for the data. Then determine the amount of space that is
required for the uncompressed and undeduplicated data.
● Before creating the VDM import session, you must do the following:
○ Create a migration interface on the source Data Mover (for IPv4, use server_ifconfig <server_name>
-create -Device <device> -name <nas_migration_interface_name> -protocol IP <ipv4>
<ipnetmask> <ip-broadcast>; for IPv6, use server_ifconfig <server_name> -create -Device
<device> -name <nas_migration_interface_name> -protocol IP6 <ipv6/PrefixLength>) and
attach the interface to the source VDM to be migrated (using nas_server -vdm <vdm_name> -attach
<nas_migration_interface_name>). The interface added on the source VDM to perform migration must be
named with the prefix nas_migration_ so that the interface can be clearly identified by the migration process. This
interface is used only for the VDM import operation and must not be used as a production interface. After each VDM
import session is committed, this interface can be reused by attaching it to the next VDM, and so on.
● Verify that the physical Data Mover on which the source VDM is located has at least one IP interface configured that is not
attached to the VDM being migrated. This IP interface ensures that the source Data Mover can provide uninterrupted Name
Services for the remaining file servers. If this additional interface is not present, the VDM import session fails.
● For NFS, verify the code page that is used on the target Unity system matches the code page that is used on the source
VNX system.
● Verify the following:
○ If the source VDM has an AD, verify that the migration interface has been added to the source CIFS server. The
migration interface must also have a prefix for a DNS domain that is different from the production interface. Ensure that
the nas_migration_ interface is assigned to a subdomain under the DNS zone.
To add this interface in a DNS zone, use the following command format: server_cifs <vdm_name> -add
compname=<compname>,domain=<domainname>,interface=<nas_migration_interface>,dns=<speci
fic_prefix.domainname>. This command creates an additional zone in the DNS server for hosting the migration IP
address. This action ensures that the migration interface is not used for production. For more information about CLI
commands that are related to the source system, see the VNX Command Line Interface Reference for File.
○ A single CIFS server is configured on the source VDM.
○ C$ share is available on the source Data Mover that hosts the VDM and is not disabled or set to Read-only.
The C$ share must be available, otherwise the import cannot start. If it was disabled or Read-only on the source, change
the corresponding parameters to enable it:

server_param <source_server> -facility cifs -modify admin.shareC_NotCreated -value 0

server_param <source_server> -facility cifs -modify admin.shareC_RO -value 0

NOTE: Stop and start the service that is associated with the CIFS facility for changes to
admin.shareC_NotCreated to take effect.
○ Local CIFS users are enabled on the source CIFS server. (For AD joined CIFS servers only) When
not enabled, to enable local users on the source CIFS server, enter server_cifs <vdmname> -add

10 Import workflow
 compname=<computername>,domain=<domainname>,local_users. See Configuring and Managing CIFS on
VNX for more information about enabling local user support on VNX.
○ A local user that is a member to the local administrator group of the source CIFS server must exist on the source CIFS
server. This user must have backup and restore privileges (by default, being a member of the administrators local group
would be enough). See Configuring and Managing CIFS on VNX for information about local user and group accounts.
○ Credentials, username, and password, of the remote local CIFS user to use for the import.
○ The extended ACL feature is enabled on the source Data Mover that hosts the VDM (parameter cifs.acl.extacl should
have bits 2, 3, and 4 set, decimal value 28). Use the following command to view the settings:

server_param <source_datamover> -facility cifs -info acl.extacl

If necessary, use the following command to change the setting:

server_param <source_datamover> -facility cifs -modify acl.extacl -value 28

○ Unknown SID feature has been enabled on the source Data Mover that hosts the VDM (parameter
cifs.acl.mappingErrorAction must be set to 0x0b, decimal value 11). Use the following command to view the settings:

server_param <source_datamover> -facility cifs -info acl.mappingErrorAction

If necessary, use the following command to change the setting:

server_param <source_datamover> -facility cifs -modify acl.mappingErrorAction

-value 11

○ NT security is enabled on the source. Share and UNIX security level is not supported. This option is in mount options of
the file systems. If necessary, change the mount option of the file systems.
○ The source VDM is utf8-based. ASCII file systems are not supported.
○ Verify that the SMB server is not a Windows NT 4.0-like CIFS server.
NOTE: For SMB operations, ensure SMB1 is enabled. SMB1 is necessary for the initial copy to start and is a
requirement for all CIFS-based migrations. You can disable SMB1 after the migration is finished.
○ DNS is configured for the Windows domain when there is a domain-joined CIFS server.
○ Other VDMs from the source can reach DNS and domain controller (DC) after cutover.
○ DNS and DCs are reachable on the destination after cutover.
● For a source VNX system with two Control Stations, the home directory of a user with the Administrator role, which is used
in configuring the import connection, must exist on the primary Control Station of the VNX. For more information, see VNX
system with two Control Stations.
● Before you perform a VDM import, an import connection must be created between the source VNX system and the target
Unity system.

Block import
Unisphere allows you to import multiple concurrent block import sessions for either LUNs or Consistency Group (CG) of LUNs,
from the VNX system to the Unity system. This limit is based on the SAN Copy limits of the source VNX system and is also
based on the number of members in each CG. Block import uses the SAN Copy feature on the VNX storage system to push data
to the Unity storage system. Use the VNX management IP address and VNX Admin credentials to configure a remote system
connection from the target Unity system to the source VNX system. The VNX SAN Copy FC or iSCSI initiators are discovered
through this connection and the Unity system is registered as a SANCopy host. Also, all block resources that are eligible for
import are discovered, which includes:
● Pool LUNs, Thin LUNs, and Meta LUNs that are:
○ Not reserved LUN pool LUNs
○ Not LUNs exposed to VNX file
○ Not System LUNs
● CGs of LUNs
Before you perform an import of a LUN or CG of LUNs, the reserved LUN pool (RLP) on the source VNX system should contain
at least one free LUN for each LUN planned for import. Each reserved LUN can vary in size. However, using the same size
for each LUN in the pool is easier to manage because the LUNs are assigned without regard to size. That is, the first available
free LUN in the global reserved LUN pool is assigned. Since you cannot control which reserved LUNs are being used for a
particular import session or a VNX process such as SnapView™, incremental SAN Copy, or MirrorView/A, use a standard size for
all reserved LUNs. To assist in estimating a suitable reserved LUN pool size for the storage system, consider the following:

Import workflow 11
● If you want to optimize space utilization, use the size of the smallest source LUN as the basis of the calculations. If you want
to optimize the total number of source LUNs, use the size of the largest source LUN as the basis of the calculations.
● If you have a standard online transaction processing configuration (OLTP), use reserved LUNs sized at 10-20%. This size
tends to be appropriate to accommodate the copy-on-first-write activity.
● If you are also using SnapView or MirrorView/A on the VNX LUN, then you may need additional RLP LUNs.
NOTE: If free reserved LUNs are not available in the RLP, the import session enters an error state. Add space to the RLP,
after which the session can resume. The additional space does not have to be as high as the number of source LUNs. The
RLP LUNs get re-used once an import session completes.
For more information about the RLP and reserved LUNs, refer to the Unisphere online help on the source VNX.

Block import prerequisites

The preparation for block import (either LUN or CG of LUNs) is different than the preparation for file-based (VDM) import.
Import of one or more LUNs or a CG of LUNs from a VNX storage system to a Unity storage system requires the following
prerequisites:
● SAN Copy is enabled on the VNX storage system
● For FC-based import:
○ Ports zoning is configured between the VNX and Unity storage systems.
● For iSCSI-based import:
○ iSCSI interfaces are configured on both the VNX and Unity storage processors.
○ From the VNX storage system - iSCSI IP connections are configured between the source VNX SPs and target Unity SPs
as pairs. For example, VNX SPA is paired to Unity SPA and VNX SPB is paired to Unity SPB. Also, verify the connection
configuration.
● A reserved LUN pool (RLP) is configured with LUNs based on LUNs planned for the import. Refer to the existing VNX
Unisphere online help for detailed information concerning RLP.
● Hosts are configured on the Unity storage system the same as block hosts or storage groups on the source VNX storage
system from which resources are imported. If needed, you can reconfigure host access on the Unity system.
NOTE: Do not use ports that are used by MirrorView for either FC-based or iSCSI-based import.

Configure a VDM or block import

To configure import for block or file storage resources, use the native Import feature in Unisphere. Complete the following
steps:
1. Configure the mobility (import) interfaces on each SP of the target systems.
NOTE: Although these interfaces are needed only for importing a VDM and its related file systems, if you use the same
import connection for both file and block import sessions, the interfaces must be configured.
2. Configure an import connection.
3. Create an import session for the storage resource.
NOTE: The interfaces are only required for file import operations, and not for block imports.

Related concepts

About protection and mobility interfaces

Protection and mobility interfaces may be shared network interfaces for replication-related and import data or management
traffic using the virtual management port. Each storage processor (SP) must have one or more interfaces. Although import only
requires one interface, the creation of an interface on both SPA and SPB is enforced.
When you create a VDM import session, the VDM-to-Unity SP interfaces are paired up. Configure these interfaces before you
create an associated connection. Interfaces are needed only for the import of a VDM and its file systems.

NOTE: The import connection cannot use the replication (MirrorView) interfaces on the VNX.

12 Import workflow
From a replication perspective, if an interface is shared between replication and import, you must remove all import sessions to
change the interface and remove both replication and import sessions before deleting the interface.

About import connections

Import requires a configured connection between the source system and target system. This connection is called an import
connection. An import connection handles either a block import or a VDM and its file systems import.
On the target Unity system, connections must be defined separately for replication and import but Interfaces can be shared
between replication and import. Import connections are not verified until the session is created
For block, the initiators must be pushed from the VNX (VNX1 or VNX2) source system to the Unity target system.
NOTE: Before creating a mobility interface or import connection for a VNX import, configure the FC zoning when an FC
connection is used for block import. If the connection uses iSCSI, an iSCSI connection is required between the source VNX
system to the target Unity system.
Once an import connection is created, the Unity target system automatically discovers both file and block resources on the
source system.
NOTE: The SAN Copy Enabler must be installed on the VNX1 storage system so that block resources on the system can
be discovered automatically. Otherwise, only the file resources are discovered when the import connection is created. VNX2
storage systems include the SAN Copy Enabler already installed.

About import sessions

An import session uses a configured import connection and associated interfaces to establish an end-to-end path for importing
data between the source and target storage resources. The basic operations for an import session are:
1. Create
2. Resume or Pause
3. Cutover
4. Commit
5. Cancel
NOTE: For a block import session, the commit operation is performed automatically at the end of cutover.

You can cancel an import session that is in any state (with the exceptions of Canceling, Canceled, or Cutting Over) before the
commit state. For a VDM (NFS, CIFS, or multiprotocol) import session, the cancel operation rolls back the VDM and related file
systems to the source VNX. The cancel operation also deletes the target file systems. If no file systems exist on the NAS server,
the cancel operation deletes the NAS server. For a LUN or consistency group (CG) import session, the cancel operation deletes
the SAN Copy session for each set of LUN pairs in the import session. It also disables SAN Copy access to the target LUNs and
deletes the target LUNs or CG associated with the import session.
NOTE: You cannot upgrade a Unity system when an import session is in progress or create an import session when an
upgrade session is in progress.

Import workflow 13
 3
Considerations for import
Topics:
• Importing VNX file systems with File Level Retention (FLR) enabled
• VNX port requirements for data import
• Restrictions and limitations for NFS-only VDM file import
• Restrictions and limitations for CIFS-only VDM file import
• Restrictions for multiprotocol VDM file import
• Block import restrictions and limitations

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.
NOTE: 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.
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 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.
NOTE: 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

14 Considerations for import

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.
NOTE: 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
NOTE: 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 (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.

Considerations for import 15

● 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.

16 Considerations for import

 ○ 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.

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.
● For SMB operations, SMB1 must be enabled for the initial copy to start. SMB1 is a requirement for all CIFS-based migrations.
You can disable SMB1 after the migration is finished.
● 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.

Considerations for import 17

 ○ Import of deduplicate settings is not supported. During the import session, data is un-deduplicated 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 are 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 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 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.
NOTE: For example, if the source epoch year is 2003, do not set the time 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'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, multiprotocol 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).
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) might 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

18 Considerations for import

 source VNX. Beginning with Unity 5.1, you can enable those files to be imported to Unity as stub files. See Preserving
stub files for more information.
● 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.

Restrictions for multiprotocol VDM file import

The limitations for both NFS and CIFS imports apply to multiprotocol migration, except for ntxmap configurations, which can be
imported with multiprotocol migration.
For more information about NFS and CFS-related limitations, see Prerequisites for an NFS-only VDM import session and
CIFS-only VDM import.
The following restrictions and limitations relate to multiprotocol VDM file migration from either a VNX1 or VNX2 storage system
to a Unity storage system:
NOTE: For SMB operations, SMB1 must be enabled for the initial copy to start. SMB1 is a requirement for all CIFS-based
migrations. You can disable SMB1 after the migration is finished.
● Client access behaviors can sometimes be impacted.
Client access issues can arise from access policy differences between the source VNX system and the target Unity system.
● Multiprotocol migrations only support CIFS and NFSv3.
● A VDM that contains a stand-alone CIFS server cannot be migrated.
● The CIFS server alias is not migrated.
● The SECMAP database is not migrated; only the file system owner and role information are migrated.

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:

NOTE: 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.

Considerations for import 19

● 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.
NOTE: 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.

20 Considerations for import

 4
Configure import using Unisphere
Topics:
• Configure protection and mobility interfaces
• Configure import connection
• Create an import session for file
• Manage import sessions for file
• Create an import session for block
• Manage import sessions for block

Configure protection and mobility interfaces

Prerequisites
Protection and mobility (import) interfaces can be shared between replication and import. For import, only VDM imports require
interfaces. Block imports do not require interfaces.
Protection and mobility (import) interfaces are configured to support VDM imports and must be created prior to creating
an import connection. A mobility interface IP address is assigned to SPA and SPB on the target Unity system. Once the
mobility interface is configured, you can create the import connection between the Unity system and the VNX system. Mobility
interfaces are not used for block import sessions.
Ensure the following:
● The interface port is cabled and connected to a network switch.
● Both SPs are up and running.
Obtain the following information for each Storage Processor (SP):
● IP address associated with the interface (replication or import). Although you can specify an IPv4 or IPv6-based address,
ensure that you specify the same type of address for both SPs.
● IP address mask or prefix length that identifies the associated subnet.
● Gateway IP address associated with the interface.
● If applicable, the VLAN ID (between 1 and 4095) you want to associate the interface with.
NOTE: For the network to continue functioning properly, ensure that you set the VLAN ID only when you have
configured the network switch port to support VLAN tagging of multiple VLAN IDs.

Steps
1. Under Protection & Mobility, select Interfaces.
2. Perform one of the following actions:
● To create an interface, select the Add icon. On the Create Interface window, specify the relevant information:
○ For asynchronous replication or import, from the Ethernet Port list, select an available Ethernet port.
○ For synchronous replication, from the Ethernet Port list, select Sync Replication Management Port.
NOTE: Do not use Sync Replication Management Port for asynchronous replication or import interfaces.
● To modify an interface, select the interface, and then select the Edit icon. On the Interface Properties window,
specify the relevant information.
● To delete an interface, select the interface, and then select the Delete icon.
NOTE: Before you delete an interface, ensure that the interface is not being used by any replication or import
session.

Configure import using Unisphere 21

Configure import connection
Prerequisites
Once the mobility interfaces have been configured (required for file import only), you can create a single import connection
between the Unity system and the source VNX system. The import connection supports either block or file import sessions. You
need to enter the IP address of the source SPA or SPB and the credentials of a user with administrator privileges on the source
system when you create the connection. After creating the import connection, you are ready to create your file or block import
session.
Ensure the following:
● For a source VNX system with two control stations, the home directory of a user with the Administrator role, which is used
in configuring the import connection, must exist on the primary control station of the VNX.
● An import connection does not already exist to the source system.
● If the connection will be used for a VDM import, ensure mobility interfaces are configured on each SP of the target system.
● The relevant SP pair (source and target SPAs or source and target SPBs) are up and running.
● For block:
○ If using Fibre Channel, Zoning between VNX and Unity SP pairs is configured. Avoid using VNX MView ports or Unity
Synchronous Replication ports.
○ If using iSCSI, iSCSI interface IP addresses on both SPs on the VNX and Unity systems are configured.
○ The iSCSI connection pairs between the VNX SPs and the Unity SPs are created.
NOTE: Highlight the system name and right click iSCSI, then select Connections Between Storage Systems >
Connections > Add. Select iSCSI IP on SPA, enter the Target Portal IP address for Unity SPA, then repeat for SPB,
and assign a name for the Connection.
Obtain the SP IP management address and associated user credentials that will be used to connect to the source system.

Steps
1. Under Protection & Mobility, select Import > Connections.
2. Perform one of the following actions:
● To create an import connection, select the Add icon. On the Create Connection window, specify the relevant
information.
● To modify an import connection, select the import connection, and then select the Edit icon. On the Connection
Properties window, specify the relevant SP (SPA or SPB) IP address, username, and password to authenticate to the
SP of the source storage system.
● If new import interfaces were added, or existing import interfaces were deleted, the source system connection may
become outdated. Select the relevant import connection, and then select Verify and Update to update the source
system connection to pick up the latest import interface changes on the target and source systems.
● If new source storage resources were added, or existing source storage resources were deleted or modified after you
create an import connection and before you create an import session to the source system, you need to re-discover the
source storage system resources. Select the relevant import connection, and then select Discover Import Objects to
re-discover the source system resources.
● To delete a mobility interface, select the import interface, and then select the Delete icon.
NOTE: Before you delete an import connection, ensure that the state of the associated import session is either
cancelled or completed.

Create an import session for file

Prerequisites
Although all import sessions are listed and created from the same starting point in the UI, the steps that appear in the related
wizard are based on whether the resource type for the import session is a NAS server (for NFS, CIFS/SMB, or both, in a
multiprotocol session) or a LUN or consistency group (CG). This procedure is pertinent to a NAS server. To create an import
session for a LUN or CG, see Create an import session for block.
Ensure that you have first created relevant mobility interfaces and import connection, and then determine the following:
● The system that you want to assign as the import source system. This is based on the import connection that is configured
on the storage system.

22 Configure import using Unisphere

● The name, pool, storage provisioning, and tiering policy you want to use for the import storage resource. The system will
automatically create a target storage resource as part of this process.
● The source NFS, CIFS, or multiprotocol VDM server must be configured with a separate, non-production interface, that has
the prefix "nas_migration_xxx", which is used during the import session to migrate the VDM and file system data through
the Unity system's mobility interface.
● Verify that the physical Data Mover on which the source VDM is located has at least one IP Interface configured that is not
attached to the VDM being migrated. This ensures that the source Data Mover can provide uninterrupted Name Services for
the remaining file servers. The VDM import session will fail if this additional interface is not present.
● If the source VNX system is configured with the code page 8859-1 or 8859-15 for the NFSv3 clients, ensure that the code
page for the Unity system matches the code page being used on the VNX system. With Unity OE 4.3 and later, the code
page of the Unity system can be changed through the svc_nas {<NAS_server_name> | all} -param -facility
vdm -modify codepage -value <value> service command.
NOTE: If you change settings on the source system (such as attaching an interface to the source VDM or mounting a
file system to the source VDM), you must discover these objects before starting an import session. In Unisphere under
PROTECTION & MOBILITY , select Import > VNX Connections and select the import connection and More Actions >
Discover Import Objects.

Steps
1. Under Protection & Mobility, select Import > Sessions.
2. To create an import session, select the Add icon.
The Select Source to Import screen of the Create Import Session wizard appears.
3. Select the appropriate Source System, select NAS Server as the Resource Type, and the VDM by name for the Resource.
OE 5.1.0 supports multiprotocol migration from a VNX source VDM to a Unity destination VDM. For multiprotocol migrations,
choose Multiprotocol NAS Server as the source.
The source VDM name in the Resource field indicates whether that VDM supports multiprotocol migration. If you want to
initiate multiprotocol migration, the source VDM must have a multiprotocol-migration enabled configuration.

4. For the Configure Target NAS Server screen, the NAS Server Name is the same as the source VDM name. Select the
target Pool to use for the NAS server, the target SP Owner (SPA or SPB), and the appropriate Target Storage Pool
for the imported file systems, if different from the pool used for the NAS server. You can specify the Target Type as File
System or VMware NFS data store (VMNFS) for each file system.
5. For the Modify Target Production Port screen, select the appropriate Ethernet port under the Target Port column.
Leave Allow comparison of Server Parameters checked, unless you prefer to override the parameter comparison
between the source VNX and the target Unity file servers.
NOTE: Skipping the server parameters comparison could lead to a disruptive cutover during import.

Select the Target Import Interface from the list. For Import File System with FileRetention Enabled, which is
applicable only to Unity systems running OE version 4.4 or earlier, keep No selected if you prefer not to import any file
system that is using File Level Retention.
NOTE: If you prefer to import file systems that are configured for File Level Retention, select Yes to override this
selection.
● For Unity systems with OE versions earlier than 4.5, File Level Retention settings themselves are not supported on
the target Unity system and will not be imported.
● For Unity systems with OE versions 4.5 and later, for the subsequent Specify DHSM Credentials screen, specify
the username and password to use to connect to the source DHSM HTTP server.
NOTE: If DHSM is not already configured on the source file system, see the VNX system 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.

6. For Specify Source CIFS Server Credentials, specify the username and password to use to connect with the remote
CIFS server. These are for the local user who is a member of the administrators local group.
Ensure that the prerequisites for the source CIFS server configuration have been completed. See Prerequisites for CIFS-only
VDM import .
Once you specify the necessary information, the system will generate a summary of the import session information. Go to
the next step.
7. Verify that the import session information appearing in the summary is accurate and complete.

Configure import using Unisphere 23

8. Click Finish to create and start the import session.
The Results window appears and shows the progress of the creation and start of the import session.

Manage import sessions for file

About this task
An import session establishes an end-to-end path for an import operation between a source and target. The import source and
target are remote to each other, so the session establishes the path that the data follows as it moves from source to target.
To set up an import session for file, see Configure import.

Steps
1. Under Protection & Mobility, select Import > Sessions.
2. Perform one of the following actions:

Action Description
Modify a Select a session and click the pencil (view or edit) icon or double-click a session to modify the name of
session the session. The file system to pool mapping and the interface to port mapping cannot be changed through
Unisphere once the target resources (NAS server, file system, and interface) are created; however, the CLI
does allow you to change the session configuration before the start of import or during an initial copy failed
state.
Pause and Select a session and under More Actions, click Pause or Resume. Use Pause to pause an import session
resume a that is in either the Initial Copy or Incremental Copy state. Use Resume to start an import session that
session is in the Initialized state, or resume an import session that has been paused and is in the Initial Copy or
Incremental Copy state.
Cutover Select a session that is in the ready to cutover state, and under More Actions, click Cutover to cut over
an import session to promote the target to production mode.
NOTE: Client accesses are switched from the source VDM, to the target NAS Server. During the
cutover of a CIFS-only VDM migration, hosts have I/O interrupted and see a short period of data
unavailability (DU).

Cancel Select a session and under More Actions, click Cancel. You can cancel an import session that is in any
state (with the exceptions of Canceling, Canceled, Cutting Over, or Committed) before the commit state.
The cancel operation rolls back the VDM and related file systems to the source VNX.
NOTE: Hosts have I/O interrupted and see a short period of data unavailability (DU). NFS exports
must be remounted on the hosts. For CIFS, hosts see DU (disconnection and no access) and must
reconnect.

Commit Select a session and under More Actions, click Commit. You can commit an import session that is in the
Ready to Commit state to finish the import process.
Download Select a session and under More Actions, click Download Summary Report.
summary
report

Create an import session for block

Prerequisites
Although all import sessions are listed on and created from the same starting point in the UI, the steps that appear in the related
wizard are based on whether the resource type for the import session is a NAS server or a LUN or consistency group (CG). This
procedure is pertinent to a LUN or consistency group (CG). To create an import session for a NAS server, see Create an import
session for file.
Ensure that you have first configured FC zoning for the source and target systems or created an iSCSI connection between
the source and target systems and, if necessary, created relevant interfaces and import connection, and then determine the
following:

24 Configure import using Unisphere

● The import source system, which is based on the import connection configured on the storage system.
● The name, pool, storage provisioning, and tiering policy you want to use for the import storage resource and, depending on
the type of pool, whether data reduction is enabled. The system will automatically create a target storage resource as part of
this process.
NOTE: For storage provisioning, determine whether to convert a thin LUN to a non-thin (thick) LUN, or a thick LUN to
a thin LUN. Also, determine whether to enable data reduction on a thin LUN.

Steps
1. Under Protection & Mobility, select Import > Sessions.
2. To create an import session, select the Add icon.
The Create Import Session wizard appears.
3. Step through the wizard and specify the relevant information to select the source to import, configure the target LUN or CG
and, if necessary, configure the host access and session throttle settings for the import session.
The name of the import session will default to
import_sess_<sourceResourceName>_<sourceSystemSerialNumber>_<targetSystemSerialNumber>.
In the Target step, the LUN or CG name is the same as the source LUN or CG name. In case of a naming conflict, the source
system name will be appended with the next available number, such as 01. You should always see a suggested pool selection
based on capacity unless there are no valid pools available. If necessary, the Target Name and Pool, Tiering Policy, Thin, and
Data reduction of the associated LUN or LUNs can be modified.
NOTE: If Thin is not selected, Data Reduction cannot be selected and is disabled. If Thin is selected, Data Reduction
can be selected.
In the Access step, select or add a host or hosts that can access the storage resource.
In the Setting step, specify whether to throttle the import transfer. Transfer throttle impacts the import speed and host
latency for the related LUNs and file systems that are in use on the source and target storage systems. The default is set
to throttle (checkbox is checked), which means that the session is throttled. If set to unchecked, import transfer would be
unthrottled and allowed to function at the highest rate possible.

Once you specify the necessary information, the system will generate a summary of the import session information.
4. Verify that the import session information appearing in the summary is accurate and complete.
5. Click Finish to create and start the import session.
The Results window appears and shows the progress of the creation and start of the import session.

Manage import sessions for block

About this task
An import session establishes an end-to-end path for an import operation between a source and target. The data follows the
path as it moves from source to target.
To set up an import session for block, see Configure import.

Steps
1. Under Protection & Mobility, select Import > Sessions.
2. Perform one of the following actions:

Action Description
Modify a Select a session and click the View/Edit icon or double click a session to modify the name of the session or
session change the configuration settings for the transfer throttle and the cutover threshold percent.
Pause and Select a session and under More Actions, click Pause or Resume. Use Pause to pause an import session
resume a that is in either the Initial Copy or Incremental Copy state. Use Resume to start an import session that
session is in the Initialized state, or resume an import session that has been paused and is in the Initial Copy or
Incremental Copy state, or when a session fails and the cause of the failure has been fixed.
Cutover Select a session and under More Actions, click Cutover to cut over an import session to promote the
target to production mode.

Configure import using Unisphere 25

 Action Description
Cancel Select a session and under More Actions, click Cancel. You can cancel an import session that is in any
state (with the exceptions of Cancelling, Cancelled, or Cutting Over) before the commit state. The cancel
operation deletes the SAN Copy session for each set of LUN pairs in the import session and disables SAN
Copy access to the target LUN. It also deletes the target LUN or CG associated with the import session.
Commit Disabled since a separate commit action is not needed for a block import session. This action is performed
automatically at the end of cutover for a block import session.

26 Configure import using Unisphere

 5
Configure import using the CLI
Topics:
• Create mobility interfaces
• Create remote system configurations
• View import sessions
• Create a NAS import session
• View import sessions for file
• Change import session settings for file
• Cutover import session for file
• Commit import session for file
• Cancel a NAS import session
• Create a block import session
• View import sessions for block
• Change import session settings for block
• Cut over import session for block
• Cancel a block import session
• View import session elements

Create mobility interfaces

Create a mobility interface.

Format
/net/if create [-async] [-vlanId <value>] -type {iscsi | replication} -port <value> -addr
<value> [-netmask <value>] [-gateway <value>]

Action qualifier
Qualifier Description
-async Run the creation operation in asynchronous mode.
-type Specify the interface type. Value is one of the following:
● iscsi—Interface for iSCSI storage.
● replication—Interface for replication-related data or management traffic.
NOTE: The replication type is also used to create the mobility interface which is used during a file import
session.

-port Specify the ID of the SP port or link aggregation that will use the interface.
NOTE: For systems with two SPs, a file interface is created on a pair of symmetric Ethernet ports rather
than on a single specified port. Its current port is defined by NAS server SP and may differ from the specified
port. For example, if the user specifies port spa_eth2, but the NAS server is on SP B, the interface is created
on port spb_eth2.

-vlanId Specify the virtual LAN (VLAN) ID for the interface. The interface uses the ID to accept packets that have VLAN
tags. The value range is 1–4095.

Configure import using the CLI 27

Qualifier Description

NOTE: If no VLAN ID is specified, which is the default, packets do not have VLAN tags. The Unisphere online
help provides more details about VLANs.

-addr Specify the IP address for the interface. The prefix length should be appended to the IPv6 address and, if
omitted, will default to 64. For IPv4 addresses, the default length is 24. The IPv4 netmask may be specified in
address attribute after slash.
-netmask Specify the subnet mask for the interface.
NOTE: This qualifier is not required if the prefix length is specified in the -addr attribute.

-gateway Specify the gateway for the interface.

NOTE: This qualifier configures the default gateway for the specified port’s SP.

Example
The following command creates a replication interface. The interface receives the ID IF_1:
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /net/if create -type replication -port
eth1_spb -addr 10.0.0.1 -netmask 255.255.255.0 -gateway 10.0.0.1

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

ID = IF_1
Operation completed successfully.

Create remote system configurations

Configures a remote system configuration for the local system to access.
NOTE: For a source VNX system with two control stations, the home directory of a user with the Administrator role, which
is used in configuring the import connection, must exist on the primary control station of the VNX. See VNX system with
two Control Stations.

Format
/remote/sys create -addr <value> [-type VNX] -srcUsername <value> {-srcPassword <value>
| -srcPasswordSecure} -dstUsername <value> {-dstPassword <value> | -dstPasswordSecure} [-
connectionType {sync | async | both}]

Action qualifiers
Qualifier Description
-addr Specify the network name or IP address of the remote system.
-type Specify the remote system type. Valid values are:
● VNX
-srcUsername For systems that are the source in a replication, type the username that is used to access the
system.
-srcPassword For systems that are the source in a replication, type the user password that is used to access the
system.

28 Configure import using the CLI

Qualifier Description
-srcPasswordSecure Specify the password in secure mode. Once you run the command with this qualifier, you will be
asked to type the password separately.
-dstUsername For systems that are the destination in a replication session or VNX in an import session, specify
the username that is used to access the system.
-dstPassword For systems that are the destination in a replication session or VNX in an import session, specify
the user password that is used to access the system.
-dstPasswordSecure Specify the password in secure mode. Once you run the command with this qualifier, you will be
asked to type the password separately.
-connectionType Specify this qualifier to indicate the type of replication connection. Valid values are async, sync, or
both.

Example
The following command creates a remote system configuration with these settings:
● Network address is 10.64.75.10.
● Includes access credentials for when the system is the source or destination.
The configure remote system receives the ID RS_65536:
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /remote/sys create –addr 10.64.75.10 –
type VNX -dstUsername admin1 -dstPassword Password789!

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

ID = RS_65536
Operation completed successfully.

View import sessions

View details about existing import sessions for both file and block. You can filter on the session ID.

Format
/import/session [-id <value> | -active | -completed | -cancelled] [-type {block | nas}]
show

Object qualifier
Qualifier Description
-id Type the ID of the import session.
-active Show only active sessions (sessions that are not completed or cancelled).
-completed Show only completed sessions.
-cancelled Show only cancelled sessions.
-type Specifies what type of sessions to show. Valid values are :
● block
● nas

Configure import using the CLI 29

Example
The following command displays all existing import sessions on the system:
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session show -detail

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

1: ID = import_1
Name =
import_sess_vdm1_BB0050562C7D2A_FCNCH0972C330D
Session type = nas
Health state = OK (5)
Health details = "The component is
operating normally. No action is required."
State = Initialized
Progress = empty
Source system = RS_65535
Source resource = vdm1
Target resource = nas_1

2: ID = import_2
Name = VNX LUN Group 1 import
Session type = block
Health state = OK (5)
Health details = "The component is
operating normally. No action is required."
State = Initial copy
Progress =
Source system = RS_65535
Source resource = LUNGroup1
Target resource = res_1

Create a NAS import session

Create a NAS import session.
NOTE: This command only creates the import session. To start the import session through the UEMCLI, you must run
the /import/session/nas set command and specify no for the action qualifier -paused.

Prerequisites
Before creating a NAS import session, complete the following configuration tasks:
● Create interfaces on both the source and target systems for data transfer.
● Create an import connection from the source VNX to the current Unity-based target system.
● Create a target pool.
● If the source VNX system is configured with the code page 8859-1 or 8859-15 for the NFSv3 clients, ensure that the code
page for the Unity system matches the code page being used on the VNX system. With Unity OE 4.3 and later, the code
page of the Unity system can be changed through the svc_nas {<NAS_server_name> | all} -param -facility
vdm -modify codepage -value <value> service command.

Format
/import/session/nas create [-async] [-name <value>] -srcSys <value> -srcRes <value>
-targetResPool <value>< [-targetImportIf <value>] [-productionIfPortPairs <value>] [-
productionIfVlanPairs <value>] –fsPoolPairs <value>] –defaultProductionPort <value>
[-srcDhsmUsername <value>] [-srcDhsmPasswd <value>] [-srcDhsmPasswdSecure <value>]
[-unixDirectoryService {directMatch | local | nis | ldap |localThenNis |

30 Configure import using the CLI

localThenLdap | none}] [-srcLocalCifsAdminUsername <value> {-srcLocalCifsAdminPasswd
<value>|-srcLocalCifsAdminPasswdSecure}] [-srcFsImportedAsVMWareDatastore <value>] [-
srcFsImportedWithDataReductionEnabled <value>] [-srcFsImportedWithAdvancedDedupEnabled
<value>] [-skipServerParamCheck]

Action qualifiers
Qualifier Description
-async (Optional) Run operation in asynchronous mode.
-name (Optional) Specifies the new name of the import session.
NOTE: If name is not specified, it is generated in the pattern

import_sess_<srcRes>_<srcSysSerialNumber>_<targetSysSeri
alNum
ber>[_<index>]

-srcSys Specifies the source (remote) system.

-srcRes Specifies the source resource.
-targetResPool Specifies the default storage pool to store target NAS server configuration
information and file systems.
-targetImportIf (Optional) Specifies the target replication interface for the import session.
-productionIfPortPairs (Optional) Specifies the source VDM production interfaces and target port pairs.
Values are a comma-separated list of mappings between source VDM production
interfaces and target ports.
NOTE: Use the following format:
source_interface_1:dest_port_1,source_interface_2:dest_p
ort_2

-productionIfVlanPairs (Optional) Specifies the source VDM production interface and the target VLAN
pairs. Values are a comma-separated list of mappings between source VDM
production interfaces and target VLAN pairs.
NOTE: Use the following format:
source_interface_1:1,source_interface_2:2

-fsPoolPairs (Optional) Specifies the source file system IDs and target pool pairs. Values are a
comma separate list of mappings between file system IDs and target pool pairs.
NOTE: Use the format sourceFsId1:destination_pool_friendlyId
(sourceFsid must be an existing supported
source file system ID, otherwise validation fails),
or sourceFsId2~sourceFsId3:destination_pool_friendlyId
(sourceFsId2 and sourceFsId3 must be existing supported source file system
IDs, the other file system IDs between sourceFsId2 and sourceFsId3 do not
necessarily must exist. The create process only takes existing source file
system IDs and skips nonexistent file system IDs in the range.). For example,
for the input 12:pool_1,15~20:pool_2, source file system IDs with 12, 15,
and 20 must exist but source file systems with IDs starting from 16 to 19 do not
must exist.

-defaultProductionPort Specifies the target port where NAS server production interfaces will be created
by default.
-srcDhsmUsername Specifies the username for authentication to DHSM service on the source Data
Mover.
NOTE: When the source VDM has FLR-E/C file systems, file import needs to
connect to the DHSM service on the source Data Mover. If the DHSM service
is configured with basic or digest authentication, the username needs to be
specified.

Configure import using the CLI 31

Qualifier Description
-srcDhsmPasswd Specifies the password for authentication to the DHSM service on the source Data
Mover.
-srcDhsmPasswdSecure Specifies the password for authentication to the DHSM service on the source Data
Mover in secure mode.
NOTE: The user will be prompted to input the password and the password
confirmation.

-unixDirectoryService (Optional) Specifies which UNIX directory service to import. Directory service is
used for querying identity information for UNIX (such as UIDs, GIDs, net groups).
Valid values are:
● directMatch - Import source unixDirectoryService to target without any
change.
● local - Use Local files (passwd, group, hosts, netgroup) for querying identity
information for UNIX.
● nis - Use NIS for querying identity information for UNIX.
● ldap - Use LDAP for querying identity information for UNIX.
● localThinNis - Use Local files and then NIS for querying identity information
for UNIX.
● localThinLdap - Use Local files and then LDAP for querying identity
information for UNIX.
● none - Do not use any of UNIX directory services.
-srcLocalCifsAdminUsername (Optional) Specifies the username for authentication to the CIFS server on the
source VDM.
-srcLocalCifsAdminPasswd (Optional) Specifies the password for authentication to the CIFS server on the
source VDM.
-srcLocalCifsAdminPasswd (Optional) Specifies the password in secure mode.
Secure NOTE: The user is prompted to input the password and the password
confirmation.

-srcFsImportedAsVMWareDatasto (Optional) Specifies which source file systems are imported as VMWare datastore
re file systems. Values are a comma-separated list of source file system IDs with
comma-separated value of single file system ID or a range of file system IDs;
for example, sourceFsId1,sourceFsId2~sourceFsId3. sourceFsId1,
sourceFsId2, and sourceFsId3 must be existing supported source file system
IDs. The source file systems with IDs between sourceFsId2 and sourceFsId3
do not necessarily must exist. The create process only takes existing source file
system IDs and skips nonexistent file systems in the range. For example, for input
13,15~20,25, source file systems with ID 13, 15, 20 and 25 must exist; source file
systems with IDs starting from 16 to 19 do not must exist.
NOTE: If a VNX file system is specified by this option, it should not contain any
tree quotas or user quotas.

-srcFsImportedWithDataReducti (Optional) Specifies which source file systems are imported with data reduction
onEnabled enabled. Values are a comma-separated list of source file system IDs with comma-
separated value of single file system ID or a range of file system IDs; for example,
sourceFsId1,sourceFsId2~sourceFsId3. sourceFsId1, sourceFsId2,
and sourceFsId3 must be existing supported source file system IDs. The
source file systems with IDs between sourceFsId2 and sourceFsId3 do not
necessarily must exist. The create logic only takes existing source file system IDs
and skips nonexistent file systems in the range. For example, for input 13,15~20,25,
source file systems with ID 13,15,20 and 25 must exist; source file systems with IDs
starting from 16 to 19 do not must exist.
-srcFsImportedWithAdvancedDed (Optional) Specifies which source file systems are imported with advanced
upEnabled deduplication enabled. Values are a comma-separated list of source file system IDs
with comma-separated value of single file system ID or a range of file system IDs;
for example, sourceFsId1,sourceFsId2~sourceFsId3. sourceFsId1,
sourceFsId2, and sourceFsId3 must be existing supported source file system

32 Configure import using the CLI

Qualifier Description
IDs. The source file systems with IDs between sourceFsId2 and sourceFsId3
do not necessarily must exist. The create logic only takes existing source file
system IDs and skips nonexistent file systems in the range. For example, for input
13,15~20,25, source file systems with ID 13,15,20 and 25 must exist; source file
systems with IDs starting from 16 to 19 do not must exist.
-skipServerParamCheck (Optional) Specifies whether to skip server parameters check (comparison). When
selected, the server parameters check is skipped. In silent mode, the check is not
skipped. Import session creation compares server parameters between VNX and
Unity. When import session creation fails with a Server parameter error, this option
enables the creation to proceed.
CAUTION: Skipping the server parameters check could lead to
disruptive cutover during import.

Import session example

The following command creates an import session with these settings:

NOTE: The source VDM is an NFS-only VDM.

● Import session name is newName.

● Source storage system is RS_1.
● Source storage resource (VDM) is src_vdm_to_migrate.
● Target resource pool is pool_1.
● Target import interface is if_3.
● Source VDM production interface and target port pairs are source_interface_1:spa_iom_0_eth1 and
source_interface_2:spa_iom_0_eth0.
● Source file system and target pool pairs are 100~200:pool_2 and 255:pool_3.
● Target port where NAS server production interfaces will be created is spa_iom_0_eth0.
● Migrate the direct match UNIX Directory Service.
● File systems 13, 20 through 25, and 30 are to be imported as VMWare datastore file systems.
● Skip the server parameters check.
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! import/session/nas create -name
newName -srcSys RS_1 -srcRes src_vdm_to_migrate -targetResPool pool_1 -targetImportIf if_3
-productionIfPortPairs source_interface_1:spa_iom_0_eth1,source_interface_2:spa_iom_0_eth0
-fsPoolPairs 100~200:pool_2,255:pool_3 -defaultProductionPort spa_iom_0_eth0
-unixDirectoryService directMatch -srcFsImportedAsVMWareDatastore 13,20~25,30
-skipServerParamCheck

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Using '-skipServerParamCheck' option could lead to disruptive cutover during migration.

Do you want to continue?
yes / no: yes
ID = import_1
Operation completed successfully.

The following command creates an import session with these settings:

NOTE: The source VDM is a NFS-only VDM.

● Import session name is newName.

● Source storage system is RS_1.
● Source storage resource (VDM) is src_vdm_to_migrate.
● Target resource pool is pool_1.
● Target import interface is if_3.
● Source VDM production interface and target port pairs are source_interface_1:spa_iom_0_eth1 and
source_interface_2:spa_iom_0_eth0.

Configure import using the CLI 33

● Source file system and target pool pairs are 100~200:pool_2 and 255:pool_3.
● Target port where NAS server production interfaces will be created is spa_iom_0_eth0.
● Migrate the direct match UNIX Directory Service.
● File systems 13, 20 through 25, and 30 are to be imported as VMware datastore file systems.
● File systems 14, 22, 25 through 30 are imported as thin.
● File systems 31 and 40 through 45 are imported and have data reduction applied.
● Skip the server parameters check.
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! / import/session/nas create -name
newName -srcSys RS_1 -srcRes src_vdm_to_migrate -targetResPool pool_1 -targetImportIf if_3
-productionIfPortPairs source_interface_1:spa_iom_0_eth1,source_interface_2:spa_iom_0_eth0
-fsPoolPairs 100~200:pool_2,255:pool_3 -defaultProductionPort spa_iom_0_eth0
-unixDirectoryService directMatch -srcFsImportedAsVMwareDatastore 13,20~25,30
-srcFsImportedAsThin 14,22,25~30 -srcFsImportedWithDataReductionEnabled 31,40~45
-skipServerParamCheck

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

ID = import_1
Operation completed successfully.

The following command creates an import session with these settings:

NOTE: The source VDM is a CIFS-only VDM.

● Import session name is newName.

● Source storage system is RS_1.
● Source storage resource (VDM) is src_vdm_to_migrate.
● Target resource pool is pool_1.
● Target import interface is if_3.
● Source VDM production interface and target port pairs are source_interface_1:spa_iom_0_eth1 and
source_interface_2:spa_iom_0_eth0.
● Source file system and target pool pairs are 100~200:pool_2 and 255:pool_3.
● Target port where NAS server production interfaces will be created is spa_iom_0_eth0.
● The username for authentication to the CIFS server on the source VDM is cifsadmin1
● The password for authentication to the CIFS server on the source VDM is cifspassword1
● File systems 13, 20 through 25, and 30 are to be imported as VMware datastore file systems.
● File systems 14, 22, 25 through 30 are imported as thin.
● File systems 31 and 40 through 45 are imported and have data reduction applied.
● Skip the server parameters check.
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! import/session/nas create -name
newName -srcSys RS_1 -srcRes src_vdm_to_migrate -targetResPool pool_1 -targetImportIf if_3
-productionIfPortPairs source_interface_1:spa_iom_0_eth1,source_interface_2:spa_iom_0_eth0
-fsPoolPairs 100~200:pool_2,255:pool_3 -defaultProductionPort spa_iom_0_eth0
-srcFsImportedAsVMWareDatastore 13,20~25,30 -srcLocalCifsAdminUsername cifsadmin1
-srcLocalCifsAdminPasswd cifspassword1 -skipServerParamCheck

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Using '-skipServerParamCheck' option could lead to disruptive cutover during migration.

Do you want to continue?
yes / no: yes
ID = import_1
Operation completed successfully.

View import sessions for file

View details about import sessions for file. You can filter on the session ID.

34 Configure import using the CLI

Format
/import/session/nas [{-id <value> | -active | -completed | -cancelled}] show

Object qualifier
Qualifier Description
-id Type the ID of the import session.
-active Show only active sessions (sessions that are not completed or cancelled).
-completed Show only completed sessions.
-cancelled Show only cancelled sessions.

Example
The following command displays file import sessions on the system:
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session/nas show -detail

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

1: ID = import_1
Type = cifs
Name = test1
Health state = OK (5)
Health details = "The import
session is operating normally."
State = Cancelled
Progress =
Source system = RS_65536
Source resource = vdm_cifs_frank
Source import interface =
nas_migration_frank
Source file systems imported as VMware datastore =
Source file systems imported with compression enabled =
Source file systems imported with data reduction enabled =
Source file systems imported with advanced deduplication enabled =
Target resource = nas_1
Target resource pool = pool_1
Target file system to pool mapping =
res_10~res_11:pool_1
Target file system access policy mapping =
Target import interface = if_5
Target default production port = spa_iom_0_eth0
Target production interface to port mapping =
if_6:spa_iom_0_eth0
Target production interface to vlan mapping = if_6:0
CIFS local user = Administrator
Source DHSM user =

2: ID = import_3
Type = Multiprotocol
Name = test2
Health state = OK (5)
Health details = "The import
session is operating normally."
State = Cancelled
Progress =
Source system = RS_65536
Source resource = vdm_test
Source import interface =
nas_migration_test1
Source file systems imported as VMware datastore =

Configure import using the CLI 35

 Source file systems imported with compression enabled =
Source file systems imported with data reduction enabled =
Source file systems imported with advanced deduplication enabled =
Target resource = nas_2
Target resource pool = pool_1
Target file system to pool mapping = res_12~res
13:pool_1
Target file system access policy mapping = 1400:UNIX;
174:WINDOWS
Target import interface = if_5
Target default production port = spa_iom_0_eth0
Target production interface to port mapping =
if_7:spa_iom_0_eth0
Target production interface to vlan mapping = if_7:0
CIFS local user = Administrator
Source DHSM user =

Change import session settings for file

Change the settings for a NAS import session.

Format
/import/session/nas –id <value> set [-async] [-paused {yes | no}] -name
<value>] [-targetResPool <value>] [-fsPoolPairs <value>] [-targetImportIf <value>] [-
productionIfPortPairs <value>] [-productionIfVlanPairs <value>] [-srcLocalCifsAdminUsername
<value> {-srcLocalCifsAdminPasswd <value> | srcLocalCifsAdminPasswdSecure}] [-
srcFsImportedAsVMwareDatastore <value>] [-srcFsImportedWithDataReductionEnabled <value>] [-
srcFsImportedWithAdvancedDedupEnabled <value>]}

Object qualifier
Qualifier Description
-id Type the ID of the import session.

Action qualifiers
Qualifier Description
-async Run action in asynchronous mode.
-name Specifies the new name of the import session.
-paused Specifies whether to pause the session. Valid values are:
● yes
● no
NOTE: no starts or resumes the import session.

-targetResPool Specifies the new pool for the target resource. Applicable only when
the session status is Initialized or the target NAS server provision fails.
-fsPoolPairs Specifies the source file system IDs and target pool pairs. Applicable
only when the session status is Initialized or the target file system
provision fails.
-targetImportIf Specifies the new target migration interface. Applicable only when the
session status is Initialized or the target NAS server provision fails.

36 Configure import using the CLI

Qualifier Description
-productionIfPortPairs Specifies the source VDM production interface and target port pairs.
Applicable only when the session status is Initialized or the target
production interface creation fails.
-productionIfVlanPairs Specifies the source VDM production interface and the target VLAN
pairs. Applicable only when the session status is Initialized or the target
production interface creation fails.
-srcLocalCifsAdminUsername Specifies the user name for authentication to the CIFS server on the
source VDM.
-srcLocalCifsAdminPasswd Specifies the password for authentication to the CIFS server on the
source VDM.
-srcLocalCifsAdminPasswdSecure Specifies the password in secure mode.
NOTE: The user is prompted to input the password and the
password confirmation.

-srcFsImportedAsVMWareDatastore Specifies what source file systems are imported as VMware datastore
file systems. Only applies to file import when the session is initialized.
NOTE: If a VNX file system is specified by this option, it should not
contain any tree quotas or user quotas.

-srcFsImportedWithDataReductionEnabled Specifies which source file systems are imported with data reduction
enabled. Only applies to file import when the session is initialized.
-srcFsImportedWithAdvancedDedupEnabled Specifies which source file systems are imported with advanced
deduplication enabled. Only applies to file import when the session is
initialized.

Example
The following command changes the NAS import session settings:
NOTE: This command only makes changes to the import session configuration. To resume (start) the import session
through the UEMCLI, you must run the /import/session/nas set command and specify no for the action qualifier
-paused.
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session/nas –
id import_1 set -name newName -targetResPool pool_2 -targetImportIf if_3
-productionIfPortPairs source_interface_1:spa_iom_0_eth1,source_interface_2:spa_iom_0_eth0
-fsPoolPairs 100~200:pool_2,255:pool_3 -srcFsImportedAsVMWareDatastore 17~20
-srcFsImportedWithDataReductionEnabled 31,40~45

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Operation completed successfully.

Start or resume an import session

Once an import session is created and optionally modified, it remains in the initialized state until it is started (or resumed). The
following command starts (or resumes) the example NAS import session:
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session/nas –id import_1 set
-paused no

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Configure import using the CLI 37

 Operation completed successfully.

Cutover import session for file

Cut over an existing NAS import session. Cutting over a session switches the active host IOs to the target side and initiates the
incremental data synchronization from the source to the target.

Format
/import/session/nas -id <value> cutover [-async] [-netbiosName <value>] [-cifsServerName
<value> -domainUsername <value> {-domainPasswd <value> | -domainPasswdSecure}] -[ou] <AD
organizational unit tree>

Object qualifier
Qualifier Description
-id Specifies the ID of the import session.

Action qualifier
Qualifier Description
-async Run the action in asynchronous mode.
-netbiosName Specifies new NetBIOS name for source the CIFS server.
-cifsServerName Specifies the new name for the source CIFS server after the cutover. SMB (CIFS) server name
must be unique on the network.
NOTE: If not specified, the default name for renaming the source CIFS server is the original
CIFS server name that is prefixed with an underscore (_).

-domainUsername Specifies the domain administrator name. This name is required for renaming the source CIFS
server and joining it to the Active Directory. (Used for AD-joined CIFS server migration only)
-domainPasswd Specifies the domain user password.
-domainPasswdSecure Specifies the password in secure mode.
NOTE: The user is prompted to input the password and the password confirmation.

-ou Specifies the complete Active Directory organizational unit tree for the source CIFS server.
NOTE: This parameter is optional. If provided, the LDAP search of the CIFS server in AD is
shown in the specified OU tree.

Example 1
The following command cuts the NFS import session, import_1, over to the target system:
uemcli -d 10.0.0.1 -u Local/joe -p <value> /import/session/nas -id import_1 cutover

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Operation completed successfully.

38 Configure import using the CLI

Example 2
The following command shows the SMB import session, import_1, being cut over to the target system:
uemcli -d 10.0.0.1 -u Local/joe -p <value> /import/session/nas -id import_1 cutover
-cifsServerName <value> -domainUsername <value> -domainPasswd <value>

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Operation completed successfully.

Example 3
The following command shows CIFS import session import_1 being cut over to the target system while specifying the AD
organizational unit tree:
uemcli -u admin -p <password> -sslPolicy accept /import/session/nas -id import_1 cutover
-netbiosName <value> -cifsServerName <value> -domainUsername <value> -domainPasswd <value>
-ou <value>
The following command shows CIFS import session import_2 being cut over to the target system after import_1 has been cut
over:
uemcli -u admin -p <value> -sslPolicy accept /import/session/nas -id import_2 cutover
-netbiosName <value> -cifsServerName <value> -domainUsername <value> -domainPasswd <value>

Commit import session for file

Commit an existing NAS import session. Committing a session completes the import process.

Format
/import/session/nas -id <value> commit [-async]

Object qualifier
Qualifier Description
-id Type the ID of the import session.

Action qualifier
Qualifier Description
-async Run the action in asynchronous mode.

Example
The following command commits the import session, import_1.
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session/nas -id import_1 commit

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Configure import using the CLI 39

 Operation completed successfully.

Cancel a NAS import session

Cancel an existing NAS import session.

Format
/import/session/nas -id <value> cancel [-async] [-domainUsername <value> {-domainPasswd
<value> | -domainPasswdSecure}] [-ou <value>]

Object qualifier
Qualifier Description
-id Type the ID of the import session.

Action qualifier
Qualifier Description
-async Run the action in asynchronous mode.
-domainUsername Specifies the domain user with administrative rights to update the AD (not necessary for
standalone CIFS server).
-domainPasswd Specifies the domain user password (not necessary for standalone CIFS server).
-domainPasswdSecure Specifies the password in secure mode (not necessary for standalone CIFS server).
NOTE: The user is prompted to input the password and the password confirmation.

-ou Specifies the complete AD organizational unit tree for the source CIFS server.
NOTE: This is an optional parameter,if provided the ldap search of the CIFS server in AD will
be in the given specified OU tree.
Specifies colon(:) separated list of ou's. Consider there are two ou's ou1 and ou2 for cifs server.
Let ou2 resides under ou1. Then the <value> will look like 'ou=ou2:ou=ou1'

Example 1
The following command cancels the NAS import session, import_1.
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session/nas -id import_1 cancel
-skipSourceRestore

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Operation completed successfully.

Example 2
The following command cancels the NAS import session, import_1.

40 Configure import using the CLI

uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session/nas -id import_1 cancel
-domainUsername user1 -domainPasswd password1 -ou 'ou=Computers:ou=EMC Celerra'

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Operation completed successfully.

Create a block import session

Prerequisites
Before creating a block import session, complete the following configuration tasks:
● Create interfaces on both source and target for data transfer.
● Create an import connection to a Unity-based target system.
● Create a block import target (LUN or LUN Group) on the target system.

Format
/import/session/block create [-async] [-name <value>] [-throttle {yes | no}] -srcSys
<value> -srcRes <value> -lunPoolPairs <value> [-cutoverThreshold <value>] [-hosts <value>]
[-importAsVMwareDatastore {yes | no}]

Action qualifiers
Qualifier Description
-async Run action in asynchronous mode.
-name Specifies the name of the import session.
NOTE: If name is not specified, it will be generated in the pattern

import_sess_<srcRes>_<srcSysSerialNumber>_<targetSysSerialNum
ber>[_<index>]

-throttle Specifies whether to throttle the import transfer. Throttle impacts the import speed and
host latency for the related LUNs and file systems that are in use on the source and target
storage systems. Valid values are:
● yes
● no
NOTE: Default is to throttle the import transfer, which means that it is throttled at
less than the full speed.

-srcSys Specifies the source system.

-srcRes Specifies the source resource.
-lunPoolPairs Specifies the LUN pool pairs. A comma separated list of mappings between the source LUN
and the target storage configuration.
NOTE: Use the format srcLUN1:tgtPool1,…,…. Target LUNs will have the same
properties as those of the source LUN, such as name, isThin, SP, and size.

-cutoverThreshold The percentage threshold below which the import session becomes ready to be cutover.
-hosts Specifies the hosts. A comma separated list of friendly IDs of hosts to give access to
target elements.

Configure import using the CLI 41

Qualifier Description
-importAsVMwareDatastore Specifies whether the source LUN is to be imported as a VMware datastore (VMFS). This
option is only valid for a LUN session and is not valid for a CG session. Valid values are:
● yes
● no

Example
The following command creates an import session with these settings:
● Import session name is lun_17_import.
● Source storage system is RS_1.
● Source storage resource is 17.
● LUN pool pair is 17:pool_1.
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! import/session/block create -name
lun_17_import -srcSys RS_65596 -srcRes 17 -lunPoolPairs 17:pool_1 -importAsVMwareDatastore
yes

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

ID = import_1
Operation completed successfully.

View import sessions for block

View details about import sessions for block. You can filter on the session ID.

Format
/import/session/block [{-id <value> | -active | -completed | -cancelled}] show

Object qualifier
Qualifier Description
-id Type the ID of the import session.
-active Show only active sessions (sessions that are not completed or cancelled).
-completed Show only completed sessions.
-cancelled Show only cancelled sessions.

Example
The following command displays block import sessions on the system:
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session/block show -detail

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

1: ID = import_2
Name = VNX LUN Group 1 import

42 Configure import using the CLI

 Session type = block
Health state = OK (5)
Health details = "This import session
is operating normally. No action is required."
State = Syncing
Progress = 0%
Source system = RS_65535
Source resource = LUNGroup1
Target resource = res_1
Estimated remaining bytes = 47185920 (45 M)
Percent remaining for import = 6
Cutover threshold percent = 5
Throttle = no

Change import session settings for block

Change the settings for a block import session.

Format
/import/session/block –id <value> set [-async] [-name <value>] [-paused {yes | no} [-
throttle {yes | no}] [-cutoverThreshold <value>]

Object qualifier
Qualifier Description
-id Type the ID of the import session.

Action qualifiers
Qualifier Description
-async Run action in asynchronous mode.
-name Specifies the new name of the import session.
-throttle Specifies whether to throttle the import transfer. Throttle impacts the import speed and host latency
for the related LUNs and file systems that are in use on the source and target storage systems. Valid
values are:
● yes
● no
NOTE: Default is to throttle the import transfer, which means that it is throttled at less than the
full speed.

-paused Specifies whether to pause the import session. Valid values are:
● yes
● no
NOTE: no starts or resumes the import session.

-cutoverThreshold Specifies the threshold percentage below which the import session is cutover-ready.

Example
The following command changes the block import session settings for name to newName, the commitThrottle level to 5, and to
not apply the throttle:

Configure import using the CLI 43

uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session/block –id import_1 set
-name newName -throttle no -cutoverThreshold 5

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Operation completed successfully.

Cut over import session for block

Cut over and complete an existing block import session. Cutting over a block import session can be a long and disruptive
process. To reduce the period of disruption, set the cutover threshold as small as possible. By decreasing the cutover threshold
to a small value, a smaller number of changes will need to be transferred after the application is quiescent. The cutover
threshold is a percentage of the LUN size and hence for larger LUNs it is recommended that the cutover threshold be set to
a value smaller than the default value of 5 percent. Lastly, cut over an import session only when the session is in the Cutover
Ready state. This action ensures that the cutover is performed when the least number of changes has to be transferred.
After cutover completes successfully, host IOs are switched to the target side and the import process completes automatically.

Format
/import/session/block -id <value> cutover [-async]

Object qualifier
Qualifier Description
-id Type the ID of the import session.

Action qualifier
Qualifier Description
-async Run the action in asynchronous mode.

Example
The following command cuts the import session, import_1, over to the target system:
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session/block -id import_1
cutover

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Operation completed successfully.

Cancel a block import session

Cancel an existing block import session.

44 Configure import using the CLI

Format
/import/session/block -id <value> cancel [-async]

Object qualifier
Qualifier Description
-id Type the ID of the import session.

Action qualifier
Qualifier Description
-async Run the action in asynchronous mode.

Example
The following command commits the block import session, import_1.
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session/block -id import_1 cancel

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Operation completed successfully.

View import session elements

View details about import status for each element in the active import session, for example, each LUN in a consistency group
(CG).

Format
/import/session/element -importId <value> show

Object qualifier
Qualifier Description
-importId Type the ID of the import session.

Example
The following command displays import status for each element in the specified import session:
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /import/session/element -importId
import_2 show -detail

Storage system address: 10.0.0.1

Storage system port: 443
HTTPS connection

Configure import using the CLI 45

 1: Source system = RS_1
Source resource = lun1
Target resource = sv_1
Health state = OK (5)
Health details = "The component is operating normally. No action is required."
Stage = Incremental Sync
Iteration = 4
Progress = 10%
Source system = RS_1
Source resource = lun4
Target Resource = sv_2
Health state = OK (5)
Health details = "The component is operating normally. No action is required."
Stage = Incremental sync
Iteration = 4
Progress = 0%

46 Configure import using the CLI

 6
Troubleshooting
Topics:
• Information related to import operation problems
• VNX system with two Control Stations

Information related to import operation problems

Before you contact your service provider, use either Unisphere or the Unisphere CLI to access information about jobs that failed
and alert information and check the target storage system's log files.

Jobs and Alerts information

Use Unisphere to get information about Jobs that fail. Under Events, select Jobs. Use Jobs to view information on all jobs,
including those jobs that are active and those jobs that are complete or failed. To quickly determine the number of active jobs
(those jobs that are queued or running) and view job progress, use the Jobs icon in the status bar. To view detailed information
about the job, specifically the individual tasks included in the job and the status of these tasks, select the Details icon. If a task
fails, select View Error for more information.
To get information about Jobs that fail, use the Unisphere CLI. To find the job that failed, review the Jobs output. The following
is an example:
C:>uemcli -d -u Local/admin -p /sys/task/job show

74: ID = N-66
Type = Replication Service
Title = Create VNX remote system connection
State = Failed

Once you have the Job ID, you can retrieve more detailed information about the failure. The following is an example:
C:>uemcli -d -u Local/admin -p /sys/task/job/step -jobId N-66 show -detail

1: Title = Register VNX remote system connection

Status = Failed
Execution result code = 105906574
Execution result description = An error occured while trying to communicate with
the remote VNX system. The credentials used might be incorrect or there may be a network
issue while connecting to the remote VNX system. (Error Code:0x650018e)
Rollback result code = 4106
Rollback result description = Task was rolled back and marked as failed. This is
because some tasks failed or SP rebooted during task execution. (Error Code:0x100a)

Alerts provide you with information about the source of an event, the symptoms and cause, and actions that you can take to
resolve it. Any actions that are taken to resolve an alert must be performed directly on the system on which the alert was
reported.
In Unisphere under Events, select Alerts. In addition to appearing on the Alerts page, each alert generates a pop-up alert
bubble in Unisphere. The alert bubble provides information about the alert and may also contain a link to a help topic on how to
resolve the problem.
Use the Unisphere CLI commands /event/log show and /event/alert/hist show to display additional event attributes
that provide more detailed event reports than what appear in Unisphere. For example:
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /event/log show -fromTime “2009-11-09
00:00:00.000” –to “2009-11-09 23:59:59.999”
uemcli -d 10.0.0.1 -u Local/joe -p MyPassword456! /event/alert/hist show

Troubleshooting 47
For detailed information about Jobs and Alerts, refer to either the Unisphere Online Help or the Unisphere Command Line
Interface User Guide.

Log information
One of the most useful logs for reviewing errors that are related to setting the file import connection or creating an import
session, or any other file import task, is /EMC/CEM/log/cemtracer_migration.log.

VNX system with two Control Stations

For a VNX system with two Control Stations, ensure that the following exists before you set up a file-based import:
● The home directory of a user with Administrator role exists on the primary Control Station of the VNX. The home directory is
used when you configure the import connection.
● When you configure other components for an import operation, the primary Control Station of the VNX that is used must be
the same Control Station as in the previous bullet item.
You can retrieve information about the primary Control Station of the VNX system using the VNX command-line interface (CLI).
The following CLI output is an example that includes SPA, SPB, and the primary Control Station.
# naviseccli -User Local/joe -Password MyPassword456! -Scope 0 -h 10.50.100.104 domain
-list

Node: APM00153042305
IP Address: 10.0.0.1
Name: hop21130
Port: 80
Secure Port: 443
IP Address: 10.0.0.2
Name: hop21131
Port: 80
Secure Port: 443
IP Address: 10.0.0.3
Name: Unity_CS0_03
Port: 80
Secure Port: 443

If the primary Control Station of the VNX does not have a user home directory, you can manually fail over the Control Station.
The following is an example set up by logging on the primary Control Station through SSH.
# /nas/sbin/cs_standby -failover

The system will reboot, do you wish to continue? [yes or no]: yes
Failing over from Primary Control Station...

For more information about this situation and how to resolve it, see Knowledge Base Article 000489181.

48 Troubleshooting
 A
NFS-only VDM import details
Topics:
• NFS-only VDM import work flow
• View NFS-only VDM import information
• File system mount options mapping
• NFS export options mapping

NFS-only VDM import work flow

Most of the NFS-only VDM import operations are executed from the target Unity storage system. However, some initial setup
operations, such as creating an import interface on the source VDM, must be executed on the source VNX system.

Prerequisites for an NFS-only VDM import session

Before starting an NFS-only VDM import session, the following conditions must be met:
1. The source VNX system exists, and the VNX1 OE is 7.1.x or later or the VNX2 OE is 8.1.x or later.
2. (Optional) The specified name for the import session is not used by other import sessions.
3. The source VDM exists, and is in the loaded state.
4. The source VDM is not under import or has an associated complete import.
5. The source VDM is not configured with CIFS servers, secured NFS, or NFSv4.
6. The maximum allowed deviation in time between the source side Data Mover (DM) that hosts the VDM and the target side
SP that hosts the target NAS server is 5 seconds.
7. There exists only one network interface whose name starts with nas_migration_xx among all the up network interfaces that
are attached to the source VDM. This interface is used as the source import interface.
8. Verify that the physical Data Mover on which the source VDM is located, has at least one IP interface configured that is not
attached to the VDM being migrated.
9. One import interface of type replication exists on the default production port of the target SP, uses the same IP protocol
(IPv4 or IPv6) and is in the same VLAN as the source import interface. The target import interface can reach the source
import interface and access all the source base exports. This interface can be auto-detected, or specified as the target
import interface.
10. The default target production port exists, and supports the type file.
11. All the specified target production ports in the interface-port pairs exist, support the type file, and are on the same SP of the
default target production port.
12. All the specified source production interfaces in the interface-port pairs exist, and are in the up state.
13. The import interface on the source must be dedicated for only the import purpose. Hosts must not use this interface for
access. Ensure it is not used for any other purpose, for example, used to export NFS exports or CIFS shares to hosts.
14. All the specified source file systems in the file system-pool pairs exist, and are valid import candidates. (These import
candidates are mounted to the source VDM, and cannot be NMFS, replication destination, root file system, raw file system,
and non-imported FLR file system.).
15. The target pool that is specified to create the target NAS server exists.
16. All the specified target pools in the file system-pool pairs exist.
17. All the specified source file systems in the target VMware data store candidate exist, and are valid import candidates.
18. There is no active import session on the SP of the default target production port.
19. If the import session is created, the total number of the import candidate source file systems cannot exceed the limit of total
file systems of all active sessions.
20. There is at least one valid source file system that is mounted on the source VDM.
21. There is at least one valid source production interface, which is up, attached to the source VDM.
22. The total number of valid source production interfaces cannot exceed the limit of network interfaces for each NAS server on
the target Unity system.

NFS-only VDM import details 49

23. The specified file systems to be imported as a VMware NFS data store should have only one export at root directory.
24. NFS export does not contain an unsupported character or characters, such as comma (,) or double quote (").
25. There are no NFS exports that were only temporarily un-exported and whose path do not exist anymore. To check
for this kind of export run the following command on the control station: nas_server -query:name==vdm147
-fields:exports -format:%q -query:IsShare==False -fields:Path,AlternateName,Options
-format:"<Path>%s</Path>\n<AlternateName>%s</AlternateName>\n%s\n" Compare the resulting list with
the ouput of server_export. If there are some differences, you must delete the old entry in the VDM in the vdm.cfg file. Do
the following:
a. Login as root on the control station.
b. Go to the root file system of the VDM (cd /nas/quota/slot_X/root_vdm_xx/.etc).
c. Edit the file vdm.cfg and remove the line corresponding to the NFS export that you want to clean (vi vdm.cfg
export "/fs4" anon=0).
d. Check that the export does not appear any more in the nas_server -query. You do not need to reboot the VDM.
26. If the source VNX system is configured with the code page 8859-1 or 8859-15 for the NFSv3 clients, ensure the code page
for the Unity system matches the code page being used on the VNX system. With Unity OE 4.3 and later, the code page of
the Unity system can be changed through the svc_nas {<NAS_server_name> | all} -param -facility vdm
-modify codepage -value <value> service command.
27. When performing a VDM import of FLR-enabled file systems, the source VNX Data Mover that is running the DHSM service
should also be configured with username and password credentials.

Change settings of an NFS-only VDM import

You can change some import settings before the import session starts or during an initial copy failed status. The changeable
parameters include:
● Pools of the target file system
● Pool of the target NAS server
● Ports of the target production interfaces
● Mobility interface for import
● Name of import session
NOTE: The import session name is not limited to an import session start or during an initial copy failed status and can be
changed at any time.
The following changes on the source system are discouraged during an import session:
● Changes to Quota settings
● NIS or LDAP configuration changes
● DNS, gateway, or routing changes
● Creating or deleting file systems
● File system level FLR properties (on either source or target systems) or epoch year on source file systems
● Retention settings of DHSM for the specific file systems
NOTE: If the source system is configured with auto delete or auto lock enabled, the target system will not enable the
respective option until the import session is committed. Also, if expired files exist on the source FLR file systems, after file
import, the expired files remain expired. However, the time they expired is not the same as before. The expired time after
file import is the time that the file was imported.
The target system cannot prevent these actions on the source system. However, these actions can result in the changes not
being imported to the target system and causing the import session to fail.

Start an NFS-only VDM import session

The import session is automatically started after creation in the Unisphere UI.
For UEMCLI or REST, the UEMCLI command and REST operation of start are shared with the same command and operation of
resume to align with the behavior of block import and replication. You can only start an import session when it is in the Initialized
state. If the import start fails, the import state is kept as Initial Copy with a Minor failure health state and the health details are
set to The migration session failed to provision target resource. At this time, you can fix the problem by
getting detailed information from the job and tasks and then resume the import session.

50 NFS-only VDM import details

The start of an import session is an asynchronous operation by default and always returns a success after creating a backend
job to run the initial copy. Before the start of the import, a pre-check is done.
In the event of an SP reboot, affected import sessions fail over to the peer SP. In the event of a system reboot, import sessions
pause and automatically resume when the system returns.

NFS-only VDM import initial copy

After the start of the import, VDM import enters the initial copy state. The initial copy consists of three sequential stages:
1. Target NAS server and file system (thin file systems) provisioning
2. Initial data copy
3. Configuration import

Target provisioning
The following is the sequence of provisioning of the NAS server and file systems (thin file systems) in the target system:
1. The import session is validated to be initialized and all parameters are set correctly.
2. The target NAS server is created in import target mode with the correct name.
3. The target file system or file systems are created in import target mode with correct names that exactly match the source
mount path.
4. The quota information is dumped from the source file system or file systems to the matching target file system or file
systems. If the file system is imported as a VMware NFS data store on Unity, quotas import dumping is skipped.
5. A private server is set up for data transfer from the source NFS server to the target SP. The source VDM exports are
updated to include the target import IP address at the file system root directory.
6. The file system level import session between source side file system and the target side file system are created and started.
7. The auto-retry mechanism is started.

Initial copy
Once the import target NAS server and file systems are provisioned, the initial copy job creates and starts the file system level
import sessions for the initial data copy between the source and target file systems. Initial copy does not enter the Configuration
Import stage until all file systems are migrated.

Configuration import
The initial copy job task continuously runs while waiting for the completion of the baseline copy. Once the baseline copy
is complete, it stops the auto-retry mechanism and starts the configuration import (configuration import task). The VDM
configuration that is imported ensures that the NAS server on the target system works correctly. The VDM configuration
includes:
● NFS export
● Network interface
● Route configuration
● IP reflect parameter
● DNS configuration
● Local file
● LDAP configuration
● NIS configuration
● UNIX Directory Service setting
● Quota configuration
Once the configuration import completes, the initial copy job prepares for cutover to reduce the overall time and the DU time for
cutting over. After the configuration import completes, the file import session enters the Ready to Cutover state. If import failed
during initial copy, the configuration import is not rolled back. You can resume the import operation after fixing the reported
issues, and import start can continue from the last point when it failed.

NFS-only VDM import details 51

NFS-only VDM import cutover
Before you run the cut over operation, ensure the following:
● The source VDM has not been deleted or renamed before cutover.
● The file system that is mounted on the source VDM has not been renamed, unmounted, or deleted.
● The source VDM interface has not been deleted or renamed.
● When migrating a VNX VDM that is using NIS, ensure that NIS connectivity is enabled before cutover.
CAUTION: The Unity system firewall can block a NAS server from connecting to a NIS server. It is highly
recommended to enable NIS connectivity before cutover. If NIS is not enabled after cutover, a host
application may not be able to access the NAS server successfully. In this case, follow the instructions
to resolve the access issue.
To resolve the NAS server access issue due to disabled NIS connectivity, enable NIS. The following example demonstrates how
to do this:
1. Query NAS server with ID nas_6: # uemcli -d localhost -sslPolicy accept -noheader -u admin -p
adminpassword /import/session/nas show

1: ID = import_1
Type = CIFS
Name = import_sess_vdm1_APM00151909181_FNM00153800463
Health state = OK (5)
State = Completed
Progress =
Source system = RS_65538
Source resource = vdm1
Target resource = nas_6
CIFS local user = cifsuser

2. Query NAS server network interface, for example, if_14: # uemcli -d localhost -sslPolicy accept
-noheader -u admin -p adminpassword /net/nas/server -id nas_6 show

1: ID = nas_6
Name = vdm1
NetBIOS name =
SP = spb
Storage pool = pool_1
Tenant =
Interface = if_14
NFS enabled = yes
NFSv4 enabled = no
CIFS enabled = no
Multiprotocol sharing enabled = no
Unix directory service = localThenNis
Health state = OK (5)

3. Query the network interface related to the port, for example, eth2 and VLAN 404: # uemcli -d localhost
-sslPolicy accept -noheader -u admin -p adminpassword /net/if -id if_14 show

1: ID = if_14
Type = file
NAS server = nas_6
Port = spb_eth2
VLAN ID = 404
IP address = 10.109.104.133

4. Add firewall rule for NIS server connection.

● Example for VLAN-enable NAS server network interface: svc_firewall -udp -add eth2.404
10.109.177.170 and svc_firewall -udp -add eth2.404 10.109.177.169
● Example for VLAN-disabled NAS server network interface: svc_firewall -udp -add eth10 1.2.3.4
When the initial copy has completed, the file import session enters the Ready to Cutover state. You can switch the production
VDM from source to target so that the target side NAS server becomes the production side with all data synchronized. The
cutover should be transparent to the users. After cutover, the NFS host clients can access the new production side without
requiring a remount.
You can launch cutover from either Unisphere, UEMCLI, or REST. Cutover starts a job, which does the following:

52 NFS-only VDM import details

1. A pre-cutover validation check.
2. Freeze the source network lock files for import. The job tries to get all the NLM data from the source VDM and import it to
the target system.
3. Freeze the source file systems (frozen file systems ignore NFS request, NFSv3 lock request, and denies NLM lock).
4. Turn down the source client interface or interfaces (public IP interface).
5. Unfreeze source file systems.
6. Turn up the target interface or interfaces (public IP interface).
7. Reclaim network lock files in the target system. The job tries to revive all imported lock files in the target system.
8. Start an incremental copy.

NFS-only VDM import incremental copy

Incremental copy starts after the cutover to the target storage system. It synchronizes any data updates in the source after
the initial data copy starts and before cutover. During the incremental copy, all data writes to target storage system are
synchronized back to the source as well to guarantee that the data is identical between the source VDM and target NAS server.
Pause and resume operations are supported during the incremental copy.

NOTE: The data change synchronized back to the source storage system cannot be paused.

During incremental copy, quota import disables online quota check. It is resumed during import committing.

NFS-only VDM import commit

When all data is synchronized between the source VDM and target NAS server, the import session enters the Ready to commit
state. You can complete the import through Unisphere or by running the commit command in UEMCLI or REST.
After the commit operation completes, the new data update on the production (target) NAS server is no longer synchronized
back to the source VDM. All import specific resources, such as NAS server, file systems, production interfaces, are cleaned up
on the target system. The exceptions to this process are the import session information and the summary report. That data is
removed when the import related source storage system is deleted from the target storage system. Because the source VDM
is obsolete, the import temporary changes on the source VDM are not cleaned up during import commit. You cannot cancel the
import session and rollback the imported NAS server to the source VDM after the import session is committed.

NFS-only VDM import pause

You can pause an import session during the Initial Copy state (internally provisioning target, initial copy, or import configuration)
and the Incremental Copy state through Unisphere, UEMCLI, or REST. This operation is useful when the network load is too
heavy. If the import session is in the Initial Copy state, the pause operation fails the job executing the Initial Copy. When the
import session is paused, the session state remains unchanged but the health state is not OK. A paused import session can be
resumed.

NFS-only VDM import resume

You can resume a paused import session through Unisphere, UEMCLI, or REST. The Resume and Start operation (resume an
initialized session) actually share the command. Similar to the Pause operation, the Resume command returns immediately, and
then the file system level import sessions resume one by one internally. The whole import session returns to the running state
when all the underlying file system import sessions are resumed. It may take a while for the import session health state to
change to the expected OK state. Use the Resume operation to restart the data transfer or configuration import when the
import session fails and the reason for the failure has been fixed.

NFS-only VDM import cancel

Any time during the import, except the cutting over and committing phase, you can decide to cancel an ongoing import session.
Depending on which state the import session is in, canceling the import session has different meanings:
● Before import start, the import session is deleted.
● After the import starts and before cutover:
○ Stops data copy

NFS-only VDM import details 53

 ○ Cleans up the copied data and imported configuration data
○ Cleans up the migrating NAS Server and file systems except the user created file systems
● After cutover and before committing:
○ Stops data copy and data sync
○ Rollbacks to source VDM
○ Cleans up the copied data and imported configuration data
○ Cleans up the importing NAS server and file systems except the user created file systems
Hosts that are created for NFS exports during the import are not cleaned up. If the user creates file systems after import
cutover, these file systems and the target NAS server are kept while the target production interfaces are removed. If the import
to the NAS server is kept due to user created file systems, the imported configuration (UNIX Directory service, DNS) is kept as
well.

View NFS-only VDM import information

You can view VDM import session information from Unisphere, UEMCLI, or REST. After an import session is created, you can
query the progress of the session from UEMCLI or REST. However, this property is only valid when the session is in the Initial
Copy phase or Incremental Copy phase:
● When the VDM import session is in the Initial Copy phase, the progress reflects the progress of the whole initial copy,
including initial data copy, configuration import, and quota configuration import.
● When the VDM import session is in the Incremental Copy phase, the progress just reflects the progress of the incremental
data copy.

Import Summary Report

The Import Summary Report provides information about the import session. The report can be downloaded during any of the
various stages of the Import process (for example, during Initial Copy, Syncing, Paused, Ready to Cutover, Ready to Commit
states, Canceled, Completed). This report can be meaningful when reviewing or troubleshooting import session progress. In
Unisphere, after creating an import session, go to More Actions > Download Summary Report, which produces a Zip file that
can be downloaded to the host system. The most relevant file from the download is the SummaryReport.html.

File system mount options mapping

Many of the mount options for VNX storage systems are not supported on Unity storage systems. Mount option mapping
between VNX and Unity maps the VNX mount options that Unity supports.

Table 1. Mount option mapping between VNX and Unity

VNX Unity Comment
mover_name vdm
fs_name description
mount_point name
Ro rw Unity always uses rw. See Ro mount option special handling.
Rw rw Unity always uses rw.

Ro mount option special handling

For Unity systems with OE version 4.3.x or earlier, if a file system is mounted on a VNX with the Ro option, the NFS exports
that are created from this file system are actually read-only to their clients. The clients although are granted read/write or root
privilege. After import, the NFS shares that are imported to the Unity system will be ro-exported. If the default access is rw or
root, it is degraded to ro (read-only). If default access is na (no access), it remains unchanged. All rw or root host entries that
are configured on these NFS shares are degraded to roHosts so that the NFS shares will still be read-only to their clients.
For example, if source VNX export option is access=<IP>, only this IP has access permission, other clients cannot access the
export. The NFS share configuration on Unity would be: defAccess=na, roHost=<IP>.

54 NFS-only VDM import details

If source VNX export option is root=<IP>, the IP has root permission, other clients have rw permission to this export. The NFS
share configuration on Unity would be: defAccess=ro, roHost=<IP>.
For Unity systems with OE version 4.4.x or later, the following enhancements have been incorporated:
● Another type of host access (Read only, allow Root) of an NFS share has been defined that does not require a host
object. However, NFS shares still support host access by registered hosts. Read only, allow Root access means hosts have
permission to view the contents of the share, but not to write to it. The root of the NFS client has root access to the share.
● Clients can be a hostname, netgroup, subnet, a DNS domain, or IP address and must be comma-separated, without spaces.
No host object is involved in this simplified host definition.
● NFS share objects can have either five hosts lists as registered hosts or five host lists as strings. A new attribute named
advHostMgmtEnabled has been added that indicates whether host lists are configured using a string or configured by
specifying the IDs of registered hosts. For the same NFS share, you can either create a host list by using a string or by
selecting registered hosts. You cannot use both methods for creating a host list. When creating a new NFS share through
CLI or from Unisphere (in a regular context), the default is to configure host lists using the IDs of registered hosts. In the
case of importing an NFS VDM from a VNX system, the imported NFS shares are created in the Unity system with hosts lists
configured with strings (because hosts lists on VNX are strings).
NOTE: For more information about settings for NFS shares, refer to the Unisphere Command Line Interface User Guide,
Unity Unisphere Online Help, and Unity Service Commands Technical Notes.

NFS export options mapping

Some of the NFS export options for VNX storage systems are not supported on Unity storage systems. NFS export option
mapping between VNX and Unity maps the VNX NFS export options that Unity supports.

Table 2. NFS export option mapping between VNX and Unity

VNX (server_export Description Unity (/stor/prov/fs/nfs)
-option)
Sec=sec AUTH_SYS(default) -minSecurity sys
ro Exports the <pathname> for all NFS clients as read-only. -defAccess ro
ro=<client>[:<client>] Exports the <pathname> for the specified NFS clients as -roHosts
... read-only.
rw=<client>[:<client>] Exports the <pathname> as read-mostly for the specified -rwHosts &&-defAccess
... NFS clients. ro
root=<client>[:<client Provides root privileges for the specified NFS clients. -rootHosts or
>]... -roRootHosts
anon=<uid> If the NFS request comes from the root (uid=0) on the host -anonUID
and the host access is ro or rw, the anonUID is used on the
NFS server as the effective user ID.
access=<client>[:<clie Provides mount access for the specified NFS clients. roHosts, rorootHosts,
nt>]... rwHosts
access=<-client>[:<- Excludes the specified NFS clients from access even if they No access
client>] are part of a subnet or netgroup that is allowed access.
ro=<-client>[:<- Excludes the specified NFS clients from ro privileges. No access
client>]
rw=<-client>[:<- Excludes the specified NFS clients from rw privileges. No access
client>]
root=<-client>[:<- Excludes the specified NFS clients from root privileges. No access
client>]
-comment Comment for the specified NFS export entry. -descr

NFS-only VDM import details 55

 B
CIFS-only VDM import details
Topics:
• CIFS-only VDM import work flow
• View CIFS-only VDM import information

CIFS-only VDM import work flow

Most of the CIFS-only VDM import operations are performed from the target Unity storage system. However, some initial setup
operations, such as creating an import interface on the source VDM, must be performed on the source VNX system.
NOTE: SMB1 must be enabled for the initial copy to start. SMB1 is a requirement for all CIFS-based migrations. You can
disable SMB1 after the migration is finished.

Prerequisites for a CIFS-only VDM import session

Before you start a CIFS-only VDM import session, the following conditions must be met:
1. The source VNX system exists, and the VNX1 OE is 7.1.x or later or the VNX2 OE is 8.1.x or later.
2. (Optional) The specified name for the import session is not used by other import sessions.
3. The source VDM exists, and is in the loaded state.
4. The source VDM is not under import or has an associated complete import.
5. The source VDM does not have any NFS exports.
6. For SMB operations, SMB1 must be enabled for the initial copy to start. SMB1 is a requirement for all CIFS-based migrations.
You can disable SMB1 after the migration is finished.
7. The maximum allowed deviation in time between the source side Data Mover (DM) that hosts the VDM and the target side
SP that hosts the target NAS server is 5 seconds.
8. There exists only one network interface whose name starts with nas_migration_xx among all the up network interfaces that
are attached to the source VDM. This interface is used as the source import interface.
9. Verify that the physical Data Mover on which the source VDM is located, has at least one IP interface configured that is not
attached to the VDM being migrated.
10. One import interface of type replication exists on the default production port of the target SP, uses the same IP protocol
(IPv4 or IPv6) and is in the same VLAN as the source import interface. The target import interface can reach the source
import interface. This interface can be autodetected, or specified as the target import interface.
11. The default target production port exists, and supports the type file.
12. All the specified target production ports in the interface-port pairs exist, support the type file, and are on the same SP of the
default target production port.
13. All the specified source production interfaces in the interface-port pairs exist, and are in the up state.
14. The import interface on the source must be dedicated for only the import purpose. Hosts must not use this interface for
access. Ensure it is not used for any other purpose, for example, used to export NFS exports or CIFS shares to hosts.
15. All the specified source file systems in the file system-pool pairs exist, and are valid import candidates. (These import
candidates are mounted to the source VDM, and cannot be NMFS, replication destination, root file system, raw file system,
and nonimported FLR file system.).
16. The target pool that is specified to create the target NAS server exists.
17. All the specified target pools in the file system-pool pairs exist.
18. All the specified source file systems in the target VMware data store candidate exist, and are valid import candidates.
19. There is no active import session on the SP of the default target production port.
20. If the import session is created, the total number of the import candidate source file systems cannot exceed the limit of total
file systems of all active sessions.
21. There is at least one valid source file system that is mounted on the source VDM.
22. There is at least one valid source production interface, which is up, attached to the source VDM.

56 CIFS-only VDM import details

23. The total number of valid source production interfaces cannot exceed the limit of network interfaces for each NAS server
on the target Unity system. See the Unity Support Matrix on Online Support for information about network interface limits
related to NAS servers.
24. A single CIFS server is configured on the source VDM.
25. C$ share is available on the source Data Mover that hosts the VDM and is not disabled or set to Read-only. The C$
share must be available, otherwise the import cannot start. If it was disabled or Read-only on the source, change the
corresponding parameters to enable it:

server_param <source_server> -facility cifs -modify admin.shareC_NotCreated -value 0

server_param <source_server> -facility cifs -modify admin.shareC_RO -value 0

NOTE: You must stop and start the service that is associated with the CIFS facility for changes to
admin.shareC_NotCreated to take effect.
26. Local SMB users are enabled on the source CIFS server.
27. The user performing the import must belong to the source local administrator group and has backup and restore privileges.
28. The extended ACL feature is enabled on the source Data Mover that hosts the VDM (parameter cifs.acl.extacl should have
bits 2, 3, and 4 set, decimal value 28). Use the following command to view the settings:

server_param <source_datamover> -facility cifs -info acl.extacl

If necessary, use the following command to change the setting:

server_param <source_datamover> -facility cifs -modify acl.extacl -value 28

29. Unknown SID feature has been enabled on the source Data Mover that hosts the VDM (parameter
cifs.acl.mappingErrorAction must be set to 0x0b, decimal value 11). Use the following command to view the settings:

server_param <source_datamover> -facility cifs -info acl.mappingErrorAction

If necessary, use the following command to change the setting:

server_param <source_datamover> -facility cifs -modify acl.mappingErrorAction -value

11

30. NT security is enabled on the source. Share and UNIX security level is not supported.
31. The source VDM is not utf8-based.
32. The source CIFS server is not a Windows NT 4.0 like CIFS server.
33. DNS is configured for the Windows domain in the case of a domain-joined CIFS server.
34. Other VDMs from the source can reach DNS and domain controller (DC) after cutover.
35. DNS and DCs are reachable on the destination after cutover.
36. If you perform a VDM import of FLR-enabled file systems, the source VNX Data Mover that is running the DHSM service
must be configured with username and password credentials.
37. Before you begin the import session, if there is tree quota that is configured on the file system, ensure that the CIFS share
path and quota directory are the same and share the same case letters. For example, if the quota tree path is /DIR1, the
CIFS share path must be /<fsname>/DIR1.

Change settings of a CIFS-only VDM import

You can change some import settings before the import session starts or during an initial copy failed status. The changeable
parameters include:
● Pools of the target file system
● Pool of the target NAS server
● Ports of the target production interfaces
● Mobility interface for import
● Name of import session
● SMB credentials used by the target system to connect to the source CIFS server.
NOTE: The import session name is not limited to an import session start or during an initial copy failed status and can be
changed at any time.

CIFS-only VDM import details 57

The following changes on the source system are discouraged during an import session:
● Changes to Quota settings
● DNS, gateway, or routing changes
● Creating or deleting file systems
● File system level FLR properties (on either source or target systems) or epoch year on source file systems
● Settings of DHSM HTTP server configuration
NOTE: If the source system is configured with auto delete or auto lock enabled, the target system will not enable the
respective option until the import session is committed. Also, if expired files exist on the source FLR file systems, after file
import, the expired files remain expired. However, the time they expired is not the same as before. The expired time after
file import is the time that the file was migrated.
The target system cannot prevent these actions on the source system. However, these actions can result in the changes not
being imported to the target system and causing the import session to fail.

Start a CIFS-only VDM import session

The import session is automatically started after creation in the Unisphere UI.
For UEMCLI or REST, the UEMCLI command and REST operation of start are shared with the same command and operation of
resume to align with the behavior of block import and replication. You can only start an import session when it is in the Initialized
state. If the import start fails, the import state is kept as Initial Copy with a Minor failure health state and the health details are
set to The migration session failed to provision target resource. At this time, you can fix the problem by
getting detailed information from the job and tasks and then resume the import session.
The start of an import session is an asynchronous operation by default and always returns a success after creating a backend
job to run the initial copy. Before the start of the import, a pre-check is done.
In the event of an SP reboot, affected import sessions fail over to the peer SP. In the event of a system reboot, import sessions
pause and automatically resume when the system returns.

Preserving stub files

If you are using the CIFS protocol, you can preserve stub files as stub files when you import from a VNX source to a Unity
destination. Preserving stub files lessens the workload when migrating data from VNX to Unity systems.

Prerequisites
Cloud Tiering Appliance (CTA) must be configured on the source VNX system. CTA must be set for file archive. If CTA is
configured on the source VNX system and a VDM import to Unity is run, all files on the associated file system are imported as
regular files. However, you can specify that stub files be preserved as stub files when they are migrated to the destination Unity
system.
You must have the following in place to preserve stub files that are migrated from VNX to Unity systems:
● A VDM on the source VNX system
● A file system and CIFS share on the VNX system
● CTA configured on the file system for archive
NOTE: This operation can only be performed using the CLI.

Steps
1. Enter the dhsmEnabled parameter on the Unity system to enable the stub preservation feature: svc_nas ALL -param
-facility imt -modify dhsmEnabled -value 1
The value 1 is set after reboot.
2. Run the following VNX command against all source file systems that contain DHSM stubs that you want to preserve after
migration: fs_dhsm -modify fsname -backup offline
For more information about the VNX command, see the VNX Command Line Interface Reference for File.
3. Set up the remote CIFS migration between the VNX and Unity systems, and create the import session.
4. After the migration cutover phase is finished, map the CIFS share on the Unity side and verify that the stub files have been
migrated.

58 CIFS-only VDM import details

5. Commit the import session.
6. Configure CTA on the Unity system if you want stub files to be archived there.

CIFS-only VDM import initial copy

After the start of the import, VDM import enters the initial copy state. The initial copy consists of three sequential stages:
1. Target NAS server and file system (thin file systems) provisioning
2. Initial data copy
3. Configuration import

Target provisioning
The following is the sequence of provisioning of the NAS server and file systems (thin file systems) in the target system:
1. The import session is validated to be initialized and all parameters are set correctly.
2. The target NAS server is created in import target mode with the correct name.
3. The target file system or file systems are created in import target mode with correct names that exactly match the source
mount path.
4. All network interfaces of the source VDM are cloned into the target NAS server. All interfaces are created in disabled mode.
5. All network routing tables relative to the source VDM interfaces are cloned at the destination.
6. (This step is only applicable when the SMB server is joined to a domain.) The DNS domain and its corresponding servers are
selected from the source VDM and set at the target NAS server. The DNS domain is selected as follow:
● The DNS domain configured at the VDM level (nsdomain).
● The DNS domain at the storage system level matching exactly the domain name of the VDM's SMB server.
In any other cases, the pre-check fails.
7. The SMB protocol is enabled on the target NAS server and the source CIFS server configuration is cloned.
NOTE: All network interfaces that are attached to the source VDM are added to the target SMB server regardless
whether they were or were not at the CIFS server of the source VDM.
8. The quota information is dumped from the source file system or file systems to the matching target file system or file
systems. If the file system is imported as a VMware FS data store on Unity, quotas import dumping is skipped.
9. Copy data of all the file systems from the source to the target file systems. The whole directory and file structure of the file
system is parsed and cloned at the destination. However, only cold data (data not modified within one hour) is copied. Data
that cannot be accessed is skipped during initial copy.
NOTE: Parsing is done only once. If files or directories are created after the parsing is done, those new nodes are
migrated during the incremental copy.
10. Local groups and users are migrated before the CIFS shares.
11. All CIFS shares of the source VDM are cloned into the target NAS server.
12. Source parameters that are migrated during migration of CIFS-only VDM include:
● acl.extAcl
● acl.restrictedTakeOwnership
● admin.shareC_NotCreated
● admin.shareC_RO
● allowSnapSureVss
● cifsclient.timeout
● LanmanServer.disableNameChecking
● LanmanServer.IdleUserAutoLogoff
● LanmanServer.MaxMpxCount
● nullSession
● ReadOnly.Comp
● ReadOnly.Delete
● set_eas_ok
● smbsigning
● srvmgr.diskdrive
● srvpwd.updtMinutes
● windowsTimeUpdate
● virtualDirName

CIFS-only VDM import details 59

 ● updateMode
● updatePTRrecord
● cacheMaxGroups
● cacheMaxHosts
● SecurityLayer
● maxNISCacheGroupsCount
● maxNISCacheUsersCount
● followabsolutpath
● followdotdot
● Traces
After the parameter values are applied, the NAS server is restarted to take the new values into account.
If import failed during initial copy, the configuration import is not rolled back. You can resume the import operation after fixing
the reported issues, and import start can continue from the last point when it failed.

CIFS-only VDM import cutover

Before you run the cut over operation, ensure the following has not occurred:
● The source VDM has not been deleted or renamed before cutover.
● The file system that is mounted on the source VDM has not been renamed, unmounted, or deleted.
● The source VDM interface has not been deleted or renamed.
● The source SMB server has not been renamed.
When the initial copy has completed, the file import session enters the Ready to Cutover state. You can switch the production
VDM from source to target so that the target side NAS server becomes the production side with all data synchronized. During
the cutover, the I/O of SMB host clients to the VDM under import will be interrupted and a short period of data unavailability
(DU) will be observed. After cutover, the SMB host clients can access the new production side without requiring a remount.
You can launch cutover from either Unisphere, UEMCLI, or REST. Cutover starts a job, which does the following:
1. A pre-cutover validation check.
2. Forces an CIFS server account password update before the cutover.
NOTE: Not applicable for a standalone CIFS server.
3. All production network interfaces of the source VDM are disabled. CIFS clients cannot access data. Only the import network
interface remains up.
NOTE: Data Unavailable (DU) time is impacted by following factors:
● Number of production client interfaces
● Number of shares
● Time to rename and join the source server
4. The local group database file, /.etc/.db.5.localgroups, is copied from the source VDM to the target NAS Server.
5. The home directory configuration, which is located in /.etc/homedir, is copied from the source VDM to the target NAS
Sever.
6. The Kerberos configuration file, /.etc/krb5.conf, and the file containing the CIFS account, /.etc/krb5.account, are copied
from the source to the target. After the cutover, regular SMB clients can have access to the SMB server at the target in the
same way as on the source.
NOTE: Not applicable for a standalone CIFS server.
7. A new CIFS share synchronization is done with the source to get any updates since the initial share migration was done at
the beginning of the initial copy phase.
8. Permission to all the source's CIFS shares is changed to deny any access. This action is taken to prevent any host access to
the source VDM data after the cutover.
9. The source CIFS server is renamed to an alternate name that is provided by the administrator.
10. The production interfaces are enabled at the target. DU ends and clients accesses are now directed to the target.
11. Start the incremental copy phase.
NOTE: Data that was not copied during initial copy phase can be accessed after the cutover. The migration process
redirects any I/O operations to non-migrated data to the source VDM, unless it is migrated.

60 CIFS-only VDM import details

CFS-only VDM import incremental copy
Incremental copy starts after the cutover to the target storage system. It synchronizes again the target with the source to
ensure that all nodes and data that were not migrated during the intial copy phase or updated after it, are migrated to the
target. During the incremental copy, all data writes to the target storage system are synchronized back to the source as well to
guarantee that the data is identical between the source VDM and target NAS server. This operation ensures data integrity, no
data loss, in case the migration session is cancelled after the cutover.
Pause and resume operations are supported during the incremental copy. However, only the incremental copy process can be
paused, data synchronizing between the target and source is always running.
During incremental copy, quota import disables online quota check. It is resumed during import committing.
To ensure that the source is always synchronized with the target (for example, to be able to cancel the migration), any change
to the target file system is first done at the source file system.
NOTE: If the modification at the source fails, the modification is not applied at the target and an error is returned to the
SMB client. If the source becomes unreachable, the user data becomes unavailable from the target.

CIFS-only VDM import commit

When all data is synchronized between the source VDM and target NAS server, the import session enters the Ready to commit
state. You can complete the import through Unisphere or by running the commit command in UEMCLI or REST.
After the commit operation finishes, the new data update on the production (target) NAS server is no longer synchronized back
to the source VDM.
All import-specific resources, such as NAS servers, file systems, and production interfaces, serve as the production environment
on the destination array. The migration session information and the summary report remain available and are removed when the
migration-related remote storage system is deleted from the array.
The exceptions to this process are the import session information and the summary report. That data is removed when the
import-related source storage system is deleted from the target storage system. Because the source VDM is obsolete, the
import temporary changes on the source VDM are not cleaned up during import commit. You cannot cancel the import session
and rollback the imported NAS server to the source VDM after the import session is committed.

CIFS-only VDM import pause

You can manually pause an import session during the Initial Copy state and Incremental Copy state through Unisphere, UEMCLI,
or REST. The whole import session is paused when all the underlying file system import sessions are paused. When the import
session is paused, the session state remains unchanged but the health state is not OK. A paused import session can be resumed.
Pause during initial copy suspends the migration of the cold data (data not modified within one hour) from the source to the
target.
Pause during incremental copy only pauses the data copy of hot data (data that changed during the baseline copy and data that
was not accessible during the Initial Copy phase). The data change to the target is still synchronized with the source so that the
target system is still usable by the SMB clients and rollback is allowed with data consistency.

CIFS-only VDM import resume

You can resume a paused import session through Unisphere, UEMCLI, or REST. The Resume and Start operation (resume an
initialized session) actually share the same command. Similar to the Pause operation, the Resume command returns immediately,
and then the file system level import sessions resume one by one internally. The whole import session returns to the running
state when all the underlying file system import sessions are resumed. It may take a while for the import session health state
to change to the expected OK state. Use the Resume operation to restart the data transfer or configuration import when the
import session fails and the reason for the failure has been fixed.

CIFS-only VDM import cancel

Any time during the import, except the cutting over and committing phase, you can decide to cancel an ongoing import session.
Depending on which state the import session is in, canceling the import session has different meanings:

CIFS-only VDM import details 61

● Before import start, the import session is deleted.
● After the import starts and before cutover:
○ Stops data copy
○ Cleans up the copied data and imported configuration data
○ Cleans up the migrating NAS Server and file systems except the user created file systems
NOTE: CIFS clients still access the source and the source configuration is intact.
● After cutover and before committing, the SMB migration synchronizes back to the source some configuration changes made
at the target after the cutover:
○ All network interfaces are disabled at the target. The DU starts from there.
○ All file system data migration is stopped. The data on the source file system are in synchronization with the data on the
target file system.
○ The SMB server Active Directory (AD) account is copied back to the source. The source can reuse the AD account
without any change in AD.
○ The CIFS server at the source is renamed to the production name of the CIFS server. There is no join. The CIFS can
reuse the AD account without any change.
NOTE: Since AES256 is not supported on the VNX, regular CIFS clients may need to clear their kerberos cache (klist
purge) to be able to re-connect.
○ The home directory file at the target is copied back to the source.
○ Any add, delete, or update of shares done at the target during the incremental copy, are propagated back to the source
(including Access Control List (ACL)). There are several limitations relative to Distributed File System (DFS):
￭ Only DFS links of pre-existing DFS shares at the source are synced.
￭ DFS shares that are created during incremental copy will be non DFS on source.
￭ DFS shares that were DFS at the source will stay DFS
○ Re-enable all production interfaces at the source.
○ The source VDM is restarted to take all configuration updates into account. The DU ends at the end of this step.
○ The NAS server and file systems at the target are deleted.
NOTE: The import session is not destroyed to keep access to the downloadable import report.

If the user creates file systems after import cutover, these file systems and the target NAS server are kept while the target
production interfaces are removed.

View CIFS-only VDM import information

You can view VDM import session information from Unisphere, UEMCLI, or REST. After an import session is created, you can
query the progress of the session from UEMCLI or REST. However, this property is only valid when the session is in the Initial
Copy phase or Incremental Copy phase:
● When the VDM import session is in the Initial Copy phase, the progress reflects the progress of the whole initial copy,
including initial data copy, configuration import, and quota configuration import.
● When the VDM import session is in the Incremental Copy phase, the progress just reflects the progress of the incremental
data copy.

Import Summary Report

The Import Summary Report provides information about the import session. The report can be downloaded during any of the
various stages of the Import process (for example, during Initial Copy, Syncing, Paused, Ready to Cutover, Ready to Commit
states, Canceled, Completed). This report can be meaningful when reviewing or troubleshooting import session progress. In
Unisphere, after creating an import session, go to More Actions > Download Summary Report, which produces a Zip file that
can be downloaded to the host system. The most relevant file from the download is the SummaryReport.html.

62 CIFS-only VDM import details

 C
Multiprotocol VDM import details
Topics:
• Prerequisites for a multiprotocol VDM import session
• Multiprotocol VDM import workflow

Prerequisites for a multiprotocol VDM import session

Conditions must be met before starting a multiprotocol VDM import session.
NOTE: For SMB operations, SMB1 must be enabled for the initial copy to start. SMB1 is a requirement for all CIFS-based
migrations. You can disable SMB1 after the migration is finished.
Those conditions include the following:
1. The VNX1 OE is 7.1.x or later, or the VNX2 OE is 8.1.x or later.
2. (Optional) The specified name for the import session is not used by other import sessions.
3. The source VDM exists, and is in the loaded state.
4. The source VDM is not under import or has an associated complete import.
5. The source VDM is configured for multiprotocol imports.
NOTE: If the source VDM has NFS exports and a CIFS server that is enabled, you can migrate the VDM even if there
are no CIFS shares. A single CIFS server must be configured on the VDM to allow multiprotocol imports to occur.
6. The user performing the import must belong to the source local Administrator group and have backup and restore privileges.
7. The maximum allowed deviation in time between the source side Data Mover (DM) that hosts the VDM and the target side
SP that hosts the target NAS server is 5 seconds.
8. There must be one network interface whose name starts with nas_migration_xx among all the up network interfaces
that are attached to the source VDM. This interface is used as the source import interface.
9. Verify that the physical Data Mover on which the source VDM is located, has at least one IP interface configured that is not
attached to the VDM being migrated.
10. One import interface of type replication exists on the default production port of the target SP, uses the same IP protocol
(IPv4 or IPv6) and is in the same VLAN as the source import interface. The target import interface can reach the source
import interface and access all the source base exports. This interface can be autodetected, or specified as the target
import interface.
11. The default target production port exists, and supports the type file.
12. All the specified target production ports in the interface-port pairs exist, support the type file, and are on the same SP of the
default target production port.
13. All the specified source production interfaces in the interface-port pairs exist, and are in the up state.
14. The import interface on the source must be dedicated for only the import purpose. Hosts must not use this interface for
access. Ensure that the import interface is not used for any other purpose; for example, migrating NFS-only exports or
CIFS-only shares to hosts.
15. The extended ACL feature must be enabled on the source Data Mover that hosts the VDM.
16. The DNS must be configured in the Windows domain.
17. The NT security must be enabled on the source VDM.
NOTE: Share and UNIX-level security levels are not supported.
18. All the specified source file systems in the file system-pool pairs exist, and are valid import candidates. (These import
candidates are mounted to the source VDM, and cannot be NMFS, replication destination, root file system, raw file system,
and nonimported FLR file system.).
19. The target pool that is specified to create the target NAS server exists.
20. All the specified target pools in the file system-pool pairs exist.
21. All the specified source file systems in the target VMware data store candidate exist, and are valid import candidates.
22. There is no active import session on the SP of the default target production port.

Multiprotocol VDM import details 63

23. If the import session is created, the total number of the import candidate source file systems cannot exceed the limit of total
file systems of all active sessions.
24. There is at least one valid source file system that is mounted on the source VDM.
25. There is at least one valid source production interface, which is up, attached to the source VDM.
26. The total number of valid source production interfaces cannot exceed the limit of network interfaces for each NAS server on
the target Unity system.
27. The specified file systems to be imported as a VMware NFS data store should have only one export at root directory.
28. NFS export does not contain an unsupported character or characters, such as comma (,) or double quote (").
29. There are no NFS exports that were only temporarily unexported and whose path does not exist anymore. To check
for this kind of export run the following command on the control station: nas_server -query:name==vdm147
-fields:exports -format:%q -query:IsShare==False -fields:Path,AlternateName,Options
-format:"<Path>%s</Path>\n<AlternateName>%s</AlternateName>\n%s\n" Compare the resulting list with
the output of server_export. If there are some differences, you must delete the old entry in the VDM in the vdm.cfg file. Do
the following:
a. Log in as root on the control station.
b. Go to the root file system of the VDM (cd /nas/quota/slot_X/root_vdm_xx/.etc).
c. Edit the file vdm.cfg and remove the line corresponding to the NFS export that you want to clean (vi vdm.cfg
export "/fs4" anon=0).
d. Check that the export does not appear anymore in the nas_server -query. Do not reboot the VDM.
30. If the source VNX system is configured with the code page 8859-1 or 8859-15 for the NFSv3 clients, ensure that the code
page for the Unity system matches the code page being used on the VNX system. With Unity OE 4.3 and later, the code
page of the Unity system can be changed through the svc_nas {<NAS_server_name> | all} -param -facility
vdm -modify codepage -value <value> service command.
31. When you perform a VDM import of FLR-enabled file systems, the source VNX Data Mover that is running the DHSM service
should also be configured with username and password credentials.

Multiprotocol VDM import workflow

Most VDM import operations are run from the target Unity storage system. However, some initial setup operations, such as
creating an import interface on the source VDM, must be completed on the source VNX system. Multiprotocol access must be
enabled on the source VDM on the source VNX system.

Multiprotocol configuration imports

When using multiprotocol migration to move VDM files from a VNX1 or VNX2 storage system to a Unity system, you can also
import the following configurations:
● Access policies (with restrictions)
● Rename policies for each file system
● File lock policies for each file system
● Server parameters for the Data Mover or each VDM
● UserMapper settings
● Configurations for ntxmap

Multiprotocol access policy mapping

VNX access policies are mapped to three types of access policies in Unity.

NOTE: Access policies differences can affect client access during migration.

Multiprotocol migration does not support the following:

● NT to UNIX
● UNIX to Windows
The following table shows the range of access policies that are set on both the source and target sides when migrating VDMs
from VNX to Unity:

NOTE: Non-default mapping is not supported.

64 Multiprotocol VDM import details

VNX access policy Unity access policy
Native Native
NT Windows
UNIX UNIX
Secure Native
MIXED Windows
MIXED_COMPAT Native

Multiprotocol renaming policies

You can select a renaming policy for a multiprotocol file migration. This policy controls the circumstances under which NFS and
CIFS clients can rename a directory.
You can select one of three policy naming policies when migrating VNX systems to Unity:

VNX Unity
NO allowedAll
All NFS and SMB clients can rename directories without any
restrictions.

CIFS (default) forbiddenSmb (default)

Only NFS clients can rename directories without any
restrictions. If at least one file is opened in the directory or
in one of its subdirectories, an SMB client cannot rename a
directory.

FULL forbiddenAll
If at least one file is opened in the directory or in one of
its subdirectories, NFS and SMB clients cannot rename a
directory.

Multiprotocol lock policy

You can migrate the lock policy for each file system from VNX to Unity.
This policy controls whether CIFS and NFSv4 range locks must be honored. In NFSv2 and NFSv3, the locking policies are
advisory but not mandatory. If the locking policy is not defined, nolock is the default setting for VNX and mandatory is the
default setting for Unity.
The following table describes NFS client policy locking rules for VNX:

Locking policy NFS clients

nolock (default) This policy enables you to open and write to a file CIFS or
NFSv4 clients have locked.
wlock This policy enables you to read but not write data to a file that
CIFS or NFSv4 clients have locked.
rwlock This policy does not allow you to read or write data to a file
that CIFS or NFSv4 clients have locked.

VNX-to-Unity lock policy mapping

The following table describes lock policy-mapping rules when migrating from VNX to Unity:

Multiprotocol VDM import details 65

VNX Unity
rwlock or wlock mandatory (default)
This policy uses the SMB and NFSv4 protocols to manage
range locks for a file that is in use by another user. If there
is concurrent access to the same locked data, a mandatory
locking policy prevents data corruption.

nolock (default) Advisory

This policy reports that a range lock conflict when a request
is made, but it does not prevent the access to the file.
This policy allows NFSv2 and NFSv3 applications that are
not range-lock-compliant to continue working, but risks data
corruption if there are concurrent writes.

Multiprotocol server parameter checks

You can migrate server parameters for the Data Mover or for each VDM when migrating from VNX to Unity systems.
NOTE: If the current value of the Data Mover server parameter differs between the source and destination side, migration
creation fails. An error message mapped to this parameter is displayed.

Parameter Description Error and Warning Message

cifs.admin.adminsAreRoot When set to true, admins have root Server parameter error: Parameter
group access on Data Mover. <facilityname.parametername>'
s value on source(<source
The default is true ion VNX and Unity.
value>) is different from it
on destination(<destination
value>).
cifs.quotas.queryNames When set to false, do not use Server parameter error: Parameter
NIS or local files to query user and <facilityname.parametername>'
group names. Use only secmap and s value on source(<source
usermapper, if enabled. value>) is different from it
on destination(<destination
The default is false on VNX and Unity. value>).
nfs.NTcred.LDAP When set to true, enable LDAP instead Server parameter error: Parameter
of SAM for group membership reading. <facilityname.parametername>'
s value on source(<source
The default is false on VNX and Unity.
value>) is different from it
on destination(<destination
value>).
cifs.secmap.enable Control the CIFS Secure Mapping cache Server parameter error: Parameter
state. <facilityname.parametername>'
s value on source(<source
The default is true on VNX and Unity.
value>) should be set 1.
This parameter cannot be changed on
Unity.

cifs.acl.noGidMapping When set to true, all Group SIDs in Server parameter warning:
ACLs are mapped to the credential GID, Global parameter
except the primary GID, which allows use <facilityname.parametername>
of the Quotas Group. will not be migrated, and
it should be 1 on VNX.
The default is false on VNX and Unity. Please, set it manually
This parameter cannot be changed on via .server_config command,
Unity. such as; .server_config
[DM_name] -v "param cifs
acl.noGidMapping=1".

66 Multiprotocol VDM import details

Parameter Description Error and Warning Message
cifs.ntCreate.badSD Define how to handle an NT create Server parameter warning:
request with a bad SD (reject, drop, Global parameter
none).0=drop, 1=reject, 2=none <facilityname.parametername>
The VNX and Unity default is reject. will not be migrated, and
it can't be 2 on Unity.
Please, set it manually via
svc_nas script. Current Unity
value: <destination current
value>; default Unityvalue:
<destination default value>

Multiprotocol UserMapper import

You can migrate the configuration for UserMapper from VNX to Unity.
UserMapper is a VNX service that automatically maps distinct Windows users and groups to distinct UNIX-style UIDs and GIDs.
The database that UserMapper uses on the source VDM is not migrated to the target Unity system. If the source VDM has
UserMapper enabled, the target NAS Server has the corresponding user mapping service enabled.
The UID and SID-mapping information that is maintained on the files or directories is migrated to the target Unity system. This
mapping information is also inserted into the target Unity SECMAP. Unity automatic mapping for unmapped Windows accounts
automatically generates and assigns a unique UID to Windows users.
Unity displays automatic mapping as either enabled or disabled. You can determine whether UserMapper is enabled on the
source VDM by running the server_cifs command on the VNX system.

Multiprotocol ntxmap migration

You can migrate the ntxmap configuration from VNX to Unity when performing a multiprotocol migration. The ntxmap
configuration file enables you to map together UNIX accounts and Windows accounts that have different usernames.
If the ntxmap.conf file exists on the VNX source VDM with the VDM domain configuration enabled, or the ntxmap.conf
file exists on the VNX source Data Mover with the VDM domain configuration disabled, that file is migrated to the target Unity
system.

Multiprotocol LDAP with Kerberos migration

If Kerberos authentication is used for the LDAP-based directory service on the VNX source and the Kerberos account is a CIFS
computer name, the LDAP configuration is migrated to the target Unity system.

Change settings of a multiprotocol VDM import

You can change some import settings before the multiprotocol import session starts or during an initial copy failed status. The
changeable parameters include:
● Pools of the target file system
● Pool of the target NAS server
● Ports of the target production interfaces
● Mobility interface for import
● Name of import session
NOTE: The import session name is not limited to an import session start or during an initial copy failed status and can be
changed at any time.
The following changes on the source system are discouraged during an import session:
● Changes to quota settings on both the source and destination systems
The only exception would be if you see a quota exceed error.

Multiprotocol VDM import details 67

● NIS or LDAP configuration changes
● DNS, gateway, or routing changes
● Creating or deleting file systems
● File system level FLR properties (on either source or target systems) or epoch year on source file systems
● Retention settings of DHSM for the specific file systems
NOTE: You must turn off the auto delete or auto lock features when migrating VDM and file system.

If expired files exist on the source FLR file systems, after file import, the expired files remain expired. However, the time they
expired is not the same as before. The expired time after file import is the time that the file was imported.
The target system cannot prevent these actions on the source system. However, these actions can result in the changes not
being imported to the target system and causing the import session to fail.

Start a multiprotocol VDM import session

The import session is automatically started after creation in the Unisphere UI.
The UEMCLI command and REST operation of start are shared with the same command and operation of resume. This shared
command and operation aligns with the behavior of block import and replication.
You can only start an import session when it is in the Initialized state. If the import start fails, the import state is kept as
Initial Copy with a Minor failure health state, and the health details are set to The migration session failed to
provision target resource. You can fix the problem by getting detailed information from the job and tasks and then
resume the import session.
The start of an import session is an asynchronous operation by default. This operation always returns a success after creating a
backend job to run the initial copy. Before the start of the import, a precheck is done.
If an SP reboots, the affected import sessions fail over to the peer SP. If a system reboots, the import sessions pause and
automatically resume when the system returns.

Multiprotocol VDM initial copy

After the start of the import operation, the VDM import enters the initial copy state. The initial copy consists of three sequential
stages:
1. Target NAS server and file system (thin file systems) provisioning
2. Initial data copy
3. Configuration import
If the import operation failed during initial copy, the configuration import is not rolled back. You can resume the import operation
after fixing the reported issues, and the import can continue from the last point at which it failed.
If a path is longer than 1024 bytes, the initial copy uses NFS to perform the migration.

Multiprotocol VDM import cutover

Before you run the cutover operation, ensure that the following has not occurred:
● The source VDM has not been deleted or renamed before cutover.
● The file system that is mounted on the source VDM has not been renamed, unmounted, or deleted.
● The source VDM interface has not been deleted or renamed.
● The source NFS and SMB servers have not been renamed.
For SMB, when the initial copying has finished, the file import session enters the Ready to Cutover state. You can switch
the production VDM from source to target so that the target side NAS server becomes the production side with all data
synchronized. During the cutover, the I/O of the SMB host clients to the VDM under import is interrupted. A short period of
data unavailability (DU) occurs. After cutover, the SMB host clients can access the new production side without requiring a
remount.
For NFS, if the destination and source IP addresses are the same, the NFS hosts can access the new production side without
requiring a remount. However, if the destination IP address changes before cutover, NFS clients must be remounted to access
the production side.
You can launch cutover from either Unisphere, UEMCLI, or REST. Cutover starts a job, which does the following:

68 Multiprotocol VDM import details

1. Perform a pre-cutover validation check.
2. Stop responding the source network lock files for import.
The job tries to get all the NLM data from the source VDM and import it to the target system.
3. Freeze the source file systems.
4. Turn down the source client interface or interfaces.
5. Unfreeze the source file systems.
6. Reclaim network lock files in the target system.
The job tries to revive all imported lock files in the target system.
7. Start an incremental copy.

Multiprotocol VDM incremental copy

Incremental copy starts after the cutover to the target storage system. It synchronizes any data updates in the source after the
initial data copy starts and before cutover.
During the incremental copy phase, all data writes to target storage system are synchronized back to the source. This
synchronization back to the source guarantees that the data is identical between the source VDM and target NAS server.
Pause and resume operations are supported during the incremental copy.

NOTE: Not all permission changes are synced back to the source due to different access policies.

During incremental copy, quota import disables online quota check. It is resumed during the import commit.

NOTE: The data change synchronization back to the source storage system cannot be paused.

Multiprotocol VDM import commit

When all data is synchronized between the source VDM and target NAS server, the import session enters the Ready to commit
state. You can complete the import through Unisphere or by running the commit command in UEMCLI or REST.
After the commit operation completes, the new data update on the production (target) NAS server is no longer synchronized
back to the source VDM. All import-specific resources, such as the NAS server, file systems, and production interfaces on the
target system serve as the production environment.
The exceptions to this process are the import session information and the summary report. That data is removed when the
import-related source storage system is deleted from the target storage system.
Because the source VDM is obsolete, the import temporary changes on the source VDM are not cleaned up during import
commit. You cannot cancel the import session and rollback the imported NAS server to the source VDM after the import session
is committed.

Multiprotocol VDM import pause

You can pause an import session through Unisphere, UEMCLI, or REST. You can pause the session during the Initial Copy state
(internally provisioning target, initial copy, or import configuration) and the Incremental Copy state.
This operation is useful when the network load is too heavy. If the import session is in the Initial Copy state, the pause operation
fails the job that is running the Initial Copy. When the import session is paused, the session state remains unchanged but the
health state is not OK. A paused import session can be resumed.

Multiprotocol VDM import resume

You can resume a paused import session through Unisphere, UEMCLI, or REST. The Resume and Start operation (resume an
initialized session) share the command.
Similar to the Pause operation, the Resume command returns immediately, and then the file system level import sessions resume
one by one internally. The whole import session returns to the running state when all the underlying file system import sessions
are resumed.

Multiprotocol VDM import details 69

It might take several minutes or longer for the import session health state to change to the expected OK state. Use the Resume
operation to restart the data transfer or configuration import when the import session fails and the reason for the failure has
been fixed.

Multiprotocol VDM import cancel

You can cancel an ongoing migration session anytime except during the cutting-over and committing phases.
Depending on which state the migration session is in, canceling the migration session produces different results:
● Before the import session starts, a migration cancel deletes the import session.
● If the import session has begun but cutover has not finished, a migration cancel performs the following actions:
○ Stops data copying
○ Cleans up the copied data and imported configuration data
○ Cleans up the migrating NAS Server and file systems except the user-created file systems
● After cutover, and before the import session enters the Ready to Commit state, a migration cancel performs the following
actions:
○ Stops data copy and data sync
○ Rolls back to the source VDM
○ Cleans up the copied data and migrated configuration data
○ Cleans up the migrating NAS server and file systems, except for the user-created file systems
If the migration has been started and canceled, the migration session is not removed to allow the system to keep historical data.
This data is kept until the remote storage system is deleted. After the migration cancel is completed, the following occurs:
● The NAS server and file systems at the target system are deleted.
● The destination client network interfaces are removed.
● The source VDM is restarted to take all configuration updates into account.
NOTE: If any source or destination production interfaces are missing before the migration is canceled, the cancel operation
still succeeds without reporting errors.

70 Multiprotocol VDM import details

 D
LUN or Consistency Group of LUNs import
details
Topics:
• LUN or Consistency Group of LUNs import work flow

LUN or Consistency Group of LUNs import work flow

All LUN or Consistency Group (CG) import operations are executed from the target Unity storage system.

Prerequisites for a LUN or CG import session

Before starting a LUN or CG import session, the following conditions must be met:
1. The source VNX system exists, and the VNX1 Block OE is 5.32.x or later or the VNX2 Block OE is 5.33.x or later.
2. (Optional) The specified name for the import session is not used by other import sessions.
3. SAN Copy is enabled on the source VNX system.
4. The source LUN or CG exists.
5. The source LUN or CG is not under import or has an associated complete import.
6. Depending on the type of import connection that is used between the source and target systems:
● For an import using an FC-based connection, FC ports are cabled and ports zoning is configured between the VNX and
Unity storage systems.
NOTE: Avoid ports that are used for host traffic and MirrorView. On the VNX, SAN Copy and MirrorView configured
on the same ports do not operate. Import connections cannot be configured. Configure and cable the source SPA
FC_1 and SPB FC_1 ports to the target SPA FC_1 and SPB FC_1 ports for SAN Copy. Also, avoid ports that are used
for synchronous replication.
● For an import using an iSCSI-based connection, iSCSI interfaces are configured on both the source and target systems.
○ Configure iSCSI IP interfaces on SPA and SPB on the source system. Avoid MirrorView reserved iSCSI ports for block
import iSCSI interfaces.
○ Configure iSCSI IP connections between the source and target systems and verify the connection configuration.
● Once the import connections are created, the following has occurred:
○ Management IP connectivity and VNX Admin credentials are verified.
○ VNX SAN Copy FC or iSCSI initiators are discovered and registered.
○ All block resources on the source system that are eligible for import are discovered.
NOTE: The discovered objects and their relationships persist.
7. A reserved LUN pool (RLP) is configured:
NOTE: The size of the RLP LUN created for a source LUN is recommended to be 20% of the size of the source LUN.

● For the import of a single LUN, one RLP LUN is configured.

● For the import of a CG of LUNs, one RLP LUN is configured for each LUN in the CG.
NOTE: An RLP LUN is not tagged to a source LUN for a specific feature. When an RLP LUN is added to an RLP that is
intended for a source LUN, it is possible that a completely different SnapView or other SAN Copy session can consume
the newly added RLP LUN. It is recommended that other features like SnapView and MirrorView/A are stopped during
import.
8. Configure hosts on the target system the same as the hosts or storage groups on the source system.
NOTE: For iSCSI hosts, the hosts should log in to the target system to register the host initiators on the target system.

LUN or Consistency Group of LUNs import details 71

Start a LUN or CG import session
The import session is automatically started after creation in the Unisphere UI.
For UEMCLI or REST, the UEMCLI command and REST operation of start are shared with the same command and operation
of resume to align with the behavior of VDM import and replication. If the import start fails, the import state is kept as Initial
Copy with a Minor failure health state and the health details being set to The import session failed to provision
target resource. At this time, you can fix the problem by getting detailed information from the job and tasks and then
resume the import session.
The start of an import session is an asynchronous operation by default and always returns a success after creating a backend
job to run the initial copy. Before the start of the import, a pre-check is done.
In the event of a system reboot, import sessions are paused and resume automatically when the system returns. Affected LUNs
may fail over to the peer SP. If a LUN is failed over, it would need to be failed back and the session resumed.

LUN or CG import initial copy

When the import session starts, it enters the initial copy state. The target resource (LUN or CG) is automatically created on the
selected target pool from the respective source LUN or CG and balanced between the target SPs. The SAN Copy limits that are
configured on the source system are used to schedule syncs:
1. From the current SP of the LUN or LUNs in the import session, separate lists are created for SPA and SPB LUNs from which
to find the counts for each SP.
2. If there are available differential sync slots from the concurrent SAN Copy sync limits, the slots are allocated so from SPA
and SPB and the session is changed from the Pending to Syncing state.
NOTE: Once slots from SPA and SPB are allocated to an import session, no other session can take those slots until
either the session is canceled or completed. If the session is canceled or completed, the slots are distributed to either
existing sessions (if they can benefit from it) or new pending sessions.
3. Once the import session reaches below the cutover threshold (percentage of data remaining to be copied), the session is
changed from the Syncing to Ready for Cutover state.

LUN or CG import cutover

When the initial copy has completed, the LUN or CG import session enters the Ready to Cutover state. Before you run the
cutover operation, ensure that the import session exists and is in the Cutover Ready state.
You can launch cutover from either Unisphere, UEMCLI, or REST. Cutover starts a job, which does the following:
● Host access on VNX Source system for source LUN or LUNs is disabled for all hosts by removing source LUN or LUNs from
Host SGs.
NOTE: It is required that all Host I/O be paused before cutover is issued.
● Differential sync for SAN Copy session is run to sync the last delta.
● SAN Copy session is deleted.
● Host access to target LUN or LUNs is enabled for the selected hosts that are configured on the target system.

72 LUN or Consistency Group of LUNs import details