Add Support for Volume migration during Live (block) migration

Registered by Rohit Karajgi

Problem:
In a production environment where multiple Cinder volume nodes are present,
some instances may have volumes attached to a Volume node that requires maintenance and/or
extended downtimes.

Solution:
To achieve proper volume migration, this support could be added in Nova's Live (block) migration
feature.
Proposal is to add support for volume migration during Instance Live (Block) migration.

 High level outline of steps:
    * On Source compute node, symlinks to the currently attached cinder volumes (/dev/disks/by-path/<iqn>) are created in the instance-xxx directory before starting block migration.
    * During pre live migration on destination compute node, symlinks are created to the new cinder volumes /dev/disks/by-path/<iqn> in the instance-xxx directory on destination compute node. And the new volumes are connected to the destination compute node's Hypervisor.
    * Data is copied from source volumes to corresponding destination volumes by nova/libvirt's migrateToUri since it considers them ephemeral disks or disk images..
    * During post live migration:
        - On source compute node, we disconnect/detach and/or delete the attached volumes.
        - On destination compute node, we attach the destination volumes to the migrated instance.

Note: The data is copied by the migrateToURI method which treats the symlinks in instance-xxx directory as ephemeral disks or disk images and copies it block by block, hence this has to be done in block migration and cannot be done separately unless we want to handle the block copying of volumes oursevles instead of libvirt doing it.

Blueprint information

Status:
Complete
Approver:
Vish Ishaya
Priority:
Low
Drafter:
Rohit Karajgi
Direction:
Needs approval
Assignee:
Aswad Rangnekar
Definition:
Obsolete
Series goal:
None
Implementation:
Needs Code Review
Milestone target:
None
Started by
Rohit Karajgi
Completed by
John Garbutt

Related branches

Sprints

Whiteboard

This needs thought to work with XenAPI. The XenAPI block migration code can now migrate connections to iSCSI volumes, alongside moving the disks for root and ephemeral disks. However, there is no easy way to move the volume backing store to the new host, as this is not exposed to XenAPI - johnthetubaguy

Since the nova patch is abandoned, I'm removing this from grizzly, as it's too late in the cycle for such a large patch to be entering review. --Russell

Gerrit topic: https://review.openstack.org/#q,topic:bp/migrate-volume-block-migration,n,z

Addressed by: https://review.openstack.org/20333
    Add Support for Cinder Volume migration

Addressed by: https://review.openstack.org/#/c/20334/
    Add Support for Cinder Volume migration (novaclient)

Unapproved - please re-submit via nova-spec --johnthetubagy (20th March 2014)This needs thought to work with XenAPI. The XenAPI block migration code can now migrate connections to iSCSI volumes, alongside moving the disks for root and ephemeral disks. However, there is no easy way to move the volume backing store to the new host, as this is not exposed to XenAPI - johnthetubaguy

Since the nova patch is abandoned, I'm removing this from grizzly, as it's too late in the cycle for such a large patch to be entering review. --Russell

Gerrit topic: https://review.openstack.org/#q,topic:bp/migrate-volume-block-migration,n,z

Addressed by: https://review.openstack.org/20333
    Add Support for Cinder Volume migration

Addressed by: https://review.openstack.org/#/c/20334/
    Add Support for Cinder Volume migration (novaclient)

Unapproved - please re-submit via nova-spec --johnthetubagy (20th March 2014)

This blueprint is not complete after a good year or so, marking as Obsolete to tidy up the Nova backlog. --johnthetubaguy (20th April 2014)

(?)

Work Items