Table Of Contents

Using the DMM CLI for Data Migration

About DMM CLI Commands

Selecting Ports for Server-Based Jobs

Configuring Data Migration Using the CLI

Configuring the Virtual Initiator (Storage-Based Migration)

Creating the Data Migration Job

Configuring the Job

Committing the Job

Configuring the Peer SSM

Configuring Sessions

Server-Based Migration Example

Storage-Based Migration Example

Controlling DMM Jobs

Monitoring DMM Jobs

Completing DMM Jobs

(Optional) Verifying the Completed Job

Post-Migration Activities

Finishing the Job

Deleting the Job

Using the DMM CLI for Data Migration

---

This chapter describes how to use DMM CLI commands to configure and monitor data migration jobs.

This chapter includes the following sections:

•About DMM CLI Commands, page 7-1

•Selecting Ports for Server-Based Jobs

•Configuring Data Migration Using the CLI

•Controlling DMM Jobs

•Monitoring DMM Jobs

•Completing DMM Jobs

About DMM CLI Commands

The DMM feature includes CLI commands to configure and perform data migration jobs. Job and session configuration commands are entered at the switch CLI prompt.

A DMM job can be active on more than one switch. For example, in a dual-fabric topology with multipath configurations, the DMM job runs on a switch in each fabric. To configure the job, you enter DMM CLI commands on both switches.

The DMM feature runs on an SSM in the switch. Each session runs on only one SSM. Enter the session configuration commands on the MDS switch that will perform the session migration.

The DMM show commands are accessed directly from the SSM. From the command prompt in the switch, you must attach to the SSM module before entering these commands.

When using the DMM CLI commands, note the following guidelines:

•In DMM job configuration mode, the job configuration is not saved until you enter the commit command. If you exit DMM configuration mode without issuing the commit command, all job configuration changes are discarded. You only need to enter the commit command when configuring a new job.

•For a storage-based migration, all servers that use the selected storage enclosure must use the same operating system (for example, all AIX or all Solaris).

•If the MDS switch (hosting the storage or the server) performs a restart after the migration but before the job is destroyed, you must restart the data migration from the beginning.

Selecting Ports for Server-Based Jobs

When creating a server-based migration job, you must include all possible paths from the server HBA ports to the LUNs being migrated. This is because all writes to a migrated LUN need to be mirrored to the new storage until the cutover occurs, so that no data writes are lost.

For additional information about selecting ports for server-based jobs, refer to the "Ports to Include in a Server-Based Job" section on page 6-4.

Configuring Data Migration Using the CLI

When you enter the command to create a data migration job, the CLI enters DMM job configuration submode. This submode provides commands to configure the server HBA ports, storage ports, and job attributes. The job is only created on the SSM when you enter the commit command.

In a dual-fabric topology with redundant paths, the data migration job runs on an SSM in each fabric. You need to configure the job on both SSMs.

In this chapter, the examples and command descriptions use the following terminology (see Figure 7-1):

•The dual fabric configuration includes Fabric 1 and Fabric 2.

•Switch A (on Fabric 1) contains the SSM for data migration jobs.

•Switch B (on Fabric 2) contains the SSM for data migration jobs.

•H1 and H2 are the server HBA ports to each fabric.

•ES1 and ES2 are the existing storage ports.

•NS1 and NS2 are the new storage ports.

Figure 7-1 Example Topology

The steps to configure a data migration job are described in the following sections:

•Configuring the Virtual Initiator (Storage-Based Migration)

•Creating the Data Migration Job

•Configuring the Job

•Committing the Job

•Configuring the Peer SSM

•Configuring Sessions

•Server-Based Migration Example

•Storage-Based Migration Example

Configuring the Virtual Initiator (Storage-Based Migration)

---

Note This step is not required for a server-based data migration job.

---

Prior to creating a storage-based data migration job, you must retrieve the virtual initiator (VI) port world wide name (pWWN) and create a new zone containing the pWWNs of the VI and the storage ports. To use the new zone, add the new zone to a zoneset and activate the zoneset.

To configure the VI in Fabric 1, follow these steps:

