| Message ID | 1515045675-6993-11-git-send-email-zhangckid@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 01/04/2018 12:01 AM, Zhang Chen wrote: > From: zhanghailiang <zhang.zhanghailiang@huawei.com> > > If some errors happen during VM's COLO FT stage, it's important to > notify the users of this event. Together with 'x_colo_lost_heartbeat', Isn't that spelled x-colo-lost-heartbeat in QMP? > Users can intervene in COLO's failover work immediately. > If users don't want to get involved in COLO's failover verdict, > it is still necessary to notify users that we exited COLO mode. > > Cc: Markus Armbruster <armbru@redhat.com> > Cc: Michael Roth <mdroth@linux.vnet.ibm.com> > Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> > Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> > Signed-off-by: Zhang Chen <zhangckid@gmail.com> > Reviewed-by: Eric Blake <eblake@redhat.com> > --- Focusing on just the UI: > +++ b/qapi-schema.json > @@ -2921,6 +2921,27 @@ > { 'command': 'query-acpi-ospm-status', 'returns': ['ACPIOSTInfo'] } > > ## > +# @COLO_EXIT: > +# > +# Emitted when VM finishes COLO mode due to some errors happening or > +# at the request of users. > +# > +# @mode: which COLO mode the VM was in when it exited. > +# > +# @reason: describes the reason for the COLO exit. > +# > +# Since: 2.11 You've missed 2.11; this should be 2.12. > +# > +# Example: > +# > +# <- { "timestamp": {"seconds": 2032141960, "microseconds": 417172}, > +# "event": "COLO_EXIT", "data": {"mode": "primary", "reason": "request" } } > +# > +## > +{ 'event': 'COLO_EXIT', > + 'data': {'mode': 'COLOMode', 'reason': 'COLOExitReason' } } Since COLOMode is in migration.json, shouldn't this 'event' declaration live there as well? > + > +## > # @ACPI_DEVICE_OST: > # > # Emitted when guest executes ACPI _OST method. > diff --git a/qapi/migration.json b/qapi/migration.json > index 03f57c9..f7b2cc6 100644 > --- a/qapi/migration.json > +++ b/qapi/migration.json > @@ -854,6 +854,19 @@ > ## > { 'enum': 'FailoverStatus', > 'data': [ 'none', 'require', 'active', 'completed', 'relaunch' ] } > +## > +# @COLOExitReason: > +# > +# The reason for a COLO exit > +# > +# @request: COLO exit is due to an external request > +# > +# @error: COLO exit is due to an internal error > +# > +# Since: 2.11 2.12 > +## > +{ 'enum': 'COLOExitReason', > + 'data': [ 'request', 'error' ] } > > ## > # @x-colo-lost-heartbeat: >
On Thu, Jan 4, 2018 at 5:10 PM, Eric Blake <eblake@redhat.com> wrote: > On 01/04/2018 12:01 AM, Zhang Chen wrote: > > From: zhanghailiang <zhang.zhanghailiang@huawei.com> > > > > If some errors happen during VM's COLO FT stage, it's important to > > notify the users of this event. Together with 'x_colo_lost_heartbeat', > > Isn't that spelled x-colo-lost-heartbeat in QMP? > Yes, I will fix this comments in next version. > > > Users can intervene in COLO's failover work immediately. > > If users don't want to get involved in COLO's failover verdict, > > it is still necessary to notify users that we exited COLO mode. > > > > Cc: Markus Armbruster <armbru@redhat.com> > > Cc: Michael Roth <mdroth@linux.vnet.ibm.com> > > Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> > > Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> > > Signed-off-by: Zhang Chen <zhangckid@gmail.com> > > Reviewed-by: Eric Blake <eblake@redhat.com> > > --- > > Focusing on just the UI: > > > > +++ b/qapi-schema.json > > @@ -2921,6 +2921,27 @@ > > { 'command': 'query-acpi-ospm-status', 'returns': ['ACPIOSTInfo'] } > > > > ## > > +# @COLO_EXIT: > > +# > > +# Emitted when VM finishes COLO mode due to some errors happening or > > +# at the request of users. > > +# > > +# @mode: which COLO mode the VM was in when it exited. > > +# > > +# @reason: describes the reason for the COLO exit. > > +# > > +# Since: 2.11 > > You've missed 2.11; this should be 2.12. > I got it. > > > +# > > +# Example: > > +# > > +# <- { "timestamp": {"seconds": 2032141960, "microseconds": 417172}, > > +# "event": "COLO_EXIT", "data": {"mode": "primary", "reason": > "request" } } > > +# > > +## > > +{ 'event': 'COLO_EXIT', > > + 'data': {'mode': 'COLOMode', 'reason': 'COLOExitReason' } } > > Since COLOMode is in migration.json, shouldn't this 'event' declaration > live there as well? > OK, I will move this to migration.json like the COLOMode in next version. > > > + > > +## > > # @ACPI_DEVICE_OST: > > # > > # Emitted when guest executes ACPI _OST method. > > diff --git a/qapi/migration.json b/qapi/migration.json > > index 03f57c9..f7b2cc6 100644 > > --- a/qapi/migration.json > > +++ b/qapi/migration.json > > @@ -854,6 +854,19 @@ > > ## > > { 'enum': 'FailoverStatus', > > 'data': [ 'none', 'require', 'active', 'completed', 'relaunch' ] } > > +## > > +# @COLOExitReason: > > +# > > +# The reason for a COLO exit > > +# > > +# @request: COLO exit is due to an external request > > +# > > +# @error: COLO exit is due to an internal error > > +# > > +# Since: 2.11 > > 2.12 > I got it . Thanks Zhang Chen > > > +## > > +{ 'enum': 'COLOExitReason', > > + 'data': [ 'request', 'error' ] } > > > > ## > > # @x-colo-lost-heartbeat: > > > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3266 > Virtualization: qemu.org | libvirt.org > >
diff --git a/migration/colo.c b/migration/colo.c index 8d2e3f8..790b122 100644 --- a/migration/colo.c +++ b/migration/colo.c @@ -516,6 +516,18 @@ out: qemu_fclose(fb); } + /* + * There are only two reasons we can go here, some error happened. + * Or the user triggered failover. + */ + if (failover_get_state() == FAILOVER_STATUS_NONE) { + qapi_event_send_colo_exit(COLO_MODE_PRIMARY, + COLO_EXIT_REASON_ERROR, NULL); + } else { + qapi_event_send_colo_exit(COLO_MODE_PRIMARY, + COLO_EXIT_REASON_REQUEST, NULL); + } + /* Hope this not to be too long to wait here */ qemu_sem_wait(&s->colo_exit_sem); qemu_sem_destroy(&s->colo_exit_sem); @@ -746,6 +758,13 @@ out: if (local_err) { error_report_err(local_err); } + if (failover_get_state() == FAILOVER_STATUS_NONE) { + qapi_event_send_colo_exit(COLO_MODE_SECONDARY, + COLO_EXIT_REASON_ERROR, NULL); + } else { + qapi_event_send_colo_exit(COLO_MODE_SECONDARY, + COLO_EXIT_REASON_REQUEST, NULL); + } if (fb) { qemu_fclose(fb); diff --git a/qapi-schema.json b/qapi-schema.json index 5c06745..4ff6d2c 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -2921,6 +2921,27 @@ { 'command': 'query-acpi-ospm-status', 'returns': ['ACPIOSTInfo'] } ## +# @COLO_EXIT: +# +# Emitted when VM finishes COLO mode due to some errors happening or +# at the request of users. +# +# @mode: which COLO mode the VM was in when it exited. +# +# @reason: describes the reason for the COLO exit. +# +# Since: 2.11 +# +# Example: +# +# <- { "timestamp": {"seconds": 2032141960, "microseconds": 417172}, +# "event": "COLO_EXIT", "data": {"mode": "primary", "reason": "request" } } +# +## +{ 'event': 'COLO_EXIT', + 'data': {'mode': 'COLOMode', 'reason': 'COLOExitReason' } } + +## # @ACPI_DEVICE_OST: # # Emitted when guest executes ACPI _OST method. diff --git a/qapi/migration.json b/qapi/migration.json index 03f57c9..f7b2cc6 100644 --- a/qapi/migration.json +++ b/qapi/migration.json @@ -854,6 +854,19 @@ ## { 'enum': 'FailoverStatus', 'data': [ 'none', 'require', 'active', 'completed', 'relaunch' ] } +## +# @COLOExitReason: +# +# The reason for a COLO exit +# +# @request: COLO exit is due to an external request +# +# @error: COLO exit is due to an internal error +# +# Since: 2.11 +## +{ 'enum': 'COLOExitReason', + 'data': [ 'request', 'error' ] } ## # @x-colo-lost-heartbeat: