Open Stack

Thanks Chris and Alex :-)

@Chris, OK, I will update patch then.

@Alex, yes, John also give some explanation as following:

=============================================
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.
=============================================



2014/1/22 Alex Xu <xuhj at linux.vnet.ibm.com>

>  On 2014年01月08日 23:12, Jay Lau wrote:
>
>  Thanks Russell, OK, will file a bug for first issue.
>
> For second question, I want to show some of my comments here. I think that
> we should disable cold migration for an ACTIVE VM as cold migrating will
> first destroy the VM then re-create the VM when using KVM, I did not see a
> use case why someone want to do such a case.
>
> Even further, this might make end user confused, its really strange both
> cold migration and live migration can migrate an ACTIVE VM. Cold migration
> should only target STOPPED VM instance.
>
>
> I think cold migrate an ACTIVE VM is ok. The different of cold migration
> and live migration is there isn't down time for vm with live migration.
> Cold migration is make the vm
> down first, then migrate it.
>
>
>
> What do you think?
>
>  Thanks,
>
>  Jay
>
>
>
> 2014/1/8 Russell Bryant <rbryant at redhat.com>
>
>> On 01/08/2014 04:52 AM, Jay Lau 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?
>>
>>  The confirm step definitely makes more sense for the resize case.  I'm
>> not sure if there was a strong reason why it was also needed for cold
>> migration.
>>
>> If nobody comes up with a good reason to keep it, I'm fine with removing
>> it.  It can't be changed in the v2 API, though.  This would be a v3 only
>> change.
>>
>> > 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.
>>
>>  I'm not sure why would require different states here, though.  ACTIVE
>> and STOPPED are allowed now.
>>
>> --
>> Russell Bryant
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140122/16220b2a/attachment-0001.html>