Step	Command	Comments
Step 1	switchA# configuration terminal	Enters configuration mode.
Step 2	switchA(config)# dmm module module-id job job-id get-vi vsan 0-4093	Retrieves the VI information for the specified SSM module. You must specify a unique job identifier. The command output displays the assigned VI node WWN and port WWN.
Step 3	switchA(config)# zone name name vsan 0-4093	Creates a new zone.
Step 4	switchA(config-zone)# member pwwn value	Uses the member command multiple times to add the VI pWWN, the existing storage pWWNs, and the new storage pWWNs.
Step 5	switchA(config-zone)# exit	Exits zone configuration submode.
Step 6	switchA(config)# zoneset name name vsan 0-4093	Enters configuration mode for the active zoneset. Specify the name of the active zoneset.
Step 7	switchA(config-zoneset)# member name	Adds the named zone to the zoneset.
Step 8	switchA(config-zoneset)# exit	Exits zoneset configuration submode.
Step 9	switchA(config)# zoneset activate name name vsan 0-4093	Reactivates the zoneset.

Prior to creating the data migration job, you must complete the following configuration tasks on the storage devices:

1. Configure the existing storage to give the VI pWWN access to LUNs that need to be migrated.

2. Configure the new storage to give the VI pWWN access to LUNs that need to be migrated.

---

Note For a dual-fabric topology, you must repeat the same set of configuration steps on switch B. Retrieve the VI information and create a new zone on switch B and configure the storage to allow the VI to access the LUNs exposed in fabric B. For an example configuration, see the "Storage-Based Migration Example" section.

---

Creating the Data Migration Job

To configure a data migration job, first create the job on Switch A. After creating the job, the CLI enters DMM job configuration mode, where you enter the commands for configuring the job.

To create the data migration job, follow these steps:

Step	Command	Comments
Step 1	switchA# configuration terminal	Enters configuration mode
Step 2	switchA(config)# dmm module module-id job job-id create	Creates a migration job on the specified SSM module and enters DMM job configuration mode. Specify a unique job identifier. For a storage-based job, use the same job identifier that you specified when retrieving the VI information (in the previous task).

Configuring the Job

Use the commands in DMM job configuration mode to add the server and storage ports to the job.

---

Note To prevent data corruption, the job must contain all the server HBA ports that can access the set of LUNs being migrated, and all storage ports that expose these LUNs:

•Add all server HBA ports in this fabric that can access the LUNs being migrated.

•Add all storage ports in the fabric that expose the set of LUNs being migrated.

For additional information, see the "Checking Storage ASL Status" section on page 3-2.

---

In a dual-fabric topology, configure the IP address of the peer SSM (the DMM peers communicate using the management IP network).

Configure the data migration job using the following steps:

Step	Command	Comments
Step 1	switchA(config-dmm-job)# server vsan 0-4093 pwwn pWWN	Specifies the VSAN and pWWN of the server HBA port to include in the migration. Note All server HBA ports (in fabric 1) that can access the LUNs to be migrated need to be added to this job.
Step 2	switchA(config-dmm-job)# storage vsan 0-4093 pwwn pWWN existing	Specifies the VSAN and pWWN of the existing storage port. Note All existing storage ports (in fabric 1) that expose the LUNs to be migrated need to be added to this job.
Step 3	switchA(config-dmm-job)# storage vsan 0-4093 pwwn pWWN new	Specifies the VSAN and pWWN of the new storage port. Note All new storage ports (in fabric 1) that expose the new LUNs need to be added to this job.
Step 4	switchA(config-dmm-job)# attributes job_type {1 | 2} job_mode {1 | 2} job_rate {1 | 2 | 3 | 4} job_method {1|2}	Specifies the job type, job mode, and job rate: For job_type, enter 1 for server-based migration or 2 for storage-based migration. For job_mode, enter 1 for online or 2 for offline migration. For job_rate enter 1 for best effort, 2 for slow, 3 for medium, and 4 for fast data migration. For job_method enter 1 for Method 1and 2 for Method 2. For additional information about data migration rate, see the "Configuring Migration Rate" section on page 2-6.
Step 5	switchA(config-dmm-job)# peer IP_address	Configures the IP address of the SSM on switch B. For information about configuring SSM IP addresses, see the "Configuring IP Connectivity" section on page 2-3

Committing the Job

The next step is to commit the data migration job on switch A. To commit the job, use the commit command.

When you enter the commit command, the switch sends the job configuration to the SSM.

The DMM feature sends configuration information to other switches in the fabric as required, so that all traffic between the server HBA port and the existing storage is redirected to the SSM.

The SSM performs discovery of all existing and new storage LUNs visible to the server HBA ports/VIs in this job.

---

Note The commit command may require a noticeable amount of time to complete, depending on the number of LUNs to be discovered.

---

Configuring the Peer SSM

