Difference between revisions of "Migrate-volume-block-migration"

Latest revision as of 14:10, 6 March 2017

Add Support for Volume migration during Live (block) migration

External Specification:

Add --block-device-mapping parameter to "nova live-migration --block_migrate" command.

The entire format of the command will be like this

`nova live-migration --block-migrate --block-device-mapping vda=1:::0, --block-device-mapping vdb=...(all attached EBS volumes) <instance_name> <name_of_destination_compute_node>`

Administrator has to specify --block-device-mapping parameters for all volumes attached to the instance.

Follow the existing format to specify block device mapping

`--block-device-mapping <device_name>=<a>::<c>:<d>`

<device_name>: device name referred from the instance

<a>: destination volume uuid (Note: MUST specify an existing volume, must be same size to the source volume)

<b>: N/A

<c>: N/A or size of the volume

<d>: 0:Do not delete the source volume, 1:delete the source volume

Note: Volumes on the destination volume node need to be created before the migration takes place. The migration could ensure copying the data onto the destination volumes.
Example:

Instance1 has two cinder volumes (created on cinder-node1) attached at vol-a on vdc (1gb) ,vol-b on vdb (3gb) (compute-node1).

Instance1 is to be migrated to compute-node2.

Create two (1gb vol-c, 3gb vol-d) volumes on cinder-node2.

run : "nova live-migration --block-migrate --block-device-mapping vda=<vol-c uuid>::1:0 vdb=<vol-d uuid>::3:0 <Instance1 uuid> compute-node2.

All data in vol-a is copied to vol-c by nova/libvirt's migrateToURI.

All data in vol-b is copied to vol-d by nova/libvirt's migrateToURI.

@@ Line 1: / Line 1: @@
-__NOTOC__
 == Add Support for Volume migration during Live (block) migration ==
 '''External Specification:'''
-Add --block_device_mapping parameter to "nova live-migration --block_migrate" command.
+Add --block-device-mapping parameter to "nova live-migration --block_migrate" command.
 The entire format of the command will be like this
-`nova live-migration --block_migrate --block_device_mapping vda=1:::0, --block_device_mapping vdb=...(all attached EBS volumes) <instance_name> <name_of_destination_compute_node>`
+`nova live-migration --block-migrate --block-device-mapping vda=1:::0, --block-device-mapping vdb=...(all attached EBS volumes) <instance_name> <name_of_destination_compute_node>`
-Administrator has to specify --block_device_mapping parameters for all volumes attached to the instance.
+Administrator has to specify --block-device-mapping parameters for all volumes attached to the instance.
 Follow the existing format to specify block device mapping
-`--block_device_mapping <device_name>=<a>:<b>:<c>:<d>`
+`--block-device-mapping <device_name>=<a>:<b>:<c>:<d>`
      <device_name>: device name referred from the instance
-     <a>: destination volume name (Note: MUST specify an '''existing volume''', must be same size to the source volume)
+     <a>: destination volume uuid (Note: MUST specify an '''existing volume''', must be same size to the source volume)
      <b>: N/A
@@ Line 25: / Line 25: @@
      <d>: 0:Do not delete the source volume, 1:delete the source volume
+'''Note:''' Volumes on the destination volume node need to be created before the migration takes place.
+The migration could ensure copying the data onto the destination volumes.
+'''Example:'''
+* Instance1 has two cinder volumes (created on cinder-node1) attached at vol-a on vdc (1gb) ,vol-b on vdb (3gb) (compute-node1).
+* Instance1 is to be migrated to compute-node2.
+* Create two (1gb vol-c, 3gb vol-d) volumes on cinder-node2.
+* run : "nova live-migration --block-migrate --block-device-mapping vda=<vol-c uuid>::1:0 vdb=<vol-d uuid>::3:0 <Instance1 uuid> compute-node2.
+* All data in vol-a is copied to vol-c by nova/libvirt's migrateToURI.
+* All data in vol-b is copied to vol-d by nova/libvirt's migrateToURI.