migrateexts

Use the migrateexts command to migrate extents from one managed disk to another.

Syntax

migrateexts -source { source_mdisk_id | source_mdisk_name } -target { target_mdisk_id | target_mdisk_name } -extsnumber_of_extents [ -threadsnumber_of_threads ] [ -copyid ] -vdisk { vdisk_id | vdisk_name }

Parameters

-sourcesource_mdisk_id | source_mdisk_name
(Required) Specifies the MDisk on which the extents currently reside.
-targettarget_mdisk_id | target_mdisk_name
(Required) Specifies the MDisk to migrate the extents to.
-extsnumber_of_extents
(Required) Specifies the number of extents to migrate.
-threadsnumber_of_threads
(Optional) Specifies the number of threads to use while migrating these extents. You can specify 1 - 4 threads. The default number of threads is 4.
-copyid
(Required if the specified volume has more than one copy) Specifies the volume copy that the extents belong to.
-vdiskvdisk_id | vdisk_name
(Required) Specifies the volume that the extents belong to.

Description

This command migrates a given number of extents from the source volume and the managed disk that contains extents that are used to make up the volume. The target is a managed disk within the same storage pool.

If a large number of extents are being migrated, you can specify 1 - 4 threads. You can issue the lsmigrate command to check the progress of the migration.

The migrateexts command fails if there are insufficient free extents on the target managed disk. To avoid this problem, do not issue new commands that use extents until the extents migration is completed.

The migrateexts command fails if the target or source volume is offline, or if Easy Tier ® is active for the volume copy. Correct the offline condition before attempting to migrate the volume.

Note: Migration activity on a single managed disk is limited to a maximum of 4 concurrent operations. This limit does not take into account whether the managed disk is the source or the destination target. If more than four migrations are scheduled for a particular managed disk, further migration operations are queued pending the completion of one of the currently running migrations. If a migration operation is stopped for any reason, a queued migration task can be started. However, if a migration is suspended, the current migration continues to use resources and a pending migration is not started. For example, the following setup is a possible initial configuration:
  • MDiskGrp 1 has volume 1 created in it
  • MDiskGrp 2 has volume 2 created in it
  • MDiskGrp 3 has only one MDisk
With the previous configuration, the following migration operations are started:
  • Migration 1 migrates volume 1 from MDiskGrp 1 to MDiskGrp 3, running with 4 threads.
  • Migration 2 migrates volume 2 from MDiskGrp 2 to MDiskGrp 3, running with 4 threads.
Due to the previous limitations, the two migration operations do not always run at the same speed. MDiskGrp 3 has only one MDisk and the two migration operations have a total of 8 threads that are trying to access the one MDisk. Four threads are active. The remaining threads are in standby mode waiting to access the MDisk.
Remember: This command cannot be used if the source MDisk is an SAS MDisk (which works in image mode only).

An invocation example

migrateexts -vdisk vdisk4 -source mdisk4 -exts
	64 -target mdisk6 -threads 4

The resulting output:

No feedback