On 8 January 2014 15:29, Jay Lau <jay.lau....@gmail.com> wrote: > 2014/1/8 John Garbutt <j...@johngarbutt.com> >> >> On 8 January 2014 10:02, David Xie <david.script...@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....@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev