qemu-devel
[Top][All Lists]
Advanced

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

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


From: Michael Roth
Subject: Re: [Qemu-devel] [PATCH 6/6] qapi: Convert migrate
Date: Wed, 15 Feb 2012 10:01:22 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Feb 15, 2012 at 02:25:49PM +0100, Juan Quintela wrote:
> Luiz Capitulino <address@hidden> 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
> > the monitor and will only release it when migration is finished.
> >
> > To support that in the new HMP command (hmp_migrate()), it was 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
> > one second in the future. If the migration has already finished, the
> > monitor lock is relased and the user can use it normally.
> >
> > All these changes should be transparent to the user.
> 
> > +static void hmp_migrate_status_cb(void *opaque)
> > +{
> > +    MigrationStatus *status = opaque;
> > +    MigrationInfo *info;
> > +
> > +    info = qmp_query_migrate(NULL);
> > +    if (!info->has_status || strcmp(info->status, "active") == 0) {
> > +        qemu_mod_timer(status->timer, qemu_get_clock_ms(rt_clock) +
> > 1000);
> 
> 1 second is one eternity.  I will ask for something smaller (100ms or
> 200ms range).
> 
> > +    qmp_migrate(uri, !!blk, blk, !!inc, inc, false, false, &err);
> 
> This is the only user of qmp_migrate, why do we need to pass both
> has_blk & blk (and inc and !!inc?)  Both parameters are bool, I am
> really confused here.

QAPI-generated qmp_marshal_input_migrate() is another user, and we don't
want to decide the defaults for incoming/blk there, so we need some way
to tell qmp_migrate() whether or not the bools we pass should be
ignored, or whether they were explicitly defined by the qmp user.

It looks weird in this particular case, but other than having multiple
variants of the qmp_migrate() command it's the only way to avoid having
randomly/un- initialized values clobber the defaults expected by the user.

> 
> Later, Juan.
> 



reply via email to

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