• CIFS-only VDM import details

    PDF

    CIFS-only VDM import details

    CIFS-only VDM import work flow

    Most of the CIFS-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 a CIFS-only VDM import session

    Before starting 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. 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. 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. Refer to the Unity Support Matrix on Online Support for information about network interface limits related to NAS servers.
    23. A single CIFS server is configured on the source VDM.
    24. 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
                                
      You must stop and start the service associated with the CIFS facility for changes to admin.shareC_NotCreated to take effect.
    25. Local SMB users are enabled on the source CIFS server.
    26. The user performing the import must belong to the source local administrator group and has backup and restore privileges.
    27. 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
                                
    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
                                
    29. NT security is enabled on the source. Share and Unix security level is not supported.
    30. The source VDM is not utf8-based.
    31. The source CIFS server is not a Windows NT 4.0 like CIFS server.
    32. DNS is configured for the Windows domain in the case of a domain joined CIFS server.
    33. Other VDMs from the source can reach DNS and domain controller (DC) after cutover.
    34. DNS and DCs are reachable on the destination after cutover.
    35. 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 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.
    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
    • 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
    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.

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

    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.

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

    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:

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