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 } -exts number_of_extents [ -threads number_of_threads ] [ -copy id ] -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 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 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