| Message ID | 1520716927-17068-12-git-send-email-zhangckid@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | COLO: integrate colo frame with block replication and COLO proxy | expand |
On 03/10/2018 03:22 PM, Zhang Chen wrote: > Libvirt or other high level sofware can use this command query colo status. s/sofware/software/ > You can test this command like that: > {'execute':'query-colo-status'} > > Signed-off-by: Zhang Chen <zhangckid@gmail.com> > --- > migration/colo.c | 35 +++++++++++++++++++++++++++++++++++ > qapi/migration.json | 35 +++++++++++++++++++++++++++++++++++ > 2 files changed, 70 insertions(+) > > +++ b/qapi/migration.json > @@ -1201,3 +1201,38 @@ > # Since: 2.9 > ## > { 'command': 'xen-colo-do-checkpoint' } > + > +## > +# @COLOStatus: > +# > +# The result format for 'query-colo-status'. > +# > +# @mode: which COLO mode the VM was in when it exited. > +# true is primary mode, false is secondary mode. Eww. Why not make this an enum ("primary", "secondary") instead of having to remember what true means? > +# > +# @colo_running: if true means COLO running well, otherwise COLO have done. New interfaces should use '-' rather than '_' as the separator; this should be 'colo-running' > +# > +# @reason: describes the reason for the COLO exit. > +# true is error, false is user request. Again, would an enum ("error", "user") be nicer than a bool? It is also more extensible if you add a third reason down the road. > +# > +# Since: 2.12 > +## > +{ 'struct': 'COLOStatus', > + 'data': { 'mode': 'bool', 'colo_running': 'bool', 'reason': 'bool' } } > + > +## > +# @query-colo-status: > +# > +# Query COLO status while the vm is running. > +# > +# Returns: A @COLOStatus object showing the status. > +# > +# Example: > +# > +# -> { "execute": "query-colo-status" } > +# <- { "return": { "colo_running": "true", "mode": "true", "reason": "true" } } Inconsistent with your declaration above; if these are truly declared 'bool', then the example should be (with the spelling fix, but not fixing where you should have been using enums instead of bools): { "return": { "colo-running": true, "mode": true, "reason": true } } We're awfully close to soft freeze, and this is a new feature - which maintainer will be trying to get this polished and into the tree in time?
On Sun, Mar 11, 2018 at 5:33 AM, Eric Blake <eblake@redhat.com> wrote: > On 03/10/2018 03:22 PM, Zhang Chen wrote: > >> Libvirt or other high level sofware can use this command query colo >> status. >> > > s/sofware/software/ > > You can test this command like that: >> {'execute':'query-colo-status'} >> >> Signed-off-by: Zhang Chen <zhangckid@gmail.com> >> --- >> migration/colo.c | 35 +++++++++++++++++++++++++++++++++++ >> qapi/migration.json | 35 +++++++++++++++++++++++++++++++++++ >> 2 files changed, 70 insertions(+) >> >> > +++ b/qapi/migration.json >> @@ -1201,3 +1201,38 @@ >> # Since: 2.9 >> ## >> { 'command': 'xen-colo-do-checkpoint' } >> + >> +## >> +# @COLOStatus: >> +# >> +# The result format for 'query-colo-status'. >> +# >> +# @mode: which COLO mode the VM was in when it exited. >> +# true is primary mode, false is secondary mode. >> > > Eww. Why not make this an enum ("primary", "secondary") instead of having > to remember what true means? > > +# >> +# @colo_running: if true means COLO running well, otherwise COLO have >> done. >> > > New interfaces should use '-' rather than '_' as the separator; this > should be 'colo-running' > > +# >> +# @reason: describes the reason for the COLO exit. >> +# true is error, false is user request. >> > > Again, would an enum ("error", "user") be nicer than a bool? It is also > more extensible if you add a third reason down the road. > > +# >> +# Since: 2.12 >> +## >> +{ 'struct': 'COLOStatus', >> + 'data': { 'mode': 'bool', 'colo_running': 'bool', 'reason': 'bool' } } >> + >> +## >> +# @query-colo-status: >> +# >> +# Query COLO status while the vm is running. >> +# >> +# Returns: A @COLOStatus object showing the status. >> +# >> +# Example: >> +# >> +# -> { "execute": "query-colo-status" } >> +# <- { "return": { "colo_running": "true", "mode": "true", "reason": >> "true" } } >> > > Inconsistent with your declaration above; if these are truly declared > 'bool', then the example should be (with the spelling fix, but not fixing > where you should have been using enums instead of bools): > > { "return": { "colo-running": true, "mode": true, "reason": true } } > > We're awfully close to soft freeze, and this is a new feature - which > maintainer will be trying to get this polished and into the tree in time? Maybe Paolo or David? CC paolo and David, any comments about this series? I have addressed all comments about this patch and sent the PATCH V6, Thanks your comments and please review it. Thanks Zhang Chen > > > -- > 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 8ca6381..b4243ab 100644 --- a/migration/colo.c +++ b/migration/colo.c @@ -237,6 +237,41 @@ void qmp_xen_colo_do_checkpoint(Error **errp) #endif } +COLOStatus *qmp_query_colo_status(Error **errp) +{ + MigrationState *m; + MigrationIncomingState *mis; + COLOStatus *s = g_new0(COLOStatus, 1); + + if (get_colo_mode() == COLO_MODE_PRIMARY) { + m = migrate_get_current(); + + if (m->state == MIGRATION_STATUS_COLO) { + s->colo_running = true; + } else { + s->colo_running = false; + } + s->mode = true; + } else { + mis = migration_incoming_get_current(); + + if (mis->state == MIGRATION_STATUS_COLO) { + s->colo_running = true; + } else { + s->colo_running = false; + } + s->mode = false; + } + + if (failover_get_state() == FAILOVER_STATUS_NONE) { + s->reason = true; + } else { + s->reason = false; + } + + return s; +} + static void colo_send_message(QEMUFile *f, COLOMessage msg, Error **errp) { diff --git a/qapi/migration.json b/qapi/migration.json index 6c6c50e..8f81f36 100644 --- a/qapi/migration.json +++ b/qapi/migration.json @@ -1201,3 +1201,38 @@ # Since: 2.9 ## { 'command': 'xen-colo-do-checkpoint' } + +## +# @COLOStatus: +# +# The result format for 'query-colo-status'. +# +# @mode: which COLO mode the VM was in when it exited. +# true is primary mode, false is secondary mode. +# +# @colo_running: if true means COLO running well, otherwise COLO have done. +# +# @reason: describes the reason for the COLO exit. +# true is error, false is user request. +# +# Since: 2.12 +## +{ 'struct': 'COLOStatus', + 'data': { 'mode': 'bool', 'colo_running': 'bool', 'reason': 'bool' } } + +## +# @query-colo-status: +# +# Query COLO status while the vm is running. +# +# Returns: A @COLOStatus object showing the status. +# +# Example: +# +# -> { "execute": "query-colo-status" } +# <- { "return": { "colo_running": "true", "mode": "true", "reason": "true" } } +# +# Since: 2.12 +## +{ 'command': 'query-colo-status', + 'returns': 'COLOStatus' }
Libvirt or other high level sofware can use this command query colo status. You can test this command like that: {'execute':'query-colo-status'} Signed-off-by: Zhang Chen <zhangckid@gmail.com> --- migration/colo.c | 35 +++++++++++++++++++++++++++++++++++ qapi/migration.json | 35 +++++++++++++++++++++++++++++++++++ 2 files changed, 70 insertions(+)