The next step is to configure the data migration job on the peer SSM.

---

Note You must use the same job number that you created on switch A.

---

To configure the data migration job on the peer SSM, follow these steps:

Step	Command	Comments
Step 1	switchB# configuration terminal	Enters configuration mode.
Step 2	switchB(config)# dmm module module-id job job-id create	Creates a migration job on the specified SSM module and enters DMM job configuration mode. Note Enter the same job ID that you created on switch A.
Step 3	switchB(config-dmm-job)# server vsan 0-4093 pwwn pWWN	Specifies the VSAN and pWWN of the server HBA port to include in the migration. Note All server HBA ports (in Fabric 2) that can access the LUNs to be migrated need to be added to this job.
Step 4	switchB(config-dmm-job)# storage vsan 0-4093 pwwn pWWN existing	Specifies the VSAN and pWWN of the existing storage port. Note All existing storage ports (in Fabric 2) that expose the LUNs to be migrated need to be added to this job.
Step 5	switchB(config-dmm-job)# storage vsan 0-4093 pwwn pWWN new	Specifies the VSAN and pWWN of the new storage port. Note All new storage ports (in Fabric 2) that expose the new LUNs need to be added to this job.
Step 6	switchB(config-dmm-job)# attributes job_type {1 | 2} job_mode {1 | 2} job_rate {1 | 2 | 3 | 4} job_method {1 | 2}	Specifies the job type, job mode, job rate, and job method. Note The configuration values for the attributes and the schedule must match on both switches.
Step 7	switchB(config-dmm-job)# peer IP_address	Configures the IP address of the SSM on switch A.
Step 8	switchB(config-dmm-job)# commit	Commits the data migration job on switch B.

Configuring Sessions

The next step is to configure sessions in the data migration job. For a server-based migration, configure all of the sessions on one SSM.

For a storage-based migration, you can manually balance the load on the SSMs by configuring sessions on both SSMs.

---

Note For a a storage-based migration, use the pWWN of the VI as the server in the session configuration.

---

To display that the SSM has discovered the LUNs correctly, enter the show dmm job job-id job id storage command from the SSM CLI.

To configure sessions, follow these steps:

Step	Command	Comments
Step 1	switchA(config)# dmm module module-id job job-id session	Enters session configuration mode for the specified job on the specified SSM.
Step 2	switchA(config-session)# server pWWN src_tgt pWWN src_lun num dst_tgt pWWN dst_lun num	Configures a session. The server HBA port, existing storage port, and new storage port must all belong to the same VSAN. •server is the server pWWN (server-based job) or VI pWWN (storage-based job). •src_tgt is the existing storage pWWN. •src_lun is the LUN number in the existing storage. Enter this value in hexidecimal notation. •dst_tgt num is the new storage pWWN. •dst_lun is the LUN number in the new storage. Enter this value in hexidecimal notation.

Server-Based Migration Example

The topology for this example is dual fabric with multipath ports defined in the server and redundant paths to the storage devices (as shown in Figure 7-2).

Figure 7-2 Topology for the Example

On both switches, the SSM module is located in slot 8. The pWWNs for the ports are listed here:

Port	pWWN
H1	21:00:00:e0:8b:0a:5d:e7
ES1	50:06:04:82:bf:cf:e0:43
NS1	50:06:0e:80:03:4e:95:13
H2	21:01:00:e0:8b:0a:5d:e7
ES2	50:06:04:82:bf:cf:e0:5d
NS2	50:06:0e:80:03:4e:95:03

Configure the data migration job on switch A: 

switchA# configure terminal

switchA(config)# dmm module 8 job 2345 create

Started New DMM Job Configuration.

Do not exit sub-mode until configuration is complete and committed

switchA(config-dmm-job)# server vsan 100 pwwn 21:0d:00:0d:ec:02:2d:82

switchA(config-dmm-job)# storage vsan 100 pwwn 50:06:04:82:bf:cf:e0:43 existing

switchA(config-dmm-job)# storage vsan 100 pwwn 50:06:0e:80:03:4e:95:13 new

switchA(config-dmm-job)# peer 10.10.2.4

switchA(config-dmm-job)# attributes job_type 1 job_mode 1 job-rate 1 job-method 1

switchA(config-dmm-job)# commit

switchA(config-dmm-job)# end

Ending DMM Job Configuration.

If the Job was not committed, it will be required to reconfigure the job.

Configure the data migration job on switch B: 

switchB# configure terminal

