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 <[email protected]> > 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 <[email protected]> > >> 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 >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > _______________________________________________ > OpenStack-dev mailing > [email protected]http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
