Open Stack

Hey,

I have to bring up this topic again. A patch
https://review.openstack.org/#/c/66101/ has been uploaded for review to
resolve the cold migration auto confirm issue.

One question want to get some input from you guys: Do we need to
distinguish V2 and V3 API for this behavior? My thinking is that we do not
need to distinguish this for V2 and V3 API for the auto confirm feature,
the reason is as following:
1) It is a new feature for Icehouse, for cold migration, Icehouse will auto
confirm all cold migration operations.
2) We cannot know if the instance was cold migrated by V2 or V3, if really
want to distinguish, we may need to add some data in system metadata to
mark if the VM was cold migrated by V2 or V3 API.

Any comments?

Thanks,

Jay



2014/1/9 John Garbutt <john at johngarbutt.com>

> On 8 January 2014 15:29, Jay Lau <jay.lau.513 at gmail.com> wrote:
> > 2014/1/8 John Garbutt <john at johngarbutt.com>
> >>
> >> On 8 January 2014 10:02, David Xie <david.scriptfan at gmail.com> wrote:
> >> > In nova/compute/api.py#2289, function resize, there's a parameter
> named
> >> > flavor_id, if it is None, it is considered as cold migration. Thus,
> nova
> >> > should skip resize verifying. However, it doesn't.
> >> >
> >> > Like Jay said, we should skip this step during cold migration, does it
> >> > make
> >> > sense?
> >>
> >> Not sure.
> >>
> >> > On Wed, Jan 8, 2014 at 5:52 PM, Jay Lau <jay.lau.513 at gmail.com>
> wrote:
> >> >>
> >> >> Greetings,
> >> >>
> >> >> I have a question related to cold migration.
> >> >>
> >> >> Now in OpenStack nova, we support live migration, cold migration and
> >> >> resize.
> >> >>
> >> >> For live migration, we do not need to confirm after live migration
> >> >> finished.
> >> >>
> >> >> For resize, we need to confirm, as we want to give end user an
> >> >> opportunity
> >> >> to rollback.
> >> >>
> >> >> The problem is cold migration, because cold migration and resize
> share
> >> >> same code path, so once I submit a cold migration request and after
> the
> >> >> cold
> >> >> migration finished, the VM will goes to verify_resize state, and I
> need
> >> >> to
> >> >> confirm resize. I felt a bit confused by this, why do I need to
> verify
> >> >> resize for a cold migration operation? Why not reset the VM to
> original
> >> >> state directly after cold migration?
> >>
> >> I think the idea was allow users/admins to check everything went OK,
> >> and only delete the original VM when the have confirmed the move went
> >> OK.
> >>
> >> I thought there was an auto_confirm setting. Maybe you want
> >> auto_confirm cold migrate, but not auto_confirm resize?
> >
> > [Jay] John, yes, that can also reach my goal. Now we only have
> > resize_confirm_window to handle auto confirm without considering it is
> > resize or cold migration.
> > # Automatically confirm resizes after N seconds. Set to 0 to
> > # disable. (integer value)
> > #resize_confirm_window=0
> >
> > Perhaps we can add another parameter say cold_migrate_confirm_window to
> > handle confirm for cold migration.
>
> I like Russell's suggestion, but maybe implement it as always doing
> auto_confirm for cold migrate in v3 API, and leaving it as is for
> resize.
>
> See if people like that, I should check with our ops guys.
>
> >> >> Also, I think that probably we need split compute.api.resize() to two
> >> >> apis: one is for resize and the other is for cold migrations.
> >> >>
> >> >> 1) The VM state can be either ACTIVE and STOPPED for a resize
> operation
> >> >> 2) The VM state must be STOPPED for a cold migrate operation.
> >>
> >> We just stop the VM them perform the migration.
> >> I don't think we need to require its stopped first.
> >> Am I missing something?
> >
> > [Jay] Yes, but just curious why someone want to cold migrate an ACTIVE
> VM?
> > They can use live migration instead and this can also make sure the VM
> > migrate seamlessly.
>
> If a disk is failing, people like to turn off the VMs to reduce load
> on that host while performing the migrations.
>
> And live-migrate (sadly) does not yet work in all configurations yet,
> so its useful where live-migrate is not possible.
>
> Also live-migrate with block_migration can use quite a lot more
> network bandwidth than cold migration, at least in the XenServer case.
>
> John
>
> _______________________________________________
> 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/20140120/96dbbf68/attachment.html>