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.
Note: The
command cannot be used with image-mode volumes.
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.
You cannot specify this command for thin-provisioned or compressed volume
copies that are in data reduction storage pools.
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 a 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