Open Stack

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