* [Qemu-devel] [PATCH v2 0/2] Fix stop/cont vs. connect races @ 2012-10-19 14:45 Paolo Bonzini 2012-10-19 14:45 ` [Qemu-devel] [PATCH v2 1/2] qmp: handle stop/cont in INMIGRATE state Paolo Bonzini 2012-10-19 14:45 ` [Qemu-devel] [PATCH v2 2/2] migration: go to paused state after finishing incoming migration with -S Paolo Bonzini 0 siblings, 2 replies; 8+ messages in thread From: Paolo Bonzini @ 2012-10-19 14:45 UTC (permalink / raw) To: qemu-devel; +Cc: lcapitulino Here are two patches to make the handling more uniform when stop/cont commands are sent to a QEMU instance that is waiting for incoming migration. Right now the handling will change, depending on whether the command came before or after the source has connected. The behavior that makes most sense is the one you have if the command comes while migration is in progress and the monitor is blocked, so ensure that we always resolve the race like that. This will also help when incoming migration is moved to a coroutine, which (by design) will cause the monitor not to block. Paolo Bonzini (2): qmp: handle stop/cont in INMIGRATE state migration: go to paused state after finishing incoming migration with -S migration.c | 2 +- qapi-schema.json | 7 +------ qerror.h | 3 --- qmp.c | 17 +++++++++++------ vl.c | 2 +- 5 file modificati, 14 inserzioni(+), 17 rimozioni(-) -- 1.7.12.1 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Qemu-devel] [PATCH v2 1/2] qmp: handle stop/cont in INMIGRATE state 2012-10-19 14:45 [Qemu-devel] [PATCH v2 0/2] Fix stop/cont vs. connect races Paolo Bonzini @ 2012-10-19 14:45 ` Paolo Bonzini 2012-10-22 15:06 ` Luiz Capitulino 2012-10-19 14:45 ` [Qemu-devel] [PATCH v2 2/2] migration: go to paused state after finishing incoming migration with -S Paolo Bonzini 1 sibling, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2012-10-19 14:45 UTC (permalink / raw) To: qemu-devel; +Cc: lcapitulino Right now, stop followed by an incoming migration will let the virtual machine start. cont before an incoming migration instead will fail. This is bad because the actual behavior is not predictable; it is racy with respect to the start of the incoming migration. That's because incoming migration is blocking, and thus will delay the processing of stop/cont until the end of the migration. In addition, there's nothing that really prevents the user from typing the block device's passwords before incoming migration is done, so returning the DeviceEncrypted error is also helpful in the QMP case. Both things can be fixed by just toggling the autostart variable when stop/cont are called in INMIGRATE state. Note that libvirt is currently working around the race by looping if the MigrationExpected answer is returned. After this patch, the command will return right away without ever raising an error. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- v1->v2: kill MigrationExpected and QERR_MIGRATION_EXPECTED, yay! qapi-schema.json | 7 +------ qerror.h | 3 --- qmp.c | 17 +++++++++++------ 3 file modificati, 12 inserzioni(+), 15 rimozioni(-) diff --git a/qapi-schema.json b/qapi-schema.json index c615ee2..7e102c5 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -22,15 +22,11 @@ # @KVMMissingCap: the requested operation can't be fulfilled because a # required KVM capability is missing # -# @MigrationExpected: the requested operation can't be fulfilled because a -# migration process is expected -# # Since: 1.2 ## { 'enum': 'ErrorClass', 'data': [ 'GenericError', 'CommandNotFound', 'DeviceEncrypted', - 'DeviceNotActive', 'DeviceNotFound', 'KVMMissingCap', - 'MigrationExpected' ] } + 'DeviceNotActive', 'DeviceNotFound', 'KVMMissingCap' ] } ## # @add_client @@ -1299,7 +1295,6 @@ # Since: 0.14.0 # # Returns: If successful, nothing -# If the QEMU is waiting for an incoming migration, MigrationExpected # If QEMU was started with an encrypted block device and a key has # not yet been set, DeviceEncrypted. # diff --git a/qerror.h b/qerror.h index c91708c..5e98a39 100644 --- a/qerror.h +++ b/qerror.h @@ -165,9 +165,6 @@ void assert_no_error(Error *err); #define QERR_MIGRATION_NOT_SUPPORTED \ ERROR_CLASS_GENERIC_ERROR, "State blocked by non-migratable device '%s'" -#define QERR_MIGRATION_EXPECTED \ - ERROR_CLASS_MIGRATION_EXPECTED, "An incoming migration is expected before this command can be executed" - #define QERR_MISSING_PARAMETER \ ERROR_CLASS_GENERIC_ERROR, "Parameter '%s' is missing" diff --git a/qmp.c b/qmp.c index 36c54c5..2c8d559 100644 --- a/qmp.c +++ b/qmp.c @@ -85,7 +85,11 @@ void qmp_quit(Error **err) void qmp_stop(Error **errp) { - vm_stop(RUN_STATE_PAUSED); + if (runstate_check(RUN_STATE_INMIGRATE)) { + autostart = 0; + } else { + vm_stop(RUN_STATE_PAUSED); + } } void qmp_system_reset(Error **errp) @@ -144,10 +148,7 @@ void qmp_cont(Error **errp) { Error *local_err = NULL; - if (runstate_check(RUN_STATE_INMIGRATE)) { - error_set(errp, QERR_MIGRATION_EXPECTED); - return; - } else if (runstate_check(RUN_STATE_INTERNAL_ERROR) || + if (runstate_check(RUN_STATE_INTERNAL_ERROR) || runstate_check(RUN_STATE_SHUTDOWN)) { error_set(errp, QERR_RESET_REQUIRED); return; @@ -162,7 +163,11 @@ void qmp_cont(Error **errp) return; } - vm_start(); + if (runstate_check(RUN_STATE_INMIGRATE)) { + autostart = 1; + } else { + vm_start(); + } } void qmp_system_wakeup(Error **errp) -- 1.7.12.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH v2 1/2] qmp: handle stop/cont in INMIGRATE state 2012-10-19 14:45 ` [Qemu-devel] [PATCH v2 1/2] qmp: handle stop/cont in INMIGRATE state Paolo Bonzini @ 2012-10-22 15:06 ` Luiz Capitulino 2012-10-22 15:35 ` Paolo Bonzini 0 siblings, 1 reply; 8+ messages in thread From: Luiz Capitulino @ 2012-10-22 15:06 UTC (permalink / raw) To: Paolo Bonzini; +Cc: qemu-devel On Fri, 19 Oct 2012 16:45:23 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote: > Right now, stop followed by an incoming migration will let the > virtual machine start. cont before an incoming migration instead > will fail. > > This is bad because the actual behavior is not predictable; it is > racy with respect to the start of the incoming migration. That's > because incoming migration is blocking, and thus will delay the > processing of stop/cont until the end of the migration. > > In addition, there's nothing that really prevents the user from > typing the block device's passwords before incoming migration is > done, so returning the DeviceEncrypted error is also helpful in > the QMP case. > > Both things can be fixed by just toggling the autostart variable when > stop/cont are called in INMIGRATE state. > > Note that libvirt is currently working around the race by looping > if the MigrationExpected answer is returned. After this patch, the > command will return right away without ever raising an error. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Could you please add a note in cont's and stop's entries in qapi-schema.json explaining their behavior on INMIGRATE? Otherwise series looks good. > --- > v1->v2: kill MigrationExpected and QERR_MIGRATION_EXPECTED, yay! > > qapi-schema.json | 7 +------ > qerror.h | 3 --- > qmp.c | 17 +++++++++++------ > 3 file modificati, 12 inserzioni(+), 15 rimozioni(-) > > diff --git a/qapi-schema.json b/qapi-schema.json > index c615ee2..7e102c5 100644 > --- a/qapi-schema.json > +++ b/qapi-schema.json > @@ -22,15 +22,11 @@ > # @KVMMissingCap: the requested operation can't be fulfilled because a > # required KVM capability is missing > # > -# @MigrationExpected: the requested operation can't be fulfilled because a > -# migration process is expected > -# > # Since: 1.2 > ## > { 'enum': 'ErrorClass', > 'data': [ 'GenericError', 'CommandNotFound', 'DeviceEncrypted', > - 'DeviceNotActive', 'DeviceNotFound', 'KVMMissingCap', > - 'MigrationExpected' ] } > + 'DeviceNotActive', 'DeviceNotFound', 'KVMMissingCap' ] } > > ## > # @add_client > @@ -1299,7 +1295,6 @@ > # Since: 0.14.0 > # > # Returns: If successful, nothing > -# If the QEMU is waiting for an incoming migration, MigrationExpected > # If QEMU was started with an encrypted block device and a key has > # not yet been set, DeviceEncrypted. > # > diff --git a/qerror.h b/qerror.h > index c91708c..5e98a39 100644 > --- a/qerror.h > +++ b/qerror.h > @@ -165,9 +165,6 @@ void assert_no_error(Error *err); > #define QERR_MIGRATION_NOT_SUPPORTED \ > ERROR_CLASS_GENERIC_ERROR, "State blocked by non-migratable device '%s'" > > -#define QERR_MIGRATION_EXPECTED \ > - ERROR_CLASS_MIGRATION_EXPECTED, "An incoming migration is expected before this command can be executed" > - > #define QERR_MISSING_PARAMETER \ > ERROR_CLASS_GENERIC_ERROR, "Parameter '%s' is missing" > > diff --git a/qmp.c b/qmp.c > index 36c54c5..2c8d559 100644 > --- a/qmp.c > +++ b/qmp.c > @@ -85,7 +85,11 @@ void qmp_quit(Error **err) > > void qmp_stop(Error **errp) > { > - vm_stop(RUN_STATE_PAUSED); > + if (runstate_check(RUN_STATE_INMIGRATE)) { > + autostart = 0; > + } else { > + vm_stop(RUN_STATE_PAUSED); > + } > } > > void qmp_system_reset(Error **errp) > @@ -144,10 +148,7 @@ void qmp_cont(Error **errp) > { > Error *local_err = NULL; > > - if (runstate_check(RUN_STATE_INMIGRATE)) { > - error_set(errp, QERR_MIGRATION_EXPECTED); > - return; > - } else if (runstate_check(RUN_STATE_INTERNAL_ERROR) || > + if (runstate_check(RUN_STATE_INTERNAL_ERROR) || > runstate_check(RUN_STATE_SHUTDOWN)) { > error_set(errp, QERR_RESET_REQUIRED); > return; > @@ -162,7 +163,11 @@ void qmp_cont(Error **errp) > return; > } > > - vm_start(); > + if (runstate_check(RUN_STATE_INMIGRATE)) { > + autostart = 1; > + } else { > + vm_start(); > + } > } > > void qmp_system_wakeup(Error **errp) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH v2 1/2] qmp: handle stop/cont in INMIGRATE state 2012-10-22 15:06 ` Luiz Capitulino @ 2012-10-22 15:35 ` Paolo Bonzini 2012-10-22 15:38 ` Luiz Capitulino 0 siblings, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2012-10-22 15:35 UTC (permalink / raw) To: Luiz Capitulino; +Cc: qemu-devel Il 22/10/2012 17:06, Luiz Capitulino ha scritto: >> > Note that libvirt is currently working around the race by looping >> > if the MigrationExpected answer is returned. After this patch, the >> > command will return right away without ever raising an error. >> > >> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > Could you please add a note in cont's and stop's entries in qapi-schema.json > explaining their behavior on INMIGRATE? > > Otherwise series looks good. > Can I do that as a followup? Paolo ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH v2 1/2] qmp: handle stop/cont in INMIGRATE state 2012-10-22 15:35 ` Paolo Bonzini @ 2012-10-22 15:38 ` Luiz Capitulino 2012-10-23 12:54 ` [Qemu-devel] [PATCH v3 " Paolo Bonzini 0 siblings, 1 reply; 8+ messages in thread From: Luiz Capitulino @ 2012-10-22 15:38 UTC (permalink / raw) To: Paolo Bonzini; +Cc: qemu-devel On Mon, 22 Oct 2012 17:35:58 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote: > Il 22/10/2012 17:06, Luiz Capitulino ha scritto: > >> > Note that libvirt is currently working around the race by looping > >> > if the MigrationExpected answer is returned. After this patch, the > >> > command will return right away without ever raising an error. > >> > > >> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > > Could you please add a note in cont's and stop's entries in qapi-schema.json > > explaining their behavior on INMIGRATE? > > > > Otherwise series looks good. > > > > Can I do that as a followup? You can re-work 1/2 and submit only that one. I'll order the two patches correctly in my queue. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Qemu-devel] [PATCH v3 1/2] qmp: handle stop/cont in INMIGRATE state 2012-10-22 15:38 ` Luiz Capitulino @ 2012-10-23 12:54 ` Paolo Bonzini 2012-10-23 13:39 ` Luiz Capitulino 0 siblings, 1 reply; 8+ messages in thread From: Paolo Bonzini @ 2012-10-23 12:54 UTC (permalink / raw) To: qemu-devel; +Cc: lcapitulino Right now, stop followed by an incoming migration will let the virtual machine start. cont before an incoming migration instead will fail. This is bad because the actual behavior is not predictable; it is racy with respect to the start of the incoming migration. That's because incoming migration is blocking, and thus will delay the processing of stop/cont until the end of the migration. In addition, there's nothing that really prevents the user from typing the block device's passwords before incoming migration is done, so returning the DeviceEncrypted error is also helpful in the QMP case. Both things can be fixed by just toggling the autostart variable when stop/cont are called in INMIGRATE state. Note that libvirt is currently working around the race by looping if the MigrationExpected answer is returned. After this patch, the command will return right away without ever raising an error. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- qapi-schema.json | 23 ++++++++++++++--------- qerror.h | 3 --- qmp.c | 17 +++++++++++------ 3 file modificati, 25 inserzioni(+), 18 rimozioni(-) diff --git a/qapi-schema.json b/qapi-schema.json index c615ee2..6b14edc 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -22,15 +22,11 @@ # @KVMMissingCap: the requested operation can't be fulfilled because a # required KVM capability is missing # -# @MigrationExpected: the requested operation can't be fulfilled because a -# migration process is expected -# # Since: 1.2 ## { 'enum': 'ErrorClass', 'data': [ 'GenericError', 'CommandNotFound', 'DeviceEncrypted', - 'DeviceNotActive', 'DeviceNotFound', 'KVMMissingCap', - 'MigrationExpected' ] } + 'DeviceNotActive', 'DeviceNotFound', 'KVMMissingCap' ] } ## # @add_client @@ -149,7 +145,11 @@ # # @finish-migrate: guest is paused to finish the migration process # -# @inmigrate: guest is paused waiting for an incoming migration +# @inmigrate: guest is paused waiting for an incoming migration. Note +# that this state does not tell whether the machine will start at the +# end of the migration. This depends on the command-line -S option and +# any invocation of 'stop' or 'cont' that has happened since QEMU was +# started. # # @internal-error: An internal error that prevents further guest execution # has occurred @@ -1210,7 +1210,9 @@ # Since: 0.14.0 # # Notes: This function will succeed even if the guest is already in the stopped -# state +# state. In "inmigrate" state, it will ensure that the guest +# remains paused once migration finishes, as if the -S option was +# passed on the command line. ## { 'command': 'stop' } @@ -1299,11 +1301,14 @@ # Since: 0.14.0 # # Returns: If successful, nothing -# If the QEMU is waiting for an incoming migration, MigrationExpected # If QEMU was started with an encrypted block device and a key has # not yet been set, DeviceEncrypted. # -# Notes: This command will succeed if the guest is currently running. +# Notes: This command will succeed if the guest is currently running. It +# will also succeed if the guest is in the "inmigrate" state; in +# this case, the effect of the command is to make sure the guest +# starts once migration finishes, removing the effect of the -S +# command line option if it was passed. ## { 'command': 'cont' } diff --git a/qerror.h b/qerror.h index c91708c..5e98a39 100644 --- a/qerror.h +++ b/qerror.h @@ -165,9 +165,6 @@ void assert_no_error(Error *err); #define QERR_MIGRATION_NOT_SUPPORTED \ ERROR_CLASS_GENERIC_ERROR, "State blocked by non-migratable device '%s'" -#define QERR_MIGRATION_EXPECTED \ - ERROR_CLASS_MIGRATION_EXPECTED, "An incoming migration is expected before this command can be executed" - #define QERR_MISSING_PARAMETER \ ERROR_CLASS_GENERIC_ERROR, "Parameter '%s' is missing" diff --git a/qmp.c b/qmp.c index 36c54c5..2c8d559 100644 --- a/qmp.c +++ b/qmp.c @@ -85,7 +85,11 @@ void qmp_quit(Error **err) void qmp_stop(Error **errp) { - vm_stop(RUN_STATE_PAUSED); + if (runstate_check(RUN_STATE_INMIGRATE)) { + autostart = 0; + } else { + vm_stop(RUN_STATE_PAUSED); + } } void qmp_system_reset(Error **errp) @@ -144,10 +148,7 @@ void qmp_cont(Error **errp) { Error *local_err = NULL; - if (runstate_check(RUN_STATE_INMIGRATE)) { - error_set(errp, QERR_MIGRATION_EXPECTED); - return; - } else if (runstate_check(RUN_STATE_INTERNAL_ERROR) || + if (runstate_check(RUN_STATE_INTERNAL_ERROR) || runstate_check(RUN_STATE_SHUTDOWN)) { error_set(errp, QERR_RESET_REQUIRED); return; @@ -162,7 +163,11 @@ void qmp_cont(Error **errp) return; } - vm_start(); + if (runstate_check(RUN_STATE_INMIGRATE)) { + autostart = 1; + } else { + vm_start(); + } } void qmp_system_wakeup(Error **errp) -- 1.7.12.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] [PATCH v3 1/2] qmp: handle stop/cont in INMIGRATE state 2012-10-23 12:54 ` [Qemu-devel] [PATCH v3 " Paolo Bonzini @ 2012-10-23 13:39 ` Luiz Capitulino 0 siblings, 0 replies; 8+ messages in thread From: Luiz Capitulino @ 2012-10-23 13:39 UTC (permalink / raw) To: Paolo Bonzini; +Cc: qemu-devel On Tue, 23 Oct 2012 14:54:21 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote: > Right now, stop followed by an incoming migration will let the > virtual machine start. cont before an incoming migration instead > will fail. > > This is bad because the actual behavior is not predictable; it is > racy with respect to the start of the incoming migration. That's > because incoming migration is blocking, and thus will delay the > processing of stop/cont until the end of the migration. > > In addition, there's nothing that really prevents the user from > typing the block device's passwords before incoming migration is > done, so returning the DeviceEncrypted error is also helpful in > the QMP case. > > Both things can be fixed by just toggling the autostart variable when > stop/cont are called in INMIGRATE state. > > Note that libvirt is currently working around the race by looping > if the MigrationExpected answer is returned. After this patch, the > command will return right away without ever raising an error. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Applied series to the qmp branch, thanks. > --- > qapi-schema.json | 23 ++++++++++++++--------- > qerror.h | 3 --- > qmp.c | 17 +++++++++++------ > 3 file modificati, 25 inserzioni(+), 18 rimozioni(-) > > diff --git a/qapi-schema.json b/qapi-schema.json > index c615ee2..6b14edc 100644 > --- a/qapi-schema.json > +++ b/qapi-schema.json > @@ -22,15 +22,11 @@ > # @KVMMissingCap: the requested operation can't be fulfilled because a > # required KVM capability is missing > # > -# @MigrationExpected: the requested operation can't be fulfilled because a > -# migration process is expected > -# > # Since: 1.2 > ## > { 'enum': 'ErrorClass', > 'data': [ 'GenericError', 'CommandNotFound', 'DeviceEncrypted', > - 'DeviceNotActive', 'DeviceNotFound', 'KVMMissingCap', > - 'MigrationExpected' ] } > + 'DeviceNotActive', 'DeviceNotFound', 'KVMMissingCap' ] } > > ## > # @add_client > @@ -149,7 +145,11 @@ > # > # @finish-migrate: guest is paused to finish the migration process > # > -# @inmigrate: guest is paused waiting for an incoming migration > +# @inmigrate: guest is paused waiting for an incoming migration. Note > +# that this state does not tell whether the machine will start at the > +# end of the migration. This depends on the command-line -S option and > +# any invocation of 'stop' or 'cont' that has happened since QEMU was > +# started. > # > # @internal-error: An internal error that prevents further guest execution > # has occurred > @@ -1210,7 +1210,9 @@ > # Since: 0.14.0 > # > # Notes: This function will succeed even if the guest is already in the stopped > -# state > +# state. In "inmigrate" state, it will ensure that the guest > +# remains paused once migration finishes, as if the -S option was > +# passed on the command line. > ## > { 'command': 'stop' } > > @@ -1299,11 +1301,14 @@ > # Since: 0.14.0 > # > # Returns: If successful, nothing > -# If the QEMU is waiting for an incoming migration, MigrationExpected > # If QEMU was started with an encrypted block device and a key has > # not yet been set, DeviceEncrypted. > # > -# Notes: This command will succeed if the guest is currently running. > +# Notes: This command will succeed if the guest is currently running. It > +# will also succeed if the guest is in the "inmigrate" state; in > +# this case, the effect of the command is to make sure the guest > +# starts once migration finishes, removing the effect of the -S > +# command line option if it was passed. > ## > { 'command': 'cont' } > > diff --git a/qerror.h b/qerror.h > index c91708c..5e98a39 100644 > --- a/qerror.h > +++ b/qerror.h > @@ -165,9 +165,6 @@ void assert_no_error(Error *err); > #define QERR_MIGRATION_NOT_SUPPORTED \ > ERROR_CLASS_GENERIC_ERROR, "State blocked by non-migratable device '%s'" > > -#define QERR_MIGRATION_EXPECTED \ > - ERROR_CLASS_MIGRATION_EXPECTED, "An incoming migration is expected before this command can be executed" > - > #define QERR_MISSING_PARAMETER \ > ERROR_CLASS_GENERIC_ERROR, "Parameter '%s' is missing" > > diff --git a/qmp.c b/qmp.c > index 36c54c5..2c8d559 100644 > --- a/qmp.c > +++ b/qmp.c > @@ -85,7 +85,11 @@ void qmp_quit(Error **err) > > void qmp_stop(Error **errp) > { > - vm_stop(RUN_STATE_PAUSED); > + if (runstate_check(RUN_STATE_INMIGRATE)) { > + autostart = 0; > + } else { > + vm_stop(RUN_STATE_PAUSED); > + } > } > > void qmp_system_reset(Error **errp) > @@ -144,10 +148,7 @@ void qmp_cont(Error **errp) > { > Error *local_err = NULL; > > - if (runstate_check(RUN_STATE_INMIGRATE)) { > - error_set(errp, QERR_MIGRATION_EXPECTED); > - return; > - } else if (runstate_check(RUN_STATE_INTERNAL_ERROR) || > + if (runstate_check(RUN_STATE_INTERNAL_ERROR) || > runstate_check(RUN_STATE_SHUTDOWN)) { > error_set(errp, QERR_RESET_REQUIRED); > return; > @@ -162,7 +163,11 @@ void qmp_cont(Error **errp) > return; > } > > - vm_start(); > + if (runstate_check(RUN_STATE_INMIGRATE)) { > + autostart = 1; > + } else { > + vm_start(); > + } > } > > void qmp_system_wakeup(Error **errp) ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Qemu-devel] [PATCH v2 2/2] migration: go to paused state after finishing incoming migration with -S 2012-10-19 14:45 [Qemu-devel] [PATCH v2 0/2] Fix stop/cont vs. connect races Paolo Bonzini 2012-10-19 14:45 ` [Qemu-devel] [PATCH v2 1/2] qmp: handle stop/cont in INMIGRATE state Paolo Bonzini @ 2012-10-19 14:45 ` Paolo Bonzini 1 sibling, 0 replies; 8+ messages in thread From: Paolo Bonzini @ 2012-10-19 14:45 UTC (permalink / raw) To: qemu-devel; +Cc: lcapitulino At the end of migration the machine has started already, and cannot be destroyed without losing the guest's data. Hence, prelaunch is the wrong state. Go to the paused state instead. QEMU would reach that state anyway (after running the guest for the blink of an eye) if the "stop" command had been received after the start of migration. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- migration.c | 2 +- vl.c | 2 +- 2 file modificati, 2 inserzioni(+), 2 rimozioni(-) diff --git a/migration.c b/migration.c index 32d43e7..72abd3c 100644 --- a/migration.c +++ b/migration.c @@ -108,7 +108,7 @@ static void process_incoming_migration_co(void *opaque) if (autostart) { vm_start(); } else { - runstate_set(RUN_STATE_PRELAUNCH); + runstate_set(RUN_STATE_PAUSED); } } diff --git a/vl.c b/vl.c index 5b357a3..8b1e0b2 100644 --- a/vl.c +++ b/vl.c @@ -341,7 +341,7 @@ static const RunStateTransition runstate_transitions_def[] = { { RUN_STATE_DEBUG, RUN_STATE_RUNNING }, { RUN_STATE_INMIGRATE, RUN_STATE_RUNNING }, - { RUN_STATE_INMIGRATE, RUN_STATE_PRELAUNCH }, + { RUN_STATE_INMIGRATE, RUN_STATE_PAUSED }, { RUN_STATE_INTERNAL_ERROR, RUN_STATE_PAUSED }, { RUN_STATE_INTERNAL_ERROR, RUN_STATE_FINISH_MIGRATE }, -- 1.7.12.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-10-23 13:39 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-10-19 14:45 [Qemu-devel] [PATCH v2 0/2] Fix stop/cont vs. connect races Paolo Bonzini 2012-10-19 14:45 ` [Qemu-devel] [PATCH v2 1/2] qmp: handle stop/cont in INMIGRATE state Paolo Bonzini 2012-10-22 15:06 ` Luiz Capitulino 2012-10-22 15:35 ` Paolo Bonzini 2012-10-22 15:38 ` Luiz Capitulino 2012-10-23 12:54 ` [Qemu-devel] [PATCH v3 " Paolo Bonzini 2012-10-23 13:39 ` Luiz Capitulino 2012-10-19 14:45 ` [Qemu-devel] [PATCH v2 2/2] migration: go to paused state after finishing incoming migration with -S Paolo Bonzini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).