Open Stack

On Mon, Feb 4, 2013 at 10:02 AM, Vishvananda Ishaya
<vishvananda at gmail.com>wrote:

> 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> So I'll have to look at this a bit closer, but although I understand the
intent and I think it's a nicely worked feature I'm not sure about pushing
this sort of functionality back into Nova.  I'm wondering if we would be
better off taking the clone functionality we currently have in Cinder
(which does much of what you've got going on here) and enhancing that a bit
to cover some of the other special cases here.

Just seems like pushing complex volume operations back in to Nova isn't
necessarily the best approach if there's an alternative.

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