Message ID | 20190228165508.21594-5-chen.zhang@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Migration/colo: Fix upstream bugs when occur failover | expand |
On 2/28/19 10:55 AM, Zhang Chen wrote: > From: Zhang Chen <chen.zhang@intel.com> > > In this patch we add the processing state for COLOExitReason, > because we have to identify COLO in the failover processing state or > failover error state. In the way, we can handle all the failover state. > We have improved the description of the COLOExitReason by the way. > > Signed-off-by: Zhang Chen <chen.zhang@intel.com> > --- > migration/colo.c | 24 +++++++++++++----------- > qapi/migration.json | 15 +++++++++------ > 2 files changed, 22 insertions(+), 17 deletions(-) > > +++ b/qapi/migration.json > @@ -983,19 +983,22 @@ > ## > # @COLOExitReason: > # > -# The reason for a COLO exit > +# Describe the reason for COLO exit. > # > -# @none: no failover has ever happened. This can't occur in the > -# COLO_EXIT event, only in the result of query-colo-status. > +# @none: failover has never happened. This state does not occurred > +# in the COLO_EXIT event, only happened in the result of > +# query-colo-status. Grammar suggestion: This state does not occur in the COLO_EXIT event, and is only visible in the result of query-colo-status. > # > -# @request: COLO exit is due to an external request > +# @request: COLO exit caused by an external request. > # > -# @error: COLO exit is due to an internal error > +# @error: COLO exit caused by an internal error. > +# > +# @processing: COLO in failover handling state. Missing a (since 4.0) tag. Maybe: @processing: COLO is currently handling a failover (since 4.0).
-----Original Message----- From: Eric Blake [mailto:eblake@redhat.com] Sent: Friday, March 1, 2019 1:05 AM To: Zhang, Chen <chen.zhang@intel.com>; Li Zhijian <lizhijian@cn.fujitsu.com>; Zhang Chen <zhangckid@gmail.com>; Dr. David Alan Gilbert <dgilbert@redhat.com>; Juan Quintela <quintela@redhat.com>; zhanghailiang <zhang.zhanghailiang@huawei.com>; Markus Armbruster <armbru@redhat.com>; qemu-dev <qemu-devel@nongnu.org> Subject: Re: [PATCH V2 4/7] Migration/colo.c: Add new COLOExitReason to handle all failover state On 2/28/19 10:55 AM, Zhang Chen wrote: > From: Zhang Chen <chen.zhang@intel.com> > > In this patch we add the processing state for COLOExitReason, because > we have to identify COLO in the failover processing state or failover > error state. In the way, we can handle all the failover state. > We have improved the description of the COLOExitReason by the way. > > Signed-off-by: Zhang Chen <chen.zhang@intel.com> > --- > migration/colo.c | 24 +++++++++++++----------- > qapi/migration.json | 15 +++++++++------ > 2 files changed, 22 insertions(+), 17 deletions(-) > > +++ b/qapi/migration.json > @@ -983,19 +983,22 @@ > ## > # @COLOExitReason: > # > -# The reason for a COLO exit > +# Describe the reason for COLO exit. > # > -# @none: no failover has ever happened. This can't occur in the -# > COLO_EXIT event, only in the result of query-colo-status. > +# @none: failover has never happened. This state does not occurred # > +in the COLO_EXIT event, only happened in the result of # > +query-colo-status. Grammar suggestion: This state does not occur in the COLO_EXIT event, and is only visible in the result of query-colo-status. OK~ I will fix it in next version. > # > -# @request: COLO exit is due to an external request > +# @request: COLO exit caused by an external request. > # > -# @error: COLO exit is due to an internal error > +# @error: COLO exit caused by an internal error. > +# > +# @processing: COLO in failover handling state. Missing a (since 4.0) tag. Maybe: @processing: COLO is currently handling a failover (since 4.0). Sure, thank you for your comments~ Thanks Zhang Chen -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
diff --git a/migration/colo.c b/migration/colo.c index 89325952c7..dbe2b88807 100644 --- a/migration/colo.c +++ b/migration/colo.c @@ -267,7 +267,11 @@ COLOStatus *qmp_query_colo_status(Error **errp) s->reason = COLO_EXIT_REASON_REQUEST; break; default: - s->reason = COLO_EXIT_REASON_ERROR; + if (migration_in_colo_state()) { + s->reason = COLO_EXIT_REASON_PROCESSING; + } else { + s->reason = COLO_EXIT_REASON_ERROR; + } } return s; @@ -579,16 +583,13 @@ out: * or the user triggered failover. */ switch (failover_get_state()) { - case FAILOVER_STATUS_NONE: - qapi_event_send_colo_exit(COLO_MODE_PRIMARY, - COLO_EXIT_REASON_ERROR); - break; case FAILOVER_STATUS_COMPLETED: qapi_event_send_colo_exit(COLO_MODE_PRIMARY, COLO_EXIT_REASON_REQUEST); break; default: - abort(); + qapi_event_send_colo_exit(COLO_MODE_PRIMARY, + COLO_EXIT_REASON_ERROR); } /* Hope this not to be too long to wait here */ @@ -850,17 +851,18 @@ out: error_report_err(local_err); } + /* + * There are only two reasons we can get here, some error happened + * or the user triggered failover. + */ switch (failover_get_state()) { - case FAILOVER_STATUS_NONE: - qapi_event_send_colo_exit(COLO_MODE_SECONDARY, - COLO_EXIT_REASON_ERROR); - break; case FAILOVER_STATUS_COMPLETED: qapi_event_send_colo_exit(COLO_MODE_SECONDARY, COLO_EXIT_REASON_REQUEST); break; default: - abort(); + qapi_event_send_colo_exit(COLO_MODE_SECONDARY, + COLO_EXIT_REASON_ERROR); } if (fb) { diff --git a/qapi/migration.json b/qapi/migration.json index 7a795ecc16..48e21880a3 100644 --- a/qapi/migration.json +++ b/qapi/migration.json @@ -983,19 +983,22 @@ ## # @COLOExitReason: # -# The reason for a COLO exit +# Describe the reason for COLO exit. # -# @none: no failover has ever happened. This can't occur in the -# COLO_EXIT event, only in the result of query-colo-status. +# @none: failover has never happened. This state does not occurred +# in the COLO_EXIT event, only happened in the result of +# query-colo-status. # -# @request: COLO exit is due to an external request +# @request: COLO exit caused by an external request. # -# @error: COLO exit is due to an internal error +# @error: COLO exit caused by an internal error. +# +# @processing: COLO in failover handling state. # # Since: 3.1 ## { 'enum': 'COLOExitReason', - 'data': [ 'none', 'request', 'error' ] } + 'data': [ 'none', 'request', 'error' , 'processing' ] } ## # @x-colo-lost-heartbeat: