Open Stack

I believe it was my comment on the review that started this idea, but I was actually suggesting something different from point 2 below. Comments in line.
On Feb 4, 2013, at 3:33 AM, "Kanade, Rohan" <Rohan.Kanade at nttdata.com> wrote:

> This is in context to an ongoing review https://review.openstack.org/#/c/20333/   and comments on the review.
>  
> There are two cases which need to be considered for the topic of “Attached and Un-attached Volume migration”.
>  
> Case 1: Is intended to be implemented by the above review . Libvirt api (migrateToURI)  takes care of correctly copying and syncing data between the original volumes (attached) on “cinder-node1”  and the new destination volumes on "cinder-node2", without taking the original volumes offline or detaching them before copying.

I may have slightly misunderstood the functionality of the patch, so let me ask the following question to clarify:

Is it possible to do live-migration and specify the same compute node so that only the volumes are migrated?

for example:

nova live-migration instance1 compute-node1 --block_device_mapping …

If it is possible to keep the instance on the same node while migrating volumes, then I think my concerns are addressed.

>  
> Case 2: Adding a separate command to migrate individual volumes that are un-attached could be useful in the following scenario:

I agree that this is important and could be done in a separate patch.

>  
> "cinder-node1" contains 10 volumes , 2 volumes are attached to "instance1" on "compute-node1", To take down "cinder-node1", we can block migrate the "instance1" using this patch, which will migrate the 2 volumes to "cinder-node2", But the rest 8 volumes on "cinder-node1" need to be migrated too. Since taking down "cinder-node1" will render the remaining 8 volumes unusable. This is where individual volume migration can be used.
> But , for all volumes on "cinder-node1" which are attached to "instance1", they cannot be simply live migrated individually or detached and then migrated.
>  
> There are two points to be observed here:
> 1) We cannot use LVM volume snapshots and recreate another volume on the new "cinder-node2", since LVM commands are specific to
> the node.
>  
> 2) We can use rsync to copy/sync between the original volume on "cinder-node1" and the destination volume on "cinder-node2".
>  
> 3) The volume uuid will change, since we are creating a destination volume in which the source volume data will be copied, This might cause issue to users who are using the source volume uuid's in automated scripts etc.

I think it would be fairly easy to come up with a way of copying volumes without having to change the uuid
> 
> ______________________________________________________________________
> Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130204/65c14fcf/attachment.html>