switchB(config)# dmm module 8 job 2345 create

Started New DMM Job Configuration.

Do not exit sub-mode until configuration is complete and committed

switchB(config-dmm-job)# server vsan 100 pwwn 21:0d:00:0d:0a:01:2b:82

switchB(config-dmm-job)# storage vsan 100 pwwn 50:06:04:82:bf:cf:e0:5d existing

switchB(config-dmm-job)# storage vsan 100 pwwn 50:06:0e:80:03:4e:95:03 new 

switchB(config-dmm-job)# peer 10.10.1.8

switchB(config-dmm-job)# attributes job_type 1 job_mode 1 job-rate 1 job-method 1

switchB(config-dmm-job)# commit

switchB(config-dmm-job)# end

Ending DMM Job Configuration.

If the Job was not committed, it will be required to reconfigure the job.

switchB#

Configure the data migration sessions on switch A: 

switchA(config)# dmm module 4 job 2345 session

switchA(config-session)# server 21:00:00:e0:8b:0a:5d:e7 src_tgt 50:06:04:82:bf:cf:e0:43 
src_lun 0x5 dst_tgt 50:06:0e:80:03:4e:95:13 dst_lun 0x0

switchA(config-session)# server 21:00:00:e0:8b:0a:5d:e7 src_tgt 50:06:04:82:bf:cf:e0:43 
src_lun 0x6 dst_tgt 50:06:0e:80:03:4e:95:13 dst_lun 0x1

switchA(config-session)# exit

Start the data migration job on switch A: 

switchA(config)# dmm module 8 job 2345 start 

Started New DMM Job Configuration.

Do not exit sub-mode until configuration is complete and committed

switchA(config)# exit

Storage-Based Migration Example

The topology for this example is dual fabric with multipath ports defined in the server and redundant paths to the storage devices (as shown in Figure 7-3).

Figure 7-3 Topology for the Example

On both switches, the SSM module is located in slot 8. The pWWNs for the ports are listed here:

Port	pWWN
Host 1	21:00:00:e0:8b:0a:5d:e7
VI 1	21:0d:00:0d:ec:02:2d:82
ES1	50:06:04:82:bf:cf:e0:43
NS1	50:06:0e:80:03:4e:95:13
Host 2	21:01:00:e0:8b:0a:5d:e7
VI 2	21:0d:00:0d:0a:01:2b:82
ES2	50:06:04:82:bf:cf:e0:5d
NS2	50:06:0e:80:03:4e:95:03

Configure the VI on switch A: 

switchA# configure terminal

switchA(config)# dmm module 8 job 2345 get-vi vsan 100

DMM Storage Job:0x929 assigned follwing VI - 

VI NodeWWN: 21:0c:00:0d:ec:02:2d:82

VI PortWWN: 21:0d:00:0d:ec:02:2d:82

sjc7-9509-6(config)# 

Configure the zone and zoneset on switch A:

switchA(config)# zone name DMM1 vsan 100

switchA(config-zone)# member pwwn 21:0d:00:0d:ec:02:2d:82 vi

switchA(config-zone)# member pwwn 50:06:04:82:bf:cf:e0:43 es

switchA(config-zone)# member pwwn 50:06:0e:80:03:4e:95:13 ns

switchA(config-zone)# exit

switchA(config)# zoneset name DMM1 vsan 100

switchA(config-zoneset)# member DMM1

switchA(config-zoneset)# exit

switchA(config)# 

Configure the data migration job on switch A: 

switchA(config)# dmm module 8 job 2345 create

Started New DMM Job Configuration.

Do not exit sub-mode until configuration is complete and committed

switchA(config-dmm-job)# server vsan 100 pwwn 21:0d:00:0d:ec:02:2d:82

switchA(config-dmm-job)# storage vsan 100 pwwn 50:06:04:82:bf:cf:e0:43 existing

switchA(config-dmm-job)# storage vsan 100 pwwn 50:06:0e:80:03:4e:95:13 new

switchA(config-dmm-job)# peer 10.10.2.4

switchA(config-dmm-job)# attributes job_type 2 job_mode 1 job-rate 1 job-method 1

switchA(config-dmm-job)# commit 

switchA(config-dmm-job)# end

Ending DMM Job Configuration.

If the Job was not committed, it will be required to reconfigure the job.

switchB#

Configure the VI on switch B: 

switchB# configure terminal

switchB(config)# dmm module 8 job 2345 get-vi vsan 100

DMM Storage Job:0x929 assigned follwing VI - 

