Difference between revisions of "Migrate-volume-block-migration"
m (Text replace - "__NOTOC__" to "") |
|||
| Line 1: | Line 1: | ||
| − | + | ||
== Add Support for Volume migration during Live (block) migration == | == Add Support for Volume migration during Live (block) migration == | ||
Revision as of 23:31, 17 February 2013
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 vdc=<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.
