qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 4/4] qapi: Convert migrate


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 4/4] qapi: Convert migrate
Date: Fri, 09 Mar 2012 11:26:53 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

On 03/09/2012 11:13 AM, Luiz Capitulino wrote:
> The migrate command is one of those commands where HMP and QMP completely
> mix up together. This made the conversion to the QAPI (which separates the
> command into QMP and HMP parts) a bit difficult.
> 
> The first important change to be noticed is that this commit completes the
> removal of the Monitor object from migration code, started by the previous
> commit.
> 
> Another important and tricky change is about supporting the non-detached
> mode. That's, if the user doesn't pass '-d' the migrate command will lock

As a native speaker, I can state that it is unusual or even wrong to see
a contraction immediately before a comma.  I would do:

s/That's,/That is,/

> the monitor and will only release it when migration is finished.
> 
> To support that in the new HMP command (hmp_migrate()), it is necessary
> to create a timer which runs every second and checks if the migration is
> still active. If it's, the timer callback will re-schedule itself to run

Another instance of the same grammar problem:

s/it's/it is/

> one second in the future. If the migration has already finished, the
> monitor lock is relased and the user can use it normally.

s/relased/released/

> 
> All these changes should be transparent to the user.
> 

> +++ b/qapi-schema.json
> @@ -1631,3 +1631,24 @@
>  { 'command': 'qom-list-types',
>    'data': { '*implements': 'str', '*abstract': 'bool' },
>    'returns': [ 'ObjectTypeInfo' ] }
> +
> +##
> +# @migrate
> +#
> +# Migrates the current running guest to another Virtual Machine.
> +#
> +# @uri: the Uniform Resource Identifier of the destination VM
> +#
> +# @blk: #optional do block migration (full disk copy)
> +#
> +# @inc: #optional incremental disk copy migration
> +#
> +# @detach: this argument exists only for compatibility reasons and should not
> +#          be used.

Libvirt is currently using it, but it appears that libvirt always sets
it to true.  Does this mean the argument is ignored no matter whether
you pass true or false?  Or does this value have a default if omitted,
and it is safe to explicitly pass the default (I assume the default is
true), and that it is wrong to pass an explicit value that contradicts
the default (that is, I'm assuming passing an explicit 'detach':'false'
is wrong)?

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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