VI NodeWWN: 21:0c:01:0e:ec:02:2d:82

VI PortWWN: 21:0d:00:0d:0a:01:2b:82

switchB(config)# 

Configure the zone and zoneset on switch B:

switchB(config)# zone name DMM1 vsan 100

switchB(config-zone)# member pwwn 21:0d:00:0d:0a:01:2b:82 vi

switchB(config-zone)# member pwwn 50:06:04:82:bf:cf:e0:5d es

switchB(config-zone)# member pwwn 50:06:0e:80:03:4e:95:03 ns

switchB(config-zone)# exit

switchB(config)# zoneset name DMM1 vsan 100

switchB(config-zoneset)# member DMM1

switchB(config-zoneset)# exit

switchB(config)# 

Configure the data migration job on switch B:

switchB# configure terminal

switchB(config)# dmm module 8 job 2345 create

Started New DMM Job Configuration.

Do not exit sub-mode until configuration is complete and committed

switchB(config-dmm-job)# server vsan 100 pwwn 21:0d:00:0d:0a:01:2b:82

switchB(config-dmm-job)# storage vsan 100 pwwn 50:06:04:82:bf:cf:e0:5d existing

switchB(config-dmm-job)# storage vsan 100 pwwn 50:06:0e:80:03:4e:95:03 new 

switchB(config-dmm-job)# peer 10.10.1.8

switchB(config-dmm-job)# attributes job_type 2 job_mode 1 job-rate 1 job-method 1

switchB(config-dmm-job)# commit

switchB(config-dmm-job)# end

Ending DMM Job Configuration.

If the Job was not committed, it will be required to reconfigure the job.

switchB#

Configure the data migration sessions on switch A: 50:06:04:82:bf:cf:e0:43

switchA(config)# dmm module 4 job 2345 session

switchA(config-session)# server 21:0d:00:0d:ec:02:2d:82 src_tgt 50:06:04:82:bf:cf:e0:43 
src_lun 0x5 dst_tgt 50:06:0e:80:03:4e:95:13 dst_lun 0x0

switchA(config-session)# exit

Start the data migration job on switch A: 

switchA(config)# dmm module 8 job 2345 start 

Started New DMM Job Configuration.

Do not exit sub-mode until configuration is complete and committed

switchA(config)# exit

Configure the data migration sessions on switch B: 

switchB(config)# dmm module 4 job 2345 session

switchB(config-session)# server 21:0d:00:0d:0a:01:2b:82 src_tgt 50:06:04:82:bf:cf:e0:5d 
src_lun 0x5 dst_tgt 50:06:0e:80:03:4e:95:03 dst_lun 0x0

switchB(config-session)# exit

Start the data migration job on switch B: 

switchB(config)# dmm module 8 job 2345 start 

Started New DMM Job Configuration.

Do not exit sub-mode until configuration is complete and committed

switchB(config)# exit

Controlling DMM Jobs

The DMM CLI provides a set of commands to control jobs that have been configured. The job state determines which commands are valid to run. Job states are shown in Table 7-1.

Table 7-1 Job Status Values 

Job Status Value	Description
Created	The job has been created, but has not been scheduled.
Scheduled	The job has been configured with a scheduled start time. It will automatically start at that time.
Complete	The job has been completed successfully.
Verify	The completed job is being verified.
Stopped	The job has been stopped manually by the user.
Failed	The job has been stopped because of failures. See Table 5-5 for details.
In_Progress	The job is currently running.
Reset	The job has been reinitialized because of failures . See Table 5-6 for details.
Finishing	The Method 2 job is in the final copy iteration.
Verify_Stopped	The job verification has been stopped.
Verify_Complete	The job verification has been completed.
Verify_Failure	The job verification is unsuccessful.

Table 7-2 describes the data migration commands.

Table 7-2 Command Valid States 

Command	Description	Valid Job Status Values
Verify	Performs offline verification of the selected job. User is prompted to confirm the verification command.	Completed, InProgress, VerifyStopped, Verify_Failure
Destroy	Deletes the selected job (or jobs) and retrieves the job execution log from the SSM. User is prompted to confirm the delete command.	Stopped, Failed, Completed, Reset, VerifyStopped, Verify_Failure, Created, Scheduled
Stop	Stops the selected job.	InProgress
Start	Starts the selected job.	Created, Reset
Modify	Allows you to modify the job attributes or configure a start time for the selected job.	Created, Scheduled, Reset, Stopped
Schedule	Allows you to set up schedules.	Created, Scheduled, Stopped
Validate	Validates the stored configuration for a job in a Reset state.	Reset
Finish	Completes the selected job only in case of Method 2.	InProgress
Log	Opens the DMM log for the selected job.	All job status values

