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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Fri, 09 Mar 2012 11:26:53 -0700
Eric Blake <eblake@redhat.com> wrote:

> 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:

Oh, that rule is new to me. Thanks for letting me know!

> 
> 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)?

'detach' is completely ignored in QMP, it's never read.