Zhang Chen <zhangchen.f...@cn.fujitsu.com> writes:
> We can call this qmp command to do checkpoint outside of qemu.
> Xen colo will need this function.
I know nothing about "Xen colo", but I'll try anyway.
I *guess* "Xen colo" is a long-running activity, and the new commands
interact with it. Correct?
>
> Signed-off-by: Zhang Chen <zhangchen.f...@cn.fujitsu.com>
> Signed-off-by: Wen Congyang <wencongy...@gmail.com>
> ---
> migration/colo.c | 17 ++++++++++++++++
> qapi-schema.json | 60
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 77 insertions(+)
>
> diff --git a/migration/colo.c b/migration/colo.c
> index 6fc2ade..2f98a33 100644
> --- a/migration/colo.c
> +++ b/migration/colo.c
> @@ -127,6 +127,23 @@ void qmp_xen_set_replication(bool enable, bool primary,
> }
> }
>
> +ReplicationResult *qmp_query_xen_replication_status(Error **errp)
> +{
> + Error *err = NULL;
> + ReplicationResult *result = g_new0(ReplicationResult, 1);
> + replication_get_error_all(&err);
> + result->status = err ?
> + REPLICATION_STATUS_ERROR :
> + REPLICATION_STATUS_NORMAL;
Reports only that there is an error, throws away the actual error
message. Naive question: could the error message be good to know for
the QMP user?
> + error_free(err);
> + return result;
> +}
> +
> +void qmp_xen_do_checkpoint(Error **errp)
> +{
> + replication_do_checkpoint_all(errp);
> +}
> +
> static void colo_send_message(QEMUFile *f, COLOMessage msg,
> Error **errp)
> {
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 9445b93..719744a 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -5931,6 +5931,66 @@
> 'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' } }
>
> ##
> +# @ReplicationStatus:
> +#
> +# Describe the status of replication.
> +#
> +# @error: Replication has an error.
> +#
> +# @normal: Replication is running normally.
> +#
> +# Since: 2.9
> +##
> +{ 'enum': 'ReplicationStatus',
> + 'data': [ 'error', 'normal' ] }
Do you expect more status values in the future?
If yes, what should clients do when they see a status value they don't
know?
If no, why not simply use bool?
> +
> +##
> +# @ReplicationResult:
> +#
> +# The result format for 'query-xen-replication-status'.
> +#
> +# @status: enum of @ReplicationStatus, which shows current
> +# replication error status
> +#
> +# Since: 2.9
> +##
> +{ 'struct': 'ReplicationResult',
> + 'data': { 'status': 'ReplicationStatus'} }
> +
> +##
> +# @query-xen-replication-status:
> +#
> +# Query replication status while the vm is running.
> +#
> +# Returns: A @ReplicationResult objects showing the status.
> +#
> +# Example:
> +#
> +# -> { "execute": "query-xen-replication-status" }
> +# <- { "return": { "status": "normal" } }
> +#
> +# Since: 2.9
> +##
> +{ 'command': 'query-xen-replication-status',
> + 'returns': 'ReplicationResult' }
The naming is a bit unfortunate: query-xen-replication-status returns
ReplicationResult, which contains ReplicationStatus.
> +
> +##
> +# @xen-do-checkpoint:
> +#
> +# Xen uses this command to notify replication to trigger a checkpoint.
> +#
> +# Returns: nothing.
> +#
> +# Example:
> +#
> +# -> { "execute": "xen-do-checkpoint" }
> +# <- { "return": {} }
> +#
> +# Since: 2.9
> +##
> +{ 'command': 'xen-do-checkpoint' }
> +
> +##
> # @GICCapability:
> #
> # The struct describes capability for a specific GIC (Generic
