qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V7 2/2] Add a new qmp command to do checkpoint,


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH V7 2/2] Add a new qmp command to do checkpoint, query xen replication status
Date: Tue, 21 Feb 2017 12:15:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Zhang Chen <address@hidden> 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 <address@hidden>
> Signed-off-by: Wen Congyang <address@hidden>
> ---
>  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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]