---

Note You must enter these commands on the switch with sessions configured. If both SSMs have sessions configured, enter the commands on both switches.

---

To control the data migration job, use the following commands:

Command	Purpose
switchA(config)# dmm module module-id job job-id start	Starts a data migration job or restarts a job that was stopped. Note For a job in reset state, run the validate command on both switches before restarting the job. The start command is ignored if the job is scheduled for a future time. Use the schedule now command to start a scheduled job.
switchA(config)# dmm module module-id job job-id stop	Stops execution of the job. Note Job progress is not preserved. If you start the job again later, the job restarts from the beginning.
switchA(config)# dmm module module-id job job-id validate	If the job is in the reset state, run the validate option. After validation, start the job using the start command. Note Always run the validate command on both SSMs (even if only one SSM has sessions).
switchA(config)# dmm module module-id job job-id schedule [ now | hour hr min min day day month month [year] | reset ]	Configures a scheduled start time for the data migration job. Enter schedule now to start the job immediately. Enter reset to remove the scheduled start time from the job. The job remains in created state until you manually start it. Note Enter the schedule command on each SSM with sessions.

Monitoring DMM Jobs

Use the show dmm job command in the SSM CLI to monitor the status of data migration jobs, and the current progress of jobs and sessions that are in progress.

To monitor data migration jobs, follow these steps:

Step	Command	Comments
Step 1	switch# attach module module-id	Enters CLI mode on the SSM module.
Step 2	module# show dmm job	Displays summary information about the data migration jobs configured on this SSM.
Step 3	module# show dmm job job-id job-id {detail | session | storage}	Displays information about the specified job. detail displays the job attributes, schedule, server HBA and storage ports, the job log, and job error log. session displays the sessions included in the job. storage displays the storage ports included in the job.

For additional information about monitoring and troubleshooting data migration jobs, see Chapter 5, "Troubleshooting Cisco MDS DMM."

Completing DMM Jobs

When all of the sessions in a job have completed successfully, you can delete the job in coordination with other post-migration tasks, which are described in the following sections:

•(Optional) Verifying the Completed Job

•Post-Migration Activities

•Deleting the Job

(Optional) Verifying the Completed Job

When all of the sessions in a job have completed successfully, you can optionally perform verification of the data in the new storage location. The SSM compares the data in the new storage with the data in the existing storage by reading each migration region from the existing and new storage, and then performing a comparison of the data.

To perform migration verification, follow these steps:

Step	Command	Comments
Step 1	switchA(config)# dmm module module-id job job-id verify	Verifies the data migration by comparing the data in the new storage with the data in the existing storage. The verify command operates in offline mode.

---

Note Verification is performed in offline mode. Any service using the existing storage needs to be quiesced before you start verification.

---

While verification is being performed on a job, you can display the verification progress using the following command:

show dmm job job-id session [session-id sess-id]

Post-Migration Activities

After the data migration job has completed successfully, you need to reconfigure the server to use the new storage. The exact post-migration configuration steps vary depending on the operating system of the server.

Reconfiguration may include the following steps:

•Perform a graceful shut down on all server applications that use the migrated LUNs to ensure that there are no pending I/O operations on the existing storage.

•Unmount the existing storage LUNs.

•Configure zoning to remove server access to the existing LUNs.

•Using the DMM CLI

For Method 1- Delete the data migration job. DMM removes the FC-Redirect entries to the SMM. Server writes are no longer mirrored to the existing and new storage.

ForMethod 2 - Finish the data migration job. When the job moves to Completed state, delete the data migration job. See the Finishing Jobs for more details.

•Configure zoning to add server access to the new LUNs.

•From the server, scan for the new storage.

•Mount the file system for the new storage.

•From the server, restart the server applications to access data from the new storage.

Finishing the Job

To finish the data migration job, follow these steps:

Step	Command	Comments
Step 1	switchA(config)# dmm module module-id job job-id finish switch A#	Finishes the specified data migration job. This is valid only for Method 2. See Finishing Jobs for more details.

Deleting the Job

To delete the data migration job, follow these steps:

Step	Command	Comments
Step 1	switchA(config)# dmm module module-id job job-id destroy switchA#	Deletes the specified data migration job.