<div dir="ltr"><div><div>Thanks Chris and Alex :-)<br><br></div>@Chris, OK, I will update patch then.<br><br></div>@Alex, yes, John also give some explanation as following:<br><br>=============================================<br>
If a disk is failing, people like to turn off the VMs to reduce load<br>
on that host while performing the migrations.<br>
<br>
And live-<span class="">migrate</span> (sadly) does not yet work in all configurations yet,<br>
so its useful where live-<span class="">migrate</span> is not possible.<br>
<br>
Also live-<span class="">migrate</span> with block_migration can use quite a lot more<br>
network bandwidth than <span class="">cold</span> <span class="">migration</span>, at least in the XenServer case.<br>=============================================<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014/1/22 Alex Xu <span dir="ltr"><<a href="mailto:xuhj@linux.vnet.ibm.com" target="_blank">xuhj@linux.vnet.ibm.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
<div>On 2014Äê01ÔÂ08ÈÕ 23:12, Jay Lau wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Thanks Russell, OK, will file a bug for first issue.<br>
<br>
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. <br>
<br>
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.<br>
</div>
</div>
</div>
</blockquote>
<br></div>
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<br>
down first, then migrate it.<div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div><br>
What do you think?<br>
<br>
</div>
Thanks,<br>
<br>
</div>
Jay<br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014/1/8 Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 01/08/2014 04:52 AM, Jay Lau wrote:<br>
> Greetings,<br>
><br>
> I have a question related to cold migration.<br>
><br>
> Now in OpenStack nova, we support live migration,
cold migration and resize.<br>
><br>
> For live migration, we do not need to confirm after
live migration finished.<br>
><br>
> For resize, we need to confirm, as we want to give
end user an<br>
> opportunity to rollback.<br>
><br>
> The problem is cold migration, because cold migration
and resize share<br>
> same code path, so once I submit a cold migration
request and after the<br>
> cold migration finished, the VM will goes to
verify_resize state, and I<br>
> need to confirm resize. I felt a bit confused by
this, why do I need to<br>
> verify resize for a cold migration operation? Why not
reset the VM to<br>
> original state directly after cold migration?<br>
<br>
</div>
The confirm step definitely makes more sense for the resize
case. I'm<br>
not sure if there was a strong reason why it was also needed
for cold<br>
migration.<br>
<br>
If nobody comes up with a good reason to keep it, I'm fine
with removing<br>
it. It can't be changed in the v2 API, though. This would
be a v3 only<br>
change.<br>
<div><br>
> Also, I think that probably we need split
compute.api.resize() to two<br>
> apis: one is for resize and the other is for cold
migrations.<br>
><br>
> 1) The VM state can be either ACTIVE and STOPPED for
a resize operation<br>
> 2) The VM state must be STOPPED for a cold migrate
operation.<br>
<br>
</div>
I'm not sure why would require different states here,
though. ACTIVE<br>
and STOPPED are allowed now.<br>
<span><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span>
<div>